Auto Deploy는 Kubernetes 클러스터에 애플리케이션을 배포하는 기능입니다. 여러 의존성으로 구성되어 있습니다:

• Auto Deploy 템플릿은 auto-deploy-image를 사용하는 파이프라인 작업과 스크립트 집합입니다.
• auto-deploy-image는 Kubernetes 클러스터와 통신하는 실행 가능한 이미지입니다.
• auto-deploy-app chart는 애플리케이션을 배포하기 위한 Helm 차트입니다.

auto-deploy-image와 auto-deploy-app 차트는 유의적 버전을 사용합니다. 기본적으로 Auto DevOps 프로젝트는 안정적이고 하위 호환 가능한 버전을 계속 사용합니다. 그러나 이러한 의존성은 배포 업그레이드가 필요한 주요 변경 사항이 있는 GitLab의 주요 버전 릴리스에서 업그레이드될 수 있습니다.

이 가이드는 최신 또는 다른 주요 버전의 Auto Deploy 의존성으로 배포를 업그레이드하는 방법을 설명합니다.

의존성 버전 확인#

현재 버전을 확인하는 프로세스는 사용 중인 템플릿에 따라 다릅니다. 먼저 어떤 템플릿이 사용 중인지 확인합니다:

• GitLab Self-Managed 인스턴스의 경우 GitLab 패키지와 번들로 제공된 안정적인 Auto Deploy 템플릿이 사용됩니다.
• 다음 중 하나가 true인 경우 GitLab.com 안정적인 Auto Deploy 템플릿이 사용됩니다:
  • Auto DevOps 프로젝트에 .gitlab-ci.yml 파일이 없습니다.
  • Auto DevOps 프로젝트에 .gitlab-ci.yml이 있고 Auto-DevOps.gitlab-ci.yml 템플릿을 includes합니다.
• 다음 모두가 true인 경우 최신 Auto Deploy 템플릿이 사용됩니다:
  • Auto DevOps 프로젝트에 .gitlab-ci.yml 파일이 있고 Auto-DevOps.gitlab-ci.yml 템플릿을 includes합니다.
  • 또한 최신 Auto Deploy 템플릿을 포함합니다.

어떤 템플릿이 사용되고 있는지 알고 있다면:

• auto-deploy-image 버전이 템플릿에 있습니다(예: auto-deploy-image:v1.0.3).
• auto-deploy-app 차트 버전은 auto-deploy-image 저장소에 있습니다(예: version: 1.0.3).

호환성#

다음 표는 GitLab과 Auto Deploy 의존성 간의 버전 호환성을 설명합니다:

현재 안정적인 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을 사용합니다.

Auto DevOps 프로젝트에 v1 auto-deploy-image로 배포된 활성 환경이 있는 경우 Helm v3을 사용하는 v2로 업그레이드하려면 다음 단계를 따르세요:

1. 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
     

2. 다음 CI/CD 변수를 설정합니다:

   • MIGRATE_HELM_2TO3를 true로. 이 변수가 없으면 마이그레이션 작업이 실행되지 않습니다.

   • AUTO_DEVOPS_FORCE_DEPLOY_V2를 1로.

   • 선택 사항: BACKUP_HELM2_RELEASES를 1로. 이 변수를 설정하면 마이그레이션 작업이 helm-2-release-backups라는 작업 아티팩트에 1주일 동안 백업을 저장합니다. Helm v2 릴리스를 준비되기 전에 실수로 삭제한 경우 kubectl apply -f $backup을 사용하여 Kubernetes 매니페스트 파일에서 이 백업을 복원할 수 있습니다.

     [!warning] 공개 파이프라인이 있는 경우 사용하지 마세요. 이 아티팩트는 시크릿을 포함할 수 있으며 작업을 볼 수 있는 모든 사용자에게 표시됩니다.

3. 파이프라인을 실행하고 <environment-name>:helm-2to3:migrate 작업을 트리거합니다.

4. 평소와 같이 환경을 배포합니다. 이 배포는 Helm v3을 사용합니다.

5. 배포가 성공하면 <environment-name>:helm-2to3:cleanup을 안전하게 실행할 수 있습니다. 이렇게 하면 네임스페이스에서 모든 Helm v2 릴리스 데이터가 삭제됩니다.

6. MIGRATE_HELM_2TO3 CI/CD 변수를 제거하거나 false로 설정합니다. 환경 범위를 사용하여 환경별로 이를 수행할 수 있습니다.

클러스터 내 PostgreSQL 채널 2#

v2 auto-deploy-image는 레거시 클러스터 내 PostgreSQL에 대한 지원을 중단합니다. Kubernetes 클러스터가 아직 여기에 의존하는 경우 v1 auto-deploy-image를 사용하여 데이터를 업그레이드하고 마이그레이션하세요.

카나리아 배포 및 증분 롤아웃의 트래픽 라우팅 변경#

Auto Deploy는 카나리아 배포와 증분 롤아웃과 같은 고급 배포 전략을 지원합니다.

이전에는 auto-deploy-image가 복제본 비율을 변경하여 불안정한 트랙과 안정적인 트랙 간의 트래픽을 분산하는 하나의 서비스를 만들었습니다. v2 auto-deploy-image에서는 Canary Ingress로 트래픽을 제어합니다.

자세한 내용은 v2 auto-deploy-app 차트 리소스 아키텍처를 참조하세요.

Auto DevOps 프로젝트에 v1 auto-deploy-image로 배포된 production 환경에 활성 canary 또는 rollout 트랙 릴리스가 있는 경우 v2로 업그레이드하려면 다음 단계를 따르세요:

1. 프로젝트가 v1 auto-deploy-image를 사용하고 있는지 확인합니다. 그렇지 않은 경우 버전을 지정합니다.
2. canary 또는 rollout 배포를 진행 중인 경우 먼저 불안정한 트랙을 삭제하기 위해 production으로 승격합니다.
3. 프로젝트가 v2 auto-deploy-image를 사용하고 있는지 확인합니다. 그렇지 않은 경우 버전을 지정합니다.
4. GitLab CI/CD 설정에서 값이 true인 AUTO_DEVOPS_FORCE_DEPLOY_V2 CI/CD 변수를 추가합니다.
5. 새 파이프라인을 만들고 v2 auto-deploy-app chart로 리소스 아키텍처를 갱신하기 위해 production 작업을 실행합니다.
6. AUTO_DEVOPS_FORCE_DEPLOY_V2 변수를 제거합니다.

Auto Deploy 의존성의 특정 버전 사용#

Auto Deploy 의존성의 특정 버전을 사용하려면 원하는 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

경고를 무시하고 계속 배포#

새 차트 버전이 안전하게 배포될 수 있다고 확신하는 경우 AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number> CI/CD 변수를 추가하여 배포를 강제로 계속할 수 있습니다.

예를 들어, 이전에 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-app 차트의 리소스 아키텍처#

v0 및 v1 차트 리소스 아키텍처#

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD;
accTitle: v0 and v1 chart resource architecture
accDescr: Shows the relationships between the components of the v0 and v1 charts.
subgraph gl-managed-app
Z[Nginx Ingress]
end
Z[Nginx Ingress] --> A(Ingress);
Z[Nginx Ingress] --> B(Ingress);
subgraph stg namespace
B[Ingress] --> H(...);
end
subgraph prd namespace
A[Ingress] --> D(Service);
D[Service] --> E(Deployment:Pods:app:stable);
D[Service] --> F(Deployment:Pods:app:canary);
D[Service] --> I(Deployment:Pods:app:rollout);
E(Deployment:Pods:app:stable)---id1[(Pods:Postgres)]
F(Deployment:Pods:app:canary)---id1[(Pods:Postgres)]
I(Deployment:Pods:app:rollout)---id1[(Pods:Postgres)]
end

v2 차트 리소스 아키텍처#

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD;
accTitle: v2 chart resource architecture
accDescr: Shows the relationships between the components of the v2 chart.
subgraph gl-managed-app
Z[Nginx Ingress]
end
Z[Nginx Ingress] --> A(Ingress);
Z[Nginx Ingress] --> B(Ingress);
Z[Nginx Ingress] --> |If canary is present or incremental rollout/|J(Canary Ingress);
subgraph stg namespace
B[Ingress] --> H(...);
end
subgraph prd namespace
subgraph stable track
A[Ingress] --> D[Service];
D[Service] --> E(Deployment:Pods:app:stable);
end
subgraph canary track
J(Canary Ingress) --> K[Service]
K[Service] --> F(Deployment:Pods:app:canary);
end
E(Deployment:Pods:app:stable)---id1[(Pods:Postgres)]
F(Deployment:Pods:app:canary)---id1[(Pods:Postgres)]
end

트러블슈팅#

주요 버전 불일치 경고#

현재 배포하는 차트의 주요 버전이 이전 버전과 다른 경우 새 차트가 올바르게 배포되지 않을 수 있습니다. 아키텍처 변경으로 인한 것일 수 있습니다. 이 경우 배포 작업이 다음과 유사한 메시지와 함께 실패합니다:

*************************************************************************************
                                   [WARNING]
Detected a major version difference between the chart that is currently deploying (auto-deploy-app-v0.7.0), and the previously deployed chart (auto-deploy-app-v1.0.0).
A new major version might not be backward compatible with the current release (production). The deployment could fail or be stuck in an unrecoverable status.
...

이 오류 메시지를 제거하고 배포를 재개하려면 다음 중 하나를 수행해야 합니다:

• 수동으로 차트 버전을 업그레이드합니다.
• 특정 차트 버전을 사용합니다.

오류: missing key "app.kubernetes.io/managed-by": must be set to "Helm"#

클러스터에 v1 auto-deploy-image로 배포된 배포가 있는 경우 다음 오류가 발생할 수 있습니다:

• Error: rendered manifests contain a resource that already exists. Unable to continue with install: Secret "production-postgresql" in namespace "<project-name>-production" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "production-postgresql"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "<project-name>-production"

이는 이전 배포가 Helm3과 호환되지 않는 Helm2로 배포되었기 때문입니다. 문제를 해결하려면 업그레이드 가이드를 따르세요.