IaC 入门：为什么不再手点控制台

手点的代价

今年 3 月：在 AWS 控制台点了一些东西，跑起来了
今年 9 月：要在另一个 region 复制一份 → "我点过哪些来着？"
半年后：这些资源没人记得为什么需要 → 不敢删

这是几乎每个手点过的人都遇到过的故事。

IaC：用代码描述基础设施

# 一个 Terraform 例子（VPC + 子网）
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "prod-vpc" }
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  tags       = { Name = "prod-public-1" }
}

跑 terraform apply——它去调云 API 把这些资源建出来。这段代码就是基础设施的真相。

三件事变得可能

1. 可重复

复制一份完整环境（dev / staging / prod）→ 改几个变量
灾难恢复 → 在新 region 跑一遍
新员工本地 → 起一个迷你版

2. 可审计

改动走 git → PR 一条条审
"为什么有这个安全组规则？" → git blame + commit message
合规审计员问 → 给他 git log

3. 可回滚

改坏了 → git revert + terraform apply
比"昨天我点了几下你能撤回吗"靠谱得多

声明式 vs 命令式

风格	含义	例子
命令式	描述怎么做	"建一个 VM、装这些包、起这些服务"
声明式	描述最终状态	"这里要有一个 VPC、3 个子网、一个 RDS"

IaC 主流工具偏声明式——你说"应该长这样"，工具算出"差距 + 怎么补"。

主流工具速览

工具	风格	语言	备注
Terraform	声明式	HCL	业内事实标准；License 改动后社区分叉出 OpenTofu
OpenTofu	声明式	HCL	Terraform 的开源 fork（Linux Foundation）
Pulumi	声明式	Python/TS/Go	用真编程语言写 IaC
AWS CDK	声明式	Python/TS/Java	AWS 官方，编程语言生成 CloudFormation
Crossplane	声明式	K8s YAML	用 K8s 当控制平面管云资源
Ansible	命令式（也支持声明式）	YAML	配置管理强、IaC 弱
CloudFormation	声明式	JSON/YAML	AWS 原生，跨云不行

选型层面：新项目优先 Terraform / OpenTofu——社区资料最多、跨云支持最好。

IaC 三大坑

1. State 漂移

有人手点了一下，IaC state 不知道——下次 apply 可能把改动覆盖掉。对策：禁手点 + 定期 drift 检测（详见下一篇 Terraform）。

2. State 是单点

state 文件丢了，IaC 失忆。对策：远程 state（S3 / GCS / Terraform Cloud）+ 备份。

3. Secret 误入 state

密码出现在 state 里 → state 不能像普通代码 push 到 GitHub。对策：state 存私有桶；用 Vault / Secrets Manager 管 secret，IaC 只引用。