こんにちは、SCSK石黒です。
最近案件でTerraformを触る機会がありIaCについて勉強中なのですが、
Google Cloudが提供するIaCサービス、Infrastructure Managerを触ったことが無かったので、
今回はInfrastructure Managerを使って自動構築をしてみようと思います。
Infrastructure Managerとは
サービス概要
Infrastructure Manager（Infra Manager）はTerraform を使用した、リソースのデプロイと管理を自動化できるサービスです。
2023/9にリリースされた比較的新しいサービスとなります。
Terraform Cloudについての概要は以下をご確認ください。
Terraform Cloudとの違い
Terraform Cloudは、Cloudshellやローカル環境にTerraformをインストールする等の環境構築を行ってから実行する必要がありますが、Infrastructure Managerを使えばそのような環境構築をせずともTerraformを実行できます。
コードを実行するためのtfファイルをGCSに置いてInfrastructure Managerを実行するだけでスピーディーに自動構築ができます。
また、実行がGoogle Cloud上で完結するため、環境制約がTerraform Cloudと比較して少ないことも挙げられます。
料金
Cloud Build の実行と Cloud Storage のストレージに対して課金がされる仕組みとなります。
詳しい料金体系は公式ページをご確認ください。
実際に使ってみた
今回はBigQueryテーブルを自動構築してみたいと思います。
CLIから構築するやり方と、コンソール画面から構築するやり方の2パターンがありますので、
それぞれ記載します。
※基本的な流れは以下公式ドキュメントのクイックスタートを参考にしています。
APIの有効化
CLI
Cloudshellで該当のプロジェクトにログイン後、以下を実行します。
gcloud services enable config.googleapis.com
コンソール
コンソール上から「Infrastructure Manager API」を検索し、開きます。
APIを有効にします。有効後以下の画面になればOKです。
サービスアカウント作成
CLI
Infrastructure Managerを使用する際にサービスアカウントの指定が必要です。
今回は「inframg_test」というサービスアカウントを作成して使用します。
サービスアカウントの名前は適宜変換してください。
gcloud iam service-accounts create inframg_test
コンソール
IAMの画面の「サービスアカウント」から「サービスアカウントを作成」をクリックします。
サービスアカウント名を入力して完了をクリックします。
権限付与
CLI
サービスアカウントにInfrastructure Managerを使用する際に必要な権限を付与します。
サービスアカウント名と「PROJECT_ID」の個所は適宜変更してください。
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:inframg_test@PROJECT_ID.iam.gserviceaccount.com" --role=roles/config.agent
また、自動構築するリソースを作成するのに必要な権限も付与します。
今回はBigQueryテーブルを作成するので、「roles/bigquery.admin」を付与して実行したいと思います。
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:inframg_test@PROJECT_ID.iam.gserviceaccount.com" --role=roles/bigquery.admin
コンソール
IAMの「アクセスを許可」から「roles/config.agent」を付与します。
同様に「roles/bigquery.admin」を付与します。
tfファイル作成
CLI/コンソール共通
ローカル上で以下3つのtfファイルを作成します。
・main.tf
作成するリソースの内容を記載します。
今回は既存のデータセット「infratest」に「infratest_table」というテーブルを作成します。
※データセットは事前に作成しておきます。
idとnameという2カラムをスキーマに加えたいと思います。
「deletion_protection」はTerraformで削除されないようにする削除保護の項目です。後で削除の検証もしたいので、今回は明示的にfalseを指定しています。
resource "google_bigquery_table" "bqtable" {
project = var.project_id
dataset_id = "infratest"
table_id = "infratest_table"
schema = jsonencode([{
name = "id"
type = "STRING"
maxLength = "10"
}, {
name = "name"
type = "STRING"
}])
deletion_protection = false
}
・provider.tf
provider "google" {
project = var.project_id
}
・variables.tf
project_idを宣言していませんが、Infrastracture Managerは実行時に変数を指定できるため、今回は割愛しています。
variable "project_id" {
type = string
}
GCSバケット作成/tfファイル配置
CLI
tfファイル配置用のバケットと、ログ保管用のバケットの2つを作成します。
バケット名はそれぞれ「infra_test_tf」と「infra_test_logs」とします。
gcloud storage buckets create gs://infra_test_tf --location=asia-northeast1
gcloud storage buckets create gs://infra_test_logs --location=asia-northeast1
ローカルで作成した3つのtfファイルを「infra_test_tf」に配置します。
gsutil cp ./local-file-path gs://infra_test_tf/
コンソール
GCSの画面から「作成」をクリックします。
バケット名、ロケーションを指定して作成します。
「infra_test_tf」に3つのtfファイルをアップロードします。
事前準備はこれで終わりです。
Infrastructure Manager実行
CLI
以下を実行します。
PROJECT_IDは適宜該当するものを入れてください。
gcloud infra-manager deployments apply projects/PROJECT_ID/locations/asia-northeast1/deployments/test \ --service-account projects/PROJECT_ID/serviceAccounts/inframg_test@PROJECT_ID.iam.gserviceaccount.com \ --gcs-source=gs://infra_test_tf \ --input-values=project_id=PROJECT_ID \ --artifacts-gcs-bucket=gs://infra_test_logs
実行が完了すると、以下のような表示がでます。
BigQueryを確認すると、テーブルが作成できてました。
コンソール
Infrastructure Manager画面から「Create new deployment」をクリックします。
以下を入力し、「続行」をクリックします。
・Deployment ID：test （任意の値で問題ないです）
・リージョン：asia-northeast1
・Service Account：inframg_test （作成したサービスアカウント）
・Source of Terraform configuration：GCS
・Source：gs://infra_test_tf （作成したバケット）
Input Valuesは変数を定義できます。
今回はproject_idというキーに実際のプロジェクトIDを割り当てます。
「Value 1」にプロジェクトIDを入力し、「続行」をクリックします。
Artifacts GCS bucketにgs://infra_test_logs （作成したログ用のバケット）を入力し、
Create Deploymentをクリックします。
少し待つと完了しました！
テーブルも無事作成されていました。
ログについて
ログ格納に指定した「gs://infra_test_logs」を見てみます。
以下の階層でリビジョンごとに各ログが格納されています。
├ archived-deployments/ #削除されたInfrastructure Manager IDのLogが入る
└ID/ #Infrastructure Manager ID
└ r-0/ #リビジョン
│ ├ apply_results/
│ │ ├artifacts/ #作成したリソースの情報が入っている
│ │ └content/ #作成に使用したtfファイルなどの情報が入っている
│ └ logs/ #裏で動いているCloud Buildのログが入っている
├ r-1/ #リビジョン
:
:
infra_test_logs/test/r-0/apply_results/artifacts/resources.jsonを見てみると、作成したリソースの種類が記載されていました。
infra_test_logs/test/r-0/apply_results/contentには構築に使用したtfファイルなどがコピーされています。
いつどのtfファイルを使用してどのような更新をしたか、という情報がリビジョンごとにわかりやすく集約されており、ログの一元管理ができるため使い勝手は良いように感じました。
リソースを修正/削除したい場合
修正する場合
CLI/コンソール共通
リソースの値などを修正したい場合は、tfファイルを修正→再度Infrastructure Manager実行することで反映されます。
削除する場合
CLI
以下を実行します。
少し待つとリソースが削除されます。
gcloud infra-manager deployments delete projects/PROJECT_ID/locations/asia-northeast1/deployments/quickstart-deployment
コンソール
対象のInfrastracture Manager IDをクリックし、「削除」ボタンをクリックします。
少し待つと削除が完了し、リソースも削除されます。
使ってみた所感
Terraform Cloudと比較して、事前の環境構築が不要で実行が簡単でした。
ローカル環境からTerraformを実行できないなどのセキュリティ的な制約がある場合や、小規模な開発をスピーディーに行いたい場合などは有用であると思いました。
また、一切CLIを使わずにコンソール上だけでデプロイができるので、これからTerraformを勉強したい！という方がTerraformを理解する入口としてはおすすめのサービスだと思います。
ただし、Terraform Cloudであればterraform planで見ることのできるリソースの変更箇所を、Infrastructure Managerを使うとデプロイ前に確認できない点は注意が必要です。
Google Cloudが提供する代表的なIaCサービスであったGoogle Cloud Deployment Manager（CDM）の2025/12/31でのサポート終了（2025/5/1現在の情報）もあり、今後より注目度は高まっていくのではないでしょうか。
みなさんもぜひ、Infrastracture Manager使ってみてください。