카나리 배포

카나리 배포에 대해 설명합니다.

카나리 배포는 인기 있는 지속적 배포 전략으로, 플릿의 일부가 애플리케이션의 새 버전으로 업데이트됩니다. 지속적 배포 를 채택할 때 조직은 어떤 유형의 배포 전략을 사용할지 결정해야 합니다. 가장 인기 있는 전략 중 하나는 카나리 배포로, 플릿의 일부가 먼저 새 버전으로 업데이트됩니다. 이 서브셋인 카나리는 비유적인 탄광의 카나리아 역할을 합니다. 새 버전의 애플리케이션에 문제가 있는 경우 소수의 사용자만 영향을 받으며 변경 사항을 수정하거나 빠르게 되돌릴 수 있습니다. 사용 사례 # 카나리 배포는 임시로 배포된 기능을 방문하는 사용자 기반의 일부를 모니터링하면서 일부 포드 플릿에만 기능을 제공하려는 경우에 사용할 수 있습니다. 모든 것이 잘 작동하면 기능을 프로덕션에 배포해도 문제가 없다는 것을 알고 배포할 수 있습니다. 카나리 배포는 사용자 인터페이스는 변경되지 않지만 성능이 동일하게 유지되거나 개선되는지 확인하려는 백엔드 리팩토링, 성능 개선 또는 기타 변경 사항에도 특히 필요합니다. 개발자는 사용자 인터페이스 변경 사항에 카나리를 사용할 때 주의해야 합니다. 기본적으로 동일한 사용자의 요청이 카나리와 비카나리 포드 사이에 무작위로 분산되어 혼란이나 오류가 발생할 수 있기 때문입니다. 필요한 경우 Kubernetes 서비스 정의에서 service.spec.sessionAffinity 를 ClientIP 로 설정 하는 것을 고려할 수 있지만, 이는 이 문서의 범위를 벗어납니다. Canary Ingress를 사용한 고급 트래픽 제어 # 카나리 배포는 가중치, 세션, 쿠키 등의 요인에 따라 안정적인 배포와 카나리 배포 사이의 들어오는 HTTP 요청을 제어하는 고급 트래픽 라우팅 서비스인 Canary Ingress 를 사용하면 더 전략적으로 활용할 수 있습니다. GitLab은 사용자가 새로운 배포를 빠르고 안전하게 배포할 수 있도록 Auto Deploy 아키텍처 에서 이 서비스를 사용합니다. 카나리 배포에서 Canary Ingress를 설정하는 방법 # Auto DevOps 파이프라인이 v2.0.0+ 의 auto-deploy-image 를 사용하는 경우 Canary Ingress가 기본적으로 설치됩니다. Canary Ingress는 새 카나리 배포를 만들 때 사용할 수 있게 되며 카나리 배포가 프로덕션으로 승격될 때 삭제됩니다. 처음부터 설정하는 예시는 다음과 같습니다: Auto DevOps가 활성화된 프로젝트를 준비합니다. 프로젝트에 Kubernetes 클러스터 를 설정합니다. 클러스터에 NGINX Ingress 를 설치합니다. 위에서 할당된 Ingress 엔드포인트를 기반으로 기본 도메인 을 설정합니다. Auto DevOps 파이프라인에서 v2.0.0+ 의 auto-deploy-image 가 사용되는지 확인 합니다. 사용되지 않으면 설명서에 따라 이미지 버전을 지정합니다. 새 Auto DevOps 파이프라인을 실행 하고 production job이 성공하고 프로덕션 환경이 생성되는지 확인합니다. Auto DevOps 파이프라인에 대한