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