카나리 배포

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

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