📌 项目地址：hashicorp/terraform |
⭐ 49,105 颗星 | 🔧 Go | 📜 未标注
项目本质：一个 CLI
和一个图引擎
Terraform 不是什么“云平台”，它是一个 Go
写的命令行工具，外加一个资源依赖图引擎。你写配置文件（HCL）描述想要的最终状态，Terraform
计算差值，生成执行计划，然后调用对应 Provider 的 API
去达成那个状态。这个仓库（hashicorp/terraform）只包含核心部分——CLI
和引擎。所有 Provider（比如
AWS、Azure、Kubernetes）都在独立的仓库里，通过
terraform init 自动下载。
README
里明确说了四个关键特性：基础设施即代码、执行计划、资源图、变更自动化。这四个点不是空话，每一个都有具体的实现逻辑。
执行计划不是“预览”，是“承诺”
我一开始接触 Terraform 时，觉得 terraform plan
就是个干巴巴的预览。后来用多了才发现，它的价值在于：无论你在配置里改了什么东西，plan
都会告诉你具体哪个资源会增、删、改，以及依赖顺序。比如你改了安全组规则，它不会先删了实例再改安全组，而是根据图依赖调整顺序。这种确定性在多人协作时特别重要——你的同事不会因为手滑导致资源被重建。
资源图：Terraform 的效率来源
资源图是 Terraform
之所以快的原因。它把所有资源节点和它们的依赖关系做成一个有向图，然后并行操作那些没有依赖的节点。比如你创建
10 个互相独立的子网，Terraform
会同时创建它们，而不是一个一个来。这个图也暴露了依赖关系，让运维人员能直观地看到“我改了
VPC，哪些子网和实例会受影响”。
变更自动化：人少犯错
Terraform 的 apply
可以无人工干预地执行。对比手动在云控制台点鼠标，或者写一堆 shell
脚本去调 API，Terraform 的声明式配置把要做的操作都表述清楚，plan
确认后执行，几乎不会漏掉改依赖关系导致的连锁反应。当然，前提是你把状态文件管好了。
与其他“基础设施即代码”工具的核心差异
- 声明式 VS 过程式：Ansible 描述“先做 A，再做
B”，Terraform 描述“最终状态是 A 和 B”，剩下的工具自己算。 - 资源图 VS 线性执行：CloudFormation 也有依赖图，但
Terraform 的图更通用，不绑定任何云厂商。 - Provider 生态：Terraform 有超过 1000 个
Provider，从 AWS 到 Helm 到 DNSSimple，甚至有些自定义的 in-house
系统也能写 Provider。这是它比
Pulumi（虽然也支持多种语言）生态成熟的地方。 - 计划作为核心步骤：CloudFormation 的 change set
是可选，Terraform 的 plan 是必须的（你可以在 apply
时跳过，但没人会这么干）。
你需要警惕的几个点
许可证：BUSL 不是开源
2023 年 8 月起，Terraform 从 MPL 2.0 改成了 Business Source License
(BUSL)。代码仍然公开可见，但你不能直接用它的代码去提供商业竞争性的
Terraform
服务。这意味着如果你是个云厂商，想白嫖它做自己的产品就不行了。对普通用户和团队来说，日常使用没有影响，因为
BUSL 允许 free use、modification、distribution（非竞争性场景）。
核心与 Provider 分离带来的坑
这个仓库只有核心引擎，Provider 散落在各个仓库里。当你
terraform init 时，它会根据配置中的 provider 版本去
registry 下载插件。如果你在公司内网，没有互联网访问，就得自己搭一个
plugin cache 或者 mirror。另外，不同版本的 Terraform 核心和 Provider
之间有兼容性问题，升级前最好跑一下 terraform plan
看看报错。
状态文件是命根子
Terraform 用 .tfstate
记录当前真实资源的状态。如果你丢了状态文件，Terraform
就不知道哪些资源是它管的。团队协作必须用远程状态后端，比如 Terraform
Cloud、S3 加 DynamoDB、Consul 等。否则两个人同时 apply
会互相覆盖导致状态损坏。这是个老生常谈的教训，但我见过有团队用 Git
来管理状态文件，结果合并冲突直接崩了。
学习曲线不在
HCL，而在理解状态
很多人觉得 HCL 语法简单，但真正难的是理解 Terraform 的 resource
lifecycle、如何处理 state drift、如何编写模块。 README
没有告诉你的是：如果一个资源被手动在云控制台改了，Terraform 下次 plan
检测到漂移，要么覆盖回去，要么你主动导入新的状态。这个“状态与现实不一致”的问题是最常见的陷阱。
官方学习资源
HA（HashiCorp）官方提供了免费的教程和 certification 考试：Terraform
Associate。认证页面（https://www.hashicorp.com/certification/）有学习指南。官方学习平台（learn.hashicorp.com/terraform）有从入门到高级的路径，包括如何写模块、如何使用
provisioner、如何管理远程状态。如果你准备入坑，先从 Getting Started
的指南开始，然后看 Operations and Development 那部分——这部分 README
里写得很清楚。
我个人的建议：先别急着去学写复杂的 module，先手写一个简单的 EC2
实例（或者 AWS 以外你能访问的任何资源），跑一遍
init、plan、apply、destroy。感受一下 plan
输出的变化，然后手动修改资源（比如改安全组入站规则），再跑 plan 看看
Terraform 怎么发现漂移。这一步做完，你就掌握了 80% 的核心概念。
总结
Terraform
的价值在于把基础设施变成可版本化、可审查、可自动化的代码。它不是一个完美的工具，但它的执行计划和资源图设计，让大规模基础设施管理变得可预测。用的时候多留意许可证限制和状态文件管理，别踩坑就行。