GitLab CI/CD를 통한 점진적 롤아웃
애플리케이션의 변경 사항을 롤아웃할 때 위험 완화 전략으로 쿠버네티스 파드의 일부에만 프로덕션 변경 사항을 배포하는 것이 가능합니다. 프로덕션 변경 사항을 점진적으로 배포함으로써 오류율 또는 성능 저하를 모니터링하고 문제가 없는 경우, 모든 파드를 업데이트할 수 있습니다.
GitLab은 쿠버네티스 프로덕션 시스템으로의 점진적 롤아웃을 수동으로 트리거하거나 시간별로 지원합니다. 수동 롤아웃의 경우 각 파드 트랜치의 릴리스가 수동으로 트리거되는 반면, 타이머를 사용한 롤아웃은 5분의 기본 일시 정지 후에 단계별로 릴리스됩니다. 타이머를 사용한 롤아웃은 일시 정지 기간이 종료되기 전에 수동으로 트리거될 수도 있습니다.
수동 및 타이머를 사용한 롤아웃은 Auto DevOps로 제어되는 프로젝트에 자동으로 포함되지만, .gitlab-ci.yml 구성 파일에서도 구성할 수 있습니다.
수동으로 트리거된 롤아웃은 지속적 제공(CD)으로 구현할 수 있으며, 타임드 롤아웃은 개입을 필요로하지 않으며 연속적 배포(CD) 전략의 일부가 될 수 있습니다. 필요한 경우 수동 개입하여 앱이 자동으로 배포되도록 설정할 수도 있습니다.
이 세 가지 옵션을 보여주기 위해 샘플 애플리케이션을 만들었으며, 여기서 직접 구축할 수 있습니다:
수동 롤아웃
GitLab은 .gitlab-ci.yml을 통해 수동으로 점진적 롤아웃을 구성할 수 있습니다. 수동 구성을 통해 이 기능에 대한 더 많은 제어권을 행사할 수 있습니다. 점진적 롤아웃의 단계는 쿠버네티스 클러스터가 생성될 때 정의된 배포용 파드 수에 의존합니다.
예를 들어, 애플리케이션이 10개의 파드를 보유하고 10%의 롤아웃 작업을 실행한 경우 새 애플리케이션 인스턴스는 단일 파드에 배포되며 나머지 파드는 이전 애플리케이션 인스턴스를 보여줍니다.
먼저 .manual_rollout_template으로 템플릿을 정의:
.manual_rollout_template: &manual_rollout_template
<<: *rollout_template
stage: production
when: manual
그런 다음 각 단계에 대한 롤아웃 양을 정의:
rollout 10%:
<<: *manual_rollout_template
variables:
ROLLOUT_PERCENTAGE: 10
작업이 빌드된 후에 각 스테이지의 파드를 실행하기 위해 작업 이름 옆의 실행()을 선택할 수 있습니다. 낮은 퍼센트 작업을 실행하여 롤백할 수도 있습니다. 100%에 도달하면 이 방법으로 롤백할 수 없습니다. 배포를 되돌리려면 배포 다시 시도 또는 롤백을 참조하세요.
수동으로 트리거된 점진적 롤아웃을 보여주는 배포 가능한 애플리케이션이 있습니다.
타임드 롤아웃
타임드 롤아웃은 수동 롤아웃과 동일한 방식으로 작동하지만 각 작업은 배포 전에 지연 시간을 정의합니다. 작업을 선택하면 카운트다운이 표시됩니다.
이 기능을 수동으로 트리거된 점진적 롤아웃과 결합하여 작업이 카운트다운한 다음 배포되게 할 수 있습니다.
먼저 .timed_rollout_template으로 템플릿을 정의:
.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
타임드 롤아웃을 구성하는 .gitlab-ci.yml CI/CD 구성 파일을 보여주는 파일과 실행 가능한 애플리케이션이 있습니다.
블루-그린 배포
참고: 팀은 여기에 문서화된 블루-그린 배포 전략 대신 인그레스 주석 및 트래픽 가중치 설정을 활용할 수 있습니다.
때로는 A/B 배포 또는 레드-블랙 배포로도 알려진 이 기법은 배포 중에 발생하는 다운타임과 위험을 줄이기 위해 사용됩니다. 점진적 롤아웃과 결합하여 배포의 영향을 최소화할 수 있습니다.
이 기법은 “블루”와 “그린”이라는 두 가지 배포로 구성됩니다(다만, 임의의 이름을 사용할 수 있습니다). 이러한 배포 중 하나만 실시되며, 점진적 롤아웃 중에만 둘 다 활성화됩니다.
예를 들어 블루 배포는 프로덕션에서 활성화되고, 그린 배포는 테스트를 위해 “라이브”되지만 프로덕션에는 배포되지 않을 수 있습니다. 문제가 발견되면 그린 배포를 업데이트할 수 있으며 이는 현재 프로덕션 배포에 영향을 미치지 않습니다(현재 블루). 테스트에서 문제가 발견되지 않으면 프로덕션을 그린 배포로 전환하고, 블루는 다음 릴리스를 테스트할 수 있습니다.
이 프로세스는 프로덕션 배포를 다른 배포로 전환하기 위해 프로덕션 배포를 내리지 않아도 되므로 다운타임을 줄입니다. 두 배포는 병행하여 실행되며 언제든지 전환할 수 있습니다.
.gitlab-ci.yml CI/CD 구성 파일로 블루-그린 배포를 보여주는 실행 가능한 애플리케이션도 있습니다.
도움말