谷歌云经销商：利用 Terraform 工具 10 分钟在 GCP 上批量自动化构建标准网络架构

cloud 2026-05-30 阅读 12
1

   在公有云的运维圈子里，有一句被奉为圭臬的至理名言：“如果你在控制台里重复点同一个按钮超过三次，你就应该把它代码化。”

很多刚接触 Google Cloud (GCP) 的朋友，在面对一个全新的商业项目时，往往会轻车熟路地登录控制台，开始人肉点鼠标：建一个自定义 VPC、划分三个不同地域的 Subnet（子网）、配一堆网络标记防火墙，最后再去配一个内部的 NAT 网关让虚拟机能安全上网。

这一套流程走下来，至少折腾半个小时。更痛苦的是，当公司要在测试环境、预发环境、生产环境甚至海外新地域完美复刻一套一模一样的网络时，你只能捏着一把汗，一边看文档一边祈祷自己不要看错某一个 IP 掩码。只要手一抖点错一个地方，随之而来的就是漫长的查错和排鱼大坑。

在现代化大厂的 DevOps 生态里，有一个彻底终结这种原始作坊式运维的终极杀招，叫做 Terraform。

它的核心逻辑用四个字概括就是：基础设施即代码（IaC，Infrastructure as Code）。你不需要去点任何鼠标，只需要在一个文本文件里把你的网络蓝图写下来，Terraform 就会在 10 分钟内，像打印机一样在全球范围内的 GCP 上为你精准、批量地“打印”出一套丝毫不差的标准网络架构。

今天我们拒绝任何概念说教，拒绝废话。直接以大厂跨国架构的生产规范为标准，手把手带你用 Terraform 在 10 分钟内平地起高楼。

第一阶段：深度拆解，IaC 的“上帝视角世界模型”

在动手写第一行代码之前，你必须在脑子里建立起 Terraform 底层的物理世界模型，否则你绝对会被后面各种 .tf 文件给绕晕。

Terraform 和 GCP 之间的互动，本质上是一个“声明 -> 执行”的闭环过程：

  1. 图纸层（Configuration Files, .tf）：你用 HCL 语言（一种易读的声明式配置语言）写下的网络架构图纸。你只需要声明“我想要一个名为 prod-vpc 的网络”，不需要管谷歌底层是怎么通过 API 调度的。
  2. 连接器（Provider）：Terraform 官方提供的 GCP 翻译官。它负责把你写的图纸，翻译成谷歌云后台看得懂的 RESTful API 指令。
  3. 真实世界反馈（State File, terraform.tfstate）：这是 Terraform 的“记忆账本”。它会把云端当前有哪些真实资源、IP 是多少，雷打不动地记录在一个 JSON 文件里。它是 Terraform 能做到“增量修改、绝不重叠”的底层核心。

第二阶段：实战前夜——开辟本地弹药库

请确保你本地电脑上已经下载并安装了 Terraform CLI，并且已经配置好了 gcloud 命令行工具。

在本地电脑新建一个空目录，名字叫 gcp-network-automation。在这个目录里，我们要建立三个符合大厂架构规范的核心文件。大厂规范严禁把所有东西塞进一个文件里，我们必须将其模块化解耦：

  • providers.tf：用来跟谷歌云对齐暗号，声明我们要用哪里的资源。
  • variables.tf：变量控制台，所有的地域、项目 ID、IP 网段都在这里统一改，实现一套代码到处复用。
  • main.tf：核心网络蓝图。

第三阶段：实战演练——手把手代码化批量构建网络

接下来，双手离开鼠标，准备在你的 IDE（如 VS Code）里开启这场 10 分钟的网络速通战役。

1. 编写连接器 providers.tf

这个文件负责把 Terraform 牢牢焊死在你的 GCP 项目上。

terraform {

 required_version = ">= 1.5.0"

 required_providers {

   google = {

     source  = "hashicorp/google"

     version = "~> 5.0" # 锁定大版本，防止未来官方升级导致语法不兼容

   }

 }

}


provider "google" {

 project = var.project_id

 region  = var.main_region

}

2. 编写变量台 variables.tf

把所有可能变动的参数抽离出来，以后发新地域只需要在这个文件里改一行，不需要动核心蓝图

variable "project_id" {

 type        = string

 description = "你的 GCP 项目 ID"

 default     = "my-automation-project-2026" # 换成你自己的真实项目 ID

}


variable "main_region" {

 type        = string

 description = "主业务部署地域"

 default     = "asia-east1" # 台湾地域，国内访问延迟低

}


variable "backup_region" {

 type        = string

 description = "灾备容灾地域"

 default     = "asia-northeast1" # 东京地域，做跨国双活高可用

}

3. 编写核心网络蓝图 main.tf

这是最硬核的部分。我们要在这里一口气批量构建：1个自定义VPC、2个跨国子网、1个完全隔离的内网安全防火墙、以及一套让内网机器能够无密下载补丁的 Cloud NAT 网关。

Terraform


# 1. 批量构建大后方：自定义 VPC 网络
resource "google_compute_network" "custom_vpc" {
  name                    = "prod-standard-vpc"
  auto_create_subnetworks = false # 大厂级安全规范：坚决关闭自动原子网，必须全手动划分控制 IP 域
  routing_mode            = "GLOBAL" # 开启全球路由，让跨国子网能内网互通
}

# 2. 划分阵地一：台湾主业务子网（前端与应用）
resource "google_compute_subnetwork" "subnet_asia_east" {
  name          = "subnet-asia-east-prod"
  ip_cidr_range = "10.0.1.0/24" # 划分 254 个可用内网 IP
  region        = var.main_region
  network       = google_compute_network.custom_vpc.id
  private_ip_google_access = true # 注入灵魂：允许内网机器不挂公网 IP 也能安全连通谷歌官方 API
}

# 3. 划分阵地二：东京异地容灾子网（核心数据库与备份）
resource "google_compute_subnetwork" "subnet_asia_northeast" {
  name          = "subnet-asia-tokyo-backup"
  ip_cidr_range = "10.0.2.0/24"
  region        = var.backup_region
  network       = google_compute_network.custom_vpc.id
  private_ip_google_access = true
}

# 4. 焊死安全大闸：建立内网安全防火墙
resource "google_compute_firewall" "allow_internal" {
  name    = "allow-internal-mesh-traffic"
  network = google_compute_network.custom_vpc.name

  allow {
    protocol = "tcp"
  }
  allow {
    protocol = "udp"
  }
  allow {
    protocol = "icmp"
  }

  source_ranges = ["10.0.0.0/16"] # 只放行我们自己大网段内部的互相敲门，彻底阻断公网一切探测
  description   = "仅允许VPC内网成员之间骨干网互通"
}

# 5. 出海管道建设：配置 Cloud Router 路由器
resource "google_compute_router" "nat_router" {
  name    = "prod-nat-router"
  region  = var.main_region
  network = google_compute_network.custom_vpc.id
}

# 6. 配置完全托管的 Cloud NAT 网关
resource "google_compute_router_nat" "nat_gateway" {
  name                               = "prod-cloud-nat"
  router                             = google_compute_router.nat_router.name
  region                             = var.main_region
  nat_ip_allocate_option             = "AUTO_ONLY" # 谷歌全自动分配高防外部静态 IP
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

第四阶段：见证奇迹的时刻——云端“啪嗒”一键流水线触发

代码写完了。接下来，我们进入终端，执行 Terraform 的“通关三部曲”。

步骤 1：部队集结（初始化）

在终端项目根目录下敲入：

Bash


terraform init

此时，Terraform 会自动去官方镜像站把专门对接 GCP 的 Provider 插件下载到本地，让本地电脑拥有操控谷歌云的能力。

步骤 2：沙盘推演（预览计划）

这是IaC最无敌的步骤。在真正去云端动土之前，先来一次绝对安全的军事演习：

Bash


terraform plan

盯着终端输出的报表，它会用满屏的绿色加号（+）清清楚楚地告诉你：“如果按下确认，我将在后台为你新建 6 个全新的网络制品，0 个修改，0 个销毁。”

步骤 3：重火力全开（一键轰鸣上云）

确认图纸完美无误后，下达最终死命令：

Bash


terraform apply -auto-approve

屏幕上的进度条开始疯狂滚动。Terraform 在后台用极其密集的并发频率，同时向谷歌全球骨干网的 API 发起调用。

通常只需要 15 到 30 秒，终端最后会亮出一行金子般的提示：Apply complete! Resources: 6 added, 0 changed, 0 destroyed.。

此时你登录 GCP 控制台看一眼网络大盘，一个完美的、带有跨国多活子网、自带 NAT 网关和隔离防火墙的工业级网络大后方，已经在公网上巍然屹立。全流程不浪费一滴唾沫，不到 1 分钟全部落盘。

第五阶段：企业级大规模IaC开发的避坑血泪史

这套自动化方案用起来爽快无比。但在真正的企业级高并发、多团队协作的生产环境里，作为首席架构师，你必须立刻给团队焊死以下两条底线规范：

1. 严禁本地留存 terraform.tfstate（多人协作的灭顶之灾）

默认情况下，Terraform 运行完后会在本地生成一个 terraform.tfstate 文件。

  • 灾难发生：如果团队里的张三和李四在各自的电脑上各自跑 terraform apply，因为两个人的本地账本不同步，Terraform 会判定对方写的东西是“非法入侵”，从而在全球后台疯狂地互相把对方刚建好的服务器和网络一键抹除清空。
  • 大厂标准解法：必须配置“远端状态锁（Remote Backend）”。在 providers.tf 里加上几行代码，强行把状态账本锁在谷歌自家的 GCS 存储桶（Google Cloud Storage） 里：
  • Terraform
terraform {
  backend "gcs" {
    bucket  = "my-company-tfstate-bucket" # 把账本锁在云端安全的抽屉里
    prefix  = "terraform/state/network"
  }
}

配置之后，只要张三在运行代码，云端存储桶会自动加锁（Lock），李四在同一时刻就绝对点不动执行，彻底杜绝了多团队代码冲突导致的惨烈事故。

2. 掌握“物理超度”的终极自毁艺术

在项目结束、或者开发测试环境到了周五下班需要临时彻底关停回笼资金时，千万不要去控制台一个个去删。

  • 硬核止损建议：直接在终端敲入：
  • Bashterraform destroy -auto-approve 仅仅需要 30 秒，Terraform 会像倒带一样，把图纸上的 6 个网络制品干干净净地从谷歌机房里物理超度、全量抹去，绝不留任何一个死角，彻底杜绝因为漏关某一个网关导致的月底闲置天价账单。

总结

利用 Terraform 工具批量自动化构建 GCP 网络架构，核心的工业级精髓就在于十六个字：图纸声明，变量解耦，云端加锁，一键自毁。

你彻底摆脱了过去看运气点控制台、提心吊胆人肉对掩码的原始原始运维状态。把所有的基础设施变成可以进行版本控制（Git commit）的干净代码。让网络架构像软件一样可以无限复制、一键回滚，这才是现代云原生架构师出海远航时最地道、最优雅的控盘姿势。


1
← 返回新闻中心