概要
TerraformのStateやModuleに関する設計に関する考慮点をざっくり書く
名前付け
- ユビキタス言語とディレクトリ名や変数名を合わせて認知不可を下げる
- リソース名でなく役割・機能ベースのディレクトリ名にして認知不可を下げる
プロダクトのコードネームはユビキタス言語なのでディレクトリ名にしても問題ない - ModuleやStateのREADME.mdを書く
- https://github.com/terraform-docs/terraform-docs を使う
- うまく説明が書けない場合は設計に問題がある可能性がある
- チームメンバーが利用できるように考慮する
いつどのようなときに使えばいいかわからないものを作らない
抽象度
- 抽象度が低いModuleを作らない
例：modules/s3など
参考： https://developer.hashicorp.com/terraform/language/modules/develop#when-to-write-a-module
- 大きく作ってから小さくしていく
小さいものをまとめるほうがコストが大きいため
stateやmoduleが小さいときは上記のように抽象化を間違えて不要に小さいパターンが多いため
インフラアーキテクチャ図
アーキテクチャ図を円で囲ってstate、moduleの単位を作る
チーム
自分が把握していない変更が出るとapplyしていいかわからずコミュニケーションが発生するためチーム単位で分ける
認証情報
CI実行時などを考慮して認証情報の粒度でディレクトリを分ける
変更(デプロイ)のライフサイクル
DRYの誤用
- 不要な依存関係につながるので偶発的凝集をModuleにしない
コードの検索性
Webコンソールからリソース名やタグでコード検索したときに探しやすいように記述する
モジュール間の依存
依存関係の把握や管理が困難になるのでモジュール間の依存を作らない
特にモジュールの中で別のモジュールをローカルパス参照しない
参考: https://developer.hashicorp.com/terraform/language/modules/develop/composition
アプリケーションレイヤーとの違い
アプリケーションレイヤーと異なりライフサイクルが長く作り直しの難易度が高く、作り直しに時間がかかることを考慮する
