TerraformのState管理を「GitLab」で完結させる：IaC運用の極限最適化ガイド
TerraformのStateファイルをどこに置くか？ S3 + DynamoDBという構成は王道だが、GitLabを既に採用しているチームなら、GitLab Managed Terraform State を使わない手はない。
なぜなら、Terraformの実行環境とState管理、そしてCI/CDパイプラインが「GitLab」という単一のコンテキストで完結するからだ。これは単なる統合ではない。認証情報の散逸を防ぎ、MR（マージリクエスト）上でPlan結果を可視化し、チーム開発における「誰かがロックを外すのを待つ」という無駄な時間を排除する最強のアーキテクチャだ。
本稿では、現場のテックリードが即座に導入すべき、GitLabでのTerraform運用最適化術を伝授する。
—
1. なぜ「GitLab Managed Terraform State」を選ぶべきか
S3バックエンドの場合、DynamoDBのテーブル作成や権限管理など、インフラ構築の前に「インフラのためのインフラ」を管理する必要がある。GitLabを使えば、`HTTP`バックエンドとして標準対応しており、以下の恩恵が自動的に享受できる。
- 自動ロック: 競合によるState破損を物理的に防ぐ。
- 暗号化: GitLab側でデータは暗号化されて保存される。
- CI連携: MRにPlan結果がインラインで表示され、レビューのスピードが爆速になる。
—
2. 実践：GitLab CI/CDとの統合設定
まずは `backend.tf` を作成する。わざわざ環境ごとにファイルを分ける必要はない。Terraformの`-backend-config`オプションを活用しよう。
backend.tf
terraform {
backend “http” {
# 設定値はCI/CD実行時にオーバーライドするため、ここでは空かダミーで良い
}
}
次に、`.gitlab-ci.yml` でTerraform実行環境を構築する。ここで重要なのは「認証情報のスマートな渡し方」だ。
.gitlab-ci.yml
variables:
# プロジェクトIDはGitLabの環境変数から取得
TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/default
.terraform_base:
image: hashicorp/terraform:latest
before_script:
- terraform init
-backend-config=”address=${TF_ADDRESS}”
-backend-config=”lock_address=${TF_ADDRESS}/lock”
-backend-config=”unlock_address=${TF_ADDRESS}/lock”
-backend-config=”username=gitlab-ci-token”
-backend-config=”password=${CI_JOB_TOKEN}”
-backend-config=”lock_method=POST”
-backend-config=”unlock_method=DELETE”
-backend-config=”retry_wait_min=5″
plan:
extends: .terraform_base
script:
- terraform plan -out=plan.tfplan
artifacts:
reports:
terraform: plan.tfplan # これによりMRにPlan結果がインライン表示される
現場のハック：MRインライン表示の真髄
`artifacts:reports:terraform` を指定することで、GitLabのMR画面に「Planの結果」が表示される。レビュー時にCLIを叩く必要は一切ない。差分（+ / -）をGUIで確認し、問題なければそのままマージボタンを押す。これがTerraform運用の「あるべき姿」だ。
—
3. チーム開発を加速させる「神設定」と運用ルール
① `.terraform.lock.hcl` を必ずコミットせよ
依存関係のハッシュ値を固定するロックファイルは、チーム開発の生命線だ。「自分の環境では動く」という事故を100%防ぐ。`.gitignore` に含めるのは愚の骨頂である。
② VS Codeの「Terraformプラグイン」設定
チーム全員に導入させるべき拡張機能は `HashiCorp Terraform` 一択だ。
以下の設定を `.vscode/settings.json` に強制配置せよ。
{
“terraform.languageServer”: {
“args”: [“serve”]
},
“editor.formatOnSave”: true,
“editor.codeActionsOnSave”: {
“source.fixAll”: “explicit”
}
}
これで保存するたびに `terraform fmt` が走り、コードスタイルが統一される。
③ 隠れたキーボードショートカット（VS Code）
- `Ctrl + Shift + P` -> `Terraform: Init` : これを指に覚え込ませろ。
- `F12` (Go to Definition) : モジュール化されたコードを追う際、これがないと始まらない。
—
4. 事故を防ぐための「絶対ルール」
1. Direct Pushの禁止: `main`ブランチへの直接プッシュはGitLabのProtected Branches機能で物理的に封鎖せよ。すべてMRを通す。
2. Stateの直接編集禁止: 万が一のState破損時、ローカルで編集しようとするな。`terraform state rm` 等のコマンドラインツールを使い、手順をドキュメント化してMR経由で実行せよ。
3. CI_JOB_TOKENの活用: 外部のAWS認証キーをGitLabに保存する際、`Masked`と`Protected`を必ずオンにすること。これでログに認証情報が流出するリスクをゼロにできる。
—
最後に：テックリードからの提言
TerraformのState管理をGitLabに寄せる最大のメリットは、「エンジニアの認知負荷を下げること」にある。
「どこにStateがあるんだっけ？」「ロックが解除されないんだけど」というインフラの雑務は、すべてCI/CDのパイプラインに溶かして消し去るべきだ。
GitLabのTerraform機能は、単なるストレージではない。開発チームが「コードを書くこと」と「インフラをデプロイすること」の境界線を曖昧にし、高速なフィードバックループを回すための強力なエンジンだ。
今日からS3の管理画面を閉じて、GitLabのパイプラインを最適化しよう。その先には、もっとクリエイティブなインフラ設計が待っているはずだ。