データ基盤のための Terraform Workflow を tfaction で構築しよう

https://forkwell.connpass.com/event/339761/
Data Engineering Study #28 データ基盤のCI/CD
2025-02-27

1. データ基盤のための Terraform Workflow を tfaction で構築しよ う 2025-02-27 Shunsuke Suzuki 1
2. 自己紹介 (1) Shunsuke Suzuki seli07 (せりな) 2024/08 ~ freee SRE 2022/07 ~ Mercari Platform Engineer 2021/10 ~ Recruit SRE 2019/10 ~ Quipper SRE 2
3. 自己紹介 (2) OSS Developer - CLI や GitHub Actions など様々な OSS を開発 • aqua • tfcmt • tfaction • github-comment • tfmv • pinact • ghalint • etc 3
4. aqua - CLI Version Manager https://aquaproj.github.io/ 4
5. 概要 • データ基盤そのものの話はほぼしない • データ基盤のインフラを Terraform で管理するための Workflow を tfaction という OSS を使って構築する話 6
6. Agenda • IaC や CI, Terraform の説明 • Terraform Workflow の開発・運用の難しさ • tfaction の概要 • なぜ tfaction なのか • tfaction の機能紹介 7
7. データ基盤には様々なインフラリソースの管理が必要 • AWS • Google Clould ◦ BigQuery, Cloud Run, Cloud Workflows, etc • Azure • etc 8
8. IaC (Infrastructure as Code) による管理 • コードレビュー可能 • 似たようなインフラを簡単に構築可能 • コードを Git のような VCS で管理することで変更履歴を容易に残せる • linter を用いたテストやドキュメントの生成が可能 • CI などによる変更の適用の自動化が可能 • etc 9
9. Terraform による IaC • あらゆるリソースを統一的な方法で管理 • リソースの宣言的な管理 • 充実したコミュニティ・ナレッジ・エコシステム • 使える人が多く、導入しやすい • etc 10
10. Terraform をどうやって実行するか 1. ローカルや専用のサーバーから手動実行 2. apply は手動でそれ以外 (plan) は CI 3. CI で自動化 11
11. Why CI? • 自動化による生産性の向上 • セキュリティやガバナンスの強化 ◦ コードレビューや lint のプロセスの強制 ◦ ヒューマンエラーのリスクの軽減 ◦ CI のログによる透明性の向上や監査対応 12
12. Terraform の Workflow の実装の難しさ 13
13. シンプルなワークフローを組むのは容易 GitHub Actions で簡単に組める 1. install terraform 2. terraform init 3. terraform plan / apply 14
14. ワークフローを取り巻く環境の変化 • プロダクトの成長 • 開発組織の成長 • データ基盤の利活用の増加 • ワークフローの利用者や実行頻度の増加 • 管理対象のリソースの増加 15
15. ワークフローの品質がより重要になってくる • セキュリティやガバナンスの重要性の増加 • 開発者体験、生産性 ◦ セルフサービス化 ◦ ガードレール 16
16. ワークフローの拡張が必要になってくる • Monorepo の変更されたディレクトリでだけ CI 実行 • local-path Module が変更されたら依存するディレクトリでも CI 実行 • コードのフォーマットを強制(なんなら自動修正) • tflint, trivy, Confest • terraform-docs でドキュメント生成 • plan file 使って apply • Drift 検出 • etc 18
17. Terraform の Workflow のメンテの難しさ • 様々な機能を自前で実装するのは大変 • CI や Platform Engineering に関する専門性が必要 • 人材確保は容易ではない • 他にもやるべきことはあるので中々手が回らない • メンテコストを極力抑えて他のことにリソースを回したい 19
18. OSS 開発者としての理想 • 各企業や開発組織が似たようなものを独自に開発するのは望ましくない • あらゆる開発組織が高い品質のワークフローを実現できる OSS の開発 • ユーザーからワークフローの様々なノウハウが OSS に集約されていく => tfaction の開発 20
19. tfaction の話 21
20. tfaction とは https://github.com/suzuki-shunsuke/tfaction • Terraform Monorepo の高度な workflow を GitHub Actions で構築するための Framework (実態は GitHub Action の集合体) • OSS (MIT LICENSE) • 日本国内を中心に様々な企業で導入実績 22
21. tfaction の特徴 • ワークフロー全体という広い領域をカバーする大きな Framework • trivy や tflint, conftest, terraform-docs など周辺ツールのサポート • Drift Detection や コードの自動修正, apply のエラーのハンドリングなど、様々な 機能を提供 • Monorepo を標準でサポート 23
22. tfaction の基本的な 2 つの workflow 1. PR に対し lint やコードの自動修正、 terraform plan を実行 2. PR がマージされたら terraform apply を実行 PR をテストし、マージしたらデプロイするというシンプルな GitHub Flow 24
23. tfaction の基本的な 2 つの job 1. setup: 変更された Root Module のリストを取得 2. plan / apply: 変更された directory に対して matrix build で terraform plan / apply を実行 25
24. tfaction の設定ファイル 設定は基本 GitHub Actions ではなく設定ファイルに記述 1. tfaction-root.yaml : グローバルな設定や Root Module 群の設定 2. tfaction.yaml : 各 Root Module の設定。空 {} でも良い 設定を細かく制御したり共通化することが可能 26
25. tfaction の機能 1. Monorepo のサポート 2. local-path Module の依存関係の検出 3. terraform plan / apply の結果の分かりやすい通知 4. Linter とのインテグレーション 5. コードの自動修正 6. Renovate による自動 update 7. plan file を用いた安全な apply 8. apply 後に関連 PR を更新 9. apply 失敗対応のサポート 10. 新しい Root Module の Scaffold 27 11. tfmigrate による State Migration 12. Root Module の削除 13. terraform plan -generate-config-out によるコード生成 14. Drift Detection 15. Module 管理
26. 1. Monorepo のサポート 28
27. Terraform の Monorepo とは • 1 つのリポジトリに複数の Terraform Root Module があるリポジトリ • ディレクトリ階層の分け方は色々 ◦ 例: サービスや環境毎にディレクトリを分ける • Root Module の数は千差万別 (数個 ~ 1,000 over) • Terraform ではよくあるパターン 29
28. tfaction の Monorepo のサポート • tfaction は Monorepo を想定 • 変更された Root Module でのみ CI を実行 ◦ 毎回全 Root Module で CI 実行は無駄 (非現実的) ◦ Root Module の数が増えてもスケールする (CI の時間が伸びない) 32
29. 2. local-path Module の依存関係の検出 33
30. 2. local-path Module の依存関係の検出 例: service-a が 同じディレクトリの modules/consul に依存 service-a/ modules/ consul # Module 34
31. local-path Module の依存関係の検出 • デフォルトでは local-path Module が更新されても Root Module では CI は実行さ れない • 設定で Root Module でも実行されるようにすることができる 35
32. 3. terraform plan / apply の結果の分かりやすい通知 36
33. terraform plan / apply の結果の確認 • CI で terraform plan / apply を実行したら結果を確認する必要がある • CI の log を確認するのは面倒・分かりづらい => tfaction では tfcmt で分かりやすく PR にコメント 37
34. • log 確認不要で楽 • 色付き label • 要約 • 削除警告 • リソース一覧 • 余計なログの除去 • etc 38
35. 4. Linter とのインテグレーション 39
36. 様々な linter に対応 • tflint • trivy (tfsec) • Conftest CI で lint を実行しベストプラクティスへの準拠を強制し、コードの品質を担保 結果を分かりやすく通知 40
37. tflint & reviewdog による自動 review 41
38. PR へのコメント 42
39. 5. コードの自動修正 43
40. 様々な修正の必要性 • terraform fmt によるフォーマット • .terraform.lock.hcl の更新 • terraform-docs によるドキュメントの更新 • tflint –fix によるエラーの修正 44
41. CI による修正の自動化 • コードを CI で自動で修正することでコードの品質を担保 • ローカルで修正する手間が省ける ◦ ローカル環境にも依存しなくなる 45
42. terraform fmt による自動フォーマット 46
43. terraform-docs によるドキュメントの自動生成 47
44. 6. Renovate による自動 update 48
45. Renovate による自動更新 • Renovate: Dependabot のように dependency を update するツール • Terraform Provider や Module などを Renovate で自動更新できる • マージまで自動化すると人間の負担が減って楽 • しかし、自動マージでインフラの変更が勝手に適用されると危険 49
46. 自動マージによるインフラの変更の適用の防止 50
47. 7. plan file を用いた安全な apply 51
48. • レビューした plan の結果と違う結果が apply されると危険 • terraform plan で生成した plan file を用いて apply を実行すると plan と同じ結果 を apply できて安全 52
49. plan file とは • terraform plan の -out option で生成されるバイナリファイル • plan の結果を保持している • terraform apply 時に plan file を渡すと plan 結果をそのまま apply できる • plan file は state file のバージョン情報を保持しており、 apply 実行時に plan file に保持されたバージョンが古くなっていると apply が失敗する ◦ 古い結果が apply されるのが防がれるので安全 53
50. • tfaction は plan file を GitHub Actions Artifact で管理することで安全に apply を 実行 ◦ plan file が改竄されると任意の結果を apply できて非常に危険 ◦ GitHub Actions Artifact は改竄不可なので安全 54
51. 8. apply 後に関連 PR を更新 55
52. • 同じ Root Module に対する PR が同時に複数作られることはままある • ある PR がマージされた場合、同じ Root Module に対する PR を更新する必要が ある ◦ CI の結果が変わりうるため ◦ terraform plan を再実行し stale になった plan file を再作成するため 56
53. apply 後に関連 PR を自動更新 同じ Root Module に対する PR を自動で更新 57
54. 9. apply 失敗対応のサポート 58
55. apply 失敗時の対応 • plan に成功したけど apply に失敗するのは良くある • 失敗したら何かしら対応が必要 59
56. apply 失敗時の対応の課題 • 失敗に気づかないことがある • apply 失敗時にどうすればよいかわからない人もいる • PR を新たに作るのが地味に面倒 • すぐに修正できず忘れ去られる場合がある 60
57. Follow up PR の自動生成 • apply 失敗時にメンションして通知 • 失敗を修正するための PR を自動生成 • 後述する Drift Detection を有効にすると Issue として管理可能 61
58. 62 メンション やるべきことの案内
60. 10. 新しい Root Module の Scaffold 64
61. 新しい Root Module の Scaffold • Monorepo に新しい Root Module を追加する際、一から書くのは大変 • tfaction では workflow を実行してテンプレートを元に生成できる ◦ テンプレートは自分で用意する必要がある ◦ workflow 経由なのでローカル環境に依存しない 65
64. 11. tfmigrate による State Migration 68
65. tfmigrate とは terraform state mv, rm や terraform import による State 操作をコードで定義して自動 化するツール 実際に変更を適用する前に terraform plan で差分がないか検証できる Terraform による import, moved, removed block のサポートにより以前より使う機会 は減ったが、複数の State を跨った State 操作をしたい場合は便利 69
66. tfaction の tfmigrate のサポート • workflow で .tfmigrate.hcl やマイグレーションファイルの雛形を生成できる • CI で tfmigrate を実行可能 70
68. 12. Root Module の削除 72
69. Root Module の削除 • サービスの終了などで Root Module ごと削除したくなることはままある • 単にディレクトリを消してしまうとリソースがそのまま残ってしまう • backend や provider など最低限のコード以外を削除するのは地味に面倒 73
70. tfaction.yaml の destroy option • destroy option を有効にすることで CI で全リソースを削除可能 ◦ terraform plan 実行時に –destroy option が設定される 74
71. 13. terraform plan -generate-config-out によるコード生成 75
72. terraform plan -generate-config-out • import block を元にコードを自動生成するコマンド • 生成されるコードは完璧ではないが、 0 から自分で書くより圧倒的に楽 • 権限的にローカルで terraform plan が実行できないと通常使うのが難しい 76
73. terraform plan -generate-config-out workflow 77 • workflow_dispatch で実行可能 • 生成されたコードが commit される
74. 14. Drift Detection 78
75. Drift Detection とは • Drift: IaC においてコードによるインフラの定義と実際のインフラの状態が乖離した 状態 • Drift Detection: Drift を自動で検出する機能 79
76. Terraform における Drift の主な原因 • Terraform 以外によるインフラの変更 • terraform apply の失敗 Terraform を運用していれば Drift は避けられない 80
77. Why Drift Detection? • Drift はなるべく早く解消すべき • Drift はコードの信頼性をなくす ◦ コードでなく実際のインフラの状態を確認する必要が出てくる • Drift はブロッカーにもなる ◦ terraform plan 時に予期せぬ差分として現れる ◦ 差分の原因を逐一確認する必要が出てくる 81
78. tfaction における Drift Detection • Root Module ごとに GitHub Issue を作成して Drift を管理 • Issue は Drift が検出されたら Open, 解消されたら Close される • Drift の検出・解消のたびに Issue に結果がコメントされる • Drift Detection のタイミングは 2 種類 ◦ terraform apply 実行時 ◦ schedule workflow で terraform plan を定期的に実行時 82
79. tfaction の Drift Detection のタイミング • terraform apply 実行時 ◦ 失敗したら Drift があると判定 • schedule workflow で terraform plan を定期的に実行時 ◦ No change でなければ Drift があると判定 83
80. 84 Issue が作られる
81. apply の結果次第で reopen / close 85
82. 定期的な Drift のチェック 86
83. • Drift を Issue で管理できる • Issue を見ればいつから Drift があるのかだいたい分かる • あくまで Drift を検出するだけで自動で修正したりはしない ◦ 如何に Drift (Issue) に対処するかはユーザーに委ねられている 87
84. 15. Module 管理 88
85. Module 管理 • 独自の Terraform Module を如何に管理するかは難しい問題 • 色々やりようはある ◦ local-path Module ◦ S3, GCS ◦ GitHub ◦ HCP Terraform ◦ etc 89
86. Module 管理 • tfaction では標準的な管理方法を提供 ◦ 同じ Monorepo に集約 ◦ GitHub Source で versioning して管理 ◦ Scaffold, Test, Release といった一連の開発フローをサポート • ただし自分の好きな方法で管理することも可能 90
87. まとめ 91
88. まとめ • データ基盤のインフラを Terraform で管理するための Workflow を tfaction で構築 • ビジネスや開発組織の成長に伴い、より生産性やセキュリティ・ガバナンスが求め られる • tfaction の様々な機能を活用し、高度なワークフローを少ない運用コストで管理 92
90. 今後やりたいこと • Security の強化 ◦ よりセキュアな Secret 管理 • Linter 設定の管理の改善 ◦ 少ない運用コストで適切な設定を適用していくという課題への道筋を提示 • apply before merge の検討 • tfaction の導入ハードルの低減 • Module 管理の改善 ◦ Renovate による update の自動化 • Terraform のテストのサポート • 設定ファイルの JSONSchema の自動生成 94
91. pull_request_target で GitHub Actions の改竄を防ぐ tfmv - Terraform のリソース名のリファクタリング tfprovidercheck - 危険な Terraform Provider の実行を防ぐ Shunsuke Suzukiさんの記事一覧 | Zenn 95