GitLab CI/CD로 단계적 배포하기
GitLab CI/CD로 단계적 배포하기 (Incremental rollouts with GitLab CI/CD)
애플리케이션 변경을 배포할 때, 위험 완화 전략으로 프로덕션 변경을 Kubernetes 파드의 일부에만 먼저 배포할 수 있어요. 이렇게 점진적으로 변경을 배포하면 오류율이나 성능 저하를 모니터링할 수 있고, 문제가 없다면 전체 파드로 확장해 업데이트하면 돼요.
GitLab은 Incremental Rollout을 사용해 Kubernetes 프로덕션 시스템에 수동 트리거 및 시간 기반 배포를 모두 지원해요. Manual Rollout을 쓰면 각 파드 그룹(tranche)의 배포를 수동으로 트리거하고, Timed Rollout은 기본 5분 대기 후 그룹 단위로 배포를 수행해요. 시간 기반 배포도 대기 시간이 끝나기 전에 수동으로 트리거할 수 있어요.
Manual Rollout과 Timed Rollout은 Auto DevOps로 제어되는 프로젝트에 자동으로 포함되지만, .gitlab-ci.yml 설정 파일에서 GitLab CI/CD로 직접 구성할 수도 있어요.
수동 트리거 배포는 Continuous Delivery(지속적 전달)로 구현할 수 있고, 시간 기반 배포는 개입 없이 진행되므로 Continuous Deployment(지속적 배포) 전략의 일부가 될 수 있어요. 두 가지를 결합해 애플리케이션을 자동 배포하되 필요할 때만 수동으로 개입하도록 만들 수도 있어요.
다음 샘플 애플리케이션은 세 가지 옵션을 보여줘요. 직접 만들 때 참고할 수 있어요:
출처: 문서
본문
수동 배포 (Manual Rollouts)
.gitlab-ci.yml을 통해 GitLab에서 단계적 배포를 수동으로 수행하도록 구성할 수 있어요. 수동 구성은 이 기능을 더 세밀하게 제어할 수 있게 해줘요. 단계적 배포의 단계 수는 Kubernetes 클러스터를 만들 때 구성한 배포의 파드 수에 따라 달라져요.
예를 들어 애플리케이션에 파드가 10개 있고 10% 배포 잡이 실행되면, 새 버전의 애플리케이션은 파드 하나에만 배포되고 나머지 파드는 이전 버전을 보여줘요.
먼저 템플릿을 수동으로 정의하세요:
.manual_rollout_template: &manual_rollout_template
<<: *rollout_template
stage: production
when: manual
다음으로 각 단계의 배포 비율을 정의하세요:
rollout 10%:
<<: *manual_rollout_template
variables:
ROLLOUT_PERCENTAGE: 10
잡이 만들어진 후 각 파드 그룹을 배포하려면 잡 이름 옆의 Run ( play )을 선택하세요. 더 낮은 비율의 잡을 실행하면 롤백할 수도 있어요. 100%에 도달한 뒤에는 이 방법으로 롤백할 수 없어요. 배포를 롤백하려면 배포 재시도 또는 롤백을 참고하세요.
수동으로 트리거되는 단계적 배포를 보여주는 배포 가능한 애플리케이션도 사용할 수 있어요.
시간 기반 배포 (Timed Rollouts)
Timed rollout은 각 잡이 배포 전에 분 단위 지연을 갖도록 정의된다는 점만 빼고 수동 배포와 똑같이 동작해요. 잡을 선택하면 카운트다운이 보여요.
이 기능을 수동 단계적 배포와 결합해서 잡이 카운트다운 후 배포하도록 만들 수도 있어요.
.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 Deployment)
팀은 Ingress 어노테이션과 트래픽 가중치 설정을 활용해 여기 문서화된 블루-그린 배포 전략의 대안으로 삼을 수 있어요.
A/B 배포 또는 레드-블랙 배포라고도 불리는 이 기법은 배포 중 다운타임과 위험을 줄이는 데 사용돼요. 단계적 배포와 결합하면 배포가 문제를 일으키는 영향을 최소화할 수 있어요.
이 기법에서는 두 개의 배포("blue"와 "green", 어떤 이름이든 괜찮아요)가 있어요. 단계적 배포 중인 경우를 제외하면 주어진 시점에 이 중 하나만 라이브 상태예요.
예를 들어 blue 배포가 프로덕션에서 활성 상태이고 green 배포는 테스트용으로만 "라이브"이고 프로덕션에는 배포되지 않았을 수 있어요. 문제가 발견되면 green 배포는 프로덕션(blue)에 영향을 주지 않고 업데이트할 수 있어요. 테스트에서 문제가 발견되지 않으면 프로덕션을 green 배포로 전환하고, 이제 blue가 다음 릴리스를 테스트할 수 있게 돼요.
이 과정은 다른 배포로 전환하기 위해 프로덕션 배포를 내릴 필요가 없어서 다운타임을 줄여요. 두 배포가 병렬로 실행되며 언제든 전환할 수 있어요.
블루-그린 배포를 보여주는 .gitlab-ci.yml CI/CD 설정 파일이 있는 예제 배포 가능한 애플리케이션을 사용할 수 있어요.
더 알아보기
다음으로는 Auto DevOps가 단계적 배포를 자동으로 설정하는 방식을 살펴보고, 배포 재시도 또는 롤백 문서를 읽으면 배포 후 문제 발생 시 대응하는 방법을 익힐 수 있어요.