한 달 전에 제가 쓴 에서 저는 Python 웹 애플리케이션을 프로덕션(또는 사전 개발/스테이징) 환경에 지속적으로 배포하는 방법에 대해 이야기했습니다. 기사 이전 문서를 참조하여 다른 언어로 애플리케이션을 배포할 수 있습니다. 워크플로 파일을 수정해야 합니다. 저는 최근 두 목소리를 일치시키고 둘 다 일치하는지 아닌지 예측 점수를 제공하는 마이크로서비스(Python 및 FastAPI 사용)를 구축하는 임무를 받았습니다. 이해관계자들이 음성 잠금 해제 기능을 요청했습니다. 우리는 엔지니어링 회의를 했고, 제가 그 일을 맡으려고 일어섰습니다(아니면 제 리더가 대신 나섰습니다, 하하). 저는 이전에 ML 모델을 사용해 본 적이 없기 때문에(훈련이든 아니든) 흥미로운 작업이었습니다. 코드를 설계하고 구축하여 AWS EC2 인스턴스로 배송하는 데 일주일이 걸렸습니다. 저는 CI/CD의 열렬한 팬이므로 가장 편한 GitHub Actions를 사용했습니다. 일주일 후… 변경이 요청되었고, 제가 연구하던 새로운 [배포] 기술을 시험해보고 싶었습니다. 재배포할 때 가동 중지 시간이 발생하지 않도록 하려면 AWS EC2 인스턴스에서 정상적으로 실행되는 도커화된 마이크로서비스 애플리케이션이 필요했습니다. 그리고 나는 내 소매에 완벽한 트릭을 가지고있었습니다. 그 비결은 바로 입니다. 청록색 기술 블루/그린 배포에 관한 AWS 백서에 따르면 이는 두 개의 별개이지만 동일한 환경을 생성하는 배포 전략입니다. 한 환경(파란색)은 현재 애플리케이션 버전을 실행하고 있고, 다른 환경(녹색)은 새 애플리케이션 버전을 실행하고 있습니다. 블루/그린 배포 전략을 사용하면 배포가 실패할 경우 롤백 프로세스를 단순화하여 애플리케이션 가용성을 높이고 배포 위험을 줄일 수 있습니다. 그린 환경에서 테스트가 완료되면 라이브 애플리케이션 트래픽이 그린 환경으로 전달되고 블루 환경은 더 이상 사용되지 않습니다. 간단히 말해서 블루/그린 배포 기술은 두 개의 동일한 프로덕션 환경을 실행하여 가동 중지 시간과 위험을 줄이는 방법입니다. 이러한 배포 기술을 처음 듣는 경우 전혀 두려워할 것이 없습니다. 청록색 배포를 달성하는 데 도움이 되는 자세한 단계를 알려 드리겠습니다. NDA 이유로 인해 회사를 위해 구축한 제품의 배포 단계를 진행하고 싶지 않으므로 예시 목적으로 가상의 제품을 사용하겠습니다. ㅋ. 다음 단계로 바로 들어가겠습니다. 업데이트된 코드로 새 Docker 이미지를 빌드하고 새 버전 번호로 태그를 지정하세요. $ docker build -t myexample:v2 . 그러면 현재 디렉터리의 사용하여 태그가 있는 새 Docker 이미지가 생성됩니다. Dockerfile myexample:v2 여기서 는 새로 빌드된 Docker 이미지의 이름입니다. 제 경우에는 ML 프로젝트의 이름이었습니다. 예: myexample:v2 docker build -t companyx-servicename-backend:v2 새 이미지에서 새 Docker 컨테이너를 시작하되 아직 외부에 노출하지 마세요. $ docker run -d --name myexample-v2 myexample:v2 그러면 이미지에서 라는 이름의 새 Docker 컨테이너가 시작됩니다. myexample:v2 myexample-v2 새 컨테이너가 시작되고 초기화될 때까지 기다려서 제대로 작동하는지 확인하세요. $ docker logs myexample-v2 dockerlogs 명령을 사용하여 새 컨테이너의 로그를 확인하여 제대로 시작되고 초기화되었는지 확인하세요. 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이라는 업스트림 그룹을 설정합니다. 키워드는 두 번째 서버를 백업으로 표시하는 데 사용됩니다. 지시문은 요청을 업스트림 그룹으로 전달하는 데 사용됩니다. myexample-v1 myexample-v2 backup proxy_pass myexample 애플리케이션의 이름과 포트를 반영하도록 역방향 프록시 구성을 업데이트해야 합니다. 역방향 프록시 구성을 조정하여 트래픽을 이전 컨테이너에서 새 컨테이너로 점진적으로 이동합니다. 트래픽을 새 컨테이너로 이동하려면 역방향 프록시 구성을 조정하여 새 컨테이너에 더 많은 가중치를 부여합니다. 이는 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 모든 트래픽이 새 컨테이너로 이동되면 이전 컨테이너를 안전하게 중지하고 제거할 수 있습니다. $ docker stop myexample-v1 $ docker rm myexample-v1 그러면 이전 컨테이너가 중지되고 제거되어 서버의 리소스가 확보됩니다. 결론 애플리케이션이 관계형 데이터베이스에 의존하는 경우 파란색-녹색 배포 전략으로 인해 업데이트 시 파란색 데이터베이스와 녹색 데이터베이스 간에 불일치가 발생할 수 있습니다. 최고 수준의 데이터 무결성을 보장하려면 이전 버전과 향후 버전 모두와 호환되는 통합 데이터베이스를 설정하는 것이 좋습니다. 저는 이 기술을 처음 접했고 당연히 그것에 대해 아는 바가 많지 않습니다. 그러나 나는 그 장단점과 더 잘 작동할 수 있는 다른 기술에 대해 계속해서 배울 것입니다. 저와 공유하고 싶은 비결이 한두 가지 있으신가요? 감사하겠습니다. (댓글 섹션에) 제가 드리겠습니다. 오, 오. 내 지루한 뉴스레터를 구독하는 것을 잊지 마세요. 저는 1분기부터 많은 것을 배웠으며 곧 공유할 예정입니다. 챠오.
