Infrastructure as Code（IaC）とは何ですか。

IaC は、コードを通じてプロビジョニング プロセスを自動化することで機能し、クラウド コンソールでの手動設定の必要性を排除します。デベロッパーは最初に、必要なインフラストラクチャの仕様を構成ファイルで定義します。このファイルは、通常はバージョン管理システムに保存されます。その後、Terraform などの自動化ツールがこれらのファイルを処理し、クラウド プロバイダに対して必要な API 呼び出しを行い、実際のリソースを作成、更新、削除します。このワークフローは通常、コード（定義）からバージョン管理、CI / CD パイプライン、そして最終的にプロビジョニングへと続くパスをたどります。

IaC を実装する際は、宣言型と命令型の 2 つのアプローチから選択することが一般的です。主な違いは、最終結果に焦点を当てるか、結果に至るまでのステップに焦点を当てるかです。

インフラストラクチャ定義がコード リポジトリに移行するにつれて、セキュリティ対策もこれらのファイルを保護するように適応する必要があります。「IaC セキュリティ」と「IaC スキャン」は、インフラストラクチャがデプロイされる前に構成ファイルの脆弱性を分析する手法を指します。これは「シフトレフト」セキュリティと呼ばれるコンセプトです。専用のツールがコード パイプラインをスキャンし、一般公開されているストレージ バケットや暗号化されていないデータベースといった構成ミスを検出し、セキュリティ リスクが本番環境に到達するのを防ぎます。

Google Cloud は、初期設計からデプロイ、継続的な管理まで、Infrastructure as Code の取り組みをサポートする包括的なツールセットを提供します。App Design Center は、事前に構築されたリファレンス アーキテクチャを探索、カスタマイズ、構築できる優れた出発点です。これにより、コードを 1 行も記述する前に Google Cloud のベスト プラクティスに基づいてアプリケーション スタックを設計できるため、最初からインフラストラクチャが適切に設計されます。

設計が完了したら、Google Cloud のオープン エコシステムにより、コードとして簡単に実装できます。このプラットフォームでは、Terraform などのオープンソース標準が後付けではなく、主要機能として扱われます。Infrastructure Manager などのサービスを使用すると、Terraform を直接使用して Google Cloud リソースをデプロイ、管理できます。一方、Config Connector を使用すると、Kubernetes を通じて Google Cloud リソースを管理できるため、クラウド インフラストラクチャとコンテナ オーケストレーションのギャップを埋めることができます。

Cloud Resource Manager は、組織、フォルダ、プロジェクトなどの Google Cloud リソース階層をプログラムで管理するサービスとして機能します。多くのチームが IaC を使用して仮想マシンなどのリソースをデプロイしていますが、Cloud Resource Manager ではプロジェクト構造自体をコードとして定義できます。これにより、チームは新しい環境のセットアップを自動化し、一貫した Identity and Access Management（IAM）ポリシーと組織の制約を適用して、最初からインフラストラクチャにガバナンスを組み込むことができます。

IaC の有用な活用方法の一つは、「自分のマシンでは動作したのに、本番環境ではなぜ動作しないのか？」というデベロッパーによくある問題を解決することです。これは、一時的な環境を作成することで解決できます。

このワークフローでは、デベロッパーが pull リクエスト（PR）を開くと、IaC ツールによってアプリの一時的な分離されたコピーが自動的にスピンアップされます。PR がマージされると、環境は自動的に破棄されます。

これを機能させるには、Terraform コードに名前をハードコードすることはできません。変数を使用して、PR ごとに一意のリソースを作成する必要があります。

main.tf（スニペット）

cloudbuild.yaml で、Cloud Build が提供する _PR_NUMBER 置換変数を使用して、PR 番号を Terraform に挿入します。

cloudbuild.yaml（スニペット）

このワークフローにより、IaC は静的なメンテナンス タスクから、レビュー サイクルを加速する動的な生産性向上ツールへと変わります。