OpenTofu 实战：Terraform 开源分支的 IaC 新选择

OpenTofu 是 Terraform 的社区驱动开源分支，由 Linux Foundation 托管，承诺 100% 兼容 HCL 语法并永久保持开源。当 HashiCorp 将 Terraform 从 MPL 改为 BUSL 许可证后，大量团队开始评估迁移路径。本文用实战方式，带你把一套存量 Terraform 工程平滑切换到 OpenTofu，并讲清楚它在状态管理、模块化与 CI 集成上的工程实践。

一、为什么需要 OpenTofu

2023 年 HashiCorp 宣布 Terraform 改用 BUSL（Business Source License），意味着它不再是 OSI 认可的开源协议，商业使用受到限制。OpenTofu 作为 fork，保留了所有既有能力，同时由社区共治，路线图公开透明。对已经重度使用 HCL 的团队来说，迁移成本极低：绝大多数 .tf 文件无需改动，只需替换二进制与少量后端配置。

更大的价值在于开放性：OpenTofu 率先落地了状态加密（state encryption）、早期变量评估等特性，并且与 Crossplane 这类声明式 IaC 工具、以及 Pulumi 这类通用语言 IaC 工具 形成互补生态，让团队可以按场景选型。

二、快速安装与版本管理

macOS 用户可以直接用 Homebrew 安装，也可以下载官方二进制做版本隔离。生产环境建议锁定具体版本，避免意料之外的破坏性变更。

# Homebrew 安装
brew install opentofu

# 验证版本
tofu version

# 或从官方 releases 下载并放到 PATH
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sh

如果你同时维护 Terraform 与 OpenTofu 工程，可以用 tenv 或 tofuenv 这类版本管理器在目录间自动切换，避免互相污染。

三、把存量 Terraform 工程迁移到 OpenTofu

迁移的核心步骤是：初始化 → 兼容性检查 → 复用已有状态。OpenTofu 直接读取 Terraform 生成的 terraform.tfstate，不需要任何转换。

# 进入已有工程目录
cd my-terraform-project

# 用 tofu 初始化（会复用 .terraform 与 state）
tofu init

# 运行计划，确认与 terraform plan 输出一致
tofu plan

# 应用
tofu apply

执行 tofu plan 时务必逐项比对资源 diff，确认没有出现意料之外的增删。绝大多数情况下输出与 terraform plan 完全一致，说明迁移是安全的。

四、状态后端与团队协作

多人协作时不能把状态文件留在本地。OpenTofu 原生支持 S3 + DynamoDB 的远端状态与乐观锁方案，也是业界最成熟的模式。

terraform {
  backend "s3" {
    bucket         = "my-tofu-state"
    key            = "prod/network.tfstate"
    region         = "cn-hangzhou"
    dynamodb_table = "tofu-locks"
    encrypt        = true
  }
}

provider "aws" {
  region = "cn-hangzhou"
}

如果此前状态在本地，用 tofu state push / tofu state pull 在后端之间搬运；切换后端时先 tofu init -migrate-state 让 OpenTofu 自动迁移历史状态，避免手动复制出错。

五、模块化与可复用

5.1 调用本地模块

module "vpc" {
  source = "./modules/vpc"

  cidr_block = "10.0.0.0/16"
  azs        = ["cn-hangzhou-a", "cn-hangzhou-b"]
}

output "vpc_id" {
  value = module.vpc.vpc_id
}

模块的输入输出通过 variables.tf 与 outputs.tf 显式声明，配合 validation 块可以做参数校验，把约束前移到 plan 阶段。

六、在 CI 中跑 OpenTofu

把 tofu plan 放进流水线是基础设施即代码的标准做法，既能在 MR 中预览变更，又能通过 GitHub Actions 工作流 统一执行 apply。下面示例在 Pull Request 时跑计划、合并后自动应用。

name: tofu
on:
  pull_request:
  push:
    branches: [main]
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-tofu@v1
        with: { tofu_version: "1.8.0" }
      - run: tofu init -input=false
      - run: tofu plan -input=false
      - if: github.ref == 'refs/heads/main'
        run: tofu apply -auto-approve -input=false

状态锁由 DynamoDB 保证，即使并发触发也不会出现写冲突；镜像构建与基础设施变更都可以通过 Docker 容器 与 Kubernetes 协同发布。

七、OpenTofu 与同类工具对比

结论很清晰：如果你已经被 HCL 绑定、又希望保持开源合规，OpenTofu 几乎是零成本替代；如果团队更习惯用 Python/Go 表达基础设施，则 Pulumi 更顺手；而当你把一切搬上 Kubernetes，Crossplane 的声明式范式更统一。

八、生产落地检查清单

九、结语

OpenTofu 不是又一个玩具项目，而是拥有企业级状态管理与活跃社区的主流 IaC 选择。对绝大多数 Terraform 用户而言，迁移只是一次二进制替换加一次状态后端核对。把它纳入你的工具箱，既能规避许可证风险，又能享受到更开放的路线图。下一步，可以结合本文的 CI 模板，把基础设施变更也纳入日常代码评审流程。

进阶一、状态加密：OpenTofu 的差异化能力

状态文件里往往藏着数据库密码、密钥等敏感信息。OpenTofu 从 1.7 版本起原生支持状态加密（state encryption），无需依赖外部工具即可在落盘前完成加密。它兼容 AWS KMS、GCP KMS 以及本地密钥（passphrase / 密钥文件）等多种后端，是相较 Terraform 更早落地的差异化能力。

terraform {
  encryption {
    key_provider "aws_kms" "default" {
      region  = "cn-hangzhou"
      key_arn = "arn:aws-kms:cn-hangzhou:111122223333:key/abcd-1234"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.default
    }
  }
}

开启后，tofu plan 与 tofu apply 在读写状态时自动加解密，CI 中只需注入对应云厂商凭证即可，敏感信息不再以明文形式躺在对象存储里，合规压力大幅下降。

进阶二、tofu fmt / validate / lint 工具链

与 Terraform 一致，OpenTofu 提供一整套本地校验命令，建议全部接入 pre-commit 钩子，把格式与语法问题挡在提交之前，而不是等到 CI 才暴露。

tofu fmt -recursive     # 统一 HCL 格式，消除团队协作的风格差异
tofu validate           # 不连云厂商即校验变量类型、provider 与模块一致性
tofu fmt -check         # CI 中检查格式是否规范，不规范则直接失败

tofu validate 会在不连接云厂商的情况下校验变量类型、provider 配置与模块输入输出的一致性，是本地最快的反馈环；配合 GitHub Actions 的并行 job，能在几秒内发现大部分低级错误，显著提升基础设施代码的健康度。

进阶三、从 Terraform Cloud 迁移协作工作流

如果此前使用 Terraform Cloud 的远程执行，迁移到 OpenTofu 后可以用开源的 Atlantis 或自托管 runner 接管 plan/apply 的协作评审。核心是把原本由 SaaS 托管的状态锁与 PR 评论能力，平移到自托管服务，既保留”在合并请求里直接看 diff”的体验，又彻底脱离商业授权，把控制权交回团队自己。

值得一提的是，OpenTofu 社区对破坏性变更非常克制，每个大版本都会发布详细的迁移指南与兼容性矩阵，这让它在生产环境的长期演进上比很多个人维护的开源项目更可靠。对于正在做基础设施治理、希望降低供应商锁定风险的团队，现在正是评估并落地 OpenTofu 的好时机。