가동 중지 시간 없는 배포: 블루-그린 기술로 Docker화된 앱 업그레이드

한 달 전에 제가 쓴 기사 에서 저는 Python 웹 애플리케이션을 프로덕션(또는 사전 개발/스테이징) 환경에 지속적으로 배포하는 방법에 대해 이야기했습니다.

저는 최근 두 목소리를 일치시키고 둘 다 일치하는지 아닌지 예측 점수를 제공하는 마이크로서비스(Python 및 FastAPI 사용)를 구축하는 임무를 받았습니다. 이해관계자들이 음성 잠금 해제 기능을 요청했습니다.

우리는 엔지니어링 회의를 했고, 제가 그 일을 맡으려고 일어섰습니다(아니면 제 리더가 대신 나섰습니다, 하하).

저는 이전에 ML 모델을 사용해 본 적이 없기 때문에(훈련이든 아니든) 흥미로운 작업이었습니다. 코드를 설계하고 구축하여 AWS EC2 인스턴스로 배송하는 데 일주일이 걸렸습니다. 저는 CI/CD의 열렬한 팬이므로 가장 편한 GitHub Actions를 사용했습니다.

일주일 후… 변경이 요청되었고, 제가 연구하던 새로운 [배포] 기술을 시험해보고 싶었습니다. 재배포할 때 가동 중지 시간이 발생하지 않도록 하려면 AWS EC2 인스턴스에서 정상적으로 실행되는 도커화된 마이크로서비스 애플리케이션이 필요했습니다.

그리고 나는 내 소매에 완벽한 트릭을 가지고있었습니다.

그 비결은 바로 청록색 기술 입니다.

블루/그린 배포에 관한 AWS 백서에 따르면 이는 두 개의 별개이지만 동일한 환경을 생성하는 배포 전략입니다.

한 환경(파란색)은 현재 애플리케이션 버전을 실행하고 있고, 다른 환경(녹색)은 새 애플리케이션 버전을 실행하고 있습니다. 블루/그린 배포 전략을 사용하면 배포가 실패할 경우 롤백 프로세스를 단순화하여 애플리케이션 가용성을 높이고 배포 위험을 줄일 수 있습니다.

그린 환경에서 테스트가 완료되면 라이브 애플리케이션 트래픽이 그린 환경으로 전달되고 블루 환경은 더 이상 사용되지 않습니다.

간단히 말해서 블루/그린 배포 기술은 두 개의 동일한 프로덕션 환경을 실행하여 가동 중지 시간과 위험을 줄이는 방법입니다.

이러한 배포 기술을 처음 듣는 경우 전혀 두려워할 것이 없습니다. 청록색 배포를 달성하는 데 도움이 되는 자세한 단계를 알려 드리겠습니다.

다음 단계로 바로 들어가겠습니다.

1. 업데이트된 코드로 새 Docker 이미지를 빌드하고 새 버전 번호로 태그를 지정하세요.

   
   

 $ docker build -t myexample:v2 .

그러면 현재 디렉터리의 Dockerfile 사용하여 myexample:v2 태그가 있는 새 Docker 이미지가 생성됩니다.

여기서 myexample:v2 는 새로 빌드된 Docker 이미지의 이름입니다. 제 경우에는 ML 프로젝트의 이름이었습니다. 예: docker build -t companyx-servicename-backend:v2

2. 새 이미지에서 새 Docker 컨테이너를 시작하되 아직 외부에 노출하지 마세요.

   
   

 $ docker run -d --name myexample-v2 myexample:v2

그러면 myexample:v2 이미지에서 myexample-v2 라는 이름의 새 Docker 컨테이너가 시작됩니다.

3. 새 컨테이너가 시작되고 초기화될 때까지 기다려서 제대로 작동하는지 확인하세요.

   
   

 $ docker logs myexample-v2

dockerlogs 명령을 사용하여 새 컨테이너의 로그를 확인하여 제대로 시작되고 초기화되었는지 확인하세요.

4. NGINX와 같은 역방향 프록시를 사용하여 이전 컨테이너와 새 컨테이너 모두로 트래픽을 라우팅합니다. 요청을 수신하도록 역방향 프록시를 구성하고 이를 이전 컨테이너와 새 컨테이너 모두에 전달합니다. 이렇게 하면 트래픽을 점차적으로 새 컨테이너로 이동할 수 있습니다.

다음은 두 개의 컨테이너를 라우팅하는 NGINX 구성의 예입니다.

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

이 구성은 myexample-v1 및 myexample-v2 라는 두 개의 서버가 있는 myexample이라는 업스트림 그룹을 설정합니다. backup 키워드는 두 번째 서버를 백업으로 표시하는 데 사용됩니다. proxy_pass 지시문은 요청을 myexample 업스트림 그룹으로 전달하는 데 사용됩니다.

애플리케이션의 이름과 포트를 반영하도록 역방향 프록시 구성을 업데이트해야 합니다.

5. 역방향 프록시 구성을 조정하여 트래픽을 이전 컨테이너에서 새 컨테이너로 점진적으로 이동합니다.

   
   

트래픽을 새 컨테이너로 이동하려면 역방향 프록시 구성을 조정하여 새 컨테이너에 더 많은 가중치를 부여합니다. 이는 server 지시문에서 backup 키워드를 제거하여 수행할 수 있습니다:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

이로 인해 NGINX는 myexample-v2 컨테이너에 더 많은 요청을 보냅니다. 애플리케이션을 모니터링하고 모든 트래픽이 새 컨테이너로 흐를 때까지 필요에 따라 구성을 조정합니다.

6. 모든 트래픽이 새 컨테이너로 이동되면 이전 컨테이너를 안전하게 중지하고 제거할 수 있습니다.

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

그러면 이전 컨테이너가 중지되고 제거되어 서버의 리소스가 확보됩니다.

결론

저는 이 기술을 처음 접했고 당연히 그것에 대해 아는 바가 많지 않습니다. 그러나 나는 그 장단점과 더 잘 작동할 수 있는 다른 기술에 대해 계속해서 배울 것입니다. 저와 공유하고 싶은 비결이 한두 가지 있으신가요?

감사하겠습니다. (댓글 섹션에) 제가 드리겠습니다.

오, 오. 내 지루한 뉴스레터를 구독하는 것을 잊지 마세요. 저는 1분기부터 많은 것을 배웠으며 곧 공유할 예정입니다. 챠오.