GitLab CI/CD를 활용한 점진적 배포
애플리케이션 변경 사항을 롤아웃할 때 위험 완화 전략으로 쿠버네티스 pod의 일부에만 프로덕션 변경 사항을 배포하는 것이 가능합니다. 점진적인 프로덕션 변경 사항을 배포함으로써 에러율이나 성능 저하를 모니터링하고, 문제가 없는 경우에만 모든 pod가 업데이트될 수 있습니다.
GitLab은 점진적 롤아웃을 통해 수동으로 트리거하거나 타임드된 롤아웃을 지원하여 쿠버네티스 프로덕션 시스템에 변경 사항을 배포할 수 있습니다. 매뉴얼 롤아웃을 사용할 경우 각 pod의 릴리스는 수동으로 트리거되며, 타임드 롤아웃을 사용할 경우 기본 일시 정지 후 일부 릴리스가 순차적으로 이루어집니다. 일시 정지 기간이 만료되기 전에 타임드 롤아웃을 수동으로 트리거할 수도 있습니다.
자동 DevOps로 제어되는 프로젝트에는 자동 및 타임드 롤아웃이 자동으로 포함되지만, .gitlab-ci.yml 구성 파일에서 또한 구성할 수 있습니다.
수동으로 트리거된 롤아웃은 지속적 전달로 구현할 수 있으며, 타임드된 롤아웃은 개입이 필요하지 않으며 지속적 배포 전략의 일부가 될 수 있습니다. 이 둘을 결합하여 앱이 자동으로 배포되고, 필요할 경우 매뉴얼으로 개입할 수도 있습니다.
세 가지 옵션을 설명하는 샘플 응용 프로그램을 만들어볼 수 있습니다.
매뉴얼 롤아웃
GitLab을 설정하여 .gitlab-ci.yml을 통해 점진적인 롤아웃을 매뉴얼으로 할 수 있습니다. 매뉴얼 구성을 통해 이 기능을 더욱 세밀하게 제어할 수 있습니다. 점진적 롤아웃의 단계는 쿠버네티스 클러스터를 생성할 때 정의된 배포용 pod의 수에 따라 달라집니다.
예를 들어, 애플리케이션이 10개의 pod를 가지고 있고 10%의 롤아웃 작업이 실행된 경우, 애플리케이션의 새로운 인스턴스는 단일 pod로 배포되며, 나머지 pod는 이전 애플리케이션의 인스턴스를 표시합니다.
우선, 매뉴얼으로 템플릿을 정의합니다:
.manual_rollout_template: &manual_rollout_template
<<: *rollout_template
stage: production
when: manual
다음으로, 각 단계별 롤아웃 양을 정의합니다:
rollout 10%:
<<: *manual_rollout_template
variables:
ROLLOUT_PERCENTAGE: 10
작업이 만들어지면 작업 이름 옆에 play 버튼이 나타납니다. 각 단계의 pod를 릴리스하려면 play를 선택하면 됩니다. 또한 더 낮은 백분율 작업을 실행하여 롤백할 수도 있습니다. 100%에 도달하면 이 방법으로 롤백할 수 없지만, 환경 페이지의 Rollback 버튼을 사용하여 이전 버전을 재배포하는 것은 여전히 가능합니다.
수동으로 트리거된 점진적 롤아웃을 이미 구현한 배포 가능한 애플리케이션을 살펴볼 수 있습니다.
타임드 롤아웃
타임드 롤아웃은 매뉴얼 롤아웃과 동일하게 동작하지만, 각 작업은 배포 전에 지연 시간을 분으로 정의합니다. 작업을 선택하면 카운트다운이 나타납니다.
이 기능은 타임드된 점진적 롤아웃을 사용하여 작업이 카운트다운된 후 배포하도록 조합할 수 있습니다.
먼저, 템플릿을 타임드로 정의합니다:
.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 구성 파일을 통해 확인할 수 있습니다.
도움말