カナリアのデプロイ

  • GitLab 9.1 で導入されました。
  • 13.8でGitLab PremiumからGitLab Freeに移行。

カナリアデプロイはよく使われる継続的デプロイ戦略で、フリート内のごく一部をアプリケーションの新しいバージョンに更新します。

継続的デリバリを採用する場合、組織はどのタイプのデプロイ戦略を使用するかを決定する必要があります。最も一般的な戦略の1つはカナリアデプロイで、フリート内のごく一部が最初に新しいバージョンにアップデートされます。このサブセット（カナリア）は、炭鉱のカナリアとして機能します。

新バージョンのアプリケーションに問題があったとしても、影響を受けるユーザーはごく一部であり、変更は修正されるか、すぐに元に戻されます。

ユースケース

カナリアデプロイは、ポッドフリートの一部だけに機能を配布し、一時的にデプロイされた機能にユーザーの何パーセントかがアクセスしたときの挙動を観察したいときに使用できます。すべてがうまくいけば、その機能を本番環境にデプロイしても問題は起きません。

カナリアデプロイは、バックエンドのリファクタリングやパフォーマンスの改善、あるいはユーザーインターフェイスは変更しないがパフォーマンスが変わらないか改善されることを確認するような変更にも特に必要です。デフォルトでは、同じユーザーからのリクエストはカナリアポッドと非カナリアポッドにランダムに振り分けられ、混乱やエラーになる可能性があるからです。必要であれば、Kubernetesサービス定義でservice.spec.sessionAffinity をClientIP に設定することを検討したいかもしれませんが、このドキュメントの範囲を超えています。

Canary Ingressによる高度なトラフィック制御

CanaryIngress は、ウェイト、セッション、Cookie などの要素に基づいて、安定したデプロイメントと Canary デプロイメント間の HTTP リクエストの着信を制御する高度なトラフィックルーティングサービスです。GitLabはこのサービスをAuto Deployアーキテクチャで使用し、ユーザーが新しいデプロイメントを迅速かつ安全にロールアウトできるようにしています。

カナリア・デプロイで Canary Ingress を設定する方法

Auto DevOpsパイプラインがauto-deploy-image](../../topics/autodevops/upgrading_auto_deploy_dependencies.md#verify-dependency-versions)の[v2.0.0+ を使用する場合、Canary Ingressはデフォルトでインストールされます。 Canary Ingressは、新しいCanaryデプロイメントを作成するときに使用可能になり、Canaryデプロイメントが本番環境に昇格させられるときに破棄されます。

以下は、ゼロからのセットアップフローの例です：

  1. Auto DevOps対応プロジェクトを準備します。
  2. プロジェクトにKubernetesクラスターをセットアップします。
  3. NGINX Ingressをクラスターにインストールします。
  4. 上記で割り当てたIngress Endpointに基づいてベースドメインを設定します。
  5. auto-deploy-image のv2.0.0+ が Auto DevOps パイプラインで使用されているか確認してください。そうでない場合は、ドキュメントに従ってイメージのバージョンを指定します。
  6. 新しいAuto DevOpsパイプラインを実行し、production ジョブが成功し、本番環境が作成されることを確認します。
  7. Auto DevOpsパイプライン用のcanary デプロイジョブの設定。
  8. 新しいAuto DevOpsパイプラインを実行し、canary ジョブが成功し、Canary IngressでCanaryデプロイが作成されることを確認してください。

デプロイボードにCanary Ingressデプロイを表示する（非推奨）

caution
この機能はGitLab 14.5で非推奨となりました。

カナリアデプロイを表示するには、デプロイボードを適切に設定する必要があります：

  1. デプロイボードを有効にする手順に従ってください。
  2. カナリア・デプロイメントを追跡するには、Kubernetesデプロイメントとポッドにtrack: canary でラベルを付ける必要があります。すぐに始めるには、GitLabが提供するカナリアデプロイ用の自動デプロイテンプレートを使用できます。

デプロイによって、ラベルはstable かcanary のどちらかにする必要があります。GitLabは、ラベルが空白または見つからない場合、トラックラベルをstable と見なします。それ以外のトラックラベルはcanary （仮）とみなされます。これにより、GitLabはデプロイが安定したものなのか、それともカナリア（一時的なもの）なのかを知ることができます。

上記のすべての設定が完了し、パイプラインが少なくとも1回実行されたら、[パイプライン] > [環境] の [環境] ページに移動します。パイプラインが実行されると、デプロイボードにカナリアポッドが明示され、各環境とデプロイのステータスを迅速かつ明確にインサイトできるようになります。

カナリア デプロイにはデプロイボードに黄色の点が表示されるので、すぐに気づくことができます。

Canary deployments on deploy board

Canary Ingress の現在のトラフィックウェイトを確認する方法（非推奨）

caution
この機能はGitLab 14.5で非推奨となりました。
  1. デプロイボードをご覧ください。

  2. 右側に現在のウェイトが表示されます。

    Rollout Status Canary Ingress

カナリア・イングレスのトラフィック・ウェイトを変更する方法（非推奨）

caution
この機能はGitLab 14.5で非推奨となりました。

環境のデプロイボードのトラフィックウェイトは、GraphiQLを使うか、GraphQL APIにリクエストを送ることで変更できます。

デプロイボードを使用するには

  1. プロジェクトの[オペレーション] > [環境]に進みます。
  2. 右側のドロップダウンリストで新しいウェイトを設定します。
  3. 選択を確定します。

GraphiQLを使用した例です：

  1. GraphiQLエクスプローラーをご覧ください。

  2. environmentsCanaryIngressUpdate GraphQLミューテーションを実行します：

    mutation {
  environmentsCanaryIngressUpdate(input:{
    id: "gid://gitlab/Environment/29",              # Your Environment ID. You can get the ID from the URL of the environment page.
    weight: 45                                      # The new traffic weight. for example, If you set `45`, 45% of traffic goes to a canary deployment and 55% of traffic goes to a stable deployment.
  }) {
    errors
  }
}
  3. リクエストが成功すると、errors レスポンスには空の配列が含まれます。GitLabは、Canary Ingressのweightパラメータを更新するためのPATCH リクエストをKubernetesクラスターに送信します。