【ITニュース解説】Part 2: From Docker Compose up to Terraform on AWS, and the CI That Checks It

システム開発において、私たちが作ったアプリケーションを自分のパソコンで動かすことは比較的簡単だが、それを実際のユーザーが利用する「本番環境」で安全かつ確実に動かすことは、想像以上に難しい課題だ。特に、医療データのような機密性の高い情報を扱うシステムでは、単に「動く」だけでは不十分で、「正しく、安全に動いている」ことを証明できなければならない。このニュース記事は、ローカル環境でDocker Composeを使って動かしていたシステムを、AWS上にTerraformというツールを使って構築し、その信頼性を確保するためにCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを導入する過程で遭遇した具体的な問題とその解決策について深く掘り下げている。

ローカル環境での開発は、Docker Composeのようなツールを使えば迅速にシステムを立ち上げられるが、これには大きな落とし穴がある。Docker Composeはシステムが「動く」ことを示してくれるが、それがセキュリティの観点から安全であるか、過去の変更履歴に機密情報が残っていないか、テストが十分に実施されているかといった、より深い側面については何も教えてくれない。例えば、データベースがインターネットからアクセス可能になっていないか、アプリケーションの認証情報がGitの履歴に残っていないか、デプロイしたものがテストされたものと全く同じであるかといった保証はされない。このようなギャップは、NHS（英国国民保健サービス）のような、患者の個人情報を扱う厳格な環境では決して許されない。そのため、「自分のパソコンでは動いた」というだけでは全く通用しないのだ。

この課題を解決するために採用されたのが、Infrastructure as Code（IaC）とCI/CDパイプラインという二つの強力な手法である。IaCとは、サーバーやネットワークといったインフラの構築設定をコードとして記述し、それを自動的に適用する技術で、ここではTerraformが使われた。Terraformを使うことで、AWS上に仮想ネットワーク（VPC）、コンテナ実行環境（EKS）、データベース（RDS）、ファイルストレージ（S3）といった様々なリソースを、人間の手作業ではなくコードで一貫して管理できるようになる。しかし、インフラをコード化しただけでは不十分で、そのコードが正しく、安全であることを常に確認するためのCI/CDパイプラインが必要となる。CI/CDパイプラインは、コードの変更があるたびに自動で様々なチェックを実行し、問題があれば開発者に知らせる自動化された仕組みだ。

実際にCI/CDパイプラインを構築し、稼働させてみると、予想外の多くの問題が発覚した。まず、Gitleaksという秘密情報スキャンツールが正しく機能していなかったことが判明した。設定ファイルに誤りがあり、本来検出されるべき約100種類の秘密情報検出ルールが無効になっていたのだ。これにより、過去のコミット履歴に、デモ環境用のAPIキーが半年間も公開されたままになっていたことが発覚した。さらに、Pythonのテスト実行でコードカバレッジを計測するpytest-covというライブラリが、開発環境の依存関係リストに含まれていなかったため、コードカバレッジの計測自体が機能していなかった。これにより、テストは実行されていたものの、テストがコードのどの範囲をカバーしているか全く分からなかった。

セキュリティ面では、Terraformで定義されたAWSインフラ設定にも重大な問題が見つかった。TrivyというIaCスキャンツールが、データベースのセキュリティグループのアウトバウンド通信がインターネット全体に開かれていることを指摘したのだ。これは、データベースが外部の不正なサーバーと通信できてしまう危険性を示唆していた。また、EKSクラスタのAPIエンドポイントも、本来内部からのみアクセス可能であるべきところが、誤ってインターネット全体に公開されていた。これらの設定は、開発者が意図せずデフォルトのルールを適用してしまったり、誤った解釈をしてしまったりした結果生じたものだ。さらに、FastAPIというWebフレームワークが依存しているStarletteというライブラリに、既知の脆弱性が存在することも発覚した。これらの問題は、コードレビューだけでは見過ごされがちだが、パイプラインによる自動チェックによって初めて明らかになった。

このパイプラインでは、コードの品質、セキュリティ、インフラの整合性を多角的にチェックする。具体的には、コードのスタイルを自動で整形するlintやruff、Pythonコードのテストとカバレッジ測定、Gitの履歴まで含めた秘密情報スキャン、コードの静的解析（Semgrep）、Terraformコードの文法や整合性チェック、Terraformで定義されたインフラ設定のセキュリティスキャン、そしてDockerイメージのビルドと脆弱性スキャン、使用されているソフトウェアの部品表（SBOM）生成など、7つの重要なジョブがプルリクエストごとに実行される。これらのチェックを自動化することで、人間の見落としを減らし、品質とセキュリティの基準を確実に維持できる。また、各ツールやライブラリのバージョンを厳密に固定することで、予期せぬ挙動の変化を防ぎ、安定したチェックを保証している。

ニュース記事では、CI/CDパイプラインを効果的に活用するためのいくつかのベストプラクティスが提示されている。例えば、TerraformのロックファイルをGitリポジリに含めることで、CI環境でもローカルと同じ環境でTerraformが実行されることを保証する。また、ローカル環境で実行するコマンドとCI環境で実行するコマンドを同一にすることで、「ローカルでは動いたのにCIでは動かない」という問題をなくす。秘密情報スキャンでは、現在のコードだけでなくGitの履歴全体をスキャンすることの重要性が強調されている。一度コミットされた秘密情報は、その後のコミットで削除されても履歴に残ってしまうため、注意が必要だ。そして何よりも、自動チェックツールは問題を発見したら明確にエラーを出すように設定し、エラーログを注意深く読み、なぜエラーが発生したのかを理解することが重要だと述べている。

AIの活用についても触れられている。AIは、GitLab CIの設定をGitHub Actionsに変換するような定型的で機械的な作業においては非常に有用だ。しかし、今回のケースで発見された多くの問題、例えばGitleaksの設定ミスやEKSの公開設定などは、AIがコードを見ただけでは気づかない種類の問題だった。これらの問題は、実際にパイプラインを動かし、その出力を確認することで初めて明らかになった。AIはドラフト（下書き）を作るのに優れているが、システムの最終的な仕様、テスト、そして実際に動作するシステムこそが真実を語る。さらに、チェック結果が正しいかどうかも人間が検証しなければならない。

今回の経験から得られた最も重要な教訓は、CI/CDパイプラインはコードやインフラを構築するよりも「先に」構築すべきだったという反省点だ。パイプラインは、開発プロセスの初期段階から品質基準を設け、それを強制するガードレールとしての役割を果たす。そして、本番ブランチへのマージには、必ずパイプラインのすべてのチェックがパスしていることを必須条件とすべきだった。ドキュメントに記載された理想と、実際のシステムの状態が一致していなかった例も挙げられ、ドキュメントの記述が現実と乖離しないよう、常に実際のシステムの状態を反映させる重要性を示している。このニュース記事は、ローカル環境で動いていたものが、信頼とセキュリティが求められる本番環境で「正しく動いている」と胸を張って言えるようになるまでの、現実的な道のりと、その過程でいかに自動化されたチェックが不可欠であるかを私たちに教えてくれる。それは、システム開発における「動く」と「正しく動く」の間の大きな距離を埋めるための、貴重なガイドラインとなるだろう。