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