3. Terraform 工作流：init、plan、apply、destroy 命令详解及最佳实践
Terraform 的核心工作流由四个基本命令构成：init、plan、apply 和 destroy。理解每个命令的职责、执行顺序以及最佳实践，是构建可靠基础设施即代码（IaC）管道的基石。本章将深入剖析每个命令的内部机制，并结合质量门禁场景给出实战建议。
3.1 工作流全景：从初始化到销毁
下图展示了 Terraform 标准工作流的完整生命周期，以及每个阶段对应的核心命令与产出物。
核心原则：在 CI/CD 管道中，
plan 和 apply 必须分离。永远不要在 apply 时重新计算 plan，而是使用预先保存的 plan 文件，确保实际变更与审批内容完全一致。
3.2 命令详解与参数对比
| 命令 | 核心功能 | 关键参数 | 常见错误 |
|---|---|---|---|
| init | 初始化工作目录，下载 Provider 插件，配置后端存储 | -backend-config、-upgrade、-reconfigure |
后端配置变更后未执行 -reconfigure |
| plan | 对比当前状态与配置文件，生成执行计划 | -out、-var-file、-target |
未使用 -out 保存 plan 文件 |
| apply | 执行 plan 中的变更操作，更新真实世界资源 | -auto-approve、-input=false |
直接运行 apply 不带 plan 文件 |
| destroy | 销毁所有由当前配置管理的资源 | -auto-approve、-target |
未使用 -target 进行局部销毁 |
3.3 各命令最佳实践
3.3.1 terraform init — 初始化环境
init 是工作流的起点，负责建立 Terraform 运行所需的所有依赖。在质量门禁场景中，init 通常作为管道的第一步，确保环境一致性。
# 标准初始化
terraform init
# 使用后端配置文件（推荐用于多环境）
terraform init -backend-config=environments/prod/backend.hcl
# 升级 Provider 版本（谨慎使用，需配合版本锁定）
terraform init -upgrade
最佳实践清单：
- 始终将
.terraform.lock.hcl文件纳入版本控制，锁定 Provider 版本。 - 在 CI/CD 中，每次执行
init前清理.terraform目录，避免缓存污染。 - 使用
-backend-config参数动态注入后端配置，避免硬编码敏感信息。 - 多环境部署时，为每个环境创建独立的
backend.hcl文件。
3.3.2 terraform plan — 生成执行计划
plan 是质量门禁的核心环节。它不产生任何实际变更，仅输出一份“变更清单”。在门禁管道中，plan 的输出将被解析并用于合规检查。
# 生成 plan 并保存到文件（推荐做法）
terraform plan -out=tfplan.binary
# 使用变量文件
terraform plan -var-file=environments/prod.tfvars -out=tfplan.binary
# 仅查看计划，不保存（仅用于调试）
terraform plan
⚠️ 关键门禁规则：在 CI/CD 中，
plan 步骤必须输出 JSON 格式用于自动化解析：terraform show -json tfplan.binary。门禁系统通过解析 JSON 判断是否有资源变更、变更类型（增/删/改）以及是否涉及敏感资源。
3.3.3 terraform apply — 应用变更
apply 执行预先保存的 plan 文件。这是生产环境变更的“执行门”，必须确保 plan 文件来自经过审批的管道阶段。
# 使用 plan 文件执行（生产环境强制要求）
terraform apply tfplan.binary
# 直接 apply（仅限开发/沙箱环境）
terraform apply -auto-approve -var-file=environments/dev.tfvars
安全执行规则：
- 生产环境 禁止 直接运行
terraform apply不带 plan 文件。 - plan 文件应带有时间戳和构建 ID，确保可追溯：
tfplan-${BUILD_ID}.binary。 - apply 成功后，立即将 state 文件备份到安全存储（如 S3 版本控制桶）。
3.3.4 terraform destroy — 销毁资源
destroy 是高风险操作，在质量门禁体系中需要额外的审批层级。建议使用 -target 进行局部销毁，避免误删整个环境。
# 销毁特定资源（推荐）
terraform destroy -target=aws_instance.web_server -auto-approve
# 销毁整个环境（需人工审批）
terraform destroy -var-file=environments/staging.tfvars
🛑 门禁增强策略：
- 在管道中为
destroy设置独立的审批门，需要至少两名高级工程师确认。 - 使用
prevent_destroy = true保护关键资源（如数据库、存储桶）。 - 执行
destroy前，强制运行一次plan并生成销毁清单供审批。
3.4 工作流状态转换与门禁集成
下图展示了在质量门禁管道中，Terraform 工作流如何与门禁检查点集成，形成“计划→审批→执行→验证”的闭环。
3.5 常见陷阱与规避策略
| 陷阱场景 | 问题描述 | 规避策略 |
|---|---|---|
| State 文件锁定冲突 | 多人同时执行 apply 导致 state 损坏 |
使用支持锁定的后端（S3+DynamoDB、Terraform Cloud） |
| Plan 文件过期 | plan 生成后 state 被其他管道修改，导致 apply 失败 | 在 apply 前重新执行 plan 并重新审批 |
| Provider 版本漂移 | 不同环境使用不同 Provider 版本导致行为不一致 | 锁定 .terraform.lock.hcl，CI 中强制 -upgrade=false |
| 敏感信息泄露 | plan 输出或 state 文件中包含明文密码 | 使用 sensitive = true 标记变量，后端启用加密 |
自动化脚本示例：在 CI/CD 管道中，使用以下模式确保工作流完整性：
terraform init -backend-config=backend.hcl && terraform plan -out=tfplan.binary && terraform show -json tfplan.binary | check-gate && terraform apply tfplan.binary