【ITニュース解説】Terraform as a One-Shot Init Container in Docker Compose and CI: Ending "It Worked On My Machine"

システム開発では、「自分の環境では問題なく動作するのに、他の環境、例えばテストサーバーや本番環境、あるいは同僚の開発環境では動かない」という事態が頻繁に発生する。これは「環境ドリフト」と呼ばれ、アプリケーションが正しく動作するために必要なインフラ（データベースのインデックスやAPIキーなど）が、特定の環境で手動で設定されたために生じる問題である。例えば、ローカル環境でブログアプリケーションを開発している際に、Elasticsearchという検索エンジンに必要なblog_postsというインデックスを手動で作成したとしよう。アプリケーションコードは、このインデックスが存在することを前提として動作する。しかし、この設定作業はコードとして管理されていないため、継続的インテグレーション（CI）環境のような、常にクリーンな状態から始まる環境では、このインデックスが存在せず、アプリケーションがエラーを起こしてしまうのだ。

このような状況は、開発者が一度だけ実行したcurlコマンドや、手動でのデータベース設定が原因で発生することが多い。アプリケーションコードと、それに依存するインフラのセットアップ手順が別々の世界に存在するため、時間が経つにつれて両者が乖離し、「自分の環境では動いたのに」という問題を引き起こす。新しいチームメンバーがプロジェクトに参加した際も、この手動設定の知識が共有されていないと、開発環境の構築に大きな手間と時間がかかり、生産性を低下させる原因となる。

この問題を解決する鍵は、「Infrastructure as Code（IaC、コードとしてのインフラ）」という考え方にある。これは、インフラのセットアップ自体もソフトウェアコードと同様に扱い、バージョン管理し、自動化するというものだ。この記事で提案されている具体的なアプローチは、TerraformというIaCツールをDocker Composeの「ワンショット初期化コンテナ」として利用することである。

このアプローチでは、アプリケーションが必要とするインフラ（例えば、Elasticsearchの特定のインデックスとそのデータ構造、あるいはアクセス権限を持つAPIキーなど）をTerraformのコードとして定義する。そして、このTerraformコンテナをアプリケーションコンテナと同じDocker Composeスタック内で起動させる。compose.yamlファイルには、terraformというサービスが定義され、hashicorp/terraformイメージを使用する。restart: noという設定により、このコンテナは一度だけ実行されて完了したら終了する。

実行の順序が非常に重要である。depends_onという設定とヘルスチェック機能を利用することで、Terraformコンテナは、MinIO（Terraformの状態を保存するためのS3互換ストレージ）やElasticsearchといった、その前提となるサービスが完全に起動し、健全な状態になった後にのみ実行されるようにする。Terraformコンテナが起動すると、terraform initで初期化を行い、terraform applyコマンドを実行して、定義されたインフラを自動的にプロビジョニングする。つまり、Elasticsearchにblog_postsやblog_posts_logといったインデックスを正しいデータ型（マッピング）で作成し、必要な権限を持つAPIキーを生成するのだ。このインフラの準備が完了して初めて、アプリケーションコンテナやテストが開始される。

Terraformコードの中では、各インデックスの具体的な名前や、titleをテキスト型、authorをキーワード型とするような詳細なデータマッピング、APIキーに付与する操作権限（作成、読み取りなど）が明示的に定義されている。これにより、インフラのどんな設定も曖昧さを排してコードで管理され、手動での設定漏れや間違いの余地がなくなる。インデックスのマッピングに変更が必要な場合も、Terraformファイルを更新して再デプロイするだけで、全ての環境に一貫した変更を適用できる。

このアプローチの大きな利点は、ローカル開発環境とCI環境とで、全く同じワークフローが実行される点にある。開発者はローカルでdocker compose up -dを実行し、Terraformコンテナの終了を待ってからテストを実行する。CI環境でも、全く同じ手順でDockerスタックを起動し、Terraformコンテナの完了を待ってからテストを実行するのだ。これにより、「ローカルでは動くのにCIでは動かない」という原因不明のトラブルが劇的に減少し、CIでの失敗もローカルで容易に再現・デバッグできるようになる。

さらに、この方法はテストの信頼性も高める。モック（模擬オブジェクト）を使ってElasticsearchの動作をシミュレートする代わりに、Terraformによって実際にプロビジョニングされた本物のElasticsearchインスタンスに対してテストを実行できる。これにより、インデックスの欠落、マッピングの誤り、APIキーの権限不足、データ型不一致など、モックでは検出できない統合レベルの問題を早期に発見できる。テストがパスすれば、アプリケーションが実際のインフラと正しく連携して動作しているという、より高い確信が得られ、本番環境での動作に対する不安が軽減される。

この手法は、開発から本番環境へのデプロイプロセスにも一貫性をもたらす。ローカル環境では開発用のElasticsearchエンドポイントを指すlocal.tfvarsファイルを使用し、本番環境では実際のクラウド上のElasticsearchエンドポイントを指すprod.tfvarsファイルを使用する。Terraformコード自体は共通であり、設定ファイルを変えるだけで異なる環境に対応できる。これにより、本番環境へのデプロイ時にも、ローカルやCIでテストされたのと同じインフラ設定が適用されるため、予期せぬトラブルを大幅に減らすことができる。

最終的にこのパターンは、金曜の午後のデバッグセッションを減らすだけでなく、開発ワークフロー全体の信頼性を向上させる。docker compose upコマンド一つで、本番環境とほぼ同じインフラを再現できるため、問題は早期に発見され、修正コストが低く抑えられる。新しいチームメンバーも、手動での複雑なセットアップ作業なしに、すぐに開発に着手できる。インフラのセットアップが「部族知識」として口頭で伝達されるのではなく、コードとして明文化されることで、チーム全体の生産性と連携が向上する。

現代のシステム開発において、多数のサービスに依存するマイクロサービスアーキテクチャでは、一つの設定ミスが大きな障害につながる可能性がある。このような状況で、確定的（常に同じ結果を保証する）なインフラセットアップは、もはや「あったら良いもの」ではなく、不可欠な要素である。今度「自分の環境では動いたのに」という言葉を耳にした際には、コードによってすべての環境で一貫したインフラを構築する方法が、その解決策となるだろう。