はじめに

前回以下でご紹介した自分の記事の続きで、Cloud Deployを利用しCloud Runへデプロイしますが、そのデプロイ前に承認を入れ、承認後、デプロイされ、その後の動作確認について記載します。

Cloud Deploy の承認及び動作確認の内容

Cloud Deploy での承認

前回実施したような手順で Cloud Deploy を動作させると、Cloud Deploy 上でそのままデプロイが流れます。
デプロイタイミングをはかったり、想定していたものであることを確認したり、デプロイ前に承認フェーズを設けることが可能です。

後の手順内でGUI上の表示も記載します。

Cloud Deploy でのデプロイ動作確認

デプロイ処理が動作し、実際のサービスに展開された後に、独自の実行環境で動作確認することが可能です。
仮にその動作確認が失敗した場合、デプロイ失敗とし、元のリリースバージョンへロールバックし戻すことが可能となります。
記事の内容としてはこちらのブログがわかりやすいです。

こちらも後の手順内でGUI上の表示も記載します。

手順

手順の流れは大きく以下となり、前回の記事と同様です。

ターゲット、デリバリーパイプラインを登録するための定義ファイル作成
ターゲット、デリバリーパイプラインを登録
Cloud Run のサービス定義ファイルを作成、Skaffold 構成ファイル作成
登録したパイプラインに Cloud Run のサービス定義を渡してデプロイ

ターゲット、デリバリーパイプラインを登録するための定義ファイル作成

今回以下のように作成しました。
前回との大きな違いは2点あります。

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: delivery-h-saito-run-02
 annotations: 
  key: test
 labels:
  key: test
description: デリバリー名
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
    standard:
      verify: true
---

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: dev
description: development service
requireApproval: true
run:
 location: projects/プロジェクト名/locations/リージョン

承認に係る変更点

区切りのうち後半の以下が追記され、これにより承認処理が加わります。

requireApproval: true

動作確認に係る変更点

区切りのうち前半に以下が追記され、これにより動作確認処理が加わります。

   strategy:
   standard:
     verify: true

ターゲット、デリバリーパイプラインを登録

この手順内では前回と同様です。
以下のコマンドを実行し Cloud Deployにデリバリープラン、ターゲットを登録します。

gcloud deploy apply --file 前の手順で作成したデリバリプランファイル --region=デプロイするリージョン --project 対象プロジェクト

Cloud Run のサービス定義ファイルを作成、Skaffold 構成ファイル作成

今回以下のようにSkaffoldのファイルを作成しております(サービスは前回と同様のものが利用でき変更は不要です)。
前回との変更点は動作確認に関する箇所がございます。

apiVersion: skaffold/v3alpha1
kind: Config
metadata: 
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}
verify:
- name: deploy-after-check
  container:
    name: alpine-wget
    image: alpine:latest
    command: ["/bin/sh"]
    args: ["-c", "wget https://対象URL"]

動作確認に係る変更点

以下を追記しております。

verify:
- name: deploy-after-check
  container:
    name: alpine-wget
    image: alpine:latest
    command: ["/bin/sh"]
    args: ["-c", "wget https://対象URL"]

name箇所にはその動作確認名称になり、1つに限らず複数定義できるため、用途に応じてわけてください。
独自環境で動作確認用のイメージを利用でき、記事内ではalpineのイメージを起動しています。
commandとargsの定義はCloud Buildでの記載と同様ですが、そのような形で、必要なコマンドを実行することが可能です。

登録したパイプラインに Cloud Run のサービス定義を渡してデプロイ

前回と同様に以下のコマンドを実行します。
※前回記載時に意識しませんでしたが、リリース名に$DATEや$TIMEなどの複数回実施してもかぶらない値を利用することでCloud Buildなどでの機械的な実行が可能です。

gcloud deploy releases create 'my-release-$DATE-$TIME' --project=プロジェクト名 --region=リージョン --delivery-pipeline=デリバリ名

結果確認

承認

上記によるデプロイが進むと、以下のように承認フェーズで待ちの状態となります。
確認ボタンを押下します。

以下のような画面に遷移しますので更に名前部分を押下します。

その後、承認するか拒否するかを選択できますので、承認すると後続の処理が進み、デプロイされます。

動作確認

以下はもう流れたあとになりますが、以下のようにフェーズ単位の状態が確認できます。

Verificationのログ箇所を参照するとverifyで指定したコマンドの実行結果が確認でき、以下の動作確認が正常に完了していることがわかります。

所感

Cloud Deploy の Cloud Run への対応に伴い、前回の記事ではまずはCloud Run への単純なデプロイを試しましたが、ちょっと実運用を意識し、承認と、近いうちにアップデートがあった、動作確認も含めて動作させてみました。
実際にやってみたところ、特段煩雑にならず定義ファイルも作成でき、実行もできたかと思います。
恐らく、Googleで完結しようと思う場合、Cloud BuildでBuildし、その後、Cloud Deployするというような構成も考えられると思います。
今までのCloud Buildではデプロイ成功だった後の確認は組むことはできても、その動作確認後に失敗時にロールバックするようなことを考える場合にはひと手間必要でしたが、今回はその手間も自動で行われ、更に承認部分も網羅することができるので、Google内で完結したければ、Cloud Buildから必要に応じて、Cloud Deployにしても良いのかなと思いました。
以下にその内容も含めて、Cloud Buildと Deployの使い分けなども記載があったので参照ください。