Google Cloud Deploy と Cloud Run のテスト

このドキュメントは、Google Cloud Deploy のデリバリー パイプラインを使用してコンテナを Cloud Run にデプロイするテスト チュートリアルです。このチュートリアルを終了すると、dev と prod の 2 つの環境で Cloud Run をターゲットとする CD パイプラインが作成されます。新しいコンテナ イメージをパイプラインのステージを介してデプロイして昇格させ、Google Cloud Console でプロセスをモニタリングできます。

このチュートリアルでは、いくつかの Google Cloud サービス（特に Config Controller）と、まだプレビュー版で一般提供されていない一般提供前のサービス（Cloud Run Admin API v2）を利用しています。Config Controller では、Kubernetes Resource Model（KRM）を使用して GCP リソースを宣言的にプロビジョニングできます。Google Cloud Deploy では、配信パイプラインの一部として Config Controller を使用して Cloud Run サービスを作成し、管理します。

ご質問、バグの発見、フィードバックがございましたら、clouddeploy-feedback-external@google.com までご連絡ください。

Cloud Shell のチュートリアル

このドキュメントの手順は、わかりやすい Cloud Shell ベースのチュートリアルにも含まれています。ガイダンスとコンテキストについては、このドキュメントのチュートリアルをご覧ください。

環境の設定

  1. 新しいプロジェクトを作成し、Google Cloud CLI のデフォルト プロジェクトを設定します。

    まず、新しいプロジェクトから始めることをおすすめします。

    gcloud config set project PROJECT_ID

    上記のコマンドで、PROJECT_ID は実際のプロジェクト ID に置き換えます。このドキュメント全体を通して、コード（コマンドとファイル）にはプレースホルダとして {PROJECT_ID} が含まれています。ここに置き換えると、ページを更新しない限り、このドキュメントのすべてのインスタンスが自動入力されます。

  2. 必要な API を有効にします。

    gcloud services enable \
    krmapihosting.googleapis.com \
    clouddeploy.googleapis.com \
    compute.googleapis.com \
    run.googleapis.com

    このコマンドにより、次の API が有効になります。これらの API は、このテストを完了するために必要です。

    • Compute Engine
    • Config Controller
    • Google Cloud Deploy
    • Cloud Build（Google Cloud Deploy を通じて有効化）
    • Cloud Storage（Google Cloud Deploy を通じて有効化）
    • Resource Manager
    • Cloud Run
    • Google Kubernetes Engine（Config Controller で有効化）

  3. Google Cloud CLI をインストールして構成していることを確認します。

    さらに、kubectl がインストールされていることを確認する必要があります。

    which kubectl || gcloud components install kubectl

    Cloud Shell からコマンドを実行する場合、これらのコンポーネントはすでにインストールされています。

  4. デフォルトの Compute Engine サービス アカウントを構成する

    デフォルトでは、Google Cloud Deploy はデフォルトの Compute Engine サービス アカウントを使用します。サービス アカウントには、すでに必要な権限がある場合があります。この手順は、デフォルトのサービス アカウントに対する自動のロール付与を無効にする組織を対象としています。

    次のコマンドを実行して、サービス アカウントに適切な権限があることを確認します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/clouddeploy.jobRunner"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
    --role="roles/container.developer"

  5. Google Cloud Deploy の概要を確認します。

    この概要は、Google Cloud Deploy サービスとコンセプトを理解するのに役立ちます。

Config Controller を設定する

Google Cloud Deploy は、Config Controller インスタンスを使用して Cloud Run サービスとリビジョンをデプロイします。

  1. Config Controller を作成する前に、デフォルト ネットワークがあることを確認します。

    gcloud compute networks list

    コンソールの出力が成功すると、次のように表示されます。

    NAME: default
SUBNET_MODE: AUTO
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:

    デフォルト ネットワークがない場合は、次のコマンドを実行します。

    gcloud compute networks create default --subnet-mode=auto

    出力が正しい場合は、このコマンドを実行する必要はありません。

    それでも問題が解決しない場合は、Config Controller のトラブルシューティング ガイドを参照するか、組織の管理者にお問い合わせください。

  2. Config Controller インスタンスを作成します。

    gcloud anthos config controller create cc-deployrun --location=us-central1

  1. デプロイ先のプロジェクト内で Config Controller の権限を付与します。次のコマンドは、Config Controller がプロジェクトの Cloud Run サービスを作成および管理するために必要な最小限の権限を付与します。

    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"

gcloud projects add-iam-policy-binding "PROJECT_ID" \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "roles/run.admin" \
    --project "PROJECT_ID"

gcloud projects add-iam-policy-binding "PROJECT_ID" \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "roles/iam.serviceAccountUser" \
    --project "PROJECT_ID"

構成ファイルを作成する

Google Cloud Deploy では、Skaffold を使用して、デプロイする対象と、個別のターゲットに対して適切にデプロイする方法の詳細が提供されます。このテストでは、run-dev と run-prod の 2 つのターゲットがあります。

Google Cloud Deploy Cloud Run のテスト ターゲット（run-dev と run-prod）

このセクションでは、skaffold.yaml ファイルを作成して、Google Cloud Deploy デリバリー パイプラインを介してアプリケーションをデプロイする Cloud Run マニフェストを指定します。また、ターゲット環境（run-dev-service.yaml と run-prod-service.yaml）ごとに 1 つずつ、Cloud Run サービスのマニフェストを作成します。

  1. マニフェストの新しいディレクトリを作成し、そのディレクトリに移動します。

    mkdir deploy-cloudrun
cd deploy-cloudrun

  2. このディレクトリに skaffold.yaml ファイルを作成します。

    skaffold.yaml は、パイプラインの各ターゲットに対して、特定のリリースに対してデプロイするマニフェストを Google Cloud Deploy に指示します。

    apiVersion: skaffold/v2beta26
kind: Config
profiles:
 - name: prod
   deploy:
     kubectl:
       manifests:
         - run-prod-*.yaml
 - name: dev
   deploy:
     kubectl:
       manifests:
         - run-dev-*.yaml

  3. 同じディレクトリに run-dev-service.yaml ファイルを作成します。

    この宣言型マニフェストは、Cloud Run サービスの dev 環境バージョンを表します。

    コンテナのスケーリングを 2 つのインスタンスに制限するなど、この環境用にカスタマイズされた設定に注意してください。ラベルと名前は、プロジェクト内のこのバージョンのサービスを区別するために使用されます。イメージ名は変数です。特定のコンテナ イメージではなく run-container です。これは、Google Cloud Deploy でリリースを作成するときに、特定のコンテナ イメージに置き換えられます。

    apiVersion: run.cnrm.cloud.google.com/v1beta1
kind: RunService
metadata:
  labels:
    cloud-deploy-target: run-dev
  name: deploytest-dev
  namespace: config-control
spec:
  ingress: INGRESS_TRAFFIC_ALL
  location: us-central1
  projectRef:
    external: projects/PROJECT_ID
  template:
    containers:
      - env:
          - name: environment
            value: dev
        image: run-container
    scaling:
      maxInstanceCount: 2
  traffic:
    - percent: 100
      type: TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST

  4. 同じディレクトリに run-prod-service.yaml ファイルを作成します

    このマニフェストは、Cloud Run サービスの prod バージョンを表します。更新された名前、ラベル、スケーリング設定と、run-container の再利用に注意してください。

    apiVersion: run.cnrm.cloud.google.com/v1beta1
kind: RunService
metadata:
  labels:
    cloud-deploy-target: run-prod
  name: deploytest-prod
  namespace: config-control
spec:
  ingress: INGRESS_TRAFFIC_ALL
  location: us-central1
  projectRef:
    external: projects/PROJECT_ID
  template:
    containers:
      - env:
          - name: environment
            value: prod
        image: run-container
    scaling:
      maxInstanceCount: 10
  traffic:
    - percent: 100
      type: TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST

デリバリー パイプラインとターゲットを作成する

Google Cloud Deploy デリバリー パイプラインとターゲットは、1 つのファイルでも別のファイルでも定義できます。このチュートリアルでは、わかりやすくするために単一のファイルを作成します。

  1. 最近作成したマニフェスト（/deploy-cloudrun/）を含むディレクトリで、clouddeploy.yaml ファイルを作成します。

    apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-run-app-1
description: main application pipeline
serialPipeline:
 stages:
 - targetId: run-dev
   profiles:
   - dev
 - targetId: run-prod
   profiles:
   - prod
---

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: run-dev
description: Cloud Run development environment
gke:
 cluster: projects/PROJECT_ID/locations/us-central1/clusters/krmapihost-cc-deployrun
---

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: run-prod
description: Cloud Run production environment
gke:
 cluster: projects/PROJECT_ID/locations/us-central1/clusters/krmapihost-cc-deployrun

    cloudeploy.yaml は、デリバリー パイプラインの 2 つのステージ（run-dev と run-prod）の進行シーケンスを定義します。このファイルは、これら 2 つのステージのそれぞれのターゲットも定義します。

    どちらのターゲットも、GKE クラスタと同じ Config Controller を指しています。この Config Controller は Config Controller の作成時に作成された基盤となる GKE クラスタでサポートされているため、それぞれのマニフェストを使用して環境ごとに Cloud Run サービスを作成します。

    GKE クラスタ

  2. Google Cloud Deploy にデリバリー パイプラインとターゲットを登録します。

    gcloud deploy apply --file clouddeploy.yaml --region=us-central1

    出力は次のようになります。

    Waiting for the operation on resource projects/sample-project/locations/us-central1/deliveryPipelines/my-run-app-1...done.
Created Cloud Deploy resource: projects/sample-project/locations/us-central1/deliveryPipelines/my-run-app-1.
Waiting for the operation on resource projects/sample-project/locations/us-central1/targets/run-dev...done.
Created Cloud Deploy resource: projects/sample-project/locations/us-central1/targets/run-dev.
Waiting for the operation on resource projects/sample-project/locations/us-central1/targets/run-prod...done.
Created Cloud Deploy resource: projects/sample-project/locations/us-central1/targets/run-prod.

リリースを作成してコンテナをデプロイする

構成ファイルを準備し、デリバリー パイプラインとターゲットを登録したら、デプロイするコンテナ イメージを表すリリース リソースを作成できます。サンプル コンテナを使用して、echoserver をデプロイします。

gcloud deploy releases create run-release-001 --project=PROJECT_ID --region=us-central1 --delivery-pipeline=my-run-app-1 --labels="use-case=my-cloud-run-experiment" --images=run-container="us-docker.pkg.dev/cloudrun/container/hello"

出力は次のようになります。

Creating temporary tarball archive of 4 file(s) totalling 2.0 KiB before compression.
Uploading tarball of [.] to [gs://sample-project_clouddeploy_us-central1/source/1643560782.447815-aed1fdf4973b4d25b9b7d09ff9fbbaa9.tgz]
Waiting for operation [operation-1643560782826-5d6cf50a08a8d-e40f7a45-ac4aa0ae]...done.
Created Cloud Deploy release run-release-001.
Creating rollout projects/sample-project/locations/us-central1/deliveryPipelines/my-run-app-1/releases/run-release-001/rollouts/run-release-001-to-run-dev-0001 in target run-dev...done.

これは最初のリリース（進行中の最初のターゲットへのデプロイ）であるため、Google Cloud Deploy は自動的にロールアウト リソースを作成し、進捗状況の最初のターゲット（run-dev）にアプリをデプロイします。ロールアウトが完了するまで数分待つことが必要な場合があります（ロールアウト状態: SUCCEEDED）。次のコマンドを使用して、ロールアウト ステータスを確認できます。

gcloud deploy rollouts list --delivery-pipeline=my-run-app-1 --region=us-central1 --release run-release-001

出力は次のようになります。

approvalState: DOES_NOT_NEED_APPROVAL
createTime: '2022-02-10T21:25:11.228171Z'
deployEndTime: '2022-02-10T21:26:37.984888Z'
deployStartTime: '2022-02-10T21:26:09.778897390Z'
deployingBuild: projects/435050644073/locations/us-central1/builds/59f588d1-0cbc-4c46-9574-7e3f3b763ae6
enqueueTime: '2022-02-10T21:26:09.108240Z'
etag: 5f57d54f8b11d20e
name: projects/sample-project/locations/us-central1/deliveryPipelines/my-run-app-1/releases/run-release-001/rollouts/run-release-001-to-run-dev-0001
state: SUCCEEDED
targetId: run-dev
uid: 9cab18e1dfea4054b7d182b707c21f75

アプリが最初のターゲットにデプロイされたので、Cloud Run サービス（deploytest-dev）が期待どおりに実行されていることを確認できます。

gcloud run services list --region=us-central1

出力は次のようになります。

✔
SERVICE: deploytest-dev
REGION: us-central1
URL: https://deploytest-dev-k5kzux4u6a-uc.a.run.app
LAST DEPLOYED BY: service-435050644073@gcp-sa-yakima.iam.gserviceaccount.com
LAST DEPLOYED AT: 2022-01-30T04:25:13.081829Z

リリースを昇格する

これで、アプリケーションが最初のターゲット run-dev にデプロイされたので、次のコマンドを使用してアプリケーションをプロモートします。

gcloud deploy releases promote --release=run-release-001 --delivery-pipeline=my-run-app-1 --region=us-central1 --project=PROJECT_ID

出力は次のようになります。

Promoting release run-release-001 to target run-prod.

Do you want to continue (Y/n)? Y

Creating rollout projects/sample-project/locations/us-central1/deliveryPipelines/my-run-app-1/releases/run-release-001/rollouts/run-release-001-to-run-prod-0001 in target run-prod...done.

Google Cloud Console からリリースをプロモートする

完了したら、もう一度 Cloud Run 本番環境サービスが実行されていることを確認します。

gcloud run services list --region=us-central1

出力は次のようになります。

✔
SERVICE: deploytest-dev
REGION: us-central1
URL: https://deploytest-dev-k5kzux4u6a-uc.a.run.app
LAST DEPLOYED BY: service-435050644073@gcp-sa-yakima.iam.gserviceaccount.com
LAST DEPLOYED AT: 2022-01-30T04:25:13.081829Z

✔
SERVICE: deploytest-prod
REGION: us-central1
URL: https://deploytest-prod-k5kzux4u6a-uc.a.run.app
LAST DEPLOYED BY: service-435050644073@gcp-sa-yakima.iam.gserviceaccount.com
LAST DEPLOYED AT: 2022-01-30T16:04:43.468907Z

Cloud Run サービス

Cloud Deploy コンソールで結果を表示する

デリバリー パイプラインを介してリリースの進行状況を確認するには、Google Cloud Deploy コンソールを開き、my-run-app-1 デリバリー パイプラインに移動します。

パイプラインの可視化におけるリリースの進行

リリースを確認する

デリバリー パイプラインの詳細ビュー内のリリース テーブルで関連する名前 run-release-001 をクリックすると、作成したリリースの詳細を表示できます。

リリースの詳細ビューでは、指定されたイメージ（コンテナ）パラメータ（ビルド アーティファクト）やレンダリングされたサービス マニフェストなどのアセットをさらに検査できます。

リリースの詳細

ロールアウトを確認する

各リリースは、リリースページにも一覧表示されます。ロールアウト名をクリックすると、ロールアウトの詳細が表示されます。ここでは、ロールアウトとレンダリング ログ、デプロイログの詳細情報を確認できます。

展開の詳細

Cloud Run コンソールでサービスを表示する

Cloud Run コンソールで作成されたサービスログを使用して、サービスが正しく起動したことを確認できます。

Cloud Run サービスログ

チャレンジ エクササイズ

この時点で、Cloud Run サービス デリバリー パイプラインが正常に作成され、開発環境から本番環境にコンテナをプロモートできるようになりました。以下に、Google Cloud Deploy で Cloud Run のデリバリー パイプラインを詳しく確認するために実施できるチャレンジ演習のリストを示します。

  • 本番環境 Service のデリバリー パイプラインに承認を追加します。

  • 独自の既存の Cloud Run サービスのいずれかを Google Cloud Deploy デリバリー パイプラインを使用するように変換します。

  • Kustomize を使用して、dev と prod の Cloud Run サービス マニフェストをパラメータ化します。（Google Cloud Deploy の Skaffold プロファイルのチュートリアルもご覧ください）。

クリーンアップ

このテストが完了したら、プロジェクトを削除するか、プロジェクト内のリソースを削除して、これらのリソースに対する Google Cloud アカウントへの課金を回避します。

  1. Config Controller を介してデプロイされた Cloud Run サービスをクラスタから直接削除します。

    Config Controller クラスタから名前空間を削除すると、作成されたすべての Cloud Run サービスが削除されます。

    kubectl -n config-control delete runservice deploytest-dev

    kubectl -n config-control delete runservice deploytest-prod

  2. Config Controller を削除します。

    gcloud anthos config controller delete cc-deployrun  --location=us-central1 --project=PROJECT_ID

  3. デリバリー パイプラインを削除します。

    gcloud deploy delivery-pipelines delete my-run-app-1 --force --region=us-central1 --project=PROJECT_ID

    これにより、デリバリー パイプライン自体と、Google Cloud Deploy がそのパイプライン用に作成したすべてのリリース リソースとロールアウト リソースが削除されます。

  4. Cloud Storage Console を使用して、Google Cloud Deploy が作成した Cloud Storage バケットを削除します。

    ストレージ バケットを識別するには、[PROJECT]_clouddeploy_[region] や [region].deploy-artifacts.[project-id].appspot.com などの命名規則と以下のコマンドを使用します。

    gsutil ls | egrep "_clouddeploy_|deploy-artifacts.PROJECT_ID.appspot.com" | xargs --max-lines=1 echo gsutil gsutil -m rm -r

    これにより、バケットのリストが正しいかどうかを確認した後に実行するコマンドが出力されます。

    gsutil rb gs://PROJECT_ID_clouddeploy_us-central1/
gsutil rb gs://us-central1.deploy-artifacts.PROJECT_ID.appspot.com/