より新しいAuto Deploy依存のデプロイのアップグレード

AutoDeployは、アプリケーションをKubernetesクラスターにデプロイする機能です。いくつかの依存関係で構成されています：

  • AutoDeployテンプレートは、auto-deploy-image を利用するパイプラインジョブとスクリプトのセットです。
  • auto-deploy-image はKubernetesクラスターと通信する実行イメージです。
  • auto-deploy-app chart はアプリケーションをデプロイするためのHelmチャートです。

auto-deploy-image とauto-deploy-app チャートはセマンティック・バージョニングを使用します。デフォルトでは、Auto DevOpsプロジェクトは安定したバージョンと壊れないバージョンを使い続けます。しかし、これらの依存関係はGitLabのメジャーバージョンリリースでアップグレードされる可能性があり、デプロイをアップグレードする必要があります。

このガイドでは、Auto Deploy の依存関係の新しいバージョンや異なるメジャーバージョンでデプロイをアップグレードする方法を説明します。

依存関係のバージョンの確認

現在のバージョンを確認する手順は、使用しているテンプレートによって異なります。まず、どのテンプレートを使用しているかを確認します：

使用されているテンプレートがわかれば

  • auto-deploy-image のバージョンはテンプレート内部にあります（例：auto-deploy-image:v1.0.3 ）。
  • auto-deploy-app Chart のバージョンはauto-deploy-image リポジトリにあります (例えばversion: 1.0.3)。

互換性

以下の表は、GitLab と Auto Deploy の依存関係のバージョンの互換性について説明しています：

GitLabバージョン auto-deploy-image バージョン備考
v10.0からv14.0v0.1.0から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が管理する未修正のチャートを使用する必要があります。カスタマイズされたChartはサポートされていません。

デプロイを v1 にアップグレードしてください。auto-deploy-image

v1チャートはv0チャートと下位互換性があるため、設定の変更は必要ありません。

v2へのデプロイのアップグレードauto-deploy-image

v2 auto-deploy-image には、複数の依存関係とアーキテクチャの変更が含まれています。あなたの Auto DevOps プロジェクトに v1auto-deploy-image でデプロイされたアクティブな環境がある場合、以下のアップグレードガイドに進んでください。そうでない場合は、このプロセスをスキップできます。

Kubernetes 1.16+の場合。

v2 auto-deploy-imageはKubernetes 1.15以下のサポートを停止します。Kubernetesクラスタをアップグレードする必要がある場合は、クラウドプロバイダの指示に従ってください。以下はGKEでの例です。

Helm v3

GitLab 13.4 で導入されました。

auto-deploy-image Helmバイナリを使ってリリースを操作 auto-deploy-imageします。auto-deploy-image 以前は auto-deploy-image、クラスターでTillerを使うHelm v2を使用していました。v2auto-deploy-image では、Tillerを必要としないHelm v3を使用します。

Auto DevOpsプロジェクトにv1auto-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マニフェストファイルからこのバックアップを復元できます。

      警告: 公開パイプラインを使用している場合は、これを使用しないでください。このアーティファクトにはシークレットが含まれている可能性があり、ジョブを見ることができるユーザーなら誰でも見ることができます。

  3. パイプラインを実行し、<environment-name>:helm-2to3:migrate ジョブをトリガーします。
  4. 通常通り環境をデプロイします。このデプロイは Helm v3 を使用します。
  5. デプロイが成功したら、<environment-name>:helm-2to3:cleanup を安全に実行できます。これにより、ネームスペースからすべてのHelm v2リリースデータが削除されます。
  6. CI/CD 変数MIGRATE_HELM_2TO3 を削除するか、false に設定します。環境スコープを使用して、一度に1つの環境を実行できます。

クラスタ内PostgreSQLチャネル2

v2 auto-deploy-imageでは、レガシーなクラスタ内PostgreSQLのサポートが削除されました。KubernetesクラスタがまだPostgreSQLに依存している場合は、v1 auto-deploy-imageでアップグレードしてデータをマイグレーションしてください。

カナリアデプロイとインクリメンタルロールアウトのためのトラフィックルーティングの変更

GitLab 13.4 で導入されました。

Auto Deploy は、カナリアデプロイや インクリメンタルロールアウトなどの高度なデプロイ戦略をサポートします。

以前は、auto-deploy-image レプリカの比率を変更することで、不安定なトラックと安定したトラックの間のトラフィックのバランスを取るために1つのサービスを作成 auto-deploy-imageしました。auto-deploy-image v auto-deploy-image2では、Canary Ingressでトラフィックを制御します。

詳細はv2auto-deploy-app チャートリソースアーキテクチャを参照してください。

Auto DevOps プロジェクトで、v1auto-deploy-imageでデプロイされたproduction 環境にアクティブなcanary またはrollout トラック・リリースがある場合は、以下の手順で v2 にアップグレードしてください：

  1. プロジェクトが v1auto-deploy-image](#verify-dependency-versions)を使用して[いることを確認します。そうでない場合は、バージョンを指定します。
  2. canary やrollout のデプロイ中であれば、まずproduction に昇格させて不安定なトラックを削除してください。
  3. プロジェクトがで、v2auto-deploy-imageを使用していることを確認してください。そうでない場合は、バージョンを指定してください。
  4. GitLab CI/CD 設定にtrue という値を持つAUTO_DEVOPS_FORCE_DEPLOY_V2 CI/CD 変数を追加します。
  5. 新しいパイプラインを作成し、production ジョブを実行してリソースアーキテクチャを v2auto-deploy-app chart で更新します。
  6. AUTO_DEVOPS_FORCE_DEPLOY_V2 変数を削除します。

特定のバージョンのオートデプロイの依存関係を使用します。

特定のバージョンの Auto Deploy 依存関係を使用するには、auto-deploy-image とauto-deploy-app](#verify-dependency-versions)の[希望バージョンを含む以前の Auto Deploy 安定版テンプレートを指定します。

例えば、テンプレートが GitLab 13.3 にバンドルされている場合は、.gitlab-ci.yml を変更します：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://gitlab.com/gitlab-org/gitlab/-/raw/v13.3.0-ee/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml

あるいは、v13.12 Auto DevOps templates アーカイブを使うこともできます。

警告を無視してデプロイを続行します。

新しいChartのバージョンがデプロイしても安全であることが確実であれば、AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number> CI/CD変数を追加して、デプロイを強制的に続行することができます。

たとえば、v0.17.0 チャートを使用していたデプロイにv2.0.0 チャートをデプロイする場合は、AUTO_DEVOPS_FORCE_DEPLOY_V2 を追加します。

アーリーアダプタ

auto-deploy-image の最新ベータ版や不安定版を使いたい場合は、.gitlab-ci.yml に最新の自動デプロイテンプレートを入れてください：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - template: Jobs/Deploy.latest.gitlab-ci.yml
caution
ベータ版や不安定版のauto-deploy-image を使用すると、環境に回復不能なダメージを与える可能性があります。重要なプロジェクトや環境でテストしないでください。

次の安定版テンプレートのアップデートはGitLab v14.0を予定しています。

auto-deploy-app チャートのリソースアーキテクチャ

v0とv1のChartリソースアーキテクチャ

graph TD; 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チャート・リソース・アーキテクチャ

graph TD; 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"

クラスターに v1auto-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 でデプロイされていたためです。この問題を解決するには、アップグレードガイドに従ってください。