はじめに
前回以下でご紹介した自分の記事の続きで、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の使い分けなども記載があったので参照ください。