3. Terraform on Google Cloud快速上手

本节把 Terraform 与 Google Cloud 串成一条可执行的最小链路：安装 Terraform、配置 Google Provider 认证、用 HCL 描述一个自定义 VPC 网络与一台 GCE 实例，然后走完 init → plan → apply → destroy 全流程。目标不是背命令，而是理解每个阶段在做什么、输入是什么、输出如何判断。

一、安装 Terraform 与目录准备

Terraform 是单二进制工具，安装即把可执行文件放进 PATH。以 Linux x86_64 为例，示例版本为 1.7.5（版本号可按需替换）：

# 下载并解压（示例版本 1.7.5）
curl -O https://releases.hashicorp.com/terraform/1.7.5/terraform_1.7.5_linux_amd64.zip
unzip terraform_1.7.5_linux_amd64.zip
sudo mv terraform /usr/local/bin/

# 验证
terraform -version
# Terraform v1.7.5

随后建立工作目录，约定三个文件：main.tf 放资源，variables.tf 放变量，terraform.tfvars 放具体取值。这种拆分让同一份配置可以在 dev/prod 之间复用，只替换变量文件。

二、Google Provider 认证的三种方式

Provider 是 Terraform 与云 API 之间的适配层。Google Provider 认证的本质是让 Terraform 拿到一个具备相应 IAM 权限的凭据。常见三种方式：

• 本地开发：使用 gcloud auth application-default login 生成应用默认凭据（ADC），Terraform 自动读取，无需在代码里写密钥。
• CI/CD：使用服务账号 JSON 密钥，通过环境变量 GOOGLE_APPLICATION_CREDENTIALS 指向密钥文件。
• 推荐做法：Workload Identity Federation，用外部身份换取短期令牌，避免长期密钥泄露风险。

无论哪种方式，都需要在 Provider 块中声明项目与区域：

provider "google" {
  project = var.project_id
  region  = var.region
}

权限上，创建 VPC 与 GCE 至少需要 compute.networks.create、compute.instances.create、compute.firewalls.create 等权限，实践中常直接授予 roles/compute.admin 用于实验环境。

三、编写第一个 VPC 与 GCE 实例

下面是一份可直接运行的最小配置。自定义模式 VPC 不自动创建子网，需要显式声明，这样网络拓扑完全可控。

# variables.tf
variable "project_id" { type = string }
variable "region"     { type = string, default = "asia-east1" }
variable "zone"       { type = string, default = "asia-east1-a" }

# main.tf
resource "google_compute_network" "vpc" {
  name                    = "demo-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = "demo-subnet"
  ip_cidr_range = "10.10.0.0/24"
  region        = var.region
  network       = google_compute_network.vpc.id
}

resource "google_compute_firewall" "allow_ssh" {
  name    = "allow-ssh"
  network = google_compute_network.vpc.name
  allow { protocol = "tcp", ports = ["22"] }
  source_ranges = ["0.0.0.0/0"]
}

resource "google_compute_instance" "vm" {
  name         = "demo-vm"
  machine_type = "e2-micro"
  zone         = var.zone

  boot_disk {
    initialize_params { image = "debian-cloud/debian-12" }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.subnet.id
  }
}

注意 google_compute_network.vpc.id 这种引用：Terraform 会自动推导依赖顺序，先建网络，再建子网，最后建实例。这是声明式配置与脚本式命令最本质的区别。

四、init / plan / apply / destroy 全流程

init 是第一步，它读取 Provider 声明，下载对应插件到 .terraform/ 目录，并生成 .terraform.lock.hcl 锁定版本。执行后看到 “Terraform has been successfully initialized!” 即成功。

terraform init

plan 是只读的预演。它把配置中的期望状态与 state 中的实际状态对比，输出将要执行的动作。首次执行会看到 4 个资源全部为 + create：

terraform plan -var-file="terraform.tfvars"

Plan: 4 to add, 0 to change, 0 to destroy.

这里要重点看三件事：资源数量是否符合预期、CIDR 与机型是否正确、有没有意外的 - destroy。plan 不产生任何费用，是安全网。

apply 才真正调用 GCP API。它会再次展示计划并要求输入 yes 确认，随后按依赖顺序创建资源，并把结果写入 terraform.tfstate。完成后输出 Apply complete! Resources: 4 added.。此时可在控制台看到 demo-vpc、demo-subnet、allow-ssh 与 demo-vm。

terraform apply -var-file="terraform.tfvars"
# 输入 yes 确认

destroy 按依赖逆序删除：先删实例，再删防火墙与子网，最后删网络。执行前同样会列出待删除清单，确认后资源全部释放，避免持续计费。

terraform destroy -var-file="terraform.tfvars"

五、结果判断与常见问题

判断一次 apply 是否真正成功，不能只看命令退出码，还要核对三处：plan 中的资源数量与 apply 输出是否一致；GCP 控制台或 gcloud compute instances list 能否查到实例；terraform state list 是否列出全部 4 个资源。三者一致才算闭环。