この記事ではTerraformを使用するにあたってのノウハウを紹介しようと思います。
今回紹介するディレクトリ構成の概要
terraform-project/
│──tokyo
│ ├── provider.tf #terraform実行時に必要な最低限の情報
│ ├── aws_instance.tf #terraformのリソース名をそのままファイル名として使用する。
│ ├── aws_subnet.tf…
│── virginia
│ ├── provider.tf #terraform実行時に必要な最低限の情報
│ ├── aws_instance.tf #terraformのリソース名をそのままファイル名として使用する。
│ ├── aws_subnet.tf…
│── README.md
実際に使用してみて良かった点・悪かった点について
今回この構成に至るまでには以下の背景がありました。
良い背景
・お手本となる環境が存在している。
悪い背景
・IaCの経験者はいるが、自分含めてterraformの経験者はおらずコード的な記法にも経験が浅い。
・期間が非常に短い（設計が固まっていない段階から構築までおよそ一か月で要求されていた。正気とは思えない）
上記の条件を活用しつつ課題を解決するために上記のディレクトリ構成を考案いたしました。
このディレクトリ構成にすることによって、下記のメリットを見込むことができると想定していました。
・リソース名とファイル名が関連づいているため直感的に理解しやすい。
（Terraformの公式サイトの情報も調査しやすくなる）
・変数をモジュールやoutput.tfに外だししていないため、関連づいているリソース名を検索しやすい。
・変数を参照させる時にリソース名と同一であるため、命名規則がしっかりしているものであればコードを理解していなくても習得しやすい。
・上記二つの理由から実作業までの着手時間を短縮することができる。
メリット① リソース名とファイル名が関連づいているため直感的に理解しやすい。
例えば、インスタンスを作成したいという場合に基本的には最低限以下のリソースを作成する必要があります。
aws_subnet
aws_instance
aws_security_groupなど
よくある構成の場合は、以下のように作成することを推奨されているところをよく見ます。
terraform-project/
│── modules/
│ ├── network/
│ ├── compute/
│ ├── database/
│── main.tf # モジュール呼び出し
│── variables.tf # 変数定義
│── outputs.tf # 出力値
│── backend.tf # Terraform Cloud / S3 バックエンド
│── terraform.tfvars # デフォルト変数
│── README.md
ただし、上記のような構成を使用する場合、以下のスキルや考え方が必須になるデメリットがあります。
・変数として使用する情報を認識しておく必要がある→上記のディレクトリ構成で変数を使いたい場合、output.tfに出力させる必要があるため、明示的に情報を指定する必要がある。
・作成が必要なリソースが後から判明した場合（インスタンスを例にした場合、インスタンスプロファイルなど）新しいディレクトリおよびファイル名を検討する必要が発生する。また、編集箇所が複数に及ぶため作業工数が増える。→事前の設計が困難
今回紹介する構成にすることで、上記のデメリットに対して以下の回答を出すことができます。
・同一のディレクトリに配置している場合、変数をoutput.tfに出力させなくても使用することができるため後戻りの工数を減らすことができる。
・リージョンが同一のリソースはすべて同じディレクトリに配置しているため、ディレクトリが増えることはない。
・ファイル名はterraformの公式サイト記載のものと同一にするというルールであるため、ファイル名についても検討の必要がない。