2026-06-18 ecspressoのtfstate参照が便利すぎた話

社内勉強会の内容

ecspressoが便利すぎて勢い余って、自分もインスパイアされてコードを書いた話
https://github.com/masasuzu/clrnd

Transcript

1. ecspressoのtfstate参照が便利すぎてCloud Run版を作ってしまった ついでにインフラとデプロイの境界線 社内 2026-06-19
2. おまえだれよ 名前: すずきまさし/x:@masasuz/masasuzu 所属: 株式会社スリーシェイク シニアアーキテクト クラウドインフラ何でも屋さん すきなもの: AWS, Google Cloud, Terraform 2024-2025 AWS Community Builder Cloud Operations 2025 Japan All AWS Certifications Engineers Google Cloud Partner Top Engineer 2026 2
3. 今日のゴール ecspresso の tfstate 参照 が便利すぎる、という話をします IAM Role ARN や Secrets Manager ARN を ハードコードせず Terraform (tfstate) から引けます 便利すぎたので Cloud Run 版 (clrnd) を作りました (ついで) インフラとデプロイの 境界線 にも軽く触れます 3
4. 目次 1. ecspresso の tfstate 参照が便利 2. なぜインフラに寄せないのか (ついで) 3. Cloud Run でも同じ体験を 4. clrnd を作った 4
5. 1. ecspresso の tfstate 参照が便利 5
6. ecspresso とは Amazon ECS デプロイツール (読みは "espresso" と同じ) ECS の サービス定義 / タスク定義 を JSON / YAML / Jsonnet でコード管理 テンプレートで 環境変数や Terraform state の値 を埋め込める https://github.com/kayac/ecspresso 6
7. 主要サブコマンド (軽く) コマンド 何をする init 稼働中サービスから設定ファイルを生成 diff 現在の定義との差分表示 verify リソースと設定の検証 deploy サービスをデプロイ (ローリング / Blue-Green) render 設定をレンダリングして出力 ほかに rollback / run / register などもあります。 7
8. tfstate 連携 タスク定義には IAM Role ARN や Secrets Manager ARN が必要 これらは Terraform で作る → 今まではそれをコピペしてハードコードしていた 最近tfstate参照できることを知った ecspresso.yml の plugins で tfstate を有効化 plugins: - name: tfstate config: url: s3://my-bucket/terraform.tfstate 8
9. タスク定義テンプレート例 "taskRoleArn": "{{ tfstate `aws_iam_role.ecs_task.arn` }}", "secrets": [ { "name": "DB_PASSWORD", "valueFrom": "{{ tfstate `aws_secretsmanager_secret.db.arn` }}" } ] ARN を一切ベタ書きしない。Terraform 側の値をそのまま引ける {{ tfstate "addr" }} で属性値に展開、 {{ tfstatef "...%s..." "idx" }} でインデックス指定 env / must_env / json_escape も利用可能 9
10. 流れ (ECS) ecspresso の tfstate 連携 (ECS) Terraform IAM Role Secrets Manager サブネット / SG ... tfstate s3://.../ terraform.tfstate ecspresso render / deploy テンプレートを展開 タスク定義 ( 展開後) ARN が埋め込まれた task definition JSON Amazon ECS サービス更新 apply 参照 render deploy タスク定義テンプレート ( 書く側) "taskRoleArn": "{{ tfstate `aws_iam_role.ecs_task.arn` }}", "secrets": [{ "name": "DB_PASSWORD", "valueFrom": "{{ tfstate `aws_secretsmanager_secret.db.arn` }}" }] 展開結果 (ecspresso が埋める) "taskRoleArn": "arn:aws:iam::123456789012:role/ecs-task", "secrets": [{ "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1: 123456789012:secret:db-xxxxxx" }] インフラの値は Terraform がsource of truth。ecspresso は 参照するだけです。 10
11. 2. なぜインフラに寄せないのか (ついで) 11
12. 「全部 Terraform で書けばいいのでは？」 確かに、デプロイ対象 (タスク定義 / Cloud Run サービス) も Terraform で管理すれば 値は同じ state の中にある → tfstate 参照すらいらない でも、そうはしたくない 過剰: デプロイのためだけに state を増やし、 plan / apply に巻き込まれる 守備範囲: デプロイはアプリ開発者の領域。そこに Terraform を強いたくない → インフラは Terraform、デプロイは ecspresso。tfstate を境界面にして参照だけする 12
13. 境界線のイメージ インフラとデプロイの境界線 境界線 インフラ = Terraform が管理 デプロイ = ecspresso / clrnd が管理 変更頻度が低く・影響が⼤きい VPC / ネットワーク IAM Role Secret Manager Cloud SQL / DB terraform apply 出⼒を tfstate に保存 (ARN / Service Account / IP ...) tfstate S3 / GCS = 境界⾯ 変更頻度が⾼く・アプリ開発の領域 タスク定義 / マニフェスト ( テンプレート) taskRoleArn / serviceAccountName: {{ tfstate "...role.arn" }} ecspresso / clrnd deploy → ECS サービス / Cloud Run サービス アプリ開発者は Terraform を触らない 書き込む 参照 ( 読むだけ) 要点 インフラは Terraform 、デプロイは ecspresso / clrnd 。tfstate を境界⾯にし、デプロイ側は値を参照するだけ。アプリ開発者に Terraform を強いない。 13
14. 3. Cloud Run でも同じ体験を 14
15. Cloud Run のデプロイ手段 gcloud run deploy (イメージ指定) gcloud run services replace service.yaml (YAML 適用) Terraform ( google_cloud_run_v2_service ) いずれも、ecspressoのようなかゆいところに手が届く感じがないです 15
16. 欲しかったもの Service Account や Secret を tfstate から引いてマニフェストに埋めたい ecspresso と同じような使い勝手のツールがほしい 調べた範囲では Cloud Run 向けの相当ツールが見当たらなかったのでないならつくればいい AI Coding万歳 16
17. 4. clrnd を作った 17
18. clrnd とは Cloud Run へのデプロイツール。ecspresso をモデルに自作しました Go tfstate 参照は ecspresso と 同じ tfstate-lookup (fujiwara) を利用 https://github.com/masasuzu/clrnd 18
19. サブコマンド コマンド 何をする verify マニフェスト検証 (ローカルのみ、認証不要) diff 既存サービスとの差分表示 deploy Cloud Run に適用 ( --auto-approve / --dry-run ) load 既存サービスを Knative YAML で取得 19
20. 設定ファイル clrnd.yml project: my-project region: asia-northeast1 service: my-svc manifest: manifest.yaml tfstate: - location: gs://my-tf-state/app/default.tfstate - name: network location: gs://my-tf-state/network/default.tfstate tfstate は複数指定でき、 name 省略で default 扱い location は gs:// / s3:// / ローカルに対応 20
21. マニフェスト (Knative YAML + Go template) spec: template: spec: serviceAccountName: '{{ tfstate "output.run_service_account" }}' containers: - image: '{{ must_env "IMAGE" }}' env: - name: DB_HOST value: '{{ tfstate "google_sql_database_instance.main.private_ip_address" }}' - name: LOG_LEVEL value: '{{ env "LOG_LEVEL" "info" }}' 関数: tfstate "addr" / tfstate "name" "addr" / env / must_env ecspresso と同じ書き味で Service Account 等を引ける 21
22. 使い方 # まず検証 (認証不要・tfstate 展開も確認できる) clrnd verify my-svc manifest.yaml # 差分を確認 clrnd diff my-svc manifest.yaml --project p --region r # デプロイ clrnd deploy my-svc manifest.yaml --project p --region r インストール: go install github.com/masasuzu/clrnd@latest 認証: gcloud auth application-default login (ADC) 22
23. 流れ (Cloud Run) clrnd の tfstate 連携 (Cloud Run) — ecspresso と同じ形 Terraform Service Account Secret Manager Cloud SQL ... tfstate gs://.../ terraform.tfstate clrnd verify / diff / deploy テンプレートを展開 マニフェスト ( 展開後) 値が埋め込まれた Knative Service YAML Cloud Run サービス更新 apply 参照 render deploy マニフェストテンプレート ( 書く側) spec: template: spec: serviceAccountName: '{{ tfstate "output.run_service_account" }}' containers: - image: '{{ must_env "IMAGE" }}' 展開結果 (clrnd が埋める) spec: template: spec: serviceAccountName: run-sa@my-project.iam.gserviceaccount.com containers: - image: asia-docker.pkg.dev/.../app:abc123 ecspresso と同じ構図で、tfstate を境界面にできました。 23
24. 現状 (正直ベース) ざっくり欲しいものをつくりました。 設定ファイルがmanifestベースでいいのかは正直まだわからない まずは「tfstate を引いて Cloud Run に deploy できる」ところまで 24
25. まとめ 25
26. まとめ ecspresso の tfstate 参照が便利。ARN を ハードコードせず Terraform から引けます 便利すぎたので Cloud Run 版 clrnd を作りました。似た書き味で Service Account 等を引けます (ついで) インフラ = Terraform / デプロイ = 専用ツール。tfstate が境界面です 26
27. ありがとうございました 27