Terraformを書き始めた頃、こう思っていました。
「コードでインフラ管理できるの、めちゃくちゃ良いじゃん」
環境差分も減るし、 レビューもできるし、 CI/CDにも乗せられる。
インフラエンジニアとして、かなり理想的に見えました。
でも実務でTerraformを使い始めて痛感したのは、
本当に大変なのは“新規構築”ではない
ということです。
地獄は、既に動いているAzure環境をTerraform管理へ移行する瞬間に始まります。
新規構築より「既存環境のTerraform化」が圧倒的に難しい
新規環境なら比較的シンプルです。
terraform init terraform plan terraform apply
で進められる。
でも既存環境は違います。
現実には、
- 手動変更されたリソース
- 命名ルールが揃っていない環境
- 誰が作ったか分からない設定
- Portalで直接変更された構成
- 運用開始後に継ぎ足された例外設定
が大量に存在します。
つまり、
「綺麗な設計図が存在しない状態」
からスタートする。
これが本当にキツい。
importは「作業」ではなく「調査」
Terraform importをやる前、 正直かなり軽く考えていました。
でも実際に始めると、 完全に認識が変わります。
例えばAzure環境なら、
- Resource Group
- Storage Account
- App Service
- Key Vault
- Managed Identity
- Diagnostic Settings
- Role Assignment
など、import対象が大量にある。
しかも厄介なのが、
「importできた = 正しく管理できる」
ではないこと。
stateに入っただけでは終わりません。
- 属性差分
- 命名不整合
- tags違い
- SKU差分
- provider差異
などで、 planが永遠に差分を出し続ける。
terraform import は、 ただの開始の合図でしかありません。
本当の戦いは、
terraform show で出力されたstateを元に、
一つずつHCL（.tfファイル）へ書き起こし、
planで差分ゼロ（No changes）になるまで微調整を繰り返す
あの千本ノックのような作業です。
一番怖いのは「気づかないdestroy」
Terraform運用で怖いのって、 エラーではないんですよね。
むしろ怖いのは、
planが普通に通っているように見えること
です。
provider upgrade後、 何気なくplanしたら、
- Diagnostic Settings再作成
- Role Assignment差分
- App Service設定変更
などが突然出てくる。
しかもAzureRM providerって、 バージョン差異で挙動が変わるケースが結構ある。
特に怖かったのが、 App Service import後の差分でした。
Terraform側コードに定義していなかった site_config の微細なデフォルト値差異だけで、
「App ServiceのReplacement（再作成）」
が走りそうになった。
あの瞬間は、本気で血の気が引きました。
もし本番環境でapplyしていたらと思うと、 今でも少し怖い。
一時期、 terraform plan を打つのが少し怖くなっていました。
何気なく実行したplanに、 大量の差分が突然現れる。
しかも原因は、
- provider upgrade
- Azure側仕様変更
- Portalでの手動変更
だったりする。
「便利な自動化ツール」 だったはずなのに、 いつの間にか“インフラへ変更を加える兵器” にも見えてくる。
Terraformを深く触るほど、 applyボタンの重みが変わっていきました。
stateファイルは「インフラの心臓」
Terraformを触り始めた頃は、 stateを軽く見ていました。
でも実務では違いました。
stateは単なる管理ファイルではなく、
「Terraformが世界をどう認識しているか」
そのものです。
だから、
- state肥大化
- state lock競合
- backend問題
- module分割
- workspace設計
などが始まると、 一気に運用難易度が上がる。
特に複数人運用では、
「state壊したら終わる」
みたいな緊張感があります。
実際、一度state競合で想定外差分が出た時は、 かなり胃が痛かったです。
Azure運用は「理想」と「現実」の折り合いでもある
特にAzureは、 Portal側で自動付与される設定や、 勝手に有効化される属性が結構あります。
例えば：
- 自動タグ
- Diagnostic Settings
- Preview機能
- Azure Policy経由変更
など。
その結果、
「Terraform定義とAzure実環境が自然にズレる」
問題が起きやすい。
最終的には、
lifecycle { ignore_changes = [ tags, # Portal側で自動変更されやすい設定 app_settings["WEBSITE_RUN_FROM_PACKAGE"] ] }
のように、
ignore_changes で現実との折り合いをつける場面も出てきます。
でもここって、 単なるテクニックではないんですよね。
- Terraformを絶対の正とするのか
- Portal変更を許容するのか
- 運用チームの自由度を残すのか
つまり、
「どこまでコードで統制するか」
という“運用思想”の話になる。
この辺りから、 Terraformは単なるIaCツールではなく、 運用設計そのものの話になっていく感覚があります。
Terraformの価値は「速度」ではなく「再現性」
ここ、かなり重要だと思っています。
Terraformの価値って、 「速く作れる」 だけじゃない。
本当の価値は、
「壊れても同じものを再現できる」
こと。
属人化した手順書運用だと、 障害時に“その人しか戻せない”状態になります。
でもIaC化されていると、
- 差分
- 変更履歴
- レビュー
- ロールバック
が見える。
つまり、
「インフラを開発プロセスへ乗せられる」
んですよね。
この視点を持ってから、 Terraformを見る目がかなり変わりました。
import地獄を経験すると「市場価値」が変わる
Terraform importって、 正直かなりしんどいです。
新規構築より遥かに泥臭い。
でも逆に言うと、 ここを経験している人って意外と少ない。
実際、エージェント案件を見ていても、
- Terraform経験
- Azure IaC
- CI/CD
- 運用設計
をセットで求める案件はかなり増えています。
特に、
- 「既存環境をコード化した」
- 「運用まで含めてTerraform管理した」
経験は、かなり評価されやすい印象があります。
もしあなたが今、 深夜に plan の結果と格闘しながら import を進めているなら、 その苦労は間違いなく「高く売れる」経験です。
「ただTerraformが書ける」
のと、
「地獄のimportを完遂した」
のでは、市場での評価はかなり違う。
以前書いた、
「Azureエンジニアが市場価値をデバッグする」
という記事でも触れましたが、 IaCって単なる効率化ではなく、
「運用設計そのものを変える経験」
なんですよね。
だからこそ、 実務で泥臭くハマった経験ほど、 あとから市場価値に変わっていく感覚があります。
もし、 「この経験って実際どれくらい評価されるんだろう？」 と気になったら、 一度“市場価値のデバッグ”をしてみるのも面白いかもしれません。
最後に：Terraformは“綺麗事”だけでは終わらない
Terraform導入前は、
- コード化
- 自動化
- DevOps
- 再利用性
みたいな綺麗な言葉ばかり見ていました。
もちろん、それ自体は間違っていません。
でも実務では、
- import地獄
- provider事故
- state競合
- destroy恐怖
- RBAC沼
みたいな、 かなり泥臭い世界があります。
深夜、 terraform plan の結果を見ながら、
「頼むからdestroyだけは出ないでくれ……」
と祈るような瞬間もある。
ただ、その泥臭さを越えた先で、
「インフラを再現可能にする」
価値が見えてくる。
個人的には、 Terraformって単なるツールではなく、
「運用そのものを設計し直す思想」
なんじゃないかと思っています。
あわせて読みたい
- Azureエンジニアが市場価値を「デバッグ」する。Terraform経験を単価に変える生存戦略
- Azure RBACで403が消えなかった原因とManaged Identityの落とし穴
- なぜ今Terraformなのか？実務運用で感じた「コード化」の真価
- インフラエンジニアが「運用だけ」から抜け出して単価が変わった話
