企业官网建设流程全解析

照着官方示例只把ami换成自己的镜像 ID，terraform plan却给出-/+ must be replaced。

这篇把 Provider、Resource、依赖关系三件事拆开：读完你能读懂 plan 的每一个符号，也知道自己改的那一行会触发什么。

一、场景铺垫：一份配置要同时管两个区域

我接手的配置只部署到单一区域，现在要让它同时覆盖 us-east-1 与 us-west-2，两个区域的实例规格还不一样。第一反应是复制目录改掉 region，一跑 plan，几十台实例被标记为替换 —— 参数没写错，是没分清三件事各自管什么。

图

注意：三者里只有 Resource 直接决定「改一行是否重建机器」，Provider 只划定能力边界，依赖关系只决定执行顺序。

这三件事里，哪一个最可能让你在改一行参数之后失去整台机器？

二、踩坑现象：三次 plan 都没按预期走

三个坑发生在同一份配置上，报错与现象原样贴进下面的表里。

坑三最像网络故障：apply 卡在等待，我把它当网络问题排查了半天，直到发现卡住的正是被depends_on拉进来的 IAM 策略。坑一提醒标签也不是永远无痛，我给实例加的 Name 标签恰好挂在不可原地更新的字段上；坑二则是把约束写成= 5.7.1—— 以为写死更稳，实际是补丁永远进不来。

注意：同一份配置里，报错出现在 init、plan、apply 三个阶段，说明问题分属 Provider、Resource、依赖关系三层，不能混着修。

init 阶段的报错指向 Provider，plan 阶段的符号指向 Resource，apply 阶段的等待指向依赖关系 —— 这三层在命令输出里到底是怎么暴露的？

三、底层原理：Provider 插件、Resource 声明、依赖图

Terraform 内核不认识「云主机」「对象存储」这类概念，它只做语言解析、状态管理（state）和依赖图计算。真正与云厂商 API 打交道的是 Provider（提供者）插件，每个 Provider 负责一类服务的认证、资源类型定义与 API 调用。

terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.7.0" } } }

source指定 Provider 在 Terraform Registry 中的地址，version约束可接受的范围。~> 5.7.0表示允许 5.7.x 的补丁更新，但不接受 5.8.0 及以上。声明只描述需求，实际下载发生在terraform init阶段。

Provider 的两层声明

required_providers回答「需要什么」，provider块回答「如何连接」。后者至少要提供认证信息与区域；同一 Provider 需要多套配置时，用alias区分。

provider "aws" { region = "us-west-2" } provider "aws" { alias = "use1" region = "us-east-1" }

资源内通过provider = aws.use1显式选择实例。默认实例没有别名，resource块不写provider参数时自动使用默认配置。

Resource 的两层参数

resource块内部的参数分两层。一层是 Provider 定义的资源专用参数，例如aws_instance的ami与instance_type，其类型、是否必填、能否原地更新都由 Provider 文档规定；另一层是 Terraform 语言内置的元参数（meta-arguments），与具体 Provider 无关，对所有资源通用。

resource "aws_instance" "web" { ami = "ami-0abcdef1234567890" instance_type = "t3.micro" count = 2 depends_on = [aws_security_group.web] lifecycle { ignore_changes = [tags["LastModified"]] } }

依赖关系决定执行顺序

plan与apply会先构建一张资源依赖图，再据此决定创建、更新、销毁的顺序。依赖的建立有两条路径。

读取配置与状态 │ ▼ 构建依赖图 │ ┌─────┴─────┐ ▼ ▼ 隐式依赖 显式依赖 属性引用 depends_on │ │ └─────┬─────┘ ▼ 拓扑排序 → 创建 / 更新 / 销毁

注意：隐式依赖精确到属性，显式依赖精确到整个资源—— 这就是depends_on会带来无谓等待的原因。

原理层面三件事已经串起来了，落到配置上具体该守哪几条规矩？

四、解决方案：四条改配置的准则

改配置的目标是让 plan 的输出符合预期。以下四条按影响面从大到小排列，每条对应第二节里的一个坑。

resource "aws_instance" "web" { ami = "ami-0abcdef1234567890" instance_type = var.instance_type lifecycle { ignore_changes = [tags] } }

判断一个属性能不能进ignore_changes，看它是否只由外部系统写入。由 Terraform 自己管理的字段一旦被排除，配置与实际状态就会长期不一致，plan从此不再提示这类漂移。

多区域部署时，把区域相关的资源全部抽进模块，再用providers参数把模块内的 Provider 映射到不同别名的实例，而不是复制一份配置。

module "app_use1" { source = "./modules/app" providers = { aws = aws.use1 } }

准则落进配置之后，靠什么确认它真的生效？

五、实操验证：init → plan → apply 逐条对账

按上述准则改完配置，你用三个命令依次确认结果。执行环境为本地终端，Terraform 1.9 以上。

5.1 terraform init：先确认版本约束被识别

terraform init

Initializing provider plugins... - Finding hashicorp/aws versions matching "~> 5.7.0"... - Installing hashicorp/aws v5.7.1... - Installed hashicorp/aws v5.7.1 (signed by HashiCorp) Terraform has been successfully initialized!

你要在输出里盯两行：Finding 行确认约束被识别，Installing 行给出实际选中的版本。约束过严导致无匹配版本时，错误在 init 阶段就会暴露，不会拖到 plan 才出现。

5.2 terraform plan：先读符号，再读摘要

terraform plan

# aws_instance.web will be created + resource "aws_instance" "web" { ... } # aws_security_group.old will be destroyed - resource "aws_security_group" "old" { ... } # aws_subnet.public will be updated in-place ~ resource "aws_subnet" "public" { ... } Plan: 1 to add, 1 to change, 1 to destroy.

摘要行Plan: 1 to add, 1 to change, 1 to destroy是判断变更规模的入口。改完配置后这里一旦出现意料之外的 destroy 或替换计数，先停下来查属性，不要直接 apply。

5.3 terraform apply：执行与输出值

output "instance_id" { value = aws_instance.web.id description = "Web 实例的 ID" }

terraform apply

Apply complete! Resources: 1 added, 1 changed, 1 destroyed. Outputs: instance_id = "i-0a1b2c3d4e5f67890"

标记为sensitive = true的输出在终端只显示(sensitive value)，真实值仍完整写进状态文件。遮蔽的只是屏幕显示，状态文件的访问权限要单独控制。

注意：plan 的摘要行只告诉你规模，符号才告诉你性质，先读符号再读摘要。

三个命令都跑通之后，这三层知识怎么变成下次改配置的速度？

六、总结延伸：从改参数到会调试

Provider 决定 Terraform 能做什么，Resource 决定做什么，依赖关系决定按什么顺序做。命令输出是这三件事的行为痕迹：init 暴露版本约束，plan 暴露变更类型，apply 暴露最终结果。

我把这四行贴进了配置仓库的 README，改配置前先对照一遍，比事后翻 plan 便宜得多。

注意：真正需要背下来的只有一句 ——plan 里的符号比参数本身更早暴露风险。

下次在 plan 里撞上一个没预料到的-/+，你打算先去翻 Provider 的 schema，还是先改参数试一次？

术语速查表

参考链接

1. Terraform 语言 · Providers：https://developer.hashicorp.com/terraform/language/providers
2. Terraform 语言 · Resources：https://developer.hashicorp.com/terraform/language/resources
3. 元参数 depends_on：https://developer.hashicorp.com/terraform/language/meta-arguments/depends_on
4. 命令参考 · terraform plan：https://developer.hashicorp.com/terraform/cli/commands/plan
5. Terraform Registry：https://registry.terraform.io/