Terraformを実行する前に必ずプランを確認すべき理由

新しいサーバーとデータベースのTerraform設定を書き終えたとします。ファイルは正しく見えます。terraform applyを実行して待ちます。数秒後、サーバーが必要なサイズの2倍で、データベースが間違ったリージョンにあることに気づきます。今度はすべてを破棄してやり直さなければなりません。

このシナリオは、Infrastructure as Codeに慣れていないチームで頻繁に発生します。変更を直接適用しようと先走りたくなる衝動は強いものです。しかし、時間、コスト、フラストレーションを節約できるステップがあります。それは、実行前にプランを確認することです。

プランをスキップすると何が起こるか

terraform applyを直接実行すると、Terraformは設定に基づいてリソースの作成、変更、削除を即座に開始します。何か問題があれば、変更が適用された後にしか気づきません。一部のリソースではロールバックが簡単かもしれませんが、他のリソースでは手動でのクリーンアップ、クラウドプロバイダーへのサポートチケット、またはユーザーへのダウンタイムが発生する可能性があります。

問題は設定ミスだけではありません。設定が技術的に正しい場合でも、変更には予期しない副作用が生じることがあります。ネットワーク設定の変更がサービス間の接続を断つかもしれません。ストレージサイズの縮小がデータ損失を引き起こすかもしれません。セキュリティグループの更新が誤って内部リソースをインターネットに公開するかもしれません。

Terraformが何をするのか、実行前にプレビューする方法が必要です。

Terraform Planの仕組み

terraform planコマンドは、実行計画と呼ばれるものを生成します。設定ファイルを読み込み、Terraformの状態ファイルに保存されているインフラの現在の状態と比較します。出力には、どのリソースが作成、変更、削除されるか、各変更の詳細が正確に表示されます。

重要な違いは、terraform planは実際には変更を行わないことです。読み取りと比較のみを行います。リソースの作成、更新、破棄は行われません。インフラに影響を与えることなく、何度でも実行できます。

実行すると次のようになります：

terraform plan

Terraformはプロバイダーに接続し、設定を読み取り、現在の状態を確認し、計画されたアクションの概要を出力します。先ほどのサーバーとデータベースの設定の場合、出力は次のようになります：

  • 1台の仮想サーバーが2 CPUコア、8 GB RAMで作成される
  • 1つのデータベースが100 GBストレージで作成される
  • 両方のリソースが内部ネットワークを介して接続される

すでにサーバーが稼働していてその設定を変更した場合、プランは既存のサーバーが破棄されて再作成されるのではなく、インプレースで更新されることを示します。この違いは重要です。インプレース更新は通常、置き換えよりも安全で高速だからです。

プランがワークフローにとって重要な理由

実行計画は、他の方法では得にくい3つのものを提供します。

第一に、変更が意図したものと一致することを確認できます。変更を適用する前に、詳細を確認する機会があります。誤ったインスタンスタイプを設定していませんか？データベースエンジンのバージョンは正しいですか？プランはこれらの詳細を明確に示します。

第二に、考えていなかった副作用を発見できます。複数のリソースに影響する変数を変更したかもしれません。小さな設定の微調整が、更新ではなくリソースの置き換えを引き起こすかもしれません。プランはこれらの隠れた依存関係を明らかにします。

第三に、プランを他の人と共有できます。チーム設定では、全員がTerraformの構文を理解する必要はありません。しかし、ほとんどのエンジニアはプランの出力を読み、潜在的な問題を特定できます。データベース管理者はストレージ設定が適切か確認できます。セキュリティエンジニアはネットワークルールが過度に寛容でないか確認できます。

CI/CDパイプラインでのプランの活用

チーム環境では、terraform planは通常CI/CDパイプラインで自動化されます。インフラ設定を変更するプルリクエストが開かれると、パイプラインが自動的にterraform planを実行し、結果をプルリクエストのコメントとして投稿します。

このワークフローにより、コードがマージされる前にチーム全体が何が変更されるかをレビューできます。議論はプランの出力を中心に行われ、コードが何をするかという抽象的な説明ではありません。「なぜこのリソースが置き換えられるのか？」「このセキュリティグループはインターネットに開放すべきか？」といった質問が、変更が適用される前に回答されます。

次のフローチャートは、CI/CDパイプラインで使用される典型的なプラン・レビュー・適用サイクルを示しています：

flowchart TD A[コード変更] --> B[Terraform Plan] B --> C{プランをレビュー} C -->|承認| D[Terraform Apply] C -->|不承認| E[コードを修正] E --> A D --> F[インフラ更新完了]

さらに進んで、適用ステップを進める前にプラン出力に対する承認を必須とするチームもあります。プランは本番インフラへの変更をゲートするチェックポイントとなります。

よくある間違い：古いプラン

理解すべき重要な制限が1つあります。実行計画は、コマンドを実行した時点でのTerraformの動作スナップショットです。terraform planを実行してからterraform applyを実行するまでの間に、他の誰かがインフラを変更した場合、プランは正確でなくなる可能性があります。

例えば、terraform planを実行して1台のサーバーが作成されると表示されたとします。terraform applyを実行する前に、チームメイトがクラウドコンソールから手動で同じサーバーを作成した場合、terraform applyを実行するとTerraformは競合を検出して失敗するか、設定の書き方によってはさらに悪いことに重複リソースを作成する可能性があります。

これが、優れたワークフローがプランと適用のステップを近接させて保つ理由です。CI/CDパイプラインでは、通常同じパイプライン実行が両方のステップを順次実行します。ローカル開発では、数時間や数日前ではなく、適用の直前にプランを実行する必要があります。

また、状態ロックを使用して同時変更を防ぐチームもあります。ある人やパイプラインがプランや適用を実行している間、他の人は操作が完了するまで変更がブロックされます。

Terraform Planを使用するための実践的チェックリスト

  • 小さな変更でも、すべてのterraform applyの前にterraform planを実行する
  • 予期しないリソースの置き換えや削除がないかプラン出力を確認する
  • 作成されるリソースの数が期待と一致するか確認する
  • セキュリティグループ、ネットワークルール、IAMポリシーの変更を確認する
  • プラン出力を関連するチームメンバーと共有してレビューする
  • CI/CDでは、プランをプルリクエストのコメントとして投稿する
  • プランと適用のステップを時間的に近接させて保つ
  • チーム環境では状態ロックを使用して競合を防ぐ

この習慣から得られるもの

すべての変更の前にterraform planを実行する習慣は、ワークフローを受動的から意図的に変えます。リソースが作成された後に問題を発見するのではなく、まだ画面上のテキストにすぎないうちに問題をキャッチします。プランでのミスを修正するコストはゼロです。適用後に修正するコストは、デバッグ、手動クリーンアップ、チームとの調整に何時間もかかる可能性があります。

次回Terraform設定を書くときは、まずプランを実行してください。出力を注意深く読み、それから適用するかどうかを判断してください。その1つの追加ステップが、インフラを自信を持って管理するチームと、常に後始末に追われるチームを分けます。