目次
こんにちは、急に春らしく暖かい気候が到来し梅が早々に散り
スギ花粉が猛威を奮っている様ですが、まだ花粉症は発症していない高田です
私はどちらかというと春の睡魔が甚だしくて、寝ても寝足りません…
さて、２週間ほど前の2023年2月27日にGoogle Cloud (GCP) Deploy の verify 機能がGAになったとのことで
早速どんな感じで使えるのか試してみました！
なお、Coud Deploy の基本的な動作、所感についてはこちらの記事 をご覧いただければと思います
また、公式ドキュメントのページはこちらです
事前準備
必要な権限やロールが足りてるか確認しておく
今回はGoogle Kubernetes Engine (以下GKE)でCloud Deployを実施するため以下が必要になります
- Kubernetes 開発者の権限
- clouddeploy.jobRunner ロール
設定についての詳細は公式ドキュメント参照されていますのでそちらをどうぞ
GKE Clusterの作成しておく
Cloud Deploy を使ってGKE をデプロイする場合、対応しているクラスタの種類としては
- スタンダード版
- Autopilot
- 限定公開クラスタ
で動作します。限定公開クラスタも対応しているのは有難いですね！
ただし前記事にもある通りクラスタのネットワーク設定をしておかないと、リリースのタイミングでハマるかもしれないので要注意です
今回私はWebコンソールでAutopilotにしてGKEクラスタ “takada-cl” を作成しました
Cloud Deploy の準備
ここからはCloud Deployの設定です
Cloud Deployの基本的な動作記事と同様、初めにデリバリーパイプラインとそのターゲットを指定する必要がありますのでそのyamlを記述します
デプロイ検証用のために1つ以上はターゲットを構成する必要があるとのことで、こんな感じのyamlファイルを準備しました
デプロイ検証機能のverifyスタンザがどのタイミングで動作するのかイメージしづらかったので敢えて承認フローが必要となるよう”requireApproval: true”を設定しています
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へ登録します
gcloud deploy apply --file clouddeploy.yaml --region=us-central1 --project {プロジェクト名}Webコンソールでデリバリーパイプラインが作成されたのを確認できました
Skaffold の構成
検証のための Skaffold を構成します
ポイントは以下の通り
- ここの”manifests:”以下3行は、過去記事の kustomizeを使用したmanifest をデプロイするよう記述しています
- Kustomizeのデプロイ指定を記述する際の注意点として
overlaysより深い階層でskaffold.yamlのmanifest定義を記述するとCloud Deploy時のビルド中baseを参照できずにビルド失敗します - まずは検証失敗を確認したいので、安直ですがverifyスタンザの部分はshellでexit code 1を返すように記載しました
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 動作確認
では以下のコマンドにてリリースしてみます
gcloud deploy releases create v1 --delivery-pipeline=takada-demo --region=us-central1 --images=nginx=nginx:1.23.3Webコンソールで確認してみるとまだ承認待ちの状態になっているv1が作成されていますのでリンクを辿っていきます
この段階でリリースを作成した時のCloud Buildのログやmanifestなどがリンクになっているmanifestの内容もブラウザで確認が可能です
試しに、yamlファイルを表示してみました
Chromeブラウザだと別タブで表示されます
レビューしやすそうですね
それでは、先ほどの画面から承認してみます
画面遷移して、デプロイ開始の通知が画面中央下に出るので「ロールアウトを表示」を選択します
デプロイ直後は処理中となるので、ステータスが変わるまで待ちます
しばらくするとレンダリングにあるVerificationのステータスが失敗となりました
「確認ログ」からビルドログを確認してみるとexit code 1によってERRORになり検証失敗になっていることが確認できました！
Deplomentは成功ステータスですがロールアウト自体も失敗のステータスとなっています
これは公式ドキュメントの通りとなります（抜粋）：
Skaffold は、skaffold.yaml の verify スタンザで指定されたテスト（複数可）を呼び出し、デプロイされたアプリケーションに対して実行します。
いずれかのテストに失敗した場合、検証は失敗します。
- 検証が失敗した
- ロールアウトも失敗します。
- 検証中にデプロイが失敗した場合は、ロールアウトを検査して確認できます。
Webコンソール画面の上部でリニューアル版が予定されている様ですが、このPREVIEWからも確認してみます
manifestの要素別に確認ができるので分かりやすく、cloudbuildのログも同画面内で見られます
いちいち別画面へ遷移せずに確認できるのはいいですね
失敗した認証の再試行
verifyスタンザは、検証のリトライが可能です
今回の環境でのコマンドは以下になります
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版画面の以下）
リトライ実行直後、Webコンソール上でも処理中の画面に切り替わっているのが確認できます
リトライ分のビルドログが増えていることも確認できました！
※今回のmanifestはexitステータスコードを1で返し続けるので何度リトライしても確実に失敗してしまいます
失敗しないケースを見てみる
shellコマンドでビルドログにechoで適当に文字出力させるようにしたものを、リリースバージョンを上げてデプロイしてみます
skaffold.yamlは以下の様に修正しました
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!!!'"]それではリリースを作成します
gcloud deploy releases create v2 --delivery-pipeline=takada-demo --region=us-central1 --images=nginx=nginx:1.23v2が追加されているので、承認します
ロールアウトの処理を再度待ってしばらくすると、Verificationが成功に変わりました！
ログも見てみます
ちゃんとskaffold.yamlに指定した文字列が出力されていることを確認できていますね
後片付け
デリバリーパイプラインでロールアウト情報が入っている場合--forceのオプションを含めることでパイプラインの削除が行えます（元には戻せないので注意）
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コマンドを実行してた時もあり、結果は「そのバージョンは既にリリースされてるよ」と怒られたりしてました
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にしてみるのも良さそうです。
それでは、本日はここまで！
