4. Terraform 工作流基础：init、plan、apply、destroy 的标准流程，以及其在服务目录中的执行上下文

Terraform 的核心工作流由四个标准生命周期命令构成：init、plan、apply、destroy。在服务目录场景中，这些命令的执行上下文从本地 CLI 迁移到了自动化平台，其执行顺序、状态锁定、变量注入以及错误处理都需要重新设计。本章将拆解每个阶段的标准职责，并说明它们在服务目录中的适配差异。

4.1 标准工作流四阶段

下表总结了每个阶段的核心目标、产物以及典型耗时，帮助你在服务目录中预估执行窗口：

4.2 各阶段详细职责与避坑

4.2.1 init：环境准备与依赖锁定

terraform init 是工作流的起点。在服务目录中，每次执行前必须确保工作目录干净且依赖版本锁定。

• Provider 安装：根据 required_providers 下载对应版本，优先使用本地镜像或私有源以加速。
• Module 获取：从 Git、Terraform Registry 或 S3/GCS 拉取子模块。
• 后端初始化：配置 State 存储后端（如 S3 + DynamoDB），创建 State 锁表。
• 锁文件：生成 .terraform.lock.hcl，确保团队使用一致的 Provider 版本。

4.2.2 plan：差异分析与安全预览

terraform plan 生成一个不可变的执行计划。在服务目录中，plan 阶段是审批门禁的核心环节。

• 刷新状态：从后端读取最新 State，并与真实云资源对比。
• 计算变更：输出 +（创建）、~（更新）、-（销毁）三种操作。
• Plan 文件：使用 -out=plan.tfplan 保存二进制计划，确保 apply 阶段执行完全相同的变更。
• JSON 输出：terraform show -json plan.tfplan 用于集成到审批系统。

4.2.3 apply：变更执行与状态持久化

terraform apply 执行 plan 文件中的变更。在自动化环境中，apply 必须幂等且可回滚。

• 状态锁定：通过后端锁（如 DynamoDB）防止并发 apply。
• 逐资源执行：按依赖图顺序创建/更新/删除，支持 -parallelism=N 控制并发度。
• State 写入：每次成功变更后立即写入后端，失败时保持部分写入状态。
• 输出提取：通过 output 块暴露关键信息（如 IP、ARN），供下游系统消费。

4.2.4 destroy：资源回收与状态清理

terraform destroy 本质上是 terraform apply 的一个特殊计划，它销毁所有由配置管理的资源。在服务目录中，destroy 通常对应服务实例的删除操作。

• 保护机制：使用 prevent_destroy 或 lifecycle 块保护关键资源（如数据库）。
• 依赖顺序：按依赖图反向顺序销毁，先删除子资源再删除父资源。
• State 清理：销毁完成后，State 文件变为空，但后端仍保留文件用于审计。

4.3 服务目录中的执行上下文差异

在服务目录中，Terraform 工作流不再是开发者的本地操作，而是由平台引擎驱动的自动化流水线。下表对比了标准工作流与服务目录执行上下文的关键差异：

4.4 服务目录工作流执行流程（SVG）

下图展示了服务目录中一次完整的 Terraform 工作流执行流程，从用户提交请求到资源交付完成：

4.5 服务目录执行上下文架构（SVG）

下图展示了服务目录引擎如何组织 Terraform 的执行上下文，包括工作空间隔离、状态后端以及变量注入层：

4.6 服务目录中的工作流最佳实践

1. 始终使用远程状态后端：避免本地 State 文件丢失或冲突，推荐 S3 + DynamoDB 或 Terraform Cloud。
2. Plan 与 Apply 分离：在服务目录中强制两阶段执行，plan 输出供人工审批，apply 使用 plan 文件保证一致性。
3. 变量注入标准化：所有用户输入通过 terraform.tfvars.json 注入，避免使用 -var 命令行参数导致的安全风险。
4. 超时与重试：为每个阶段设置超时（如 init 60s、plan 120s、apply 300s），并实现指数退避重试。
5. 并发控制：使用状态锁 + 队列机制，确保同一工作空间不会同时执行两个 apply。
6. 审计日志：记录每个阶段的开始时间、结束时间、执行用户、变更摘要，便于事后追溯。