2026-07-28 3-shakeテックランチ Cloud Run のデプロイパラメータを考える / Cloud Run Deploy Parameter

https://3-shake.connpass.com/event/399469/ で発表した内容

Transcript

1. Cloud Run のデプロイパラメータを考える 2026-07-28 3-shake テックランチ会 #1 すずきまさし Copyright © 3-shake, Inc. All Rights Reserved.
2. おまえだれよ • • • すずきまさし/masasuzu/@masasuz 株式会社スリーシェイクSreake事業部シニアアーキテクト クラウドインフラなんでも屋さんをしてます ◦ お客様の外部から ▪ 設計、運用、構築等の技術支援を行います。 ◦ お客様の内部から ▪ インフラチームの一員として内製化支援も行います。 • 得意領域 ◦ AWS ▪ AWS Community Builder Cloud Operation Since 2024~2026 ▪ 2026 Japan All AWS Certifications Engineers ◦ Google Cloud ▪ Google Cloud Partner Top Engineer 2026 ◦ Terraform Copyright © 3-shake, Inc. All Rights Reserved. 2
3. もくじ • • • 今回の課題を考えるうえでの前提構成 Cloud Runのデプロイの課題 どう解決したか Copyright © 3-shake, Inc. All Rights Reserved. 3
4. 01 今回の課題を考えるうえでの前提構成 Copyright © 3-shake, Inc. All Rights Reserved. 4
5. 前提構成 • • • • レポジトリ: GitHub インフラ管理: Terraform ◦ tfstate管理はGCS アプリケーションデプロイ : gcloud run deploy CI/CD: GitHub Actions Copyright © 3-shake, Inc. All Rights Reserved. 5
6. アプリとインフラの責任境界 • • アプリケーション管理 ◦ Cloud Run インフラ管理 ◦ ◦ Cloud Run以外のリソース Cloud Runが使用するリソース ▪ Service Account ▪ Secret Manager ▪ Cloud SQL ▪ Cloud Storage ▪ Artifact Registry ▪ etc… Copyright © 3-shake, Inc. All Rights Reserved. 6
7. Cloud Runはアプリケーション側で管理する TerraformでもCloud Runは管理できる。が、 1. 学習コスト 2. 頻繁な変更 & ドリフト 3. ツール特性の不一致 アプリケーションエンジニアに Terraformを覚えてもらう必要があるた め、運用のハードルが高くなります。 環境変数や CPU、Memoryなど、アプ リ側で自由に変更したい項目が多い。 「デプロイ」という高頻度な行為に対し て、インフラ構築向けの Terraformとい うツールは過大であり、マッチしていな いと考えられます。 ※アプリ側で変更するとTerraformでドリフト （差分）になるため、ignore_changesの設 定が必要です。 であれば、そもそも Cloud Run自体は Terraformで管理せず、アプリ側での管理に任せたほうが良 い。 と自分は考えています。 Copyright © 3-shake, Inc. All Rights Reserved. 7
8. 02 Cloud Runのデプロイの課題 Copyright © 3-shake, Inc. All Rights Reserved. 8
9. アプリケーションで使いたい値 こういった値をアプリケーション自体で使用したり、環境変数として 埋め込んで使用したい。 • • • • • • • Service Account Cloud SQLのホスト Cloud Storage バケット名 Secret Manager サブネットワーク ◦ Direct VPC Egressを使う場合 連携するCloud RunのURL コンテナイメージ Copyright © 3-shake, Inc. All Rights Reserved. 9
10. 環境ごとのパラメータを取得する ルールベースで決められるもの (課題が少ない ) リソース名など、命名規則やルールに基づいて一意に決定できるパラメータ。 設定の自動化が容易で、管理上の破綻が起きにくい領域です。 ルールベースで決められないもの (課題の本質 ) 接続先URLや個別識別 IDなど、実環境が作成されてからでないと確定しない パラメータ。これらは実環境から動的に値を取得してくる仕組みが必要になり ます。 Copyright © 3-shake, Inc. All Rights Reserved. 10
11. なにが課題なのか 環境ごとに異なるリソース名をどう渡すか ① 手動で取得してデプロイ設定に転記 • 単純にめんどくさい • コピペミスの可能性 • 環境が増えるごとに環境ごとのファイルが自動的に増殖する • インフラ側の変更によってドリフト(乖離)が発生しうる ② デプロイ実行時に gcloudで動的取得 • リソース名がルールベースでないとき設計が破綻する • デプロイとは直接関係のない余分な参照権限を渡すことになる Copyright © 3-shake, Inc. All Rights Reserved. 11
12. 03 どう解決したか Copyright © 3-shake, Inc. All Rights Reserved. 12
13. tfstateの利用 Source of Truthとしてのtfstateの利用 tfstateからの直接取得による簡潔化 Terraformが管理するインフラ情報はすべて tfstateに記載されています。 手動でのコピペを排除し、ここから直接取得するのが最も安全で簡潔な 方法です。 オブジェクト参照権限のみのシンプル管理 tfstateはCloud Storage Objectとして保存されるため、デプロイ用の Service Accountに対してオブジェクトの参照権限を付与するだけで安 全 にアクセスが完結します。 ツール： tfstate-lookup tfstateを効率的に参照するための外部ツールとして、 fujiwara/tfstate-lookup が利用しやすかったです。 https://github.com/fujiwara/tfstate-lookup Copyright © 3-shake, Inc. All Rights Reserved. 13
14. tfstate参照をデプロイに組み込む パラメータの集約 デプロイ用の tfstateに必要なパラメータをまとめ、不要な情報を参照させない （remote state参照） 最小権限の付与 デプロイ用の GitHub Actionsには、該当するデプロイ用 tfstateへのアクセス権の み を安全に付与する パラメータを利用したデプロイ デプロイ時に tfstateを直接参照し、環境変数などの必要なパラメータを動的に利用 して展開する 環境ごとの管理 環境ごとに保存先 GCSおよびtfstateファイルが作成されるため、デプロイ対象に 応じて差し替える Copyright © 3-shake, Inc. All Rights Reserved. 14
15. もう一歩進めたい パラメータ取得の仕組み化 tfstate-lookupを使用して、いい感じにデプロイパラメータを取得する仕組みはで きた。 デプロイ連携の課題 取得したデプロイパラメータを、実際のデプロイ処理へ渡す箇所がまだこなれて いない。 AWS ECSにおける ecspresso AWSのECS環境では、このあたりをいい感じにハンドリングしてくれる kayac/ecspresso が存在。 https://github.com/kayac/ecspresso 解決へ向けた試行錯誤 (clrnd) Cloud Runでも同様の体験を実現するため、自作ツール masasuzu/clrnd を開 発してます。 https://github.com/masasuzu/clrnd Copyright © 3-shake, Inc. All Rights Reserved. 15
16. clrnd • tfstateから取得した値をマニュフェストテンプレートに埋めてデプロイする形です https://speakerdeck.com/masasuzu/2026-06-18-ecspressonotfstatecan-zhao-kabian-li-sukitahua?slide=23 Copyright © 3-shake, Inc. All Rights Reserved. 16
17. 04 まとめ Copyright © 3-shake, Inc. All Rights Reserved. 17
18. まとめ 1. デプロイパラメータの課題 2. tfstate-lookupの導入 3. clrnd(おまけ) インフラ変更時における情報の不整合（ドリフ ト）や、安全かつ正確なパラメータ取得方法が 大きな運用課題となっていた。 tfstateをSource of Truthとしてパラメータを自 動取得。設定ファイルへの直書きを排除。 AWS ECSで実績のある ecspressoに影響を 受け、Cloud Run向けデプロイツールとして自 作開発を進行中。 主なボトルネック : ・値の取得・自動化は実現 ・実際のデプロイ処理へ安全に値を渡す連携 部分に、依然として課題が残る ・手動管理による設定ミス ・インフラ状態との乖離 Copyright © 3-shake, Inc. All Rights Reserved. 現在のステータス : 今後の展望 : ・本番運用への正式投入 ・想定する要件（マニフェスト埋め込み等）は 既に実装済み