State 远程状态与锁

这一课你将能做到

1. 说清楚 state 里到底存了什么，以及本地 state 在团队协作中的四个致命问题
2. 用 S3 + DynamoDB 搭建带加密和锁的远程后端，并理解初始化的引导顺序
3. 使用 state 子命令（list/show/mv/rm/pull）和 -refresh-only 处理状态不一致

为什么要学

前 6 课的 state 都在你本机的 terraform.tfstate 文件里。单人学习没问题，一旦团队协作就四处漏风：两个人同时 apply，谁后写谁覆盖，state 与真实资源错乱；state 文件里有 RDS 密码等明文，散落在各人硬盘上；换台电脑、误删文件，整套资源就「失联」了——资源还在云上花钱，Terraform 却不认识它们。

远程 state 是 Terraform 从「个人工具」变成「团队生产工具」的分水岭。本站的所有环境都必须走远程后端：加密存储、访问留痕、加锁防并发。这一课也是故障处理密度最高的一课，state 乱了怎么救，面试和实战都绕不开。

先建立图像

┌─────────┐  ┌─────────┐
│ 开发者 A │  │ 开发者 B │
└────┬────┘  └────┬────┘
     │ plan/apply │
     ▼            ▼
┌──────────────────────────────┐
│ S3 桶 coderoadmap-tfstate    │  版本化 + SSE-KMS 加密
│   env:/dev/terraform.tfstate │
│   env:/prod/terraform.tfstate│
└───────────────┬──────────────┘
                │ 锁：谁在 apply，谁持有
                ▼
┌──────────────────────────────┐
│ DynamoDB 表 terraform-locks  │  LockID = 状态文件路径
└──────────────────────────────┘

state 的双重身份：记账本（配置地址 ↔ 云资源 ID 的映射）+ 缓存（上次 apply 的属性值，用来对比差异）。

跟着做

步骤 1：先引导（bootstrap）后端基础设施

「鸡生蛋」问题：装 state 的 S3 桶本身也可以用 Terraform 建，但那时还没有远程后端。解法是一个独立的 bootstrap 配置，用本地 state（只执行一次）：

新建 bootstrap/main.tf：

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" { region = "ap-northeast-1" }

resource "aws_s3_bucket" "tfstate" {
  bucket = "coderoadmap-tfstate-2026"
}

resource "aws_s3_bucket_versioning" "tfstate" {
  bucket = aws_s3_bucket.tfstate.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "tfstate" {
  bucket = aws_s3_bucket.tfstate.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "aws_dynamodb_table" "locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"
  attribute {
    name = "LockID"
    type = "S"
  }
}

执行：

cd bootstrap
terraform init && terraform apply
cd ..

四件套缺一不可：桶本身、版本化（误改可回滚）、KMS 加密（state 有机密）、DynamoDB 锁表（防并发写）。