カナリアデプロイ
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
カナリアデプロイは一般的な継続的デプロイ戦略であり、フリートのごく一部がアプリケーションの新しいバージョンに更新されます。
継続的デリバリーを採用する場合、組織はどのようなデプロイ戦略を使用するかを決定する必要があります。最も一般的な戦略の1つはカナリアデプロイです。この戦略では、フリートのごく一部が最初に新しいバージョンに更新されます。このサブセットであるカナリアは、ことわざにある炭鉱のカナリアとして機能します。
アプリケーションの新しいバージョンに問題がある場合、影響を受けるユーザーはごく一部であり、変更を修正するか、迅速に元に戻すことができます。
ユースケース
カナリアデプロイは、ポッドフリートの一部にのみ機能を実装し、ユーザーベースの割合としての一時的にデプロイされた機能へのアクセス状況を監視する場合に使用できます。すべてがうまくいけば、問題が発生しないことを認識した上で、機能を本番環境にデプロイできます。
カナリアデプロイは、バックエンドのリファクタリング、パフォーマンスの向上、またはユーザーインターフェースが変わらない他の変更で、パフォーマンスが同じか、または向上していることを確認したい場合にも特に必要です。デベロッパーは、ユーザーインターフェースに影響する変更を伴うカナリアを使用する場合は注意が必要です。デフォルトでは、同じユーザーからのリクエストはカナリアポッドと非カナリアポッドの間でランダムに分散されるため、混乱やエラーが発生する可能性があります。必要に応じて、Kubernetesサービスの定義でservice.spec.sessionAffinityをClientIPに設定することを検討してください。これはこのドキュメントのスコープ外です。
カナリアIngressによる高度なトラフィック制御
カナリアデプロイは、カナリアIngressを使用するとより戦略的になります。カナリアIngressは高度なトラフィックルーティングサービスで、ウェイト、セッション、Cookieなどの要素に基づいて、安定したデプロイとカナリアデプロイ間の受信HTTPリクエストを制御します。GitLabは、自動デプロイアーキテクチャでこのサービスを使用し、ユーザーが新しいデプロイを迅速かつ安全にロールアウトできるようにします。
カナリアデプロイでカナリアIngressを設定する方法
Auto DevOpsパイプラインがv2.0.0+``auto-deploy-imageを使用している場合、カナリアIngressはデフォルトでインストールされます。カナリアIngressは、新しいカナリアデプロイを作成すると利用可能になり、カナリアデプロイが本番環境にプロモートされると削除されます。
これは、最初からの設定フローの例です:
- Auto DevOps対応プロジェクトを準備します。
- プロジェクトにKubernetesクラスターを設定します。
- クラスターにNGINX Ingressをインストールします。
- 上記で割り当てられたIngressエンドポイントに基づいて、ベースドメインを設定します。
- Auto DevOpsパイプラインで
v2.0.0+``auto-deploy-imageが使用されているかどうかを確認します。そうでない場合は、ドキュメントに従ってイメージバージョンを指定します。 - 新しいAuto DevOpsパイプラインを実行して、
productionジョブが成功し、本番環境が作成されていることを確認します。 - Auto DevOpsパイプラインの
canaryデプロイメントジョブを構成します。 - 新しいAuto DevOpsパイプラインを実行して、
canaryジョブが成功し、カナリアIngressでカナリアデプロイが作成されていることを確認します。
デプロイボードにカナリアIngressデプロイを表示する(非推奨)
この機能は、GitLab 14.5で非推奨になりました。
カナリアデプロイを表示するには、デプロイボードを適切に構成する必要があります:
- デプロイボードを有効にする手順に従います。
- カナリアデプロイを追跡するには、Kubernetesデプロイとポッドに
track: canaryというラベルを付ける必要があります。すぐに開始するには、GitLabが提供するカナリアデプロイ用の自動デプロイテンプレートを使用できます。
デプロイに応じて、ラベルはstableまたはcanaryのいずれかである必要があります。GitLabは、ラベルがないか空白の場合、トラックラベルをstableと見なします。他のトラックラベルは、canary(一時的)と見なされます。これにより、GitLabはデプロイが安定しているか、カナリア(一時的)かを検出できます。
デプロイボードを構成し、パイプラインを少なくとも1回実行した後、パイプライン > 環境の順にクリックして、環境ページに移動します。パイプラインの実行中に、デプロイボードはカナリアポッドを明確にマークするため、各環境とデプロイのステータスを迅速かつ明確にインサイトできます。
カナリアデプロイはデプロイボードに黄色のドットでマークされているため、すぐに気付くことができます。
カナリアIngressの現在のトラフィックウェイトを確認する方法(非推奨)
この機能は、GitLab 14.5で非推奨になりました。
デプロイボードにアクセスします。
右側の現在のウェイトを表示します。
カナリアIngressのトラフィックウェイトを変更する方法(非推奨)
この機能は、GitLab 14.5で非推奨になりました。
GraphiQLを使用するか、GraphQL APIにリクエストを送信して、環境のデプロイボードでトラフィックウェイトを変更できます。
デプロイボードを使用するには:
- プロジェクトの操作 > 環境に移動します。
- 右側のドロップダウンリストで新しいウェイトを設定します。
- 選択を確定します。
GraphiQLを使用した例を次に示します:
GraphiQL Explorerにアクセスします。
environmentsCanaryIngressUpdateGraphQLミューテーションを実行します: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 } }リクエストが成功した場合、
errors応答には空の配列が含まれます。GitLabは、カナリアIngressのウェイトパラメータを更新するために、PATCHリクエストをKubernetesクラスターに送信します。

