More than 5 years have passed since last update.

Terraformのコンポーネント分割について検討する

Last updated at 2019-08-04Posted at 2019-08-03

はじめに

こんにちわ。Wano株式会社エンジニアのnariと申します。
前回のmoduleの記事に引き続き、terraformの話を記事にしたいと思います。
今回はtfstateをどの単位で分割し管理するか、というコンポーネント分割問題に関して書いていきます。

ただし、今回の記事の構成はプロジェクトの一旦の落とし所であって、ベストな構成とは限らないのでご了承ください。

(Pragrmatic Terraform on AWS 17章より)

分割する際の視点を利用し、現実的に分割粒度を検討していった

安定度高
- network(vpc,subnet周辺)
安定度低
- routing(route53,alb,acm)
関心ごとの分離
- services ecsのサービス単位(ecs cluster,taskdifinition,service,それに付随するec2系リソース ecr pipeline系)
- opsserver(session manager,ec2)
- events やりたい処理単位(lambda cloudwatchEvents ここはApex+Terraform)
  - モニタリングとかもここに
- state machine(step function)　
ステートフル
- storage(s3)
  - 依存関係を制御できる自信がない+複数の関心ごとの対象となるストレージが出てこなさそうなので、backend以外全て他のコンポーネントに寄せることとする(今回はコンポーネントとして登場させない)　
- datastore(elasticache,RDS)
  - elasticache,RDSを別々に管理する(それぞれクラスターごとに)
組織のライフサイクル
- iam user
依存関係の制御
- コンポーネント図を起こし、terragrunt.hclのdependenciesでしっかり管理する

terragrunt.hcl

dependencies {
  paths = ["../../network","../../routing"]
}

terragruntというツールを使うと、それぞれのサブディレクトリでplanやapplyを打ってくれるplan-allやapply-allが使えるようになるので、コマンド一発の運用に集約できる
前述したterragrunt.hclという設定ファイルでコンポーネント間の依存関係も管理できる
CIでもterragrunt plan-allをdindで唱えて差分チェックをしている（sampleのdockerfileはこちら)
codebuildでのdindの設定に関してはこちらの記事参照

皆さんのプロジェクトでのコンポーネント分割粒度についても教えていただけると大変嬉しいです。
よろしくお願いいたします。