Google Cloud Next '22 で GAが発表されたCloud DeployによるCloud Run へのデプロイ(その2)(承認と動作確認フェーズお試し)

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

https://qiita.com/hirosait/items/8170e520ba24c396b9f0

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

https://cloud.google.com/deploy/docs/promote-release#console_1

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

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

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

https://cloud.google.com/blog/products/devops-sre/google-cloud-deploy-verifies-deploys-and-supports-cloud-run?hl=en

こちらも後の手順内で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=デリバリ名
```

## 結果確認
### 承認
上記によるデプロイが進むと、以下のように承認フェーズで待ちの状態となります。
確認ボタンを押下します。
![スクリーンショット 2022-11-12 3.34.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/44a05387-4f1c-9c1d-d08b-106a9014297a.png)
以下のような画面に遷移しますので更に名前部分を押下します。
![スクリーンショット 2022-11-12 3.34.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/45f63555-6f4b-dbe7-8b17-f23ccbe187da.png)
その後、承認するか拒否するかを選択できますので、承認すると後続の処理が進み、デプロイされます。
![スクリーンショット 2022-11-12 3.35.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/7556d418-be25-cc60-447e-5f996eaadae3.png)
### 動作確認
以下はもう流れたあとになりますが、以下のようにフェーズ単位の状態が確認できます。
![スクリーンショット 2022-11-12 4.05.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/95781442-9ab5-bec3-6632-223cca6c8a45.png)
Verificationのログ箇所を参照するとverifyで指定したコマンドの実行結果が確認でき、以下の動作確認が正常に完了していることがわかります。
![スクリーンショット 2022-11-12 4.04.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1720034/d207a712-7843-a066-9325-0ca3ac0237ed.png)

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

https://lp.cloudplatformonline.com/rs/808-GJW-314/images/App_Modernization_OnAir_q4_1027_Session.pdf