GitLab CI/CD를 활용한 점진적인 롤아웃
애플리케이션에 변경사항을 롤아웃할 때, 위험 완화 전략으로 Kubernetes pod의 일부에만 프로덕션 변경 사항을 출시하는 것이 가능합니다. 점진적인 프로덕션 변경을 통해 오류율 또는 성능 저하를 모니터링하고 문제가 없는 경우 모든 pod을 업데이트할 수 있습니다.
GitLab은 점진적인 롤아웃을 통해 Kubernetes 프로덕션 시스템으로 수동으로 트리거되거나 시간별로 롤아웃하는 것을 지원합니다. 매뉴얼 롤아웃을 사용하면 각 pod의 릴리스는 수동으로 트리거되며, 타이머 롤아웃을 사용하면 기본 일시 정지 후 단계별로 릴리스됩니다. 시간별 롤아웃은 일시 정지 기간이 만료되기 전에 수동으로 트리거할 수도 있습니다.
매뉴얼 및 시간별 롤아웃은 Auto DevOps로 관리되는 프로젝트에 자동으로 포함되지만, .gitlab-ci.yml 구성 파일을 통해 GitLab CI/CD에서도 구성할 수 있습니다.
수동으로 트리거한 롤아웃은 지속적인 전달(Continuous Delivery)로 구현될 수 있으며, 시간별 롤아웃은 개입이 필요하지 않으며 지속적인 배포 전략의 일환으로 구성될 수 있습니다. 필요한 경우 매뉴얼 개입을 통해 애플리케이션이 자동으로 배포되고, 이후에 매뉴얼으로 개입할 수 있습니다.
세 가지 옵션을 보여주기 위해 샘플 애플리케이션을 만들었으며, 사용자는 이를 참고하여 자체적인 구성을 만들 수 있습니다:
매뉴얼 롤아웃
GitLab을 구성하여 .gitlab-ci.yml을 통해 점진적인 롤아웃을 매뉴얼으로 수행할 수 있습니다. 매뉴얼 구성을 통해 이 기능에 대해 더 많은 제어권을 행사할 수 있습니다. 점진적인 롤아웃의 단계는 Kubernetes 클러스터를 생성할 때 정의된 배포용 pod의 수에 따라 달라집니다.
예를 들어, 애플리케이션이 10개 pod을 보유하고 10%의 롤아웃 작업이 실행된다면, 새 애플리케이션 인스턴스는 단일 pod에 배포되고 나머지 pod은 이전 애플리케이션 인스턴스를 표시합니다.
먼저 .manual_rollout_template으로 템플릿을 매뉴얼으로 정의합니다:
.manual_rollout_template: &manual_rollout_template
<<: *rollout_template
stage: production
when: manual
그런 다음 각 단계에 대한 롤아웃 양을 정의합니다:
rollout 10%:
<<: *manual_rollout_template
variables:
ROLLOUT_PERCENTAGE: 10
작업이 빌드된 후 작업 이름 옆의 Run ()을 선택하여 각 단계의 pod을 릴리스할 수 있습니다. 또한 더 낮은 백분율 작업을 실행하여 롤백할 수 있습니다. 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
구성 가능한 시간별 롤아웃의 구성을 보여주는 배포 가능한 애플리케이션을 참고하세요.
블루-그린 배포
A/B 배포 또는 레드-블랙 배포로도 알려진 이 기법은 배포 중의 다운타임과 위험을 줄이기 위해 사용됩니다. 점진적인 롤아웃과 결합함으로써 배포로 인한 문제의 영향을 최소화할 수 있습니다.
이 기법은 두 개의 배포(‘블루’ 및 ‘그린’, 하지만 다른 이름을 사용할 수도 있음)이 존재하며, 어떤 시점에서는 한 개의 배포만 사용됩니다(점진적인 롤아웃 중을 제외하고는).
예를 들어, 블루 배포가 현재 프로덕션에서 활성화된 상태이며, 그린 배포는 테스트용으로 ‘라이브’ 상태이지만 프로덕션에는 아직 배포되지 않은 상태일 수 있습니다. 문제가 발견되면 프로덕션 배포(현재 블루)에 영향을 주지 않고 그린 배포를 업데이트할 수 있습니다. 테스트가 문제 없음을 확인하면 프로덕션을 그린 배포로 전환하고, 블루는 다음 릴리스를 테스트하는 데 사용할 수 있습니다.
이 절차는 프로덕션 배포를 변경하기 위해 프로덕션 배포를 중단할 필요가 없기 때문에 다운타임을 줄입니다. 두 배포가 병행하여 실행되며 언제든지 전환할 수 있습니다.
설명 가능한 예시 배포 애플리케이션은 여기에서 블루-그린 배포의 구성을 보여주는 .gitlab-ci.yml CI/CD 구성 파일이 제공됩니다.
도움말