최신 Auto Deploy 의존성을 위한 배포 업그레이드
Offering: GitLab.com, Self-Managed, GitLab Dedicated
Auto Deploy는 응용 프로그램을 Kubernetes 클러스터에 배포하는 기능입니다. 이 기능은 여러 의존성으로 구성됩니다:
-
Auto Deploy 템플릿은
auto-deploy-image
를 활용하는 파이프라인 작업과 스크립트의 집합입니다. -
auto-deploy-image
은 Kubernetes 클러스터와 통신하는 실행 이미지입니다. -
auto-deploy-app 차트
는 응용 프로그램을 배포하기 위한 Helm 차트입니다.
auto-deploy-image
와 auto-deploy-app
차트는 Semantic Versioning을 사용합니다.
기본적으로 Auto DevOps 프로젝트는 안정적이고 호환되는 버전을 유지합니다.
그러나 이러한 의존성은 GitLab의 주요 버전 릴리스에서 업그레이드할 수 있으며, 이로 인해 배포를 업그레이드해야 할 수 있습니다.
이 안내서에서는 Auto Deploy 의존성의 최신 또는 다른 주요 버전으로 배포를 업그레이드하는 방법에 대해 설명합니다.
의존성 버전 확인
현재 버전을 확인하는 프로세스는 사용 중인 템플릿에 따라 다르지만 확인할 때 첫 번째로 사용 중인 템플릿을 확인하세요:
- Self-Managed 인스턴스의 경우, GitLab 패키지에 번들된 안정적인 Auto Deploy 템플릿이 사용됩니다.
-
다음 중 하나가 참이면 GitLab.com 안정적인 Auto Deploy 템플릿이 사용됩니다:
- Auto DevOps 프로젝트에
.gitlab-ci.yml
파일이 없는 경우. - Auto DevOps 프로젝트에
.gitlab-ci.yml
이 있고 포함되는Auto-DevOps.gitlab-ci.yml
템플릿이 있는 경우.
- Auto DevOps 프로젝트에
-
다음 두 가지 모두가 참이면 최신 Auto Deploy 템플릿이 사용됩니다:
- Auto DevOps 프로젝트에
.gitlab-ci.yml
파일이 있고 포함되는Auto-DevOps.gitlab-ci.yml
템플릿이 있는 경우. - 최신 Auto Deploy 템플릿도 포함됩니다.
- Auto DevOps 프로젝트에
사용 중인 템플릿을 알고 있다면:
- 템플릿에 있는
auto-deploy-image
버전을 확인하세요 (예:auto-deploy-image:v1.0.3
). -
auto-deploy-app
차트 버전을 auto-deploy-image 리포지터리에서(예:version: 1.0.3
) 확인하세요.
호환성
다음 표는 GitLab과 Auto Deploy 의존성 간의 버전 호환성을 설명합니다:
GitLab 버전 |
auto-deploy-image 버전
| 노트 |
---|---|---|
v10.0 to v14.0 | v0.1.0 to v2.0.0 | v0 및 v1 auto-deploy-image가 하위 호환됩니다. |
v13.4 및 이후 | v2.0.0 및 이후 | v2 auto-deploy-image에는 파괴적인 변경 사항이 포함되어 있으며, 업그레이드 안내서에 설명되어 있습니다. |
안정적인 auto-deploy-image의 최신 버전을 Auto Deploy 안정적인 템플릿에서 찾을 수 있습니다.
업그레이드 안내서
Auto DevOps를 사용하는 프로젝트는 GitLab에서 관리하는 수정되지 않은 차트를 사용해야 합니다. 사용자 정의 차트는 지원되지 않습니다.
v1 auto-deploy-image
로 배포 업그레이드
v1 차트는 v0 차트와 하위 호환성이 있으므로 구성 변경이 필요하지 않습니다.
v2 auto-deploy-image
로 배포 업그레이드
v2 auto-deploy-image는 여러 의존성 및 구조 변경이 포함되어 있습니다.
만약 Auto DevOps 프로젝트에 v1 auto-deploy-image
로 배포된 활성 환경이 있는 경우 다음 업그레이드 안내서를 따르세요. 그렇지 않은 경우 이 프로세스를 건너뛸 수 있습니다.
Kubernetes 1.16+
v2 auto-deploy-image는 Kubernetes 1.15 및 이전 버전을 지원하지 않습니다. Kubernetes 클러스터를 업그레이드해야 하는 경우, 해당 클라우드 공급자의 지침을 따르세요. 예를 들어, 다음은 GKE의 예시입니다.
Helm v3
auto-deploy-image
는 릴리스를 조작하기 위해 Helm 이진 파일을 사용합니다.
이전에는 auto-deploy-image
가 클러스터 내의 Tiller를 사용하는 Helm v2를 사용했지만, v2 auto-deploy-image
에서는 더 이상 Tiller가 필요하지 않은 Helm v3를 사용합니다.
만약 v1 auto-deploy-image
를 사용하여 활성 환경을 배포한 Auto DevOps 프로젝트가 있는 경우 다음 단계를 사용하여 v2로 업그레이드하세요. v2는 Helm v3를 사용합니다:
-
Helm 2to3 마이그레이션 CI/CD 템플릿를 포함하세요:
- GitLab.com이나 GitLab 14.0.1 이상의 경우,이 템플릿은 이미 Auto DevOps에 포함되어 있습니다.
-
다른 GitLab 버전의 경우,
.gitlab-ci.yml
을 수정하여 다음과 같이 템플릿을 포함할 수 있습니다:include: - template: Auto-DevOps.gitlab-ci.yml - remote: https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Jobs/Helm-2to3.gitlab-ci.yml
-
다음 CI/CD 변수를 설정하세요:
-
MIGRATE_HELM_2TO3
를true
로 설정하세요. 이 변수가 없으면 마이그레이션 작업이 실행되지 않습니다. -
AUTO_DEVOPS_FORCE_DEPLOY_V2
를1
로 설정하세요. -
선택 사항:
BACKUP_HELM2_RELEASES
를1
로 설정하세요. 이 변수를 설정하면 마이그레이션 작업이helm-2-release-backups
이라는 작업 artifact에 1주일 동안 백업을 저장합니다. 준비가 되기 전에 실수로 Helm v2 릴리스를 삭제하면 이 백업을 사용하여 Kubernetes 매니페스트 파일에서 복원할 수 있습니다. 이 artifact에는 비밀 정보가 포함될 수 있으므로 공개 파이프라인을 사용하지 마세요.경고: 공개 파이프라인을 사용하지 마세요. 이 artifact에는 비밀 정보가 포함될 수 있으며 파이프라인을 볼 수 있는 모든 사용자에게 노출됩니다.
-
- 파이프라인을 실행하고
<environment-name>:helm-2to3:migrate
작업을 트리거하세요. - 환경을 사용하는 방식대로 배포하세요. 이 배포는 Helm v3를 사용합니다.
- 배포가 성공하면 안전하게
<environment-name>:helm-2to3:cleanup
을 실행하세요. 이를 통해 네임스페이스에서 모든 Helm v2 릴리스 데이터가 삭제됩니다. -
MIGRATE_HELM_2TO3
CI/CD 변수를 제거하거나false
로 설정하세요. 환경 범위를 사용하여 한 번에 하나씩 변경할 수 있습니다.
클러스터 내 PostgreSQL 채널 2
v2 자동 배포 이미지는 레거시 클러스터 내 PostgreSQL 지원을 중단합니다. 귀하의 Kubernetes 클러스터가 여전히 해당 기능에 의존하는 경우, 업그레이드하고 데이터를 마이그레이션하십시오. 특정 버전의 자동 배포 의존성을 사용하려면 v1 자동 배포 이미지를 참조하십시오.
카나리아 배포 및 점진적 롤아웃을 위한 트래픽 라우팅 변경
자동 배포는 카나리아 배포와 점진적 롤아웃과 같은 고급 배포 전략을 지원합니다.
이전 auto-deploy-image
는 안정적인 트랙과 불안정한 트랙 간의 트래픽을 레플리카 비율을 조정함으로써 제어하도록 하나의 서비스를 생성했습니다. 그러나 v2 auto-deploy-image
에서는 카나리아 인그레스를 사용하여 트래픽을 제어합니다.
더 많은 세부 정보는 v2 auto-deploy-app
차트 리소스 아키텍처를 참조하십시오.
v1 auto-deploy-image
를 사용하여 production
환경에 활성 canary
또는 rollout
트랙 릴리스가 있는 경우, 다음 단계를 따라 v2로 업그레이드하십시오:
- 귀하의 프로젝트가 v1
auto-deploy-image
를 사용하는지 확인하십시오. 그렇지 않으면 버전을 지정하십시오. -
canary
또는rollout
배포를 진행 중인 경우, 먼저 그것들을production
으로 승격시켜 불안정한 트랙을 제거하십시오. - 귀하의 프로젝트가 v2
auto-deploy-image
를 사용하는지 확인하십시오. 그렇지 않으면 버전을 지정하십시오. -
AUTO_DEVOPS_FORCE_DEPLOY_V2
CI/CD 변수를 값true
로 추가하십시오. (GitLab CI/CD 설정). - 새로운 파이프라인을 생성하고
production
작업을 실행하여 리소스 아키텍처를 v2auto-deploy-app chart
로 갱신하십시오. -
AUTO_DEVOPS_FORCE_DEPLOY_V2
변수를 제거하십시오.
특정 버전의 자동 배포 의존성 사용
특정 버전의 자동 배포 의존성을 사용하려면 원하는 버전의 auto-deploy-image
및 auto-deploy-app
을 포함하는 이전 Auto Deploy 안정 템플릿을 지정하십시오.
예를 들어, GitLab 16.10에 번들된 템플릿의 경우, .gitlab-ci.yml
을 다음과 같이 변경하십시오:
include:
- template: Auto-DevOps.gitlab-ci.yml
- remote: https://gitlab.com/gitlab-org/gitlab/-/raw/v16.10.0-ee/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml
경고 무시 및 계속 배포
새로운 차트 버전이 안전하게 배포될 수 있다고 확신하는 경우, CI/CD 변수 AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>
을 추가하여 배포를 계속하도록 할 수 있습니다.
예를 들어, 이전에 v0.17.0
차트를 사용한 배포에 v2.0.0
차트를 배포하고 싶은 경우, AUTO_DEVOPS_FORCE_DEPLOY_V2
를 추가하십시오.
초기 채택자
최신 베타 또는 불안정한 버전의 auto-deploy-image
을 사용하려면, 최신 Auto Deploy 템플릿을 .gitlab-ci.yml
에 포함하십시오:
include:
- template: Auto-DevOps.gitlab-ci.yml
- template: Jobs/Deploy.latest.gitlab-ci.yml
auto-deploy-image
을 사용하는 것은 귀하의 환경에 치명적인 피해를 줄 수 있습니다. 중요한 프로젝트나 환경에서 테스트하지 마십시오.
auto-deploy-app
차트의 리소스 아키텍처
v0 및 v1 차트 리소스 아키텍처
v2 차트 리소스 아키텍처
문제 해결
주요 버전 불일치 경고
이전 버전과 다른 주요 버전이 포함된 차트를 배포하는 경우, 새 차트가 올바르게 배포되지 않을 수 있습니다. 이는 아키텍처 변경에 기인할 수 있습니다. 그런 경우에 배포 작업이 다음과 유사한 메시지와 함께 실패합니다:
*************************************************************************************
[경고]
현재 배포 중인 차트(auto-deploy-app-v0.7.0)와 이전에 배포한 차트(auto-deploy-app-v1.0.0) 간의 주요 버전 차이가 감지되었습니다.
새 주요 버전은 현재 릴리스(production)와 호환되지 않을 수 있습니다. 배포 실패 또는 회복할 수 없는 상태에 갇힐 수 있습니다.
...
이 오류 메시지를 제거하고 배포를 계속하려면 다음 중 하나를 수행해야 합니다:
- 매뉴얼으로 차트 버전을 업그레이드.
- 특정 차트 버전을 사용.
오류: “missing key “app.kubernetes.io/managed-by”: must be set to “Helm””
귀하의 클러스터에 v1 auto-deploy-image
를 사용하여 배포된 배포가 있는 경우, 다음과 같은 오류 메시지를 만날 수 있습니다:
오류: 렌더링된 매니페스트에 이미 존재하는 리소스가 포함됩니다. 설치를 계속할 수 없음: "production-postgresql"명의 시크릿이 "<project-name>-production" 네임스페이스에 존재하며 현재 릴리스로 가져올 수 없음: 잘못된 소유권 메타데이터; 라벨 유효성 검사 오류: "app.kubernetes.io/managed-by" 키가 누락됨: "Helm"으로 설정해야 함; 주석 유효성 검사 오류: "meta.helm.sh/release-name" 키가 누락됨: "<project-name>-production"으로 설정해야 함; 주석 유효성 검사 오류: "meta.helm.sh/release-namespace" 키가 누락됨: "production-postgresql"으로 설정해야 함
이는 이전 배포가 Helm2를 사용하여 배포되었기 때문에 Helm3과 호환되지 않은 문제입니다. 이 문제를 해결하려면 업그레이드 가이드를 따르십시오.