애플리케이션에 변경 사항을 롤아웃할 때, 위험 완화 전략으로 Kubernetes 파드의 일부에만 프로덕션 변경 사항을 릴리스할 수 있습니다. 프로덕션 변경 사항을 점진적으로 릴리스함으로써 오류율 또는 성능 저하를 모니터링할 수 있으며, 문제가 없으면 모든 파드를 업데이트할 수 있습니다.

GitLab은 점진적 롤아웃을 사용하여 Kubernetes 프로덕션 시스템에 수동 트리거 및 타이머 롤아웃을 모두 지원합니다. 수동 롤아웃을 사용할 때는 각 파드 트랜치의 릴리스가 수동으로 트리거됩니다. 타이머 롤아웃을 사용하면 기본 5분의 일시 중지 후 트랜치 단위로 릴리스가 수행됩니다. 타이머 롤아웃은 일시 중지 기간이 만료되기 전에도 수동으로 트리거할 수 있습니다.

수동 및 타이머 롤아웃은 Auto DevOps가 관리하는 프로젝트에 자동으로 포함되지만, .gitlab-ci.yml 구성 파일에서 GitLab CI/CD를 통해 구성할 수도 있습니다.

수동으로 트리거되는 롤아웃은 지속적 배포로 구현할 수 있으며, 타이머 롤아웃은 개입이 필요하지 않아 지속적 배포 전략의 일부가 될 수 있습니다. 필요한 경우 수동으로 개입하지 않는 한 앱이 자동으로 배포되는 방식으로 두 가지를 결합할 수도 있습니다.

다음 샘플 애플리케이션은 세 가지 옵션을 보여줍니다. 이를 자신만의 것을 만들기 위한 예시로 사용할 수 있습니다:

• 수동 점진적 롤아웃
• 타이머 점진적 롤아웃
• 수동 및 타이머 롤아웃 모두

수동 롤아웃#

.gitlab-ci.yml을 통해 GitLab이 수동으로 점진적 롤아웃을 수행하도록 구성할 수 있습니다. 수동 구성은 이 기능에 대한 더 많은 제어를 허용합니다. 점진적 롤아웃의 단계는 배포에 대해 정의된 파드 수에 따라 달라지며, 이는 Kubernetes 클러스터가 생성될 때 구성됩니다.

예를 들어, 애플리케이션에 10개의 파드가 있고 10% 롤아웃 job이 실행되면 새 애플리케이션 인스턴스가 단일 파드에 배포되고 나머지 파드는 이전 인스턴스를 표시합니다.

먼저 템플릿을 수동으로 정의합니다:

.manual_rollout_template: &manual_rollout_template
  <<: *rollout_template
  stage: production
  when: manual

다음으로 각 단계의 롤아웃 양을 정의합니다:

rollout 10%:
  <<: *manual_rollout_template
  variables:
    ROLLOUT_PERCENTAGE: 10

job이 빌드된 후 job 이름 옆의 실행([play])을 선택하여 각 파드 단계를 릴리스합니다. 더 낮은 비율 job을 실행하여 롤백할 수도 있습니다. 100%에 도달하면 이 방법으로 롤백할 수 없습니다. 배포를 롤백하려면 배포 재시도 또는 롤백을 참조하세요.

수동으로 트리거되는 점진적 롤아웃을 보여주는 배포 가능한 애플리케이션이 있습니다.

타이머 롤아웃#

타이머 롤아웃은 각 job이 배포되기 전 지연 시간(분)으로 정의된다는 점을 제외하고 수동 롤아웃과 동일하게 작동합니다. job을 선택하면 카운트다운이 표시됩니다.

이 기능을 수동 점진적 롤아웃과 결합하여 job이 카운트다운 후 배포되도록 할 수 있습니다.

먼저 템플릿을 타이머로 정의합니다:

.timed_rollout_template: &timed_rollout_template
  <<: *rollout_template
  when: delayed
  start_in: 1 minutes

start_in 키를 사용하여 지연 기간을 정의할 수 있습니다:

start_in: 1 minutes

다음으로 각 단계의 롤아웃 양을 정의합니다:

timed rollout 30%:
  <<: *timed_rollout_template
  stage: timed rollout 30%
  variables:
    ROLLOUT_PERCENTAGE: 30

타이머 롤아웃 구성을 보여주는 배포 가능한 애플리케이션이 있습니다.

Blue-Green 배포#

A/B 배포 또는 레드-블랙 배포라고도 불리는 이 기술은 배포 중 다운타임과 위험을 줄이기 위해 사용됩니다. 점진적 롤아웃과 결합하면 배포로 인한 문제의 영향을 최소화할 수 있습니다.

이 기술에는 두 개의 배포가 있습니다("블루"와 "그린", 그러나 어떤 이름도 사용 가능합니다). 점진적 롤아웃 중을 제외하고 한 번에 이 배포 중 하나만 라이브입니다.

예를 들어, 블루 배포는 프로덕션에서 활성화되어 있고 그린 배포는 테스트용으로 "라이브"이지만 프로덕션에 배포되지 않을 수 있습니다. 문제가 발견되면 프로덕션 배포(현재 블루)에 영향을 주지 않고 그린 배포를 업데이트할 수 있습니다. 테스트에서 문제가 발견되지 않으면 프로덕션을 그린 배포로 전환하고 블루는 이제 다음 릴리스를 테스트하는 데 사용할 수 있습니다.

프로덕션 배포를 다운시키지 않고 다른 배포로 전환할 수 있으므로 이 프로세스는 다운타임을 줄입니다. 두 배포 모두 병렬로 실행 중이며 언제든지 전환할 수 있습니다.

블루-그린 배포를 보여주는 .gitlab-ci.yml CI/CD 구성 파일이 있는 예시 배포 가능한 애플리케이션이 있습니다.