IaC 基础回顾：Terraform/Pulumi 核心概念、状态文件管理、模块化设计原则
基础设施即代码（IaC）是现代云运维的基石。在事件触发 Runbook 联动审批流程中，IaC 工具负责执行最终的资源变更。理解 Terraform 与 Pulumi 的核心概念、状态文件管理机制以及模块化设计原则，是构建可靠审批流水线的必要前提。
2.1 核心概念对比：Terraform vs Pulumi
两种工具均遵循“声明式配置 → 状态对比 → 执行变更”的核心工作流，但在语言支持、状态后端和资源抽象上存在差异。
| 维度 | Terraform | Pulumi |
|---|---|---|
| 配置语言 | HCL（HashiCorp Configuration Language） | 通用编程语言（TypeScript, Python, Go, C#, Java） |
| 状态后端 | 本地文件 / 远程后端（S3, GCS, Azure Storage, Terraform Cloud） | Pulumi Cloud / 自托管（S3, GCS, Azure Blob） |
| 资源抽象 | Provider + Resource + Data Source | Provider + Resource + Component Resource |
| 执行计划 | terraform plan → apply |
pulumi preview → up |
| 模块/组件 | Module（HCL 封装） | Component Resource（编程语言封装） |
| 变更审批集成 | 通过 Runbook 调用 CLI，解析 plan JSON | 通过 Runbook 调用 CLI，解析 preview JSON |
选型建议： 若团队以运维/平台工程师为主，Terraform 的 HCL 更专注基础设施语义；若团队以全栈开发者为主，Pulumi 允许复用现有编程语言生态（循环、函数、测试框架），降低学习成本。
2.2 状态文件管理：IaC 的“单点真相”
状态文件（State File）记录了当前已部署资源的元数据与依赖关系。它是 IaC 引擎判断“创建、更新、删除”的唯一依据。状态文件管理不当将直接导致资源漂移、并发冲突甚至数据丢失。
2.2.1 状态文件的核心作用
- 映射关系： 将配置中的逻辑资源 ID 映射到云平台的实际资源 ID。
- 依赖解析： 记录资源创建/销毁顺序，避免并行操作导致的依赖错误。
- 性能优化： 避免每次执行都全量调用云 API 列举资源。
- 增量变更： 仅对比状态文件与配置文件的差异，而非对比真实云资源。
2.2.2 远程状态锁定与一致性
在团队协作与 Runbook 自动化场景中，必须使用远程状态后端并启用状态锁定，防止并发执行导致状态损坏。
| 后端类型 | 锁定机制 | 适用场景 |
|---|---|---|
| AWS S3 + DynamoDB | DynamoDB 表行锁 | Terraform 团队协作 |
| GCS + 对象版本控制 | GCS 对象条件写入 | Terraform / Pulumi 自托管 |
| Azure Storage Blob + Lease | Blob 租约锁 | Terraform 团队协作 |
| Pulumi Cloud | 内置原子操作 + 版本控制 | Pulumi 原生协作 |
关键风险： 状态文件包含敏感信息（如数据库密码、连接字符串）。必须启用静态加密（如 S3 SSE-KMS）和传输加密（HTTPS）。禁止将状态文件提交到 Git 仓库。
2.3 模块化设计原则
模块化是 IaC 实现可复用、可测试、可治理的核心手段。无论是 Terraform Module 还是 Pulumi Component Resource，都应遵循以下设计原则。
2.3.1 模块化设计三原则
- 单一职责： 每个模块只负责一个逻辑组件（如 VPC、数据库、Kubernetes 集群）。
- 显式接口： 通过输入变量（Input Variables）暴露可配置参数，通过输出值（Output Values）暴露必要信息。
- 无状态封装： 模块内部不硬编码环境、区域或账号信息；环境差异由调用方通过变量注入。
2.3.2 模块层级结构
推荐采用三层模块架构，与 Runbook 审批流程中的环境隔离策略天然匹配。
2.3.3 模块版本化与发布
模块应像软件制品一样进行版本管理，确保 Runbook 审批流程中引用的模块版本可追溯、可回滚。
| 版本策略 | Terraform 实现 | Pulumi 实现 |
|---|---|---|
| 语义化版本 | Module Registry + Git Tag | npm / PyPI / Go module + Git Tag |
| 版本约束 | source = "git::https://...//module?ref=v1.2.0" |
new Module("name", args, { version: "1.2.0" }) |
| 变更记录 | CHANGELOG.md + 模块文档 | CHANGELOG.md + 组件文档 |
2.4 状态文件与模块化的协同：审批流程的输入
在事件触发 Runbook 联动场景中，审批系统需要获取变更的精确范围。模块化设计使得状态文件中的资源归属清晰，便于生成细粒度的变更清单。
实践要点：
- 所有模块必须显式声明 Output Values，便于状态文件查询模块边界。
- 在 Runbook 中，使用
terraform state list或pulumi stack export获取完整资源清单，与 plan 输出交叉验证。 - 模块版本变更应触发审批流程中的“模块版本升级”检查点，确保依赖兼容性。