記事公開日
【Terraform × Google Cloud 入門】インストールからデプロイまでを試してみた
この記事のポイント
Terraformをインストールし、Google Cloud上にCloud Storageバケットを作成・削除するまでの一連の流れを検証しました。IaC（Infrastructure as Code）の第一歩として、環境構築からデプロイ・クリーンアップまでを実際に手を動かして確認しています。
- Terraformのインストール：
WSL2 Ubuntu上で、公式手順に沿ってapt経由でTerraformを導入する手順を紹介します。 - Google Cloudへのデプロイ：
Cloud Storageバケットを例に、terraform init→plan→applyの基本ワークフローを確認します。 - 変数ファイルの管理：
variables.tfとterraform.tfvarsの役割の違いと、Git管理の考え方を整理します。
はじめに
DXソリューション営業本部の三浦です。
AWSでIaCを使うときはCloudFormationが多く、Terraformを使うことはありませんでした。社内のGemini Enterprise導入に伴いGoogle Cloudを使う機会が増え、IaC化できたほうがよいと考え、Terraformをインストールして、Google Cloud上にCloud Storageを作成するところまでをやってみました。
前提条件
- WSL2 Ubuntu（Windows 11）
- VS Code
- Google Cloud プロジェクトあり
- gcloud CLI インストール済み
Terraformをインストール
公式手順に沿ってインストールを進めていきます。
1. パッケージのインストール
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
2. HashiCorpのGPGキーをインストール
HashiCorpの公開鍵をインストールし、パッケージが改ざんされていないかを確認するために必要です。
wget -O- https://apt.releases.hashicorp.com/gpg | \ gpg --dearmor | \ sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
3. キーを検証する
gpg --no-default-keyring --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg --fingerprint
検証が完了しました。
gpg: directory '/home/<user>/.gnupg' created
gpg: /home/<user>/.gnupg/trustdb.gpg: trustdb created
/usr/share/keyrings/hashicorp-archive-keyring.gpg
-------------------------------------------------
pub rsa4096 2023-01-10 [SC] [expires: 2028-01-09]
798A EC65 4E5C 1542 8C8E 42EE AA16 FCBC A621 E701
uid [ unknown] HashiCorp Security (HashiCorp Package Signing) <security+packaging@hashicorp.com>
sub rsa4096 2023-01-10 [S] [expires: 2028-01-09]
4. aptリポジトリを追加する
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
5. パッケージ一覧の再取得
sudo apt update
6. Terraformを最新のリポジトリからダウンロード
sudo apt-get install terraform
7. インストールを検証
terraform -version
インストールを確認できました。
Terraform v1.15.7 on linux_amd64
.tfファイルを作成する
Terraformを使ってリソースを作成できることが確認できればよいので、シンプルにCloud Storageバケットを作成します。
terraform {
required_version = ">= 1.9"
required_providers {
google = {
source = "hashicorp/google"
version = "~> 7.38"
}
}
}
provider "google" {
project = var.project_id
region = var.region
}
resource "google_storage_bucket" "sample" {
name = "${var.project_id}-tf-sample"
location = var.region
force_destroy = true
uniform_bucket_level_access = true
}
プロジェクトIDやリージョン等は、以下のファイルを作成して管理します。
- variables.tf：
「このTerraform構成には、どんな変数が必要か」という設計図・受け皿を定義します。型チェックや説明文もここに書きます。プロジェクトのコードの一部としてGit管理します（値そのものは含まないので、コミットして問題ありません）。 - terraform.tfvars：
その受け皿に「実際どんな値を入れるか」を書くファイルです。環境ごとに変わる・機密性がある可能性があるので、通常はGit管理しません（このプロジェクトでも.gitignore済み）。
ファイルをデプロイする
1. ディレクトリの初期化
terraform init
プロバイダ（hashicorp/google）がダウンロードされ、.terraform/ ディレクトリと .terraform.lock.hcl が作られます。
Initializing provider plugins found in the configuration... - Finding hashicorp/google versions matching "~> 7.38"... - Installing hashicorp/google v7.39.0... - Installed hashicorp/google v7.39.0 (signed by HashiCorp) Initializing the backend... Terraform has created a lock file .terraform.lock.hcl to record the provider selections it made above. Include this file in your version control repository so that Terraform can guarantee to make the same selections by default when you run "terraform init" in the future. Terraform has been successfully initialized!
2. フォーマットとバリデーション
terraform fmt でインデント等をTerraform標準の書式に自動整形し、terraform validate で構文・設定内容にエラーがないかをチェックします（GCPへは接続しません）。
terraform fmt terraform validate
Success! The configuration is valid.
3. 実行計画の確認と適用
terraform plan で何が作られるかを事前確認します（まだ何も作りません）。続けて terraform apply を実行し、"Do you want to perform these actions?" で yes と入力します。
terraform plan terraform apply
applyコマンドが成功しました。
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
4. 結果確認
CLI上で確認します。
terraform show
Cloud Storageのステータスの一覧が表示されています。
terraform show
# google_storage_bucket.sample:
resource "google_storage_bucket" "sample" {
default_event_based_hold = false
deletion_policy = "DELETE"
effective_labels = {
"goog-terraform-provisioned" = "true"
}
enable_object_retention = false
force_destroy = true
id = "<YOUR_PROJECT_ID>-tf-sample"
location = "ASIA-NORTHEAST1"
name = "<YOUR_PROJECT_ID>-tf-sample"
project = "<YOUR_PROJECT_ID>"
project_number = <PROJECT_NUMBER>
public_access_prevention = "inherited"
requester_pays = false
self_link = "https://www.googleapis.com/storage/v1/b/<YOUR_PROJECT_ID>-tf-sample"
storage_class = "STANDARD"
terraform_labels = {
"goog-terraform-provisioned" = "true"
}
time_created = "2026-07-01T08:45:08.124Z"
uniform_bucket_level_access = true
updated = "2026-07-01T08:45:08.124Z"
url = "gs://<YOUR_PROJECT_ID>-tf-sample"
hierarchical_namespace {
enabled = false
}
soft_delete_policy {
effective_time = "2026-07-01T08:45:08.124Z"
retention_duration_seconds = 604800
}
}
コンソール上でもリソースが作成されていることが確認できました。
クリーンアップ
今回はTerraformを使用してGoogle Cloudのリソースの作成が可能であることを確認するのが目的なので、余計なコストがかからないように作成したリソースは消しておきます。
terraform destroy を実行し、"Do you want to perform these actions?" で yes と入力します。
terraform destroy
削除されていることを確認します。
Destroy complete! Resources: 1 destroyed.
コンソール上からも消えていました。
まとめ
今回はTerraformをインストールして、Google Cloud上にCloud Storageをデプロイするところまでをやってみました。
宣言型の言語で、リソースの状態をコードで管理できるのは便利だと感じました。
ベストプラクティスや構文を勉強しながら、現状のリソースでIaC化できる部分は少しずつコード化していきたいと思います。
QESではGemini Enterpriseの導入コンサルティング、エージェント設計、Google Workspace連携、運用支援まで一貫してサポートしています。Gemini Enterpriseの支援内容については下記のサービスページをご覧いただくか、お問い合わせフォームよりお気軽にご相談ください。
※このブログで参照されている、Google、Gemini、Gemini Enterprise は、米国およびその他の国における Google の商標または登録商標です。
※このブログで参照されている、Terraform、HashiCorp は、HashiCorp, Inc. の米国およびその他の国における商標または登録商標です。
※Amazon Web Services、および CloudFormation は、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。
