IaC 工具选型是什么
基础设施即代码工具把云资源与主机配置写成可版本化、可评审的文件，按用途分为两类：声明式工具描述目标状态，由工具计算差异并收敛（Terraform、CloudFormation、Pulumi 等）；命令式工具按步骤执行（脚本、配置管理模块），灵活但幂等与顺序要自己保证。选型时除了语法风格，还要看状态管理、漂移检测、多云覆盖、密钥处理与团队既有技能。
基本信息
| 声明式 | 描述终态，工具负责 diff 与收敛，重复执行结果一致 |
|---|---|
| 命令式 | 描述执行步骤，需自行保证幂等与失败重入 |
| 状态存储 | 声明式工具通常需要状态文件：放远端存储并加锁 |
| 执行流程 | plan/diff 先评审，再 apply，变更进代码评审与流水线 |
| 巡检 | 定期执行 plan 检测控制台手工改动造成的漂移 |
典型使用场景
- 云资源纳管：网络、负载均衡、数据库实例等按代码创建与变更
- 环境一致性：开发、测试、生产用同一套模块，参数差异走变量文件
- 主机与中间件配置：配置管理工具保证软件包、配置文件与服务的收敛状态
- 灾备重建：区域故障后用同一份代码重建环境，而不是照文档手工操作
- 变更审计：每次基础设施变更都对应一次提交记录，可回溯到人和时间
- 合规基线：把安全组、加密开关等要求固化成模块默认值
声明式工具典型流程
声明式工具典型流程
terraform init -backend-config=backend.hcl # 初始化并指定远端状态后端
terraform plan -out=tfplan # 生成变更计划，先评审再执行
terraform apply tfplan # 按计划落地，避免执行时才发现差异
terraform state list # 核对已被纳管的资源清单
# 状态文件放远端存储并开启加锁，禁止提交到代码库
# 手工改动后用 plan 检查漂移，再决定是回写代码还是回退变更选型评估维度
| 维度 | 要确认什么 | 风险信号 |
|---|---|---|
| 表达方式 | 声明式收敛还是脚本步骤 | 用脚本伪装成声明式，重复执行结果不一致 |
| 状态管理 | 状态存哪里、能否加锁、是否可迁移 | 状态文件留在本地或多人共写 |
| 漂移检测 | 能否定期对比真实环境与代码 | 只编码不巡检，手工改动长期累积 |
| 多云与私有化 | 目标云与内网环境是否都覆盖 | 供应商专有能力被深度绑定，迁移成本高 |
| 密钥与权限 | 凭证如何注入、最小权限如何落地 | 密钥写进代码或变量明文提交 |
模块化是 IaC 长期可维护的前提：把网络、数据库、应用栈拆成可复用模块，用变量区分环境；模块版本要显式固定，避免上游改动直接冲击生产。
IaC 仓库本身也需要流水线：合并前跑格式检查与 plan，合并后再执行 apply，人工申请只在受控窗口内放开。