どうも、oskn259です。

今回はTerraformを使ったインフラ構築を解説していきます。
詳細な解説というよりは、ある程度使ったことがある人が最短で実践できるような内容にしました。

awsやgcpの設定をテキストで表現できるということで僕も気に入っているTerraformですが、設定の規模が大きくなってくると、意味ごとにファイルを分割したくなってきます。
EC2インスタンス設定、ELB設定... といった感じですね。
モジュール分割という方法で実現できるようなので、早速試していきましょう。

参考：https://stackoverflow.com/questions/39803182/terraform-use-case-to-create-multiple-almost-identical-copies-of-infrastructure  

今回の内容はこちらで書いた記事の修正版でもあります。
https://blog.oskn259.com/article/210903-terraform-module

公式：https://www.terraform.io/docs/language/modules/index.html
言ってしまえば、普通にtfファイルを書いた場合と同じ構造を、モジュールとして使用できるということのようです。
rootとleafが同じ構造の、フラクタル構造のような感じですね。

今回は以下のようなディレクトリ構造になりました。
shellscript
main.tf
modules/
 cloudwatch_widget_explorer/
  main.tf
  templates/
   dashboard.tpl

modulesディレクトリを追加し、cloudwatch_widget_explorerというモジュールを作成しました。
モジュールの中には、tfファイルをモジュール外と同じように作成します。
templates/ディレクトリはモジュールの処理で必要になるので、同じ階層に配置しています。

モジュール内のtfファイルはこんな感じです。
（重要でない箇所は省略しました）
terraform

# modules/cloudwatch_widget_explorer/main.tf

variable "name" {
 description = "name of dashboard"
 type = string
}

data "template_file" "body" {
 template = file("${path.module}/templates/dashboard.tpl")
 vars = {
  widgets = jsonencode([
   { name: var.name }
  ])
 }
}

resource "aws_cloudwatch_dashboard" "metrics" {
 dashboard_name = var.name
 dashboard_body = data.template_file.body.rendered
}

同階層にあるテンプレートファイルに値をセットし、それをaws_cloudwatch_dashboardにてAWSに反映するという内容です。
nameをvariableとして宣言しておくことでモジュールを利用する側にとってこの値は入力必須となり、必ず有効な値を受け取った上で実行できるようになっています。

モジュールだからといって特別な記述は必要なく、普通にtfファイルを書くように作成すればokです。

main.tfの記述はこんな感じです。
関連箇所だけ抜き出しています。
terraform
module "cloudwatch_widget_explorer_api" {
 source = "./modules/cloudWatch_widget_explorer"
 name = "api-metrics"
}

module "cloudwatch_widget_explorer_www" {
 source = "./modules/cloudWatch_widget_explorer"
 name = "www-metrics"
}

moduleを使用して、自作のモジュールを呼び出しています。
どのモジュールを呼び出しているのかを指定しているのはsourceの部分で指定するパスであって、moduleの後に続く文字列には好きな名前を指定できます。
また、モジュール側で要求しているnameをここで指定する必要があります。

機能をモジュール化しつつパラメータを指定できるようにするのは、コードの再利用がしっかり効いて良いですね。
基本的な概念なので最近のツールでできないわけは無いのですが、検索したらちゃんとドキュメントが出てきたという所です。

変更の結果を予測できるようにする、望まぬ変更は回避するというポリシーがインフラコード化界隈にはあると感じていて、今回のモジュール化に関してもパラメータのバリデーションがしっかりなされていてその意思を感じますね。