検索

5.3.5. blue-green デプロイメントストラテジーを使用したトラフィックのルーティングおよび管理

download PDF

Blue-green デプロイメントストラテジー を使用して、実稼働バージョンのアプリケーションから新規バージョンにトラフィックを安全に再ルーティングすることができます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • OpenShift CLI (oc) をインストールしている。

手順

  1. アプリケーションを Knative サービスとして作成し、デプロイします。
  2. 以下のコマンドから出力を表示して、サービスのデプロイ時に作成された最初のリビジョンの名前を検索します。

    $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

    コマンドの例

    $ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'

    出力例

    $ example-service-00001

  3. 以下の YAML をサービスの spec に追加して、受信トラフィックをリビジョンに送信します。

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 100 # All traffic goes to this revision
    ...
  4. 以下のコマンドを実行して、URL の出力でアプリケーションを表示できることを確認します。

    $ oc get ksvc <service_name>
  5. サービスの template 仕様の少なくとも 1 つのフィールドを変更してアプリケーションの 2 番目のリビジョンをデプロイし、これを再デプロイします。たとえば、サービスの imageenv 環境変数を変更できます。サービスの再デプロイは、サービスの YAML ファイルを適用するか、Knative (kn) CLI をインストールしている場合は、kn service update コマンドを使用します。
  6. 以下のコマンドを実行して、サービスを再デプロイする際に作成された 2 番目の最新のリビジョンの名前を見つけます。

    $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

    この時点で、サービスの最初のバージョンと 2 番目のリビジョンの両方がデプロイされ、実行されます。

  7. 既存のサービスを更新して、2 番目のリビジョンの新規テストエンドポイントを作成し、他のすべてのトラフィックを最初のリビジョンに送信します。

    テストエンドポイントのある更新されたサービス仕様の例

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 100 # All traffic is still being routed to the first revision
        - revisionName: <second_revision_name>
          percent: 0 # No traffic is routed to the second revision
          tag: v2 # A named route
    ...

    YAML リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 番目のリビジョンがステージングされます。トラフィックはメインの URL の 2 番目のリビジョンにルーティングされず、Knative は新たにデプロイされたリビジョンをテストするために v2 という名前の新規サービスを作成します。

  8. 以下のコマンドを実行して、2 番目のリビジョンの新規サービスの URL を取得します。

    $ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"

    この URL を使用して、トラフィックをルーティングする前に、新しいバージョンのアプリケーションが予想通りに機能していることを検証できます。

  9. 既存のサービスを再度更新して、トラフィックの 50% が最初のリビジョンに送信され、50% が 2 番目のリビジョンに送信されます。

    リビジョン間でトラフィックを 50/50 に分割する更新サービス仕様の例

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 50
        - revisionName: <second_revision_name>
          percent: 50
          tag: v2
    ...

  10. すべてのトラフィックを新しいバージョンのアプリケーションにルーティングできる状態になったら、再度サービスを更新して、100% のトラフィックを 2 番目のリビジョンに送信します。

    すべてのトラフィックを 2 番目のリビジョンに送信する更新済みのサービス仕様の例

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 0
        - revisionName: <second_revision_name>
          percent: 100
          tag: v2
    ...

    ヒント

    リビジョンのロールバックを計画しない場合は、これを 0% に設定する代わりに最初のリビジョンを削除できます。その後、ルーティング不可能なリビジョンオブジェクトにはガベージコレクションが行われます。

  11. 最初のリビジョンの URL にアクセスして、アプリケーションの古いバージョンに送信されていないことを確認します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.