Terraform CI/CDの真実：単なる「自動化」で終わらせない、堅牢なパイプライン設計
「Terraformの実行をCI/CDに乗せた」。そう言える現場は多い。だが、「変更が意図通りであることを証明し、かつ人類のミスを排除するフロー」を構築できている現場はどれほどあるだろうか。
TerraformのCI/CDは、単に `terraform apply` を叩く場所ではない。それは、インフラというコードの「品質保証ゲート」である。本稿では、GitHub Actionsを活用し、プルリクエスト（PR）駆動で安全かつ爆速にインフラを回すための極限の設計を伝授する。
—
1. 現場の生産性を極限まで高める「隠し味」
まず、エディタ環境から見直そう。Terraformを日常的に叩くエンジニアが導入すべきは以下のツールだ。
- VS Code神プラグイン: `HashiCorp Terraform` は当然として、`TFLint` は必須だ。クラウドプロバイダーの固有ルール（インスタンスタイプの互換性など）を静的解析で叩き出す。`terraform validate` では見抜けない「設計ミス」を排除せよ。
- キーボードショートカットの極致:
- `terraform fmt -recursive` を保存時に走らせる設定（`editor.codeActionsOnSave`）は、コードレビューにおける「インデント修正」という無駄な議論をこの世から消し去る。
- 共有設定: `terraform.rc`（CLI構成ファイル）を活用し、`provider_installation` のキャッシュを設定せよ。プロバイダーのダウンロード時間をミリ秒単位で削減できる。
—
2. GitHub Actionsによる「堅牢な」CI/CDパイプライン
パイプラインの肝は「プランの可視化」と「実行の完全なロック」だ。以下のYAMLは、実戦で最もトラブルが少ない構成例である。
.github/workflows/terraform.yml
name: ‘Terraform Pipeline’
on:
pull_request:
branches: [ “main” ]
push:
branches: [ “main” ]
jobs:
terraform:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write # PRへのコメント権限
steps:
- uses: actions/checkout@v4
- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
with:
terraform_wrapper: false # 独自制御のためwrapperを無効化
- name: Terraform Init
run: terraform init
- name: Terraform Plan
if: github.event_name == ‘pull_request’
id: plan
run: |
terraform plan -no-color -out=tfplan
# プラン結果をPRにコメントとして投稿する（tf-summarize等との併用推奨）
echo ‘plan_result<
terraform show -no-color tfplan >> $GITHUB_ENV
echo ‘EOF’ >> $GITHUB_ENV
- name: PR Comment
if: github.event_name == ‘pull_request’
uses: actions/github-script@v7
with:
script: |
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: `
Terraform Plan Result\n\`\`\`\n${process.env.plan_result}\n\`\`\“
})
- name: Terraform Apply
if: github.ref == ‘refs/heads/main’ && github.event_name == ‘push’
run: terraform apply -auto-approve tfplan
—
3. プロの現場で不可欠な「3つの設計哲学」
単に動くコードを書いて満足してはいけない。以下の運用ルールをチームに徹底せよ。
① プランの可読性を上げる `tf-summarize`
`terraform show` の出力は長すぎてレビューにならない。CIの中で `tf-summarize` を使い、変更差分をMarkdownテーブルでPRに吐き出せ。人間は「何が追加され、何が削除されるか」を秒で判断できる必要がある。
② 冪等性（Idempotency）を疑え
「Terraformは冪等である」と盲信してはいけない。特に外部のAPI変更や、ランダムなリソースID生成を伴う場合、`terraform plan` で表示されない副作用が隠れていることがある。CIの最後には必ず `terraform plan` を再度実行し、「Infrastructure is up-to-date」が出ることを確認するジョブを追加せよ。
③ stateファイルの分離とロック
チーム開発では、`terraform.tfstate` をGit管理するな。必ずS3 + DynamoDB（またはTerraform Cloud）でロックをかけよ。CI環境でも `TFC_WORKSPACE` を適切に切り替え、複数のPRが同時に同じインフラを書き換えないよう、`concurrency` キーを使って同時実行を制御するのだ。
—
まとめ：インフラエンジニアの価値とは
インフラの自動化において、最も価値があるのは「自動化そのもの」ではない。「ミスが発生したときに、瞬時に切り戻せる（Rollback）状態」と「変更の意図が誰の目にも明らかな状態」を維持することだ。
今日からあなたのパイプラインに `plan` のコメント投稿と `tf-summarize` を導入せよ。それだけで、チームのレビューコストは激減し、インフラ運用の品質は一段上のステージへ昇華される。
さあ、コマンドを叩くのはもう終わりだ。コードでインフラを支配する快感を、その手で確かめてほしい。