Terraformのディレクトリ構成を他記事を参考に考えてみる。

• 環境ごとにディレクトリを分けて、moduleを参照する

  • メリット
    • 再利用性が高い。
    • 可読性が高い。
    • 採用事例が多く、記事になっている。
  • デメリット
    • 本番環境と検証環境に差分が発生する可能性がある。

• 環境毎にディレクトリで分けず、workspaceを使う

  • メリット
    • 実装漏れを防ぐ。
    • 本番環境と検証環境を同一の構成にしかできないので環境による不具合をなくす。
  • デメリット
    • 環境毎にサブネットCIDRやインスタンスタイプなどパラメータの差分があるとき、条件分岐を書かなければならない。可読性に欠ける。これが煩わしいようで、環境ごとにディレクトリを分けてmoduleを参照する構成が多く採用されている印象。

以下、記事の構成が全体の見通しが良く、他プロジェクトでも再利用しやすそうなので採用してみる。しかしmoduleを２層にすることで実装コストが上がってしまう。

１．
複数プロジェクトを管理しているが、案件によって作りたいリソースは異なるのでプロジェクト毎に新しいものを作るようにする。

２．
provider.tfに関して、本番環境と検証環境で異なるproviderやバージョンを使うことは現状無いので、dev/shared/provider.tfとprod/shared/provider.tfで分ける必要がない。
provider.tfは一つだけを用意し、各コンポーネントのディレクトリ内からシンボリックリンクで参照する。

３．
ディレクトリ名を変更
project　 →　env
usecase　 →　component
elements　→　service

.
├── env
│   ├── shared
│   │ 　  └── provider.tf
│   ├── dev（tfstate管理）
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── aws.tf
│   │   ├── terraform.tf
│   │   ├── provider.tf -> ../../shared/provider.tf
│   └── prod（tfstate管理）
│                       ︙
├── component
│       ├── network
│       │       ├── main.tf
│       │       ├── outputs.tf
│       │       └── variables.tf
│       ├── cicd
│       ├── api
│       ├── db
│       ︙
└── service
        ├── vpc
        │    ├── main.tf
        │    ├── outputs.tf
        │    └── variables.tf
        ├── rds
        ├── s3
        ├── security_group
        ├── subnet
        ├── wafv2
        ︙