管理単位を小さくして運用する terraform
本記事は terraform Advent Calendar 2023 の24日目のエントリです。[1]
公開が大幅に遅れてすみません 🙇🏾
本記事では、自分の terraform フォルダ構成の変遷について書きます。2023年末時点の現在、 terraform_remote_state を活用して、できるだけ管理単位を小さくする方式をなるべく採用しています。
加えて、↓のようにも思い至るようになり、 極力、流れが速い terraform のアップグレードにもなるべく日々追従しています。GitHub Actions 利用環境に限るけど。。[2]
独自モジュール期
独自モジュール期 構成イメージ
2021 〜 2022年前半頃の自分はこの考え方で構築していました。
理解を深める意図もあり、できるだけ自分で、ドキュメントと睨めっこして「自分式」を整備していた頃です。
ポイントは以下になります。
- modulesに中区分単位でリソースを定義
- 環境によって変わる箇所を変数化
- environments/*/${module}.tf で独自moduleを利用するように source 指定
この頃の発表資料が以下です。
- LaravelプロダクトFargate化への道 (2021.03 PHPerKaigi 2021 LT)
- PHPプロダクトのDeployをラクにするCLIツールたち (2021.10 PHP Conference 2021 LT)
公式/3rdPartyモジュール期
公式/3rdPartyモジュール期 構成イメージ
2022年後半頃はこの考え方でした。
ある程度「省力」しようという意識になってきて、Terraform AWS modules を利用するのを第一に考えてました。構築にスピードを出せるようになってきた時期です。
ポイントは以下になります。
- OIDCを優先的に利用するようになったのもこの頃
- terraform_remote_state を利用してない
- しかし security group と prefix list の棲み分けはしていた（変更影響の局所化チョットできていた）
- まだ、例えば、productionディレクトリでの terraform apply が、かなりドキドキ
terraform_remote_state活用期
terraform_remote_state活用期 構成イメージ
2023年以降です。
公式/3rdParty ＋ 小規模な独自 module も利用するし、terraform_remote_state を利用して管理単位を適度に小さくしています。
管理単位が小さいので、変更のドキドキもだいぶ小さくて済むようになったと思います。
ポイントは以下になります。
- .terraform-version (など) の統一（symlink）
- outputs.tf をちゃんと書く：何を外から参照するのか
- 秘匿情報も難読化してリポジトリで管理する
- 変更影響が局所化されるので、terrafom や aws provider のアップグレードに対応しやすい
- 変更箇所に応じた CI (自動 terraform plan) を実現可能
今後の発展
今のところ、自分の関与する組織が小〜中規模なので、大規模な組織における排他制御的なことも考慮に入れていければなあ、と思っています。
-
23日目は @ryuichi_1208 さんの 【Terraform】Terraform 1.6 で追加されたtestについて書いてみる でした。 ↩︎
-
dorny/paths-filter を使って変更箇所だけ走査する、を運用してます。設定方法はだいたい ぼくの tfsec-pr-commenter-action の使い方#「dorny%2Fpaths-filter-使って変更箇所だけ」の設定例 の感じ。Bitbucket・GitLab・AWS CodeBuild で実現した事例を捜索している・・・ ↩︎
Discussion