実案件でTerraformを使った記録メモ

はじめに

個人事業として請け負ったLP案件のAWS環境構築で、Terraformを実際に使ったことがあります。

ただし「深く理解して設計した」というよりは、「必要になった部分を、公式ドキュメントを見ながら動かした」 話なので、メモとして記録を残しておきます。

どこで使ったか

LP案件でよく組んでいるのは、だいたいこんな構成です。

CloudFront ─→ S3（静的LP本体）
    │
    └→ API Gateway ─→ Lambda ─→ SES（問い合わせフォーム）

この構成を Terraform で一式コード化 しています。

コンソール操作との一番の違い

Terraform以前は、AWSの設定変更はすべてブラウザのコンソールでやっていました。

使ってみて一番感じた違いは 「変更が記録として残る」 ことです。

コンソール操作:
  - 「この設定、いつ自分が何のために変えたっけ」がわからなくなる
  - 次の案件で同じ構成を作るとき、手順書が必要
  - 手順書は古くなる、そして更新されない

Terraformで管理すると:
  - .tfファイルがGitに残る
  - git logで「いつ何を変えたか」が追える
  - terraform planで「何が変わるか」を事前に確認できる
  - 次の案件ではコピーして変数を変えるだけで再現できる

特に 「次の案件で使い回せる」 のがLP案件との相性が良かったです。案件ごとにドメインや連絡先メールは違いますが、骨格の構成はほぼ同じなので、変数化しておけば流用できます。

terraform plan の「実際に適用する前に変更内容を確認できる」という仕様も便利で、コンソール操作では「やってみるまでわからない」部分が可視化されます。

実際にやったこと

SES + Route53 の DKIM 設定

LP案件の問い合わせフォームで SES を使うとき、独自ドメインから送信するために DKIM レコードを3つ Route53 に登録する必要があります。コンソール操作だと「同じ操作を3回繰り返す」地味に面倒な作業ですが、Terraform なら count = 3 で一発です。

# SESが生成するDKIMレコードを3つRoute53に一括登録
resource "aws_route53_record" "dkim" {
  count   = 3
  zone_id = var.zone_id
  name    = "${aws_sesv2_email_identity.domain.dkim_signing_attributes[0].tokens[count.index]}._domainkey.${var.domain}"
  type    = "CNAME"
  ttl     = 300
  records = ["${aws_sesv2_email_identity.domain.dkim_signing_attributes[0].tokens[count.index]}.dkim.amazonses.com"]

  depends_on = [aws_sesv2_email_identity.domain]
}

S3 + CloudFront + API Gateway + Lambda

LP本体の配信と、問い合わせフォームのバックエンドもまとめてTerraform化しました。コンソールでCloudFrontを作るときの「OACの設定どうするんだっけ」「バケットポリシーに何書くんだっけ」でつまずく部分が、一度コード化すれば次回は悩まずに済みます。

注意するポイント

terraform.tfstate をGitにコミットはしない

Terraformは「現在の状態」を .tfstate ファイルに記録します。これをGitにコミットするとAWSのアカウントIDやリソースIDが丸見えになるので、.gitignore に必ず追加する必要があります。

# .gitignore
*.tfstate
*.tfstate.backup
.terraform/

これを知らずにコミットすると大変です。

コンソールで直接変更するとズレる

Terraformで管理しているリソースをコンソールから直接変更すると、次回 terraform plan が元に戻そうとします。

「Terraformで管理するものはTerraformだけで変更する」というルールを自分の中で守らないと混乱します。「ちょっとだけコンソールから急ぎで直した」部分が、次の terraform apply で戻されそうになってヒヤッとしたことがありました。

depends_on を忘れると順番がおかしくなる

リソース間に依存関係があるのに depends_on を書かないと、順番がおかしくなってエラーになることがあります。Terraformが自動で依存を検出してくれる場合もありますが、SES のように「アイデンティティが先にできていないと DKIM トークンが生成されない」ようなケースでは明示的に書いた方が安全です。

まだよくわかっていないこと

個人事業のLP規模だと、一人で管理しているのでリモートステートもマルチ環境も必要になったことがありません。チームで本格的に運用する場合に必要になる領域 は、これから学んでいきたい部分です。

まとめ

Terraformは「コードとして残る」「事前に確認できる」「次の案件で使い回せる」という点でコンソール操作より明らかに優れていると感じています。