--- title: "Cloud Deploy やってみた：verify(デプロイの検証機能)を試してみた | grasys blog" url: "https://blog.grasys.io/post/takada/cloud-deploy202302/" description: "こんにちは、急に春らしく暖かい気候が到来し梅が早々に散り スギ花粉が猛威を奮っている様ですが、まだ花粉症は発症していない高田です 私はどちらかというと春の睡魔が甚だしくて、寝ても寝足りません… さて、２週間ほど前の2023年2月27日にGoogle Cloud (GCP) Deploy の verify 機能がGAに…" --- # Cloud Deploy やってみた：verify(デプロイの検証機能)を試してみた - ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[takada](/authors/takada/) - 公開日：2023年3月20日 - カテゴリー：[Tech](/categories/tech/) - タグ：[#Cloud Deploy](/tags/cloud-deploy/)[#Kubernetes](/tags/kubernetes/) ![Cloud Deploy やってみた：verify(デプロイの検証機能)を試してみた](/_astro/hero.Cgkjthkx_ZlptGx.webp) こんにちは、急に春らしく暖かい気候が到来し梅が早々に散り スギ花粉が猛威を奮っている様ですが、まだ花粉症は発症していない高田です 私はどちらかというと春の睡魔が甚だしくて、寝ても寝足りません… さて、２週間ほど前の2023年2月27日にGoogle Cloud (GCP) Deploy の verify 機能がGAになったとのことで 早速どんな感じで使えるのか試してみました！ なお、Coud Deploy の基本的な動作、所感についてはこ[ちらの記事](https://blog.grasys.io/post/izumi/gcd/) をご覧いただければと思います また、公式ドキュメントのページは[こちら](https://cloud.google.com/deploy/docs/verify-deployment?hl=ja)です ## 事前準備 ### 必要な権限やロールが足りてるか確認しておく 今回はGoogle Kubernetes Engine (以下GKE)でCloud Deployを実施するため以下が必要になります - Kubernetes 開発者の権限 - clouddeploy.jobRunner ロール 設定についての詳細は[公式ドキュメント参照](https://cloud.google.com/deploy/docs/deploy-app-gke?hl=ja#:~:text=%E3%81%AB%E5%8D%81%E5%88%86%E3%81%AA-,%E6%A8%A9%E9%99%90,-%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8)されていますのでそちらをどうぞ ### GKE Clusterの作成しておく Cloud Deploy を使ってGKE をデプロイする場合、対応しているクラスタの種類としては - スタンダード版 - Autopilot - 限定公開クラスタ で動作します。限定公開クラスタも対応しているのは有難いですね！ ただし[前記事にもある通りクラスタのネットワーク設定](/post/izumi/gcd/#1-gke%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%81%AE%E6%A7%8B%E7%AF%89)をしておかないと、リリースのタイミングでハマるかもしれないので要注意です 今回私はWebコンソールでAutopilotにしてGKEクラスタ “takada-cl” を作成しました ![GKE Clusterの作成しておくの画面](/_astro/01-takada-cl_AP-7d7ec770.CaKMDZef_Z21ANyd.webp) ## Cloud Deploy の準備 ここからはCloud Deployの設定です Cloud Deployの基本的な動作記事と同様、初めにデリバリーパイプラインとそのターゲットを指定する必要がありますのでそのyamlを記述します デプロイ検証用のために1つ以上はターゲットを構成する必要があるとのことで、こんな感じのyamlファイルを準備しました デプロイ検証機能のverifyスタンザがどのタイミングで動作するのかイメージしづらかったので敢えて承認フローが必要となるよう“requireApproval: true”を設定しています Plain textcontent\_copy ``` apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: takada-demo description: taada deploy server pipeline serialPipeline: stages: - targetId: takada-cl profiles: [] strategy: standard: verify: true --- apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: takada-cl description: FOR Cloud Deploy verify cluster requireApproval: true gke: cluster: projects/{プロジェクト名}/locations/us-central1/clusters/takada-cl ``` 上記の設定をCloud Deployへ登録します Plain textcontent\_copy ``` gcloud deploy apply --file clouddeploy.yaml --region=us-central1 --project {プロジェクト名} ``` Webコンソールでデリバリーパイプラインが作成されたのを確認できました ![Cloud Deploy の準備の画面](/_astro/02-delivery-pipeline_takada-demo-1024x195-bcbbde9f.00J_0K_-_1ly86H.webp) ## Skaffold の構成 検証のための Skaffold を構成します ポイントは以下の通り - ここの“manifests:“以下3行は、過去記事の [kustomizeを使用したmanifest](https://blog.grasys.io/post/takada/kusutomize_gke_1_14/) をデプロイするよう記述しています - Kustomizeのデプロイ指定を記述する際の注意点として `overlays` より深い階層でskaffold.yamlのmanifest定義を記述するとCloud Deploy時のビルド中baseを参照できずにビルド失敗します - まずは検証失敗を確認したいので、安直ですがverifyスタンザの部分はshellでexit code 1を返すように記載しました Plain textcontent\_copy ``` apiVersion: skaffold/v3alpha1 kind: Config build: artifacts: - image: nginx context: nginx manifests: kustomize: paths: - overlays/dev deploy: kubectl: {} verify: - name: nginx container: name: nginx image: nginx command: ["/bin/sh"] args: ["-c", "exit 1"] #failさせる ``` ## Cloud Deploy 動作確認 では以下のコマンドにてリリースしてみます Plain textcontent\_copy ``` gcloud deploy releases create v1 --delivery-pipeline=takada-demo --region=us-central1 --images=nginx=nginx:1.23.3 ``` Webコンソールで確認してみるとまだ承認待ちの状態になっているv1が作成されていますのでリンクを辿っていきます ![Cloud Deploy 動作確認の画面（1）](/_astro/03-2023-03-08-18.02.40-1024x491-8fa6ccd9.BFHrRorL_Z1JCNd9.webp) この段階でリリースを作成した時のCloud Buildのログやmanifestなどがリンクになっているmanifestの内容もブラウザで確認が可能です ![Cloud Deploy 動作確認の画面（2）](/_astro/04-2023-03-08-18.07.03-1024x618-40b0226b.CnKwmt3f_Z1t178n.webp) 試しに、yamlファイルを表示してみました Chromeブラウザだと別タブで表示されます レビューしやすそうですね ![Cloud Deploy 動作確認の画面（3）](/_astro/05-2023-03-08-18.13.17-7892b7c4.Lh-lznjN_ZjprFB.webp) manifest.yamlの表示リンクを選択した時の様子 それでは、先ほどの画面から承認してみます ![Cloud Deploy 動作確認の画面（4）](/_astro/06-approva_1-ed6ee66f.CkFGNlk4_3e95C.webp) ![Cloud Deploy 動作確認の画面（5）](/_astro/07-approva_2-5115a3ec.CHWXlEUW_Z1RPUJx.webp) 画面遷移して、デプロイ開始の通知が画面中央下に出るので「ロールアウトを表示」を選択します ![Cloud Deploy 動作確認の画面（6）](/_astro/08-2023-03-08-18.16.29-1024x578-5fc45a7e.BcGC_hBB_ocKQ1.webp) デプロイ直後は処理中となるので、ステータスが変わるまで待ちます ![Cloud Deploy 動作確認の画面（7）](/_astro/09-2023-03-08-18.16.29-2-1024x578-22cdade6.s9909-jZ_Zy4ar6.webp) しばらくするとレンダリングにあるVerificationのステータスが失敗となりました ![Cloud Deploy 動作確認の画面（8）](/_astro/10-2023-03-08-18.16.45-1024x618-1553a0e0.BzkdtbUe_163mrf.webp) 「確認ログ」からビルドログを確認してみるとexit code 1によってERRORになり検証失敗になっていることが確認できました！ ![Cloud Deploy 動作確認の画面（9）](/_astro/11-2023-03-08-18.24.32-1024x542-4feb6db6.BFPocbSs_Z20dX4u.webp) Deplomentは成功ステータスですがロールアウト自体も失敗のステータスとなっています これは公式ドキュメントの通りとなります（抜粋）： > Skaffold は、skaffold.yaml の verify スタンザで指定されたテスト（複数可）を呼び出し、デプロイされたアプリケーションに対して実行します。 > いずれかのテストに失敗した場合、検証は失敗します。 > > - 検証が失敗した > > - ロールアウトも失敗します。 > - 検証中にデプロイが失敗した場合は、ロールアウトを検査して確認できます。 > Webコンソール画面の上部でリニューアル版が予定されている様ですが、このPREVIEWからも確認してみます ![Cloud Deploy 動作確認の画面（10）](/_astro/12-2023-03-08-18.27.02-da9e7e47.BJ-UKDRR_ZEselp.webp) manifestの要素別に確認ができるので分かりやすく、cloudbuildのログも同画面内で見られます いちいち別画面へ遷移せずに確認できるのはいいですね ![Cloud Deploy 動作確認の画面（11）](/_astro/13-2023-03-08-18.27.20-1024x563-f87cddb7.51dw2Mqu_1CJUP0.webp) ## 失敗した認証の再試行 verifyスタンザは、検証のリトライが可能です 今回の環境でのコマンドは以下になります Plain textcontent\_copy ``` gcloud deploy rollouts retry-job v1-to-takada-cl-0001 \ --job-id=verify \ --phase-id=stable \ --delivery-pipeline=takada-demo \ --release=v1 \ --region=us-central1 ``` Webコンソールからでもリトライ実行が可能です（先ほどのPREVIEW版画面の以下） ![失敗した認証の再試行の画面（1）](/_astro/14-prev_retry-1024x563-354a7b46.VN5pa1ta_11ttv7.webp) リトライ実行直後、Webコンソール上でも処理中の画面に切り替わっているのが確認できます リトライ分のビルドログが増えていることも確認できました！ ![失敗した認証の再試行の画面（2）](/_astro/15-2023-03-08-18.33.41-9a77e31f.RH7jxK7m_Z1I3wGl.webp) ※今回のmanifestはexitステータスコードを1で返し続けるので何度リトライしても確実に失敗してしまいます ## 失敗しないケースを見てみる shellコマンドでビルドログにechoで適当に文字出力させるようにしたものを、リリースバージョンを上げてデプロイしてみます skaffold.yamlは以下の様に修正しました Plain textcontent\_copy ``` piVersion: skaffold/v3alpha1 kind: Config build: artifacts: - image: nginx context: nginx manifests: kustomize: paths: - overlays/dev deploy: kubectl: {} verify: #success - name: nginx container: name: nginx image: nginx command: ["/bin/sh"] args: ["-c", "echo 'Two more deliveries were not enough to rank at the top of the big run in SPL3!!!'"] ``` それではリリースを作成します Plain textcontent\_copy ``` gcloud deploy releases create v2 --delivery-pipeline=takada-demo --region=us-central1 --images=nginx=nginx:1.23 ``` v2が追加されているので、承認します ![失敗しないケースを見てみるの画面（1）](/_astro/16-2023-03-08-18.50.50-046df56b.CHS9F51b_2jH2p1.webp) ![失敗しないケースを見てみるの画面（2）](/_astro/17-2023-03-08-18.51.13-e4e37179.BvGN-r4z_Z13GixX.webp) ロールアウトの処理を再度待ってしばらくすると、Verificationが成功に変わりました！ ログも見てみます ![失敗しないケースを見てみるの画面（3）](/_astro/18-2023-03-08-18.55.47-1024x556-a2012789.-WlDMBeQ_1O77xU.webp) ちゃんとskaffold.yamlに指定した文字列が出力されていることを確認できていますね ![失敗しないケースを見てみるの画面（4）](/_astro/19-2023-03-08-19.04.26-bdfa6485.DW99bmCk_Z26p7mQ.webp) ## 後片付け デリバリーパイプラインでロールアウト情報が入っている場合`--force`のオプションを含めることでパイプラインの削除が行えます（元には戻せないので注意） Plain textcontent\_copy ``` gcloud deploy delivery-pipelines delete takada-demo --region us-central1 --force ``` 事前準備で作成したGKEのAutopilotクラスタの削除も忘れずに ## 所感 ### 個人的にハマりポイントかもと思ったこと Cloud Deployで検証に失敗した結果を受けて、その原因がCloud Delopyを構成するmanifest側にある時に skaffold.yamlやk8sのmanifestを書き換えたもの、つまりデプロイ構成に変更を加えているので、それはCloud Deployとしては別バージョンとして準備していることと同義になる よって**別バージョンでロールアウトを作成しないといけない**ということになかなか気づけなかったです 失敗したverifyスタンザのみ、再試行できるので上の要素に気づかない時に （設定変更したskaffold.yamlやoverlays側のmanifestの変更反映されないな）とか思いながら、retry-jobコマンドを何度も実行してしまいました また、今となっては当たり前なことでエラーになっていると理解しましたが、同じリリースバージョンのgcloudコマンドを実行してた時もあり、結果は「そのバージョンは既にリリースされてるよ」と怒られたりしてました Plain textcontent\_copy ``` ERROR: (gcloud.deploy.releases.create) ALREADY_EXISTS: Resource 'projects/grasys-study/locations/us-central1/deliveryPipelines/takada-demo-app/releases/takada-v1' already exists ``` ### こんな時に便利そう - 例えばnginxコンテナのディレクティブをカスタムしたものを、デプロイ前にverifyスタンザで疎通確認コマンドを入れ込んで検証する - prometheusのミドルウェア用のexporterをサイドカーで追加した際にメトリクス取れるか確認したりする - 使い方次第ではカナリアデプロイできるかもしれない 試す設定はそこまで複雑ではなかったですし原因の切り分けの曖昧さも回避でき、デプロイログも確認できるので、これを機会にデプロイ処理をCloud Deployにしてみるのも良さそうです。 それでは、本日はここまで！ ## この記事を書いた人 [![](/_astro/takada.qxt788oZ_MuJr4.webp)](/authors/takada/) ### [takada](/authors/takada/) takadaのプロフィールと執筆記事をご覧いただけます。 [プロフィールと記事一覧](/authors/takada/)