把 Terraform 称作 Apache Terraform 是一个比较常见的口误，但它恰好暴露了团队在工具选型时对许可证理解不够精确的问题。Terraform 核心从 0.12 之前使用 Mozilla Public License 2.0，后来在 1.x 阶段转为 Business Source License 1.1，并不是 Apache 2.0 项目。真正与 Apache 许可证关系密切的，是 Terraform 生态中的大量官方 provider，例如 AWS、Azure、Google Cloud 的 provider 大多以 Apache 2.0 或 MPL 2.0 发布。因此讨论 Apache Terraform 时，先要把核心工具和周边生态分开看。
一、Terraform 与 Apache 许可证到底是什么关系
先说结论：官方并没有一个叫 Apache Terraform 的项目。HashiCorp 旗下的 Terraform 在 2023 年以前使用 MPL 2.0 许可，这种许可要求修改后的文件在分发时需要开放源码，但允许与私有代码共存。2023 年 8 月，HashiCorp 宣布将 Terraform 切换到 Business Source License 1.1，主要限制云厂商直接基于 Terraform 提供竞争性托管服务。这一调整引发了社区对开放性的担忧，也直接推动了 OpenTofu 分支的诞生。
Apache 2.0 则是另一种非常宽松的开源许可，允许商用、修改和再发布，不要求衍生作品必须公开源码。Terraform 核心并不采用该许可，但它的 provider 生态情况不同。很多云厂商维护的官方 provider 选择 MPL 2.0 或 Apache 2.0，这也是为什么在开源合规扫描中，团队经常能看到 Apache 2.0 与 Terraform 同时出现。理解这一点可以避免在采购合规、安全审计时把 Terraform 核心错误标记为 Apache 2.0。
如果团队对许可证比较敏感，可以使用 OpenTofu。OpenTofu 是 Terraform 的兼容分支，由 Linux 基金会托管，当前仍使用 MPL 2.0。此外 Pulumi 等同类基础设施即代码工具使用 Apache 2.0，也可以作为替代方案。工具迁移虽然要评估状态文件和模块兼容性，但至少在许可证层面提供了更多选择。
二、声明式配置与执行计划的工作机制
Terraform 使用 HCL 语言描述目标状态，用户不需要写创建、更新、删除的具体流程，只需要声明最终需要什么样的资源。下面是一段最基础的 EC2 实例配置，它说明了 provider、resource 和参数的组织方式。
provider "aws" {
region = "ap-southeast-1"
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
tags = {
Name = "web-server"
}
}
执行 terraform plan 时，Terraform 会读取当前目录下的 .tf 文件，结合已有状态文件计算资源差异，输出一份变更计划。计划中会标出哪些资源需要新增、哪些需要修改、哪些需要销毁。这个步骤不会直接操作云资源，因此非常适合在 CI 流水线中先跑一遍，再由人工或自动审批确认。
与命令式脚本相比，声明式配置的最大好处是幂等。你多次执行 terraform apply，只要配置没有变化，Terraform 会检测到状态已经符合声明目标，不再重复创建资源。对大规模环境来说，这种机制显著降低了误操作风险和人工维护成本。不过声明式也意味着要花时间理解 HCL 的表达式、函数和生命周期规则，否则很容易写出看起来正确但实际无法收敛的配置。
三、状态文件与后端存储的实践要点
状态文件是 Terraform 运行的核心。它记录真实云资源与配置之间的映射关系，也保存了资源属性、依赖关系和元数据。默认情况下，Terraform 会把状态保存在本地工作目录的 terraform.tfstate 文件中。个人学习时这样做没问题，但团队协作时本地状态会带来冲突、丢失和无法审计的问题。
解决方式是把状态迁移到远程后端。下面以 AWS S3 为例，展示了如何配置远程状态以及使用 DynamoDB 实现写入锁。
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "ap-southeast-1"
encrypt = true
dynamodb_table = "terraform-lock"
}
}
远程后端有两点必须重视。第一是访问控制，状态文件里可能包含数据库密码、API 密钥等敏感信息，存放状态文件的 S3 桶或对象存储必须具备严格的权限策略。第二是并发锁，多人同时执行 apply 时，没有锁机制会导致状态互相覆盖。DynamoDB 表在这里承担了锁的角色，Terraform 在写入状态前会先尝试获取锁，避免两个操作同时修改同一份状态。
另外，不要手工编辑状态文件。虽然 terraform state 命令提供了 mv、rm、list 等操作，可以调整资源映射，但直接修改 JSON 文件非常危险，可能让 Terraform 认为某个资源已经不存在，从而在下次 apply 时重建或误删资源。遇到状态损坏时，优先使用 terraform state pull 和 terraform state push 结合备份进行恢复。
四、模块化设计让基础设施真正可复用
当 .tf 文件越来越多，资源和变量堆在同一个目录里，维护成本会快速上升。Terraform 的模块机制可以把一组相关资源封装成可复用的单元。一个标准模块目录通常包含 main.tf、variables.tf 和 outputs.tf，分别负责资源定义、输入参数和输出值。
module "network" {
source = "./modules/network"
vpc_cidr = "10.0.0.0/16"
subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"]
}
在根模块中调用上面这个 network 模块时，只需要关心输入和输出，不需要了解内部如何创建 VPC、子网和路由表。这样不仅降低了使用门槛，也让不同环境可以共享同一套经过测试的网络拓扑。变量输入可以设置默认值，也可以由调用方显式传入，输出则可以暴露 VPC ID、子网 ID 等引用信息。
模块版本管理同样重要。团队内部的模块应该使用 Git 标签或 Terraform Registry 进行版本发布，避免在多个环境中因为模块更新导致不可预期的差异。调用模块时，尽量固定版本号而不是使用 latest，这样在升级某个环境时可以先把变更限制在测试环境中验证，再逐步推广到生产环境。
五、当许可证成为硬性要求时如何选择
有些企业或项目有明确的许可证政策，要求所有引入的工具必须使用 Apache 2.0、MIT 或 BSD 等宽松许可。此时如果直接使用 Terraform 核心，可能会在法务审查中遇到阻碍。一个务实的做法是先确认 Terraform 的 BSL 1.1 是否真的影响当前使用场景。通常只有在构建与 HashiCorp 形成直接竞争的托管服务时才会触发限制，企业内部使用、CI 流水线调用、编写 provider 都不受影响。
如果法务仍然要求宽松许可，可以评估 Pulumi。Pulumi 同样提供基础设施即代码能力，支持 TypeScript、Python、Go 等通用语言，项目本身采用 Apache 2.0。它的状态管理和模块生态与 Terraform 不同，迁移前需要做好概念映射和状态导入。OpenTofu 也可以运行 Terraform 的大部分配置和模块，但许可仍然不是 Apache 2.0，而是 MPL 2.0。因此严格按 Apache 2.0 筛选时，Pulumi 往往比 OpenTofu 更符合条件。
综上所述，Apache Terraform 这个说法虽然不够准确，但它引出的许可、状态、模块和工具选型问题非常实际。团队在落地基础设施即代码时，核心工具可以用 Terraform，也可以根据许可证要求选择 OpenTofu 或 Pulumi，关键是理解每类工具的许可证边界、状态管理策略和模块化方法，避免只盯着工具名称而忽略了工程实践。
Terraform基础设施即代码Apache 许可证修改时间：2026-09-29 12:18:09