Terraform 使用時に考慮しておくこと

Contents

はじめに
必要なドキュメントについて
ディレクトリ構成
terraform のバージョン管理について
おわりに
参考

はじめに

本記事では Terraform 使用時に考慮が必要だと感じたことについてまとめます。Terraform をプロジェクトで使用する場合、考慮する項目は本ページの内容以外にもあるかと思いますが、参考にしていただければと思います。

必要なドキュメントについて

IaC なので Terraform のコードがあればドキュメントは不要だという声もあるかと思いますが、個人的に以下は最低限必要になってくると考えています。

Terraform を含むツールのインストール手順
環境に適用する際のオプション込みのコマンドおよびその手順
インフラ構成図
drawio などで作成して git 管理する
IaCファイルに変更が入ったタイミングで構成図も変更して同時にレビューする

ディレクトリ構成

どういった構成が最適かはプロジェクトの性質よるところが大きいと考えています。以下に例を示します。
内容は以下を大いに参考にしています。詳細はリンク先をご確認ください。

個人的に最もよく使用するディレクトリ構成です。

メリット

terraform apply1回で環境のリソースを全てデプロイできる

デメリット

version.tf など中身が同じファイルが環境の数だけ作成される
module の変更を行うと全環境に影響を与える可能性がある
各環境の全リソースを1つの tfstate ファイルで管理するため、リソースが多くなると plan や apply の速度に影響する
& apply 時にかかるロックの範囲が大きくなる→同時作業可能な数に影響する

上記のデメリットを解決する他の案を示します。

module の変更を行うと全環境に影響を与える可能性があるの解決策として module を別リポジトリで管理するパターンがあります。
- module のバージョン番号を指定して呼び出すことができるため module 変更が全環境に影響を与えてしまうという問題を防ぐことができます。
- 一方で複数のリポジトリの管理が必要になります
各環境の全リソースを1つの tfstate ファイルで管理するため、リソースが多くなると plan や apply の速度に影響する & apply 時にかかるロックの範囲が大きくなる→同時作業可能な数に影響するの解決策としてリソースごとにディレクトリを作成するパターンがあります。
- 各 tfstate ファイルで管理するリソースが少ないため、速度やロックの問題を防ぐことができます。
- 一方で各ディレクトリ内で apply を実行する必要があります。(スクリプトの作成でカバー可能)

terraform のバージョン管理について

terraform ブロックで指定する。
~>を使用することで実行可能なバージョンに幅を持たせることができる、
公式では~>を使用してメジャーバージョン、マイナーバージョンを固定することを推奨している。

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      # 4.x を許容(x>16)
      version = "~> 4.16"
    }
  }
  # 1.2.0 以降のバージョンを許容
  required_version = ">= 1.2.0"
}