スモールスタートで内製ツールからTerraformに乗り換え、レビューできるインフラにする

これまで GCE インスタンスの管理には内製ツールを使用していましたが、CentOS 7 の EOL に伴う OS 移行を機に、ツールの見直しを行うことになりました。

この内製ツールの対応範囲はインスタンスの起動に限られ、インスタンスの設定変更や削除には別の手順が必要でした。

設定ファイルは Git で管理されておらず、マージリクエストを通じて変更内容を事前にレビューするなどのフローも整備されていませんでした。

また、内製ツール固有の操作方法や構成を把握する必要がありました。

少数のインスタンスを追加するだけであれば従来の内製ツールでも対応できましたが、時間が限られた中で多数のインスタンスの起動、設定、削除を進めるには作業負荷が高いという課題がありました。

そこで、インスタンスの構成と変更内容をコードで管理できる Terraform の導入を検討しました。

Terraform は広く利用されており、公式ドキュメントや実現したい構成に応じた事例や知見を参照しやすいことが、採用の主な決め手です。

利用を始めるメンバーが必要な情報を得やすいため、内製ツールと比べてオンボーディングコストを抑えられると考えました。

また、Google Cloud のリソースを管理するプラグインである Google Cloud Provider が、Google と HashiCorp によって共同でメンテナンスされ、継続的に更新されている点も決め手となりました。

OS 移行後は、移行対象のすべてのインスタンスを Terraform で管理しています。

これにより、内製ツールでは個別の対応が必要だった設定変更や削除も、起動とあわせて Terraform で一貫して管理できるようになりました。

また、Terraform の構成ファイルは Git で管理し、マージリクエストでレビューするフローとしたことで、実際の環境へ反映する前に別のメンバーが変更内容をチェックできるようになりました。

Terraform に関する情報は得やすい一方で、チーム内ではメンバーごとに Terraform や Infrastructure as Code（IaC）への理解度に差がありました。

Terraform の操作方法を共有し、リソースをコード化する際の設計方針についてチーム内で合意するまでには、時間がかかりました。

今回は対象を GCE インスタンスに限定して Terraform を導入しました。

管理対象を関連するリソース全体に広げる方法もありますが、対象を限定した導入でも、構成をコードで管理することによる作業負荷の軽減などの効果を得られました。

まずは特定の種類のリソースに対象を限定して導入する方法も選択肢の一つになると思います。

あわせて、どの単位で Terraform の構成を分けるか、ディレクトリ、ファイル構成の方針をチーム内で決めておくことをおすすめします。

適切にディレクトリ、ファイルを分けることで、レビュー対象を絞りやすくなり、terraform plan に想定外の差分が含まれている場合にも気付きやすくなります。

現在、Terraform で管理しているのは GCE インスタンスのみですが、今後はファイアウォールルールやセキュリティポリシーなどにも管理対象を広げることを目指しています。

現在の運用では、作業者が手動で terraform plan を実行し、GitLab のマージリクエストでコードをレビューした後、terraform apply で変更を反映しています。

今後は、マージリクエストの作成時に terraform plan を自動実行し、承認後のマージをトリガーに terraform apply を実行する仕組みを構築したいと考えています。