ハマログ

株式会社イーツー・インフォの社員ブログ

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

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

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

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

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

3.
ディレクトリ名を変更
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
        ︙

  kusano   2021年4月19日


関連記事

CodeBuildでEC2とAuroraのバックアップを取得する

はじめに CodePipelineで製品をデプロイする前に、EC2とAurora…

EC2のUbuntuにCloudWatch Logsエージェントをインストール

「EC2のUbuntuにCloudWatchエージェントをインストール」に続き、…

AWS WAFのカスタムレスポンスを試してみる

AWS WAFで、カスタムレスポンスを返すことができるようになったので試してみま…


← 前の投稿

次の投稿 →