GitLab CI/CDによるインクリメンタルロールアウト
アプリケーションの変更をロールアウトする際、リスク軽減策としてKubernetesポッドの一部のみに本番環境の変更をリリースすることが可能です。本番環境の変更を徐々にリリースすることで、エラー率やパフォーマンスの低下を監視し、問題がなければすべてのポッドをアップデートすることができます。
GitLabは、インクリメンタルロールアウトを使用して、Kubernetes本番システムへの手動トリガーロールアウトと時間指定ロールアウトの両方をサポートしています。手動ロールアウトを使用する場合、ポッドの各トランチのリリースは手動でトリガーされ、一方、時限ロールアウトでは、デフォルトの5分間の休止の後にトランチでリリースが実行されます。時間指定ロールアウトは、一時停止期間が経過する前に手動でトリガーすることもできます。
手動ロールアウトと時限ロールアウトは、Auto DevOpsによって制御されるプロジェクトに自動的に含まれますが、GitLab CI/CDを通して.gitlab-ci.yml の設定ファイルでも設定可能です。
手動トリガーロールアウトは継続的デリバリーで実装することができ、時間指定ロールアウトは介入を必要とせず、継続的デプロイ戦略の一部とすることができます。必要に応じて手動で介入しない限り、アプリが自動的にデプロイされるように両者を組み合わせることもできます。
私たちは3つのオプションを実証するためにサンプルアプリケーションを作成しました：
手動ロールアウト
.gitlab-ci.ymlを使って、手動でインクリメンタルロールアウトを行うようにGitLabを設定することができます。手動設定によって、この機能をよりコントロールできるようになります。インクリメンタルロールアウトのステップは、Kubernetesクラスターが作成されるときに設定される、デプロイ用に定義されたポッドの数に依存します。
例えば、アプリケーションに10ポッドがあり、10%のロールアウトジョブが実行された場合、アプリケーションの新しいインスタンスは1つのポッドにデプロイされ、残りのポッドにはアプリケーションの以前のインスタンスが表示されます。
まず、テンプレートを手動で定義します：
.manual_rollout_template: &manual_rollout_template
<<: *rollout_template
stage: production
when: manual
次に、各ステップのロールアウト量を定義します：
rollout 10%:
<<: *manual_rollout_template
variables:
ROLLOUT_PERCENTAGE: 10
ジョブがビルドされると、ジョブ名の横に再生ボタンが表示されます。ポッドの各ステージをリリースするには、再生を選択します。より低いパーセンテージのジョブを実行してロールバックすることもできます。100%に達すると、この方法ではロールバックできません。環境ページのロールバックボタンを使って古いバージョンを再デプロイすることでロールバックすることは可能です。
デプロイ可能なアプリケーションが利用可能で、手動トリガーのインクリメンタルロールアウトを実証します。
時限ロールアウト
時限ロールアウトは手動ロールアウトと同じように動作しますが、各ジョブがデプロイされる前に分単位で遅延が定義されている点が異なります。ジョブを選択するとカウントダウンが表示されます。
この機能を手動インクリメンタルロールアウトと組み合わせて、ジョブがカウントダウンしてからデプロイすることも可能です。
まず、テンプレートをtimedとして定義します：
.timed_rollout_template: &timed_rollout_template
<<: *rollout_template
when: delayed
start_in: 1 minutes
start_in 、遅延時間を定義します：
start_in: 1 minutes
次に、各ステップのロールアウト量を定義します：
timed rollout 30%:
<<: *timed_rollout_template
stage: timed rollout 30%
variables:
ROLLOUT_PERCENTAGE: 30
デプロイ可能なアプリケーションを用意し、時間指定ロールアウトの設定を実演します。
ブルーグリーンデプロイ
A/Bデプロイメントや赤黒デプロイメントとしても知られるこのテクニックは、デプロイ中のダウンタイムやリスクを減らすために使われます。インクリメンタル ロールアウトと組み合わせることで、デプロイによってイ シューが発生する影響を最小限に抑えることができます。
この手法では、2 つのデプロイ(「青」と「緑」ですが、任意の名前を使用できます)があります。これらのデプロイは、インクリメンタル ロールアウト中を除き、常に 1 つだけが有効です。
たとえば、青のデプロイは現在本番環境でアクティビティですが、緑のデプロイ はテスト用に「ライブ」ですが、本番環境にはデプロイされていません。イシューが発見された場合、本番環境のデプロイ(現在の青色)に影響を与えずに、緑色のデプロイを更新できます。テストでイシューが見つからなければ、本番環境を緑のデプロイに切り替え、 青は次のリリースのテストに使用できるようになります。
このプロセスでは、本番デプロイを停止して別のデプロイに切り替える必要がないため、ダウンタイムが短縮されます。両方のデプロイは並行して実行され、いつでも切り替えることができます。
デプロイ可能なアプリケーションの例として、.gitlab-ci.yml CI/CD 設定ファイル が用意されており、ブルーグリーン デプロイメントを実証しています。