[Nginx + Tomcat] 무중단 배포 구현하기

개요

기존의 1 machine = 1 WAS Instance 구조로

소스 패치시 해당 머신을 서비스에 사용하지 못하던 부분을 해소하고

자동 배포를 구현하기 위해 고안된 구조입니다.

In the before as 1 machine = 1 WAS Instance structure,

When patching a source, it is possible to solve a situation where the machine can not be used for a service,

It is for structure designed to implement automatic deployment.

그림에서 보이는 바와 같이, 

기존의 하나의 머신은 하나의 Nginx와 두개의 Tomcat Instance를 가집니다.

Nginx의 Reverse Proxy를 통해 두개의 Tomcat Instance를 각기 다른 포트와 서브도메인으로 연결하고

두 서브 도메인중 하나는 배포 전용 도메인, 또하나는 서비스 전용 도메인으로 설정합니다.

As shown in the picture above,

One machine has one Nginx and two Tomcat Instances.

Nginx's Reverse Proxy connects two Tomcat instances to different ports and subdomains

One of the two subdomains is set to a deployment-only domain and the other to a service-only domain.

현재 서비스중인 포트를 반환하는 간단한 API를 어플리케이션에 추가하고

이를 통해 배포 직전에 현재 서비스 전용 도메인을 호출하여 가동중인 인스턴스를 확인합니다.

이후 IDLE 인스턴스에 배포하고, 문제가 없는지 Health체크 후, 

Nginx의 설정을 통해 두 인스턴스의 도메인을 서로 Switching합니다.

이후 Nginx를 다시로드하여 서비스를 지속합니다.

Add a simple API to your application that returns the currently serving port

This identifies the running instance by calling the current service-only domain just before deployment.

After that, deploy to the IDLE instance,

Switch the domains of two instances to each other through the setting of Nginx.

Then reload Nginx to continue the service.

바뀐 IDLE Instance는 예전버전을 가지고 있어, 

혹시 테스트되지 않은 문제가 발생 할 경우 

Nginx의 설정 변경을 통해 원복 시킬 수 있습니다.

The changed IDLE Instance has an older version,

If you have any untested issues

You can rollback the settings of Nginx.

무중단 배포 서비스의 핵심은 충분히 리뷰되고, 

테스트된 코드들이 메인 브런치에 Push되었을때,

서비스에 영향을 최소화하면서 지속적인 빌드와 배포를 하는 것입니다.

이를 통해 개발자는 배포에 부담이 없이 개발에 집중을 할 수 있고, 코드 퀄리티에 신경을 쓸 수 있게됩니다.

무엇보다 정기적인 패치작업 없이 어플리케이션의 업데이트가 가능해지게 됩니다.

The core of nonstop deployment services is being thoroughly reviewed,

When the tested code is pushed to the main brunch,

To build and deploy on a continuous basis with minimal impact on service.

it can be developers to concentrate on development without worrying about deployment, and be able to focus on code quality.

Above all, you will be able to update your application without regular patching.

이 구조에서 주의해야할 점은

패치의 경중에 따라 배포가 서비스에 영향을 받지 않도록 해야합니다.

(*DB의 구조를 변경시키는 JPA와 같은 기술이 사용된 프로젝트)

이를 위해 코드 리뷰를 통해 패치의 경중을 확인하고, 

배포시기를 조율하는 것이 반드시 필요합니다.

In this structure,

Depending on the severity of the patch, you should make sure that your deployment is not affected by the service.

(* Projects using techniques such as JPA that change the structure of the DB)

To do this, we check the patch severity through code review,

It is essential to coordinate the timing of deployment.