Canary deployments

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
History
  • Introduced in GitLab 9.1.
  • Moved from GitLab Premium to GitLab Free in 13.8.

Canary deployments는 인기 있는 연속 배포 전략으로, 플리트의 작은 부분이 응용 프로그램의 새 버전으로 업데이트됩니다.

연속적인 전달를 채택할 때 조직은 사용할 배포 전략을 결정해야 합니다. 가장 인기 있는 전략 중 하나인 Canary deployments에서는 지정된 플리트의 작은 부분이 가장 먼저 새 버전으로 업데이트됩니다. 이러한 하위 집합, 캐너리, 이후에는 말하자면 천부의 캐너리 역할을 합니다.

새 응용 프로그램 버전에 문제가 있으면 작은 비율의 사용자만 영향을 받고 변경 사항을 수정하거나 빠르게 되돌릴 수 있습니다.

사용 사례

Canary deployments는 기능을 팟 플릿의 일부분에만 전달하고 사용자 그룹의 일부가 일시적으로 배포된 기능을 방문하는 동안 그들의 동작을 관찰하고 싶을 때 사용할 수 있습니다. 모든 것이 잘 작동한다면 문제를 일으키지 않을 것으로 예상하고 해당 기능을 본격적으로 프로덕션에 배포할 수 있습니다.

Canary deployments는 또한 사용자 인터페이스가 변경되지 않지만 성능이 동일하게 유지되거나 개선되는지 확인하고 싶은 백엔드 리팩터링, 성능 향상 또는 기타 변경 사항에 특히 필요합니다. 사용자가 눈에 띄는 변화와 함께 캐너리를 사용할 때는 주의가 필요합니다. 기본적으로 동일한 사용자로부터의 요청은 캐너리와 비-캐너리 팟 사이에 무작위로 분산되므로 혼란 또는 오류가 발생할 수 있습니다. 필요한 경우 Kubernetes 서비스 정의에서 service.spec.sessionAffinity를 ClientIP로 설정하는 것이 좋습니다만, 이는 이 문서의 범위를 벗어납니다.

캐너리 Ingress를 사용한 고급 트래픽 제어

Canary deployments는 Canary Ingress로 전략적으로 더 확장할 수 있는데, 이는 안정적인 지속적인 HTTP 요청을 가리키며 안정적인 배포와 캐너리 배포 사이의 비율, 세션, 쿠키 등과 같은 요소를 기반으로 하는 고급 트래픽 라우팅 서비스입니다. GitLab은 사용자가 새로운 배포를 신속하고 안전하게 롤아웃할 수 있도록 Auto Deploy architecture에서 이 서비스를 사용합니다.

캐너리 배포에서 캐너리 Ingress 설정하기

자동 DevOps 파이프라인이 auto-deploy-image의 v2.0.0+를 사용하는 경우 캐너리 Ingress가 기본적으로 설치됩니다. 캐너리 배포를 생성하면 캐너리 Ingress가 사용 가능해지며 캐너리 배포가 프로덕션으로 승격되면 파기됩니다.

다음은 처음부터 예제 설정 흐름입니다:

  1. Auto DevOps-enabled 프로젝트를 준비합니다.
  2. 프로젝트에서 Kubernetes Cluster를 설정합니다.
  3. 클러스터에 NGINX Ingress를 설치합니다.
  4. Ingress Endpoint를 기준으로 the base domain을 설정합니다.
  5. Auto DevOps 파이프라인에서 auto-deploy-image의 v2.0.0+을 사용하는지 확인합니다. 그렇지 않은 경우 문서를 따라 이미지 버전을 지정합니다.
  6. 새 Auto DevOps 파이프라인을 실행하고 production 작업이 성공하고 프로덕션 환경이 생성되는지 확인합니다.
  7. Auto DevOps 파이프라인을 위한 canary deployment 작업을 구성합니다.
  8. 새 Auto DevOps 파이프라인을 실행하고 canary 작업이 성공하고 캐너리 Ingress가 있는 캐너리 배포가 생성되는지 확인합니다.

Canary Ingress 배포를 배포 보드에 표시(사용 중지됨)

경고: 이 기능은 GitLab 14.5에서 사용 중지되었습니다.

Canary 배포를 보려면 배포 보드를 올바르게 구성해야 합니다:

  1. 배포 보드 활성화 단계를 따르세요.
  2. Canary 배포를 추적하려면 Kubernetes 배포 및 pod에 track: canary 레이블을 지정해야 합니다. 빠르게 시작하려면 GitLab이 제공하는 자동 배포 템플릿을 사용할 수 있습니다.

배포에 따라 레이블은 stable 또는 canary 여야 합니다. 레이블이 비어 있거나 누락된 경우 GitLab은 트랙 레이블을 stable로 가정합니다. 다른 트랙 레이블은 canary(임시)로 간주됩니다. 이를 통해 GitLab은 배포가 안정적인지 또는 canary(임시)인지를 확인할 수 있습니다.

위의 모든 것을 설정하고 파이프라인이 적어도 한 번 실행된 후에는 파이프라인 > 환경 페이지로 이동하세요. 파이프라인이 실행되는 동안 배포 보드는 canary pod를 명확하게 표시하여 각 환경 및 배포의 상태를 신속하고 명확하게 확인할 수 있도록 합니다.

Canary 배포는 배포 보드에서 노란색 점으로 표시되어 빠르게 식별할 수 있습니다.

배포 보드의 Canary 배포

사용 중인 Canary Ingress의 현재 트래픽 가중치 확인 방법 (사용 중지됨)

경고: 이 기능은 GitLab 14.5에서 사용 중지되었습니다.

  1. 배포 보드를 방문하세요.

  2. 오른쪽에 있는 현재 가중치를 확인하세요.

    Rollout Status Canary Ingress

Canary Ingress의 트래픽 가중치 변경 방법 (사용 중지됨)

경고: 이 기능은 GitLab 14.5에서 사용 중지되었습니다.

환경의 배포 보드에서 GraphiQL을 사용하거나 GraphQL API에 요청을 보내어 트래픽 가중치를 변경할 수 있습니다.

배포 보드를 사용하려면:

  1. 프로젝트의 운영 > 환경으로 이동하세요.
  2. 오른쪽에 있는 드롭다운 목록으로 새로운 가중치를 설정하세요.
  3. 선택 사항을 확인하세요.

다음은 GraphiQL을 사용하는 예시입니다:

  1. GraphiQL Explorer를 방문하세요.

  2. environmentsCanaryIngressUpdate GraphQL 동작을 실행하세요: 

    mutation {
  environmentsCanaryIngressUpdate(input:{
    id: "gid://gitlab/Environment/29",              # 환경 ID입니다. 환경 페이지의 URL에서 ID를 가져올 수 있습니다.
    weight: 45                                      # 새 트래픽 가중치입니다. 예를 들어, `45`를 설정하면 전체 트래픽 중 45%가 canary 배포로 이동하고 55%가 안정적인 배포로 이동합니다.
  }) {
    errors
  }
}
  3. 요청이 성공하면 errors 응답에 빈 배열이 포함됩니다. GitLab은 Canary Ingress의 가중치 매개변수를 업데이트하기 위해 쿠버네티스 클러스터로 PATCH 요청을 보냅니다.