1. 课程导入与全景认知

在传统云上运维中，工程师往往通过控制台点击、手工执行 gcloud 命令或临时脚本创建资源。这种方式在单环境、少量资源时还能应付，但一旦进入“开发—测试—预发—生产”多环境并行，问题就会集中爆发：生产环境的防火墙规则被误改、测试环境的机器规格与生产不一致、某次变更无法追溯是谁在何时执行的、回滚时只能凭记忆重建资源。基础设施即代码（Infrastructure as Code，IaC）正是为解决这类问题而生：把云资源的定义写成可版本控制、可评审、可重复执行的代码，让环境的创建与变更像软件发布一样受控。

本课程围绕 Google Cloud 上的 IaC 与环境治理展开，核心工具链由四层构成。最底层是 Terraform 与 OpenTofu，它们通过 Provider 调用 Google Cloud API，用 HCL 声明资源；中间层是 Terragrunt，用于消除多环境配置的重复；再往上是 Google Cloud Config Controller 与 Config Connector，它们把 Kubernetes 的声明式模型引入 GCP 资源管理；最上层是 CI/CD 与策略治理，包括 Cloud Build、GitHub Actions、IAM、组织策略（Organization Policy）和 Terraform State 的远端管理。四层并非必须全部使用，而是根据团队规模与治理要求逐层引入。

理解这条工具链，需要先建立一个关键认知：IaC 的价值不在于“用代码创建资源”，而在于“让环境状态可被持续比对与收敛”。Terraform 执行 plan 时，会把代码中声明的期望状态与 State 中记录的实际状态做差异计算，输出将要新增、修改、销毁的资源清单。工程师评审这份 plan，确认无误后再 apply。因此，State 文件是 IaC 的“事实来源”，绝不能放在本地磁盘，而应存入 GCS 桶并开启版本控制与对象锁，避免多人同时执行导致状态损坏。

本课程贯穿一个统一案例：为一家虚构的在线零售团队搭建 “订单服务” 的多环境基础设施。该服务需要以下 GCP 资源：一个 VPC 网络与子网、一个 GKE 集群、一个 Cloud SQL PostgreSQL 实例、一个用于存放订单附件的 GCS 桶、一个 Pub/Sub 主题，以及配套的服务账号与 IAM 绑定。开发环境（dev）使用最小规格：GKE 单节点 e2-small、Cloud SQL db-f1-micro、桶开启 7 天生命周期删除；生产环境（prod）使用 e2-standard-4 三节点、Cloud SQL db-custom-2-7680 且开启高可用、桶开启版本控制与 365 天归档。两个环境共用同一套 Terraform 模块，仅通过不同的 terraform.tfvars 注入差异参数。

下面给出案例中 dev 环境的核心变量文件示例，它体现了“同一模块、不同参数”的组织方式：

# envs/dev/terraform.tfvars
project_id      = "retail-demo-dev"
region          = "asia-east1"
env             = "dev"
gke_node_count  = 1
gke_machine_type = "e2-small"
sql_tier        = "db-f1-micro"
sql_ha_enabled  = false
bucket_retention_days = 7

对应的生产环境只需替换为：project_id = "retail-demo-prod"、gke_node_count = 3、gke_machine_type = "e2-standard-4"、sql_tier = "db-custom-2-7680"、sql_ha_enabled = true、bucket_retention_days = 365。模块内部通过 var.sql_ha_enabled 控制 availability_type 取 REGIONAL 还是 ZONAL，通过 var.bucket_retention_days 控制生命周期规则。这样，环境差异被压缩到少量变量，而不是复制两份几乎相同的资源定义。

学习路径上，建议按“先单环境、再多环境、后治理”推进。第一阶段掌握 Terraform 基础语法、Provider 配置、State 远端化与 plan/apply/destroy 循环；第二阶段引入模块化与 Terragrunt，解决 dev/staging/prod 的配置复用；第三阶段接入 CI/CD，让每次合并请求自动执行 plan 并把结果贴到评审中，合并后再由流水线执行 apply；第四阶段引入组织策略与 Config Controller，对“哪些资源允许被创建、哪些区域允许被使用”做强制约束。每一阶段都以案例中的订单服务为载体，逐步增加治理强度，而不是一次性堆砌全部工具。

需要特别提醒的是，IaC 并不能自动消除所有风险。如果 State 被误删、如果 apply 在没有评审的情况下直接对生产执行、如果密钥被硬编码进 .tf 文件，问题依然会发生。因此本课程在讲解每个工具时，都会同时说明它的边界与配套约束：State 放 GCS 并开启版本控制、生产变更走审批、敏感变量用 Secret Manager 注入、用 terraform validate 与 tflint 在流水线中做静态检查。这些约束不是附加项，而是 IaC 能否真正落地的前提。

学完本章，你应当能够说清 IaC 在 Google Cloud 上的四层工具链各自解决什么问题，理解 State 作为事实来源的地位，并知道贯穿课程的订单服务案例在 dev 与 prod 之间的差异如何通过变量表达。接下来的章节将从最基础的环境准备与 Terraform 安装开始，逐步把这张全景图变成可运行、可复现的工程实践。