GitLabでTerraform Stateを支配する：インフラ管理の「悪夢」を終わらせる実践ガイド
こんにちは。インフラ自動化の深淵へようこそ。
Terraformを触り始めたエンジニアが必ず直面する壁、それが「State（状態）ファイルの管理」です。ローカル環境で `terraform.tfstate` を抱え込み、チームメンバーとファイルを送り合って上書き事故を起こす……そんな「インフラ管理の悪夢」を経験したことはありませんか？
GitLabには、TerraformのStateをクラウド上で安全に管理し、CI/CDパイプラインと密結合させるための強力な機能が備わっています。これをマスターすれば、あなたのインフラ管理は「個人の作業」から「チームの強力な資産」へと劇的に進化します。
今日は、その本質的な設定手順を、現場の知見を交えて丁寧に解説していきます。
—
1. なぜ「GitLab Managed Terraform State」を使うべきか？
Terraformは「今のインフラがどうなっているか」をStateファイルに記録します。これをどこに置くかは死活問題です。
- 自動ロック: 複数人が同時に `terraform apply` しても、Stateをロックして競合を防ぐ。
- 暗号化: GitLab側で自動的に暗号化されるため、セキュリティ面で安心。
- CI/CD統合: `terraform plan` の結果をMR（マージリクエスト）画面に直接表示し、誰が何を変更しようとしているか一目でわかる。
これを使わない手はありません。さあ、セットアップを始めましょう。
—
2. 【最速セットアップ】State管理の基盤を作る
まずは、TerraformがGitLabのState管理機能を使うための「魔法の呪文」を `main.tf` に記述します。
main.tf
terraform {
backend “http” {
# GitLabのState APIを利用するためのエンドポイント設定
# プロジェクトIDはGitLabのプロジェクトトップ画面で確認できます
address = “https://gitlab.com/api/v4/projects/<プロジェクトID>/terraform/state/default”
lock_address = “https://gitlab.com/api/v4/projects/<プロジェクトID>/terraform/state/default/lock”
unlock_address = “https://gitlab.com/api/v4/projects/<プロジェクトID>/terraform/state/default/lock”
lock_method = “POST”
unlock_method = “DELETE”
username = “
password = “
}
}
現場の知見：認証情報の扱い
`username` や `password` をハードコードしてGitにコミットするのは絶対NGです。ローカルでの実行時は環境変数（`TF_HTTP_USERNAME`, `TF_HTTP_PASSWORD`）に設定し、GitLab CI上では、GitLabが自動で提供する `CI_JOB_TOKEN` を利用するのがベストプラクティスです。
—
3. HelloWorld：インフラ構成の第一歩
まずは、Stateが正しくGitLabに保存されるか確認する最小構成のコード（`hello.tf`）を書いてみましょう。
hello.tf
今回は確認のため、GitLabのダミーリソースを作成します
resource “null_resource” “hello” {
provisioner “local-exec” {
command = “echo ‘Terraform State is managed by GitLab!'”
}
}
動作確認の手順:
1. `terraform init` を実行します。GitLabのバックエンドが正しく認識されれば成功です。
2. `terraform apply` を実行します。
3. GitLab画面の [Infrastructure] > [Terraform] を開いてみてください。`default` というStateファイルが生成されていれば、成功です！
—
4. CI/CDパイプラインとの連携（極限の最適化）
ここからが本番です。MRを作成するたびに `terraform plan` を自動実行させ、変更内容をMR画面に表示させましょう。`.gitlab-ci.yml` をこう記述します。
.gitlab-ci.yml
image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
stages:
- validate
- plan
plan:
stage: plan
script:
- terraform init
- terraform plan -out=plan.cache
- terraform show -json plan.cache > plan.json
# GitLabの特別な機能：plan結果をMRにコメントとして投稿する
artifacts:
reports:
terraform: plan.json
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
この設定を行うと、MRの画面に「Terraform plan」の要約が表示されます。チームメンバーが「これ、本当に実行して大丈夫な変更かな？」と迷う時間がゼロになります。
—
5. 運用上の鉄則：先輩からのアドバイス
最後に、現場で事故を起こさないための「魂の心得」を3つ授けます。
1. Stateファイルを手で触るな: 「ちょっとStateファイルを直接修正して直そう」という誘惑は悪魔の囁きです。Terraformの整合性が壊れます。必ず `terraform state` コマンドを経由してください。
2. Planのログを信じすぎない: `terraform plan` はあくまで「予測」です。本番環境の直前に一度手元で `apply` をシミュレーションする習慣を、新人時代から身につけてください。
3. トークンの有効期限に注意: CI/CDで使う `CI_JOB_TOKEN` は強力です。権限は「必要最小限」に絞り、環境変数の管理にはGitLabの Masked Variable 機能を使ってください。
—
最後に
インフラをコード化する（IaC）最大のメリットは、「誰がいつ変更しても、同じ結果が再現できる」ことにあります。GitLabのState管理は、そのための最も信頼できる基盤です。
最初は少し難しく感じるかもしれませんが、一度この仕組みを組み込んでしまえば、毎日の作業は劇的に楽になります。自信を持って、最初の一歩を踏み出してください。応援していますよ！