SRE文档
1. Terraform 的许可转向
在过去近十年里，HashiCorp 的 Terraform 无疑是 IaC 领域的代名词。然而，2023年8月，HashiCorp 宣布将其核心产品（包括 Terraform）的许可证从开源的 MPL 2.0 切换到商业源许可证（Business Source License, BSL）。
BSL 许可证虽然允许个人免费使用、修改和分发代码，但对商业用途施加了严格限制。任何可能与 HashiCorp 构成竞争的商业产品，都无法在不支付昂贵费用的情况下使用 Terraform。这一转变，加上其云服务不断上涨的成本，让许多严重依赖 Terraform 的企业和开发者开始重新评估“厂商锁定”带来的风险。当一个基础工具的未来完全由一家公司的商业决策左右时，寻找一个开放、中立的替代方案便显得至关重要。
2. OpenTofu 的诞生：一个真正开源的替代方案
正是在这样的背景下，OpenTofu 应运而生。它最初是由多家公司联合发起的 OpenTF 倡议，旨在保留一个真正开源的 Terraform。如今，OpenTofu 已经成为一个由 Linux 基金会托管的独立项目，并致力于加入云原生计算基金会（CNCF）。
OpenTofu 是 Terraform 1.5.x 版本的一个硬分叉，它承诺：
• 永远开源：在 MPL 2.0 许可下发布，确保所有用户都可以自由地用于任何目的，无商业限制之忧。
• 社区驱动：由中立的基金会管理，其发展方向由社区贡献者共同决定，功能和修复的优先级基于社区的实际需求，而非单一供应商的利益。
• 向后兼容：作为 Terraform 的直接替代品，用户可以平滑迁移，现有的代码、模块和工作流几乎无需更改。
3. OpenTofu vs. Terraform：关键差异对比
虽然 OpenTofu 源于 Terraform，但两者在核心理念和功能上已开始出现分化。以下是它们之间的关键差异：
| 特性 / 维度 | OpenTofu | Terraform |
|---|---|---|
| 许可证 | MPL 2.0 (真正开源) | BSL 1.1 (商业源，限制性) |
| 治理模式 | 社区驱动，由 Linux 基金会托管 | 单一厂商 (HashiCorp) 控制 |
| 状态文件加密 | ✅ 支持 (客户端加密) | ❌ 不支持 (社区呼吁多年) |
| 早期变量评估 | ✅ 支持 | ❌ 不支持 |
| 代码即策略 (Policy as Code) | ✅ 支持 (原生支持 OPA) | ✅ 支持 (需使用 Sentinel) |
| 状态修复 | ✅ 支持 (tofu repair --auto) | ❌ 不支持 (需手动刷新和应用) |
| 生态系统 | 兼容 Terraform 提供商和模块 | 庞大但受商业策略影响 |
最显著的优势在于，OpenTofu 实现了许多 Terraform 社区长期以来渴望但未被实现的功能，其中状态文件加密尤为关键。在 Terraform 中，状态文件以明文形式存储敏感信息，存在巨大的安全隐患。OpenTofu 在 1.7 版本中引入的客户端加密功能，彻底解决了这一痛点。
4. 快速从 Terraform 迁移
如果您已有 Terraform 项目，迁移状态文件仅需两步。这是一个无损操作，因为 OpenTofu 完全兼容 Terraform 的状态格式。
# 1. 从您当前的 Terraform 后端拉取状态文件
terraform state pull > terraform.tfstate
# 2. 将状态文件推送到 OpenTofu 管理的同一后端
tofu state push terraform.tfstate# 1. 从您当前的 Terraform 后端拉取状态文件
terraform state pull > terraform.tfstate
# 2. 将状态文件推送到 OpenTofu 管理的同一后端
tofu state push terraform.tfstate完成之后， CI/CD 流程只需将 terraform 命令替换为 tofu 即可。没有学习成本
5. 为什么 OpenTofu 是更优选择
• 长期的稳定性：由中立基金会确保其开源地位，不受单一公司商业策略的冲击。
• 更高的安全性：原生支持状态加密等关键安全特性。
• 更快的创新：社区驱动的开发模式能更快地响应真实世界的需求。
• 完全的控制权：无厂商锁定，让我们的基础设施未来掌握在自己手中。