リリース戦略の選択: ZadigX、Alibaba Cloud、Argo、Spinnaker、Harness、Codefresh...

ソフトウェアの開発と運用の分野において、グレースケールリリースは、潜在的なリスクと影響を軽減するために、新しいバージョンを段階的にユーザーにプッシュするために使用される重要な展開戦略です。プラットフォームごとに独自の要件と制限を満たす必要があるため、グレースケールリリースの実装方法が異なる場合があります。

この記事では、Grayscale がリリースしたさまざまなプラットフォームを包括的に比較します。特に、ZadigX、Alibaba Cloud、Harness、Spinnaker、Argo Rollouts などの主流プラットフォームに焦点を当てます。使用条件、実装原則、使用プロセス、水平方向の違いの比較を詳細に検討し、誰もが自分に最適なプラットフォームを選択できるようにします。

実施原理と使用プロセス

01ザディグX

ZadigX は、ブルーグリーン、カナリア、バッチグレースケール、Istio リリースなどのリリース戦略をサポートしています。以下では、ZadigX ブルーグリーンリリースの原理について簡単に紹介します。リリース戦略の使用に関する詳細については、公式ドキュメント[1]を参照してください。

利用条件

ワークロードには対応するサービスが必要であり、ワークロードラベルにはすべてのサービスのセレクターラベルが含まれます。

現在、ワークロードはデプロイメントタイプのみをサポートしています。

原理

ブルー環境をデプロイし、現在のワークロードをコピーし、新しいイメージをセットアップし、それを指すブルーサービスを作成します。

ブルー環境の展開が完了し、ユーザー検証タスクが実行されます

ブルーグリーンリリースを開始し、ブルーサービスを削除します

新しく作成されたワークロードにグリーンサービスをポイントします

古いワークロードを削除する

リリースプロセスが完了または中断されたら、青い環境を削除します。

構成プロセス

リリースワークフローはインターフェイスを通じて構成されます。詳細な設定については文献[1]を参照してください。 ZadigX は、マルチサービスオーケストレーションのブルーグリーンリリース、組み込みのベストプラクティス、シンプルで簡単な構成をサポートします。システムのユーザーシステム、権限管理、プロジェクト管理を組み合わせて、企業の個別の要求に応えます。

使用プロセス

[実行] ボタンをクリックし、更新するインスタンスとイメージを選択します。

写真

設定されたタスクに従ってワークフローが実行され、実行状況が下図のように表示されます。

写真

02アリババクラウド

Alibaba Cloud は、ブルーグリーンリリースやバッチリリースなどのグレースケールリリース戦略をサポートしています。以下では、ブルーグリーンリリースを例に、その原理と使用プロセスを簡単に紹介します。 Alibaba Cloud は Istio を使用してブルーグリーンリリースを実行します。詳細なプロセスについては公式ドキュメント[2]を参照してください。

前提

Service/VirtualService/DestinationRuleは同じ名前です
デプロイメントのラベルには、サービスのすべてのセレクターラベルが含まれます。

原理

Istio とその VirtualService DestinationRule リソースタイプに基づくトラフィック制御
青緑のリリースが始まります。現在のデプロイメントインスタンスに基づいて、アプリケーションデプロイメントインスタンスの新しいバージョンがブルー環境に作成されます。
サービスはLabelSelectorを通じて複数のバージョンのデプロイメントインスタンスに直接関連付けられており、Istioはこれらのサービスインスタンスを検出できます。
Istio の DestinationRule リソースオブジェクトを更新して、異なるバージョンのサブセットを設定し、VirtualService を更新してトラフィックルーティングルールと重みを設定します。
手動検証が完了すると、リリースが完了し、すべてのトラフィックがブルー環境に切り替えられ、元のグリーン環境インスタンスは削除されます。

構成プロセス

パイプラインはインターフェースで構成されます。詳細な設定については文書[2]を参照してください。複数のサービスのブルーグリーンリリースシナリオの場合、構成は比較的面倒です。

実行プロセス

パイプラインを実行し、ブルーグリーンリリースをトリガーし、Cookie ラベルを介して新しいバージョン環境にアクセスして機能検証を実行します。検証が OK の場合は、「完了」をクリックすると、トラフィックが新しいバージョンに切り替わります。検証に問題がある場合は、「ロールバック」をクリックします。

写真

03ハーネス

Harness は、ブルーグリーンリリース、ローリングリリース、カナリアリリースなどのリリース戦略をサポートします。デプロイメントとステートフルセットのワークロードをサポートし、K8s ネイティブサービスを通じてトラフィック制御を実行します。以下では、ブルーグリーンリリースを例に、Harness ブルーグリーンリリースの実行プロセスを簡単に紹介します。具体的な原則については公式ドキュメント[3]を参照してください。

写真

原理

最初の展開:

Harness は 2 つのサービスを作成し、それぞれアノテーションを構成します。 a.オンラインサービス: アノテーション:harness.io/primary-service: "true" b.テストサービス: アノテーション:harness.io/stage-service: "true"
青い環境では、元のバージョンのポッドセットを作成し、アノテーションを構成します:harness.io/color: blue
テストサービスは、青色の環境ポッドを指します。テストが成功すると、オンラインサービスも青い環境ポッドを指します。

2回目の展開:

グリーン環境に新しいバージョンのポッドを作成し、アノテーションを設定します。harness.io/color: green
サービスをテストして、グリーン環境ポッドの新しいバージョンを指すようにし、検証します。
オンラインサービスはグリーン環境の新しいバージョンのポッドを指し、テストサービスはブルー環境の古いバージョンのポッドを指します。

3 回目の展開:

ブルー環境の古いバージョンのポッドを新しいバージョンにアップグレードする
サービスをテストして、新しいバージョンのブルー環境ポッドを指すようにし、検証します。
オンラインサービスはブルー環境の新しいバージョンポッドを指し、テストサービスはグリーン環境を指します。

構成プロセス

ワークフローはインターフェースを通じて構成されます。詳細な設定については文献[3]を参照してください。設定項目が多く、ある程度の学習コストがかかります。

実行プロセス

ワークフローを実行すると、ブルーグリーンプロセスがトリガーされます。

写真

04コードフレッシュ

Codefresh は、ブルーグリーンリリース、カナリアリリース、デプロイメントワークロードをサポートします。以下は、Codefresh のブルーグリーンリリースプロセスの簡単な紹介です。詳細な実装原則については、公式ドキュメント[4]を参照してください。

原理

新しいバージョンを展開する
HEALTH_SECONDS 時間待機した後、タスクはポッドの新しいバージョンに対していくつかのヘルスチェックを実行します。手動でいくつかのチェックを実行することもできます。
待機時間が経過すると、エラーは発生せず、トラフィックは新しいバージョンに切り替わります。
エラーが発生した場合は、以前のバージョンにロールバックします

構成プロセス

ワークフローでは、サービスブルーグリーンプロセスの関連する構成を YAML 形式で定義します。詳細な設定については文書[4]を参照してください。

実行プロセス

Codefresh ワークフローを実行して、ブルーグリーンリリースをトリガーします。これは、単一のサービスのブルーグリーンリリースのみをサポートします。

写真

05スピネーカー

Spinnaker はブルーグリーンおよびカナリアリリース戦略をサポートし、ReplicaSet ワークロードのみをサポートします。以下は、Spinnaker を使用してブルーグリーンリリースを実装するプロセスの簡単な紹介です。具体的な原則については公式ドキュメント[5]を参照してください。

原理

ReplicaSet にアノテーション <traffic.spinnaker.io/load-balancers: '["service my-service"]'> を設定すると、Spinnaker は my-service セレクターに一致するラベルをその下の Pod ラベルに自動的に追加できます。

構成プロセス

ワークフローはインターフェースベースで構成されます。詳細な設定については文献[5]を参照してください。設定項目が多く、ある程度の学習コストがかかります。

実行プロセス

新しいバージョンのイメージのレプリカセットを作成し、ブルー環境にデプロイします。
Spinnakerは、アノテーションに基づいて指定されたサービスにレプリカセットの新しいバージョンをバインドします。
テストが完了したら、ReplicaSetの元のバージョンは無効化ステージを通じてオフラインになります。

06Argoのロールアウト

Argo Rollouts は、ブルーグリーンリリースやカナリアリリースなどのリリース戦略をサポートしています。以下は、Argo Rollouts を使用したブルーグリーンリリースプロセスの簡単な紹介です。詳しい原理や使用手順については公式ドキュメント[6]を参照してください。

原理

ロールアウトCRDを使用してデプロイメントを置き換え、元の機能に基づいて複数のリリース戦略をサポートします。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollout-bluegreen spec: replicas: 2 revisionHistoryLimit: 2 selector: matchLabels: app: rollout-bluegreen template: metadata: labels: app: rollout-bluegreen spec: containers: - name: rollouts-demo image: argoproj/rollouts-demo:blue imagePullPolicy: Always ports: - containerPort: 8080 strategy: blueGreen: # activeService specifies the service to update with the new template hash at time of promotion. # This field is mandatory for the blueGreen update strategy. activeService: rollout-bluegreen-active # previewService specifies the service to update with the new template hash before promotion. # This allows the preview stack to be reachable without serving production traffic. # This field is optional. previewService: rollout-bluegreen-preview # autoPromotionEnabled disables automated promotion of the new stack by pausing the rollout # immediately before the promotion. If omitted, the default behavior is to promote the new # stack as soon as the ReplicaSet are completely ready/available. # Rollouts can be resumed using: `kubectl argo rollouts promote ROLLOUT` autoPromotionEnabled: false

構成プロセス

ブルーグリーンリリースプロセスは YAML 形式で定義されます。詳細な設定については文書[6]を参照してください。

実行プロセス

Argo は、エンタープライズレベルの管理機能がないシンプルなダッシュボードを提供します。

写真

07Fluxcd / フラガー

Flagger は、ブルーグリーンリリースやカナリアリリースなどのリリース戦略をサポートします。以下は、Flagger を使用したブルーグリーンリリースプロセスの簡単な紹介です。詳細については公式ドキュメント[6]を参照してください。

原理

実装されたカナリア型CRDを使用してデプロイメントを管理し、複数のリリース戦略をサポートします。
ブートストラップサービスの作成: 起動時に、Flagger は 3 つの ClusterIP サービス (app-primary、app-canary、app) と、app-primary という名前のブルーバージョンのデプロイメントを作成します。
新しいバージョンを検出: Flaggerが新しいバージョンを検出すると、グリーンバージョンを拡張し、適合テストを実行します。
一貫性テストを実行する: グリーンバージョンにアクセスするには、app-canary ClusterIP サービスに対して一貫性テストを実行する必要があります。
負荷テストの開始: 一貫性テストに合格すると、Flagger は負荷テストを開始し、カスタム Prometheus クエリを使用してテスト結果を検証します。
負荷テストを分析する: 負荷テスト分析が成功した場合、Flaggerは新しいバージョンをapp-primaryにアップグレードし、グリーンバージョンを削減します。