深色模式
OpenTofu 替代：与 Terraform 的差异
摘要：OpenTofu 是 Terraform 的社区开源分支，命令与 HCL 语法高度兼容。本文讲清它的由来、安装方式、从现有项目原地迁移的步骤，以及目前真正需要注意的几处差异。
适用环境
- 已有 Terraform 项目（1.5.x 及以上迁移最顺滑）
- Linux / macOS / Windows 均可
- 已配置远程 backend（S3/GCS/OSS 等均可复用）
操作步骤
1. 为什么会有 OpenTofu
Terraform 在 2023 年将许可从 MPL 改为 BUSL（商业使用受限），社区随后在 Linux Foundation 下创建 OpenTofu 分支，保持 MPL-2.0。对使用者的实际意义：语法与 provider 生态基本通用、商业闭源场景无许可风险、由基金会治理。
2. 安装
bash
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method deb # 也可 rpm / standalone
tofu version1
2
3
4
2
3
4
macOS 用 brew install opentofu。命令名是 tofu，但保留 terraform 别名以便脚本过渡。
3. 原地迁移现有项目
bash
cd ~/tf-demo
terraform state pull > backup.tfstate # 先备份 state
tofu init
tofu plan # 正常情况应为 No changes1
2
3
4
2
3
4
多数 1.5+ 项目无需改任何 .tf 文件即可直接工作。
4. 需要检查的差异点
hcl
# required_version 若写死版本号，需确认约束兼容
terraform { required_version = ">= 1.5.0" }1
2
2
text
lock 文件：两者都读写 .terraform.lock.hcl，混用会导致反复变更
环境变量：TF_VAR_* 依然通用
registry：OpenTofu 有自己的 registry，但兼容 hashicorp 命名空间1
2
3
2
3
5. OpenTofu 独有方向
hcl
# state 原生加密（无需依赖 backend 侧加密）
terraform {
encryption {
key_provider "pbkdf2" "mykey" { passphrase = var.state_passphrase }
method "aes_gcm" "m" { keys = key_provider.pbkdf2.mykey }
state { method = method.aes_gcm.m }
}
}1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
以及原生 provider for_each、模块级 removed 块等逐步补齐的能力。
别在同一项目里来回切换工具
两者交替执行会改写 lock 文件并触发 provider 重下。一个项目选定一个工具，写进 README 和 CI 镜像。
验证
bash
tofu fmt -check -recursive && tofu validate
tofu plan -detailed-exitcode # 迁移后应为 0（无变更）1
2
2
- [ ]
tofu plan无差异输出，说明 state 完全兼容 - [ ] CI 镜像中只安装了一种工具
- [ ] 备份的
backup.tfstate可正常恢复
常见坑
命令名变了导致脚本报错
CI 脚本里写死 terraform 会找不到命令。用安装脚本的别名，或定义变量 TF_CMD=tofu。
直接迁移生产有风险
再兼容也要先在非生产环境完整跑通 plan/apply。迁移前 state pull 备份必须落地保存。
部分 provider 版本滞后
极少数 provider 在 OpenTofu registry 上更新较晚。选型前先在 registry 页面确认版本可用。