第23回 Terraform講座｜ModuleでTerraformを部品化する

Terraformの学習も、いよいよ大きな区切りに入ります。

今回のテーマは、

Module

です。

ModuleはTerraformを使う上で非常に重要な機能です。

ここまで、

• VPC
• Subnet
• Route Table
• Internet Gateway
• NAT Gateway
• ALB
• Listener
• Target Group
• EC2
• RDS
• Security Group
• "count"
• "for_each"
• Variables
• Outputs

と学んできました。

これらを組み合わせてAWS環境を作れるようになってきました。

そしてModuleを理解すると、

«「Terraformのコードを書ける」»

から、

«「Terraformのコードを部品として設計できる」»

という段階へ進んでいきます。

---

今日の実務シナリオ

会社でこんなことを言われたとします。

👨‍💼 上司

«「Webサーバーを20個作って。」»

😨

今まで学んできた方法で考えると、

EC2
Security Group
IAM
Subnet

EC2
Security Group
IAM
Subnet

EC2
Security Group
IAM
Subnet

……

20回？

と書くことになります。

さすがに大変です。

しかも、後から、

«「Security Groupの設定を変更して。」»

と言われたら？

20か所修正することになってしまいます。

これはかなり面倒です。

そこで登場するのが、

Module

です。

---

Moduleとは？

例えば、

module "web" {
source = "./modules/ec2"
}

と書きます。

すると、

module "web"
↓
./modules/ec2
↓
EC2
Security Group
IAM
Subnet
その他の設定

というように、

あらかじめ作っておいたTerraformコードのまとまりを呼び出す

ことができます。

つまりModuleとは、

«Terraformコードを再利用できる「部品」にしたもの»

です。

---

料理で考えてみる

Moduleを料理に例えてみます。

毎回カレーを作るたびに、

包丁
まな板
鍋
調味料
野菜
肉

を全部準備するとします。

毎回これを一からやるのは大変です。

そこで、

🍛 カレーセット

を作っておきます。

中には、

野菜
肉
調味料
レシピ

など、カレーを作るために必要なものがまとまっています。

次からは、

«「カレーセットを使う」»

だけで済みます。

TerraformのModuleも同じです。

Module
↓
複数のTerraformコードをまとめた部品
↓
必要な場所から呼び出して使う

という考え方です。

---

今日覚えるコード

まずはこの形を覚えます。

module "web" {
source = "./modules/ec2"
}

今回まず覚えるのは、

module

と、

source

です。

---

"module" は何をしている？

module "web" {
source = "./modules/ec2"
}

この、

module "web"

は、

«「"web" というModuleを使います」»

という意味です。

そして、

source = "./modules/ec2"

で、

«「そのModuleの中身はここにあります」»

と指定しています。

---

"source"とは？

ここは今回かなり重要です。

source = "./modules/ec2"

の、

./modules/ec2

は、

«Moduleがどこにあるのか»

を指定しています。

つまり、

source
↓
Moduleの場所

です。

イメージとしては、

「EC2の部品が欲しい！」

    ↓

source = "./modules/ec2"

    ↓

「ここにEC2 Moduleがあります」

という感じです。

---

実際のフォルダ構成

例えば、

terraform-project/
│
├── main.tf
│
└── modules/
│
└── ec2/
├── main.tf
├── variables.tf
└── outputs.tf

という構成を作ったとします。

ルート側の、

module "web" {
source = "./modules/ec2"
}

は、

main.tf
↓
modules/ec2/
↓
このModuleを使う

という意味になります。

---

Moduleの中には何が入る？

例えばEC2 Moduleの中に、

modules/ec2/

main.tf
variables.tf
outputs.tf

を用意します。

そしてModuleの中で、

EC2
Security Group
IAM
その他の設定

などをまとめて管理できます。

すると、利用する側では、

module "web" {
source = "./modules/ec2"
}

と書くだけで、そのModuleを利用できます。

---

今日の問題

Q1

なぜ、

Module

を使うのでしょうか？

---

Q2

なぜ、

source

を書くのでしょうか？

何を指定していると思いますか？

---

⭐ 今日一番重要

会社には、

Webサーバー
APIサーバー
Batchサーバー

があります。

全部、

EC2
Security Group
IAM

などを使います。

毎回Terraformコードを書く場合と、

Moduleを使う場合では、

どちらの方が保守しやすいでしょうか？

そして、

«なぜそう思うのか？»

まで考えてみましょう。

---

🌟 実務ではModuleがどう使われる？

実際のTerraformプロジェクトでは、

modules/
│
├── ec2/
├── alb/
├── rds/
├── vpc/
└── security_group/

のように、

会社やチームで共通して使うModule

を用意することがあります。

例えば会社標準のEC2構成をModule化しておけば、

module "web" {
source = "./modules/ec2"
}

のように呼び出して使えます。

さらに、

module "api" {
source = "./modules/ec2"
}

module "batch" {
source = "./modules/ec2"
}

のように、同じModuleを複数回利用することもできます。

この場合、

EC2 Module
│
├── Web
├── API
└── Batch

という構造になります。

---

今回の回答

Q1

«サーバーを作るときにそれぞれ役割が違くても、EC2などは同じ設定を使いまわし出来るので、Moduleを使う。»

---

Q2

«どのModuleを参照するのかを決めるため。»

---

⭐ 今日一番重要

«Moduleを使った方が設定を変えるときに少ない工数で済む。»

---

今回のレビュー

Q1：なぜModuleを使う？

回答

«サーバーを作るときにそれぞれ役割が違くても、EC2などは同じ設定を使いまわし出来るので、Moduleを使う。»

評価：💯

考え方は正解です。

特に重要なのは、

«使い回し»

という言葉です。

Moduleの大きな目的の一つは、

«何度も使うTerraformコードを部品化して、再利用できるようにすること»

です。

例えば、

Web
↓
EC2 + SG + IAM

API
↓
EC2 + SG + IAM

Batch
↓
EC2 + SG + IAM

という構成があったとします。

同じようなコードを毎回書くより、

EC2 Module
↓
Web
API
Batch

と使い回せる方が効率的です。

---

Q2：なぜ "source" を書く？

回答

«どのModuleを参照するのかを決めるため。»

評価：💯

これも正解です。

例えば、

module "web" {
source = "./modules/ec2"
}

なら、

source
↓
./modules/ec2
↓
EC2 Module

となります。

つまり、

«"source" はModuleの場所・取得元を指定する»

ものです。

今回のようにローカルのModuleを使う場合は、

./modules/ec2

のようなパスを指定します。

なお、Moduleはローカルだけではありません。

実務では、GitリポジトリやTerraform Registryなど、外部にあるModuleを指定することもあります。

つまり、

«"source" = 「このModuleはどこから持ってくるの？」»

と考えると分かりやすいです。

---

⭐ 今日一番重要な問題のレビュー

回答

«Moduleを使った方が設定を変えるときに少ない工数で済む。»

評価：💯

これも正解です。

さらに一歩進めると、

«修正箇所を集約でき、同じModuleを利用している構成へ同じ変更を適用しやすくなる»

というメリットがあります。

例えば、Moduleを使わずに、

Web
├─ EC2
├─ Security Group
└─ IAM

API
├─ EC2
├─ Security Group
└─ IAM

Batch
├─ EC2
├─ Security Group
└─ IAM

と全部個別に書いていたとします。

ここで、

«「Security Groupの設定を変更してください。」»

と言われたら、

Web → 修正
API → 修正
Batch → 修正

と複数箇所を修正する必要があります。

修正漏れが発生する可能性もあります。

---

Moduleを使った場合

例えば、

         EC2 Module
             │
   ┌─────────┼─────────┐
   ↓         ↓         ↓
  Web       API      Batch

という構造なら、

Module側の共通設定を変更することで、

そのModuleを利用している箇所に変更を反映しやすくなります。

つまり、

修正箇所を集約
↓
保守しやすい
↓
修正漏れを減らしやすい
↓
再利用しやすい

というメリットがあります。

ここがModuleの非常に重要なポイントです。

---

ただし、Moduleは「何でも一つにまとめればいい」わけではない

ここも実務では重要です。

例えば、

VPC
ALB
EC2
RDS

を全部一つのModuleに詰め込んでしまうと、

«「このModuleは何を作るModuleなんだ？」»

となってしまいます。

そのため、

VPC Module
ALB Module
EC2 Module
RDS Module

のように、

役割ごとに適切な単位でModule化する

ことが重要です。

Moduleの目的は、

«「とにかくコードをまとめる」»

ではありません。

本質は、

«再利用しやすく、変更しやすく、理解しやすい単位にTerraformコードを部品化する»

ことです。

---

🌟 Moduleが難しく感じる理由

今回、

«「これは難しいね」»

という感覚になりました。

これはかなり自然です。

これまで勉強してきた、

VPC
EC2
ALB
RDS
Subnet

などは、全部AWSに実際に存在するサービス・リソースでした。

一方、Moduleは、

«Terraformのコードを整理・再利用するための仕組み»

です。

つまり、

今まで
AWSを理解する
↓
Terraformで作る

今回
Terraformコードそのものを
どう設計するか

というように、考える対象が一段上がっています。

だから難しく感じます。

---

🍱 Moduleを「セット商品」として考える

Moduleをもう一つ身近な例で考えてみます。

コンビニで、

パン
ジュース
ヨーグルト

を毎朝1個ずつ買うとします。

毎回、

パンを選ぶ
↓
ジュースを選ぶ
↓
ヨーグルトを選ぶ

とするより、

🌅 朝食セット

として、

パン
ジュース
ヨーグルト

がまとめられていた方が便利です。

Terraformでも、

EC2
Security Group
IAM
その他の設定

を一つのModuleとしてまとめておけば、

module "web" {
source = "./modules/ec2"
}

のように呼び出せます。

これがModuleの基本的なイメージです。

---

Module・Variables・Outputsのつながり

ここまで学んできた機能が、ここでつながってきます。

Variables

外から値を渡す
↓
Variables
↓
Module

例えば、

module "web" {
source = "./modules/ec2"
instance_type = "t3.micro"
}

のように、Moduleへ設定値を渡せます。

---

Outputs

Moduleの中で作った情報を、

Module
↓
Output
↓
必要な情報を外へ

という形で取り出せます。

---

つまりModuleはこうなる

             Module
    ┌─────────────────────┐
    │                     │

Variables → EC2 │
│ Security Group │
│ IAM │
│ その他の設定 │
│ │
└─────────┬───────────┘
↓
Outputs
↓
必要な情報

ここまで来ると、

Variables

と、

Outputs

をModuleと組み合わせて使う意味が見えてきます。

---

🌟 今回の理解度

⭐⭐⭐⭐⭐ 5 / 5

今回の回答は、Moduleを初めて学ぶ回としてかなり良い理解です。

特に、

«「EC2などは同じ設定を使い回しできる」»

というところを自分で考えられているのが重要です。

Moduleを覚える目的は、

Moduleというコードを暗記する

ことではありません。

大切なのは、

同じようなコードを何度も書いている
↓
これ、部品にできない？
↓
Moduleにする
↓
必要な場所で再利用する

という発想です。

これはTerraformだけではなく、ソフトウェア設計でも非常に重要な考え方です。

---

🎓 Terraform初級編の一区切り

ここまでで、Terraformの基礎としてかなり多くのことを学びました。

AWSリソース

• VPC
• Subnet
• Route Table
• Route Table Association
• Internet Gateway
• NAT Gateway
• ALB
• Listener
• Target Group
• Target Group Attachment
• EC2
• RDS
• Security Group
• DB Subnet Group

Terraformの機能

• "count"
• "for_each"
• "variable"
• "output"
• "module"

これらをバラバラに覚えるのではなく、

VPC
↓
Subnet
↓
Route
↓
ALB
↓
EC2
↓
RDS
↓
Security Group
↓
Variables
↓
Outputs
↓
Module

という一つの流れとして理解できるようになってきました。

---

🔥 ここから「設計」の授業へ

ここまでは、

«「このTerraformコードは何をしている？」»

という問題を中心に学んできました。

ここから先は少し変わります。

今度は、

«「会社からこんなAWS環境を作ってと言われた。どう設計する？」»

という問題に挑戦します。

例えば、

---

👨‍💼 上司

«「新しいWebサービスをAWS上に構築して。」»

要件

• インターネットからアクセスできる
• Webサーバーは複数台
• WebサーバーはPrivate Subnet
• ALBを使用する
• RDSを使用する
• RDSは外部から直接アクセスできない
• AZ障害にも対応したい
• 開発・検証・本番で設定を変えたい

---

ここで、もうコードは最初から渡しません。

自分で、

① どんなAWS構成にする？
↓
② どのSubnetが必要？
↓
③ どんなRouteが必要？
↓
④ Security Groupはどうする？
↓
⑤ どのTerraform Resourceが必要？
↓
⑥ Variablesは何に使う？
↓
⑦ Outputsは何を出す？
↓
⑧ Moduleはどう分ける？
↓
⑨ Terraformを書く

という順番で考えていきます。

これまで覚えてきた知識を、全部使います。

---

🚀 次回から実務総合演習

次回からは、

「Terraformのコードを教えてもらう授業」

ではなく、

「要件を渡されて、自分で設計する授業」

に変わります。

つまり、

先生
↓
会社の要件を出す
↓
自分でAWS構成を考える
↓
Terraform Resourceを考える
↓
コードを書く
↓
先生がレビュー
↓
改善する

という流れです。

今までの学習は、

«設計するための材料を集める期間»

でした。

ここからは、その材料を使って、

«自分でAWS環境を設計する期間»

に入ります。

Terraformの学習が、

「コードを覚える」
↓
「コードの意味を理解する」
↓
「なぜそのコードが必要か考える」
↓
「要件から構成を設計する」
↓
「設計をTerraformに落とし込む」

へ進んでいきます。

ここからが、Terraformの本当に面白いところです。🔥☁️🚀