3. Terraform plan 命令：预期状态与实际状态的差异检测

terraform plan 是 Terraform 工作流中最核心的“差异分析”命令。它不执行任何资源变更，而是通过对比 当前实际基础设施状态 与 配置代码定义的预期状态，生成一份详细的执行计划。这份计划是检测配置漂移、评估变更影响、确保环境一致性的第一道防线。

3.1 plan 命令的工作原理

plan 命令的执行分为三个关键阶段，每个阶段都涉及状态数据的读取与比较：

1. 刷新阶段（Refresh）：Terraform 读取当前状态文件（terraform.tfstate），并向所有已管理的资源对应的 Provider 发起 API 调用，获取这些资源在云平台上的最新实际属性。此阶段确保 Terraform 掌握的是真实世界的最新快照。
2. 差异计算阶段（Diff）：将刷新后的实际状态与 .tf 配置文件中定义的预期状态进行逐字段对比。Terraform 会识别出哪些资源需要创建（+）、删除（-）、修改（~）或保持不变（-/+ 表示销毁重建）。
3. 计划输出阶段（Output）：将差异结果以人类可读的格式输出到终端，同时生成一个二进制计划文件（默认 terraform.tfplan），供后续 terraform apply 使用。

3.2 通过 plan 检测预期状态与实际状态的差异

当配置代码与实际基础设施之间出现不一致（即配置漂移）时，terraform plan 会清晰地揭示这些差异。以下是 plan 输出中常见的差异类型及其含义：

3.3 使用 plan 进行漂移检测的典型流程

在实际运维中，terraform plan 通常被集成到 CI/CD 流水线或定期巡检脚本中，用于自动化检测漂移。以下是一个标准流程：

1. 获取最新代码：从版本控制仓库拉取最新的 Terraform 配置代码。
2. 初始化工作目录：执行 terraform init 确保 Provider 和模块已加载。
3. 执行 plan 命令：运行 terraform plan -out=plan.tfplan 生成计划文件。
4. 解析计划输出：使用 terraform show -json plan.tfplan 将计划转换为 JSON 格式，便于程序化解析。
5. 判断漂移状态：检查 JSON 输出中的 resource_changes 字段。如果该数组为空，则无漂移；否则，逐项分析变更原因。
6. 告警与通知：如果检测到非预期的漂移，触发告警通知（如邮件、Slack、PagerDuty）。

3.4 实战：解析 plan 输出中的漂移信息

假设我们有一个 AWS EC2 实例的配置，代码中定义其 instance_type 为 t3.medium，但实际环境中被人手动修改为 t3.large。执行 terraform plan 后，输出将包含类似以下内容：

  # aws_instance.web_server 将更新到最新状态
  ~ resource "aws_instance" "web_server" {
        id                       = "i-0abcd1234efgh5678"
      ~ instance_type            = "t3.large" -> "t3.medium"
        tags                     = {
            "Name" = "web-server"
        }
        # (其他属性保持不变)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

在这个输出中：

• ~ 符号表示这是一个修改操作。
• instance_type 行显示 t3.large（当前实际值）将变为 t3.medium（代码预期值）。
• 这明确指示了配置漂移：实际环境中的实例类型与代码定义不一致。

3.5 plan 命令的常用选项与最佳实践

3.6 plan 命令的局限性

尽管 terraform plan 是漂移检测的强大工具，但它并非万能。了解其局限性有助于构建更完善的检测体系：

• 仅检测 Terraform 管理的资源：plan 命令只对比状态文件中记录的资源。通过控制台或 CLI 手动创建的资源（未纳入 Terraform 管理）不会被检测到。
• 依赖状态文件的准确性：如果状态文件损坏、丢失或未及时更新，plan 的结果将不可靠。
• 无法检测“外部”变更：某些云服务提供商的 API 可能不会返回所有属性，导致部分漂移无法被 plan 捕获。
• 性能开销：对于拥有大量资源的环境，plan 命令的刷新阶段可能耗时较长，不适合高频实时检测。