Google Cloud Deploy を使用して Cloud Run で本番前環境を本番環境に昇格を読んだ。
Cloud Runの別のサービスを本番環境へ昇格できるというような事が書いてあり、どう実現しているんだろうと思って試したときのメモ。

このトピックに関するインタラクティブなチュートリアルへ直接移動する場合は、こちらをご利用ください。

チュートリアルがあるらしいのでやってみる。

チュートリアル開始。

次の名前の 3 つの Cloud Run サービスを my-project プロジェクトにデプロイしていきます。
test（dev と呼ばれることもあります）
staging
prod

このサービス間で昇格降格させる？

デリバリー パイプラインが、まだ作成されていない 3 つのターゲット環境を参照しています。

なんとなく意味はわかるけどGoogle Cloud Deployの用語を理解してからチュートリアルに望むとさらに理解できそう。

Google Cloudのチュートリアルは本当によくできている。
手順、実行コマンド、実行環境、エディタ、すべてが画面1つで完結するのが素晴らしい。

Google Cloud Deploy release は、特定のデリバリー パイプラインに関連付けられた 1 つ以上のコンテナ イメージの特定のバージョンです。リリースを作成すると、複数のターゲット（プロモーション シーケンス）を通じてプロモートできます。さらに、リリース レンダリングを作成すると、skaffold を使用してアプリケーションがレンダリングされ、そのリリース期間に使用されるポイントインタイム リファレンスとして出力が保存されます。

「さらに」以降がよくわからない。

今のパイプラインを確認。
staging > prodへロールアウトするパイプラインになっていてprodへ流すときは承認が必要ってことですか。なるほど。

yamlをよく読まないままチュートリアルを進めていた。
ロールアウトの順番やprodの承認はどこで定義されているのか確認する。

ロールアウトの順番

serialPipeline:
  stages:
    - targetId: test-cloudrun
      profiles: [test]
    - targetId: staging-cloudrun
      profiles: [staging]
    - targetId: prod-cloudrun
      profiles: [prod]

prodへのロールアウト時の承認

requireApproval: true

https://cloud.google.com/deploy/docs/promote-release?hl=ja#manage_approvals_for_a_delivery_pipeline

aliasコマンドを積極的に使っていこう

alias gcurl="curl -H \
    'Authorization: Bearer $(gcloud auth print-identity-token)' \
    "

ステージング環境へプロモート

gcurlで401 Unauthorizedが出る場合はおそらくトークンの有効期限が切れているのでこちらを再度実行する。

本番環境へプロモート

承認コマンド

gcloud deploy rollouts approve \
    hello-app-001-to-prod-cloudrun-0001 \
    --delivery-pipeline hello-app \
    --release hello-app-001

実際に運用するときはコマンドを打つ以外の方法で承認するはず。

プロモート完了

ロールバック方法
https://cloud.google.com/deploy/docs/roll-back?hl=ja

今回は初めてのデプロイなのでロールバックはできない。
新たにhello-app-002をデプロイするとhello-app-001へロールバックできる。

チュートリアルはここまで。実運用を視野に他の検証をしてみる。

新たにリリースを作ってそれを昇格するとどうなるか試したところ、テスト用のCloud Runに新たにリビジョンが作成された。

この時点でステージング、本番用のリビジョンは作成されておらずプロモートしたタイミングで作成された。

次にテスト環境用ターゲットのDockerイメージを変更してProdまでプロモートするとどうなるか確認。
ちゃんと変更後のイメージでCloud Runのリビジョンが作成された。

感想と疑問

感想

• プロモートするだけでCloud Runのリビジョンを作成してトラフィックをルーティングしてくれるのでデプロイパイプラインがシンプルになる。
• 環境ごとにGoogle Cloudプロジェクトが別れている場合、イメージからCloud Runをデプロイするプロセスを環境の数だけ明示的に定義しないといけないと思うけどそれが省けるのでシンプル。
• リリース前に本番環境のデータでテストしたい場合は最適な構成。
• Cloud Runのサービスごとにサービスアカウントを分けミニマムの権限を設定できるので複数の環境が同じGoogle Cloudプロジェクトに乗っていてもセキュリティは保てそう。

疑問

• フロントエンド、サーバサイドなど複数のCloud Runサービスで構成されているアプリケーションを同時にプロモートしたい場合はどうする？
• 1つのターゲットに複数のCloud Runサービスを同居できる？

フロントエンド、サーバサイドなど複数のCloud Runサービスで構成されているアプリケーションを同時にプロモートしたい場合はどうする？

複数の子ターゲットでマルチターゲットを構成してリリースすればできそう。
https://cloud.google.com/deploy/docs/parallel?hl=ja

後日、Cloud Deployを使ったカナリアリリース、マルチターゲットのハンズオンをやったのでメモを残しておく。

このチュートリアル。
https://github.com/google-cloud-japan/gig-training-materials/tree/main/gig06-03

カナリアリリースはCloud Deploy用のyamlへ以下のように設定する。
percentages: [25, 50]などとすると段階的なロールアウトが可能。

serialPipeline:
  stages:
  - targetId: run-qsdev
    profiles: [dev]
  - targetId: run-qsprod
    profiles: [prod]
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [25, 50]
          verify: false

productionへプロモートした直後の状態。

ロールアウトを進めるで先へ進められる。

チュートリアルの注意書き

Cloud Deploy では、カナリアデプロイ戦略と複数のターゲットへのデプロイがサポートされています（2023/05 時点でプレビュー）。またデプロイ結果を確認することもできます（既にGA）。

マルチターゲットの場合はtargetIdsへ書く。

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: run-qsprod-multi
requireApproval: true
description: production
multiTarget:
  targetIds: [run-qsprod, run-qsprod-tok]