4. Terraform状态管理深入

Terraform 之所以能对基础设施做增量变更，核心在于它维护了一份状态文件（state）。这份文件记录了 Terraform 上一次执行后所认知的真实世界：每个资源对应的云上对象 ID、属性值、依赖关系以及元数据。当再次执行 terraform plan 时，Terraform 会把配置（期望状态）、状态文件（已知状态）和真实 API（实际状态）三者做对比，从而算出需要新增、修改或删除的资源。理解状态文件放在哪里、如何被锁定、如何被保护，是团队协作中绕不开的一步。

本地状态：默认但脆弱

默认情况下，执行 terraform apply 后会在当前目录生成 terraform.tfstate，这就是本地状态。它简单、无需额外配置，适合个人实验。但一旦进入团队场景，问题立刻暴露：状态文件只存在于某台机器上，其他人无法共享；多人同时执行 apply 会各自基于旧状态计算，导致资源重复创建或相互覆盖；本地磁盘损坏或误删会让 Terraform 彻底“失忆”，只能靠 terraform import 逐个重建映射。

本地状态还有一个隐患：它通常包含明文敏感信息。例如创建 Cloud SQL 时生成的数据库密码、服务账号密钥、连接串等，都会以明文形式写入 state。因此本地状态文件绝不能提交到 Git 仓库。

远程状态：GCS 后端

远程状态把 state 存放到共享的远端存储中，所有协作者读写同一份状态。Google Cloud 上最常用的后端是 Google Cloud Storage（GCS）。配置方式是在 Terraform 配置块中声明 backend：

terraform {
  backend "gcs" {
    bucket = "my-tf-state-prod"
    prefix = "env/prod/network"
  }
}

其中 bucket 是存放状态的 GCS 存储桶，prefix 是桶内的对象路径前缀。执行 terraform init 时，Terraform 会提示是否把本地状态迁移到 GCS，确认后本地 terraform.tfstate 会被上传，之后所有操作都直接读写远端对象。GCS 后端天然带来几个好处：状态集中存放、天然支持对象版本控制、可通过 IAM 精细控制访问权限。

状态锁定：避免并发写坏

多人同时 apply 是状态损坏的头号原因。GCS 后端支持状态锁定：当一次操作开始时，Terraform 会在同一桶内创建一个锁对象（默认名为 default.tflock），其他进程检测到锁存在就会等待或报错，从而保证同一时刻只有一个操作在修改状态。若某次操作异常中断导致锁残留，可以用 terraform force-unlock <LOCK_ID> 手动释放，但必须先确认没有其他 apply 正在运行。

版本控制与敏感数据保护

在 GCS 桶上启用对象版本控制（Object Versioning）后，每次状态写入都会生成新版本，误操作或状态损坏时可以回滚到历史版本。配合生命周期规则，可以只保留最近若干版本以控制成本。敏感数据方面，GCS 默认使用 Google 管理的加密密钥，也可以指定 CMEK 使用 Cloud KMS 自管密钥；同时通过 IAM 只授予必要的服务账号 storage.objectAdmin 权限，避免状态被随意读取。

迁移与验证

从本地迁移到 GCS 后端的典型流程是：先创建存储桶并启用版本控制，再在配置中写入 backend 块，执行 terraform init -migrate-state，Terraform 会把本地状态上传到指定 prefix。验证是否成功，可以执行 terraform state list 查看资源列表，或到 GCS 控制台确认对象已存在。若团队多人协作，建议为每个环境（dev/staging/prod）使用不同的 prefix，避免状态互相干扰。