リリース戦略の選択: 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]を参照してください。

写真

写真

原理

最初の展開:

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

2回目の展開:

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

3 回目の展開:

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

構成プロセス

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

実行プロセス

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

写真

04コードフレッシュ

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

原理

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

構成プロセス

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

実行プロセス

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

写真

05スピネーカー

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

原理

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

構成プロセス

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

実行プロセス

1. 新しいバージョンのイメージのレプリカセットを作成し、ブルー環境にデプロイします。
2. Spinnakerは、アノテーションに基づいて指定されたサービスにレプリカセットの新しいバージョンをバインドします。
3. テストが完了したら、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]を参照してください。

原理

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

構成プロセス

K8s YAML メソッドは、ブルーグリーン リリース プロセスを構成するために使用されます。詳細な設定については文書[7]を参照してください。

使用プロセス

これは kubectl 適用モードで実行され、インターフェースベースの方法を提供しておらず、エンタープライズ レベルの管理機能がありません。