IaC核心理念与工具选型
1. 为什么需要 IaC
手动建基础设施的问题:
- 没记录:谁在什么时候建了什么,没人知道
- 不可复制:换一个 region 重建一遍要 1 周
- 漂移:手动改了控制台,文档没更新,事故定位难
- 难审查:一次点错就是生产事故
IaC(Infrastructure as Code)= 把基础设施定义当代码:
- git 版本管理
- PR review
- 自动化创建 / 销毁
- 多环境一致
2. 工具对比
| 工具 | 语言 | 模型 | 适合 |
|---|---|---|---|
| Terraform | HCL(DSL) | 声明式、state | 多云通用,事实标准 |
| Pulumi | TS / Python / Go | 声明式、state | 前端/全栈友好 |
| AWS CDK | TS / Python / Java | 编译为 CloudFormation | AWS 生态深度 |
| CloudFormation | YAML / JSON | 声明式 | AWS 原生 |
| 阿里 ROS | YAML / JSON | 声明式 | 阿里云原生 |
| Ansible | YAML | 命令式(推送) | 服务器配置管理 |
| Chef / Puppet | DSL | 命令式(拉取) | 老牌服务器配置 |
| Kubernetes Manifest | YAML | 声明式 | K8s 资源 |
| Helm | YAML 模板 | 模板 + 声明 | K8s 应用包 |
3. Terraform vs Pulumi
| 维度 | Terraform | Pulumi |
|---|---|---|
| 语言 | HCL | TS/Python/Go/Java/.NET |
| 学习曲线 | 中(新 DSL) | 低(已会 TS) |
| 生态 | 庞大(10 年+) | 成长中 |
| state 后端 | 远程 + 锁丰富 | 类似 |
| 程序逻辑 | 有限(function/loop) | 完整编程语言 |
| 类型 | 弱 | 强(TS) |
| 团队 | 标准选择 | 前端团队偏好 |
前端团队推荐 Pulumi:用 TS 写基础设施,类型提示 + 编辑器支持。 多云 + 大规模团队推荐 Terraform:生态最大,招聘容易。
4. 常见组合
Terraform / Pulumi → 创建云资源(VPC、ECS、K8s 集群)
↓
Helm / Kustomize → K8s 应用配置
↓
ArgoCD / Flux → GitOps 自动同步
服务器配置(如果不用容器):Ansible playbook。
5. 应用场景分层
| 层 | 工具 |
|---|---|
| 物理 / 网络 / 云资源 | Terraform / Pulumi |
| 操作系统配置 | Ansible / 容器化 |
| K8s 集群创建 | Terraform(云托管 K8s) |
| K8s 应用部署 | Helm + ArgoCD |
| 应用代码 + Docker | CI/CD(模块 06) |
6. 关键概念
6.1 声明式 vs 命令式
# 声明式(Terraform):描述期望状态
resource "aws_instance" "web" {
count = 3
instance_type = "t3.medium"
}
# 命令式(Ansible):描述执行步骤
- name: ensure 3 instances
loop: [1, 2, 3]
ec2: { instance_type: t3.medium }
声明式工具自动算 diff(创建/更新/删除),更现代。
6.2 State
Terraform / Pulumi 用 state 文件记录"哪些资源是我管的"。下次 apply 时对比期望 vs state 决定动作。
state 必须远程存储 + 加锁(多人协作)。
6.3 漂移(Drift)
state 里写有 ECS 1 台,但有人手动控制台开了 2 台。下次 plan 会显示要删 1 台。
terraform plan
# 显示 drift
terraform refresh # 把现实拉回 state
# 或调整代码 + apply
7. 生产实践
7.1 模块化
infra/
├── modules/
│ ├── vpc/
│ ├── k8s-cluster/
│ ├── rds/
│ └── monitoring/
├── environments/
│ ├── dev/
│ ├── staging/
│ └── prod/
└── README.md
每环境引用相同 module,参数不同。
7.2 PR 工作流
1. 改 .tf 代码 → 开 PR
2. CI 跑 terraform plan → 显示变更
3. Reviewer 看 plan 输出
4. 合并 → CI 跑 terraform apply
7.3 多环境 / 多账号
prod 账号 → prod terraform state
staging 账号 → staging state
dev 账号 → dev state
绝不共用 state。
7.4 secret 管理
不进 git。环境变量 / Vault / KMS。
export TF_VAR_db_password="..."
terraform apply
8. 上手路径
Step 1: 用 Terraform / Pulumi 起一个 VPC + 一台 ECS
Step 2: 加 RDS / Redis / 域名
Step 3: 拆 module
Step 4: CI/CD 自动 plan + 手动 apply
Step 5: K8s 集群(EKS / ACK)+ Helm
Step 6: GitOps(ArgoCD)
9. 常见反模式
- 手动改控制台:state 漂移,下次 apply 删除你的修改
- state 本地存:团队协作崩
- state 不加锁:并发 apply 损坏
- state 含密钥不加密:泄露
- 大 main.tf:拆 module
- 不分环境:dev 改影响 prod
- 不做 plan 直接 apply:等于赌
- secret 写代码:泄露
- 完全靠工具忽视审计:apply 没人 review
10. 延伸阅读
- Terraform vs Pulumi 对比
- 《Terraform 实战》
- 《Infrastructure as Code》Kief Morris
- HashiCorp Learn
- 模块 12 各工具实战篇