デプロイを確認する

このドキュメントでは、Cloud Deploy のデプロイを検証する方法について説明します。

任意のターゲットにデプロイしたアプリケーションが正しく動作していることを検証するため、Cloud Deploy を構成できます。検証は独自のテストイメージを使用して行われ、デプロイの完了後にテストを実行するように Cloud Deploy を構成します。

デプロイの検証の仕組み

  1. 実行するタスクを定義して、デプロイ検証のデリバリー パイプラインで 1 つ以上のターゲットを構成します。

  2. アプリケーションがデプロイされると、Cloud Deploy は Cloud Deploy 実行環境で検証タスクを実行します。

    実行されたテストの成功または失敗は、検証の成功または失敗を示します。

    • 検証の成功は、コンテナによって生成された終了コードによって確認されます。

      0 は成功を示します。ゼロ以外の終了コードは失敗を示します。想定される検証結果を生成するには、コンテナが適切な終了コードで終了するようにします。検証の一部として複数のコンテナが実行される場合、検証が成功するには、すべてのコンテナが成功する必要があります。

    • 検証が失敗した場合は、ロールアウトも失敗します。

    • 検証中にデプロイが失敗した場合は、ロールアウトを検査して確認できます。

       Google Cloud コンソールでのロールアウトの詳細(確認ステータスなど)

  3. 失敗した検証は無視するか、再試行できます。

    進行中の検証ジョブを終了することもできます。

検証に使用されるコンポーネント

ロールアウトリソースには、デプロイの検証をサポートする次のオブジェクトが含まれています。

  • フェーズ

    論理的にグループ化された、ロールアウト内のオペレーション(ジョブ)のコレクション(デプロイ、デプロイと検証など)。

  • ジョブ

    ロールアウト時に実行される特定のオペレーション(デプロイ、検証など)。

  • ジョブ実行

    ロールアウト リソースの子であるジョブ実行は、ジョブのインスタンスです(デプロイの試行など)。

Cloud Deploy リソースの詳細については、Cloud Deploy サービス アーキテクチャをご覧ください。

デプロイの検証用に Cloud Deploy を構成する

Cloud Deploy ターゲットのデプロイ検証を有効にするには、この例に示すように、デリバリー パイプラインの進行状況で、特定のターゲットに verify スタンザを追加します。

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-demo-app
description: main application pipeline
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
     standard:
       verify:
         tasks:
         - type: container
           image: "VERIFY_IMAGE"
           command: [COMMANDS_TO_RUN]
           args: [LIST_OF_ARGS]
           env: {VERIFY_TASK_ENV_MAP}

この YAML では:

  • VERIFY_IMAGE

    確認ジョブで実行するイメージの名前です。たとえば、Artifact Registry イメージの場合は us-central1-docker.pkg.dev/gcp-project-id-12345/my-repository/my-app:v1.2 です。

  • COMMANDS_TO_RUN

    コンテナで実行するエントリポイントのリストです。"/bin/sh" は、シェルを呼び出すためにここで指定する一般的なコマンドです。

  • LIST_OF_ARGS

    コマンドに提供する引数のリストです。これは、各引数が引用符で囲まれたカンマ区切りのリストです。COMMAND_TO_RUN"/bin/sh" の場合、ここでの引数の 1 つは "-c" になり、別の引数は呼び出したシェルで実行するコマンドの全体です。

    次に例を示します。

    command: ["/bin/sh"]
    args: ["-c", `echo "This command ran!"`]
    
  • VERIFY_TASK_ENV_MAP

    コンテナに渡される環境変数のマップです(KEY:VAL 形式)。

検証オペレーションは、独自の実行環境内で実行されます。この実行環境は、RENDERDEPLOY と同様に VERIFY に構成できます。

アプリケーション クラスタで検証を実行する

デフォルトでは、デプロイの検証は Cloud Deploy 実行環境で実行されます。アプリケーションが動作しているのと同じクラスタで検証を実行するように Skaffold を構成することもできます。

クラスタで検証コンテナを実行するには、skaffold.yamlverify スタンザで検証コンテナを構成する必要があります。定義されたコンテナごとに、executionMode.kubernetesCluster も設定する必要があります。

verify:
- name:
  container:
    name:
    image:
    command:
    args:
  executionMode:
    kubernetesCluster:

以下に、アプリケーション クラスタで検証コンテナを呼び出す executionMode を含む検証スタンザの例を示します。

verify:
- name: integration-test-container
  container:
    name: integration-test-container
    image: integration-test-container
  executionMode:
    kubernetesCluster: {}

また、配信パイプライン構成内で verify スタンザを true に設定する必要があります。

次に、dev ターゲットで検証が有効になっているデリバリー パイプライン定義の例を示します。

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-demo-app
description: main application pipeline
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
     standard:
       verify: true

この機能は、Cloud Run ではなく、GKE へのデプロイでのみ使用できます。Cloud Run へのデプロイについては、Cloud Deploy 実行環境でのみ検証を実行できます。

並行デプロイの場合、検証はマルチターゲットで構成され、検証コンテナは各子ターゲットで実行されます。

jobManifestPathoverrides のプロパティを kubernetesCluster に指定して、検証コンテナのマニフェストとオーバーライドする値を指すこともできます。(overrides は、置き換える値の Kubernetes インライン JSON を受け取ります)。詳細

executionMode スタンザの使用は任意です。省略すると、Skaffold は Cloud Deploy 実行環境で検証コンテナを実行します。

検証を再試行する

検証ジョブが失敗した場合は、検証を再試行して、新しいジョブ実行を作成できます。

gcloud deploy rollouts retry-job ROLLOUT_NAME \
             --job-id=JOB_ID \
             --phase-id=PHASE_ID \
             --delivery-pipeline=PIPELINE_NAME \
             --release=RELEASE_NAME \
             --region=REGION

検証を再試行すると、ロールアウトの状態が FAILED から IN_PROGRESS に変わります。

検証ジョブが失敗したロールアウトの検証のみ再試行できます。

使用可能な環境変数

Cloud Deploy では、実行環境で次の環境変数を指定し、入力します。これらの環境変数は、デプロイフック検証ジョブカスタム ターゲットのレンダリングまたはデプロイの一部として使用できます。

  • ANTHOS_MEMBERSHIP

    タイプが ANTHOS のターゲットの場合、Anthos メンバーシップの完全なリソース名。

  • CLOUD_RUN_LOCATION

    タイプが RUN のターゲットの場合、Cloud Run サービスがデプロイされているリージョン。

  • CLOUD_RUN_PROJECT

    タイプが RUN のターゲットの場合、Cloud Run サービスが作成されたプロジェクト。

  • CLOUD_RUN_SERVICE

    タイプが RUN のターゲットの場合、デプロイされた Cloud Run サービスの名前。

  • CLOUD_RUN_SERVICE_URLS

    タイプが RUN のターゲットの場合、エンドユーザーがサービスへのアクセスに使用する 1 つまたは複数の URL(カンマ区切りのリスト)。これらは、Google Cloud コンソールで、サービスの Cloud Run サービスの詳細で確認できます。URL は、Cloud Run サービスが正常にデプロイされた後に Cloud Run によって生成されます。そのため、この環境変数は postdeploy フックと検証ジョブでのみ使用できます。

  • CLOUD_RUN_REVISION

    タイプが RUN のターゲットの場合、Cloud Run サービスの特定のリビジョン。

  • GKE_CLUSTER

    タイプが GKE のターゲットの場合、Google Kubernetes Engine クラスタの完全なリソース名。例: projects/p/locations/us-central1/clusters/dev

  • TARGET_TYPE

    ターゲットの特定のランタイム タイプ。GKEANTHOSRUN のいずれか。 カスタム ターゲットの場合、これは設定されません。

  • CLOUD_DEPLOY_LOCATION

    Cloud Deploy リソースを含むリージョン。

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    デリバリー パイプラインの ID。

  • CLOUD_DEPLOY_TARGET

    ターゲットの ID。

  • CLOUD_DEPLOY_PROJECT

    Cloud Deploy リソースを含むプロジェクトの Google Cloud プロジェクト番号。

  • CLOUD_DEPLOY_PROJECT_ID

    プロジェクトの Google Cloud プロジェクト ID。

  • CLOUD_DEPLOY_RELEASE

    検証が実行されるリリースの ID。

  • CLOUD_DEPLOY_ROLLOUT

    フックのジョブを含むロールアウトの ID。

  • CLOUD_DEPLOY_JOB_RUN

    ジョブの現在の実行を表すジョブ実行の ID。

  • CLOUD_DEPLOY_PHASE

    デプロイフック、検証ジョブ、カスタム レンダリングまたはデプロイのジョブを含むロールアウトのフェーズ

次のステップ