IaC

Terraform→OpenTofu移行実践ガイド: 既存IaCを止めずに移行するエンタープライズ手順 Terraformのライセンス変更以降、OpenTofuへ移行したいという相談は確実に増えています。とはいえ現場の本音は「理屈は分かるが、stateが壊れたら終わる」「本番を止めずに移行できるのか不安」です。 結論から言うと、移行は十分可能です。ただし「CLIを置き換えるだけ」で済むケースは限定的で、実際は providerバージョン整合・state lock・CI/CD・運用Runbook までまとめて整える必要があります。 本記事では、既にTerraformを本番運用しているチーム向けに、OpenTofuへ段階移行する実践手順をまとめます。 1. 移行方針を先に決める 最初に決めるべきは「一気に切り替えるか」「ワークスペース単位で段階移行するか」です。実務では次の方針が安全です。 低リスク環境（dev/sandbox）から先行 本番は最終フェーズで移行 旧TerraformとOpenTofuを一定期間並行運用 ロールバック手順を文書化してから実施 この順序を守るだけで、移行事故の大半を避けられます。 2. 互換性の棚卸し（最重要） まずは現状のIaC資産を棚卸しします。 Terraformバージョン（例: 1.5.x / 1.6.x） 使用provider（AWS/Azure/GCP/Kubernetes等） backend（S3 + DynamoDB lock、Terraform Cloud、GCSなど） moduleの参照方式（registry / git / local） CI実行環境（GitHub Actions, GitLab CI, Jenkins） 2.1 依存を固定化してから移行する .terraform.lock.hcl を必ずコミットし、providerを固定します。移行時にproviderまで同時更新すると、差分原因の切り分けが困難になります。 1 2 3 4 5 6 7 8 9 terraform { required_version = ">= 1.6.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 5.40" } } } 移行フェーズでは「ツール差分」と「provider差分」を分離してください。 ...

Terraformドリフト検知プレイブック：本番事故を防ぐCI設計と運用手順 Terraform を導入していても、運用が進むほど「実環境がいつの間にかコードとズレる」問題にぶつかります。いわゆるドリフトです。最初は小さな差分でも、放置すると本番変更時に予期せぬ差分が混ざり、障害やリリース遅延の原因になります。 本記事では、Terraform ドリフト検知を単なる terraform plan 実行で終わらせず、継続運用できる仕組みとして実装するための具体策をまとめます。対象は AWS を例にしますが、考え方は他クラウドでも共通です。 1. ドリフト検知で最初に決めるべきこと 多くのチームが失敗するのは、実装前に運用設計を決めないことです。まず以下を決めます。 どの環境をいつ検知するか（prod は毎日、stg は平日など） 検知結果をどこに通知するか（Slack/Discord/Issue） 誰がいつまでに対応するか（当番制、SLA） 「意図した手動変更」をどう扱うか（例外ラベル、期限付き） ここを決めずに CI だけ作ると、通知がノイズ化して無視されます。ドリフト検知は技術課題より運用課題です。 2. リポジトリ構成と state 分離 最小限、次のような構成を推奨します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 infra/ modules/ vpc/ ecs/ rds/ envs/ prod/ main.tf backend.hcl variables.tf stg/ main.tf backend.hcl .github/ workflows/ terraform-drift.yml 環境ごとに backend と state を分けることが重要です。ドリフト検知ジョブが state を誤って参照すると、存在しない差分が出ます。S3 backend + DynamoDB lock を使う場合は、bucket/key/region/table の整合性を必ず固定化します。 ...