全书目录

第五十篇：OpenTofu 完全指南 —— 开源蓝图工务署宇宙

第五十篇：OpenTofu 完全指南 —— 开源蓝图工务署宇宙

14 分钟 5,950 字 第 931 / 962 个阅读单元

一、先把宇宙观立住：OpenTofu 不是“云命令集合”，而是“开源蓝图工务署”

把你的云环境想成一座城市。

你有道路、机房、电力、仓库、门禁、负载均衡、数据库、DNS，这些都是真实世界里的“建筑物”和“公共设施”。
OpenTofu 不负责“发明这些设施”，它负责做三件事：

  1. 接收你写的城市蓝图。
  2. 核对城市现状和档案。
  3. 指挥各类施工队把城市修到你想要的样子。

这就是 IaC，Infrastructure as Code，基础设施即代码。

它的核心不是“用代码替代点鼠标”，而是把基础设施变成一份可版本化、可审查、可复用、可回滚的蓝图系统。

text
你脑中想要的城市
        |
        v
  HCL 蓝图文件(.tf/.tofu)
        |
        v
   OpenTofu 工务署
   |      |      |
   |      |      +--> 读取 State 档案
   |      +----------> 生成 Plan 施工审批单
   +-----------------> 调用 Provider 施工队
                             |
                             v
                       云厂商/API/平台
                             |
                             v
                         真实基础设施

所以，OpenTofu 的心智模型不是“执行脚本”，而是“声明目标状态，然后做状态协调”。

你说“这里应该有一栋楼”，它不是机械执行十几条步骤；它会自己算依赖、看现状、判断是新建、修改、替换，还是销毁。

二、OpenTofu 和 Terraform 到底是什么关系

先说结论：OpenTofu 是 Terraform 的开源延续分支，但已经是独立项目。

关键时间点是 2023 年 8 月 10 日。HashiCorp 官方宣布未来版本的 Terraform 等产品从 MPL 2.0 改为 BUSL。随后 OpenTofu 官方发起分叉，目标是把这条 IaC 路线继续保留在真正的开源治理下。

你可以这样理解：

  • Terraform 是这座城市原来的总工院。
  • OpenTofu 是在治理和许可证路线变化后，另起的一座“公开工务署”。
  • 它保留了原有蓝图语言、工作流和大量生态习惯，因此 OpenTofu 官方把自己描述为 Terraform 的 drop-in replacement。
  • 但它不是“永远一模一样的影子”。OpenTofu 官方也明确说过，未来功能由社区决定，不是追着 Terraform 永远镜像同步。

这意味着两件事同时成立：

  • 如果你会 Terraform，上手 OpenTofu 通常很快。
  • 但你不能把 OpenTofu 理解成“免费 Terraform 壳子”，它有自己的路线、治理和版本演化。

还有一个很实用的兼容点：OpenTofu 官方说明它可以使用 Terraform 1.5.x 时代生成的现有 state 文件。这也是很多团队能平滑迁移的重要原因。

三、五大核心部件：provider、module、state、plan、apply

1. Provider：施工队

Provider 是 OpenTofu 与外部世界沟通的插件。

aws provider 会去调用 AWS API，azurerm 会去调用 Azure，google 会去调用 GCP。
没有 provider，OpenTofu 就像工务署只有蓝图，没有施工队。

hcl
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

要点：

  • required_providers 是“我要找哪支施工队、版本范围是什么”。
  • provider "aws" 是“这支施工队在什么区域开工、拿什么凭证进场”。

一个很容易踩的坑是：provider 不是随便删的。
OpenTofu 官方文档说明，state 里会保留资源最近一次使用过的 provider 配置引用。你把资源删了，往往还要留 provider 再跑一轮 plan/apply，让它有机会把旧资源善后拆掉。

2. Module：标准化图纸包

Module 是把一组相关资源打包成可复用蓝图。

比如“VPC 网络底座”“EKS 集群”“标准三层应用”“日志桶+告警”都很适合做成 module。

hcl
module "network" {
  source     = "./modules/network"
  cidr_block = "10.10.0.0/16"
}

你可以把 module 理解成：

  • root module：总图院总平面图
  • child module：标准楼栋设计包
  • registry module：公开发行的标准图纸

OpenTofu 官方文档明确说，module 是复用资源配置的主要方式。
所以，provider 解决“怎么连外界”，module 解决“怎么复用结构”。

3. State：档案室总台账

State 是 OpenTofu 最容易被低估、也最不能乱碰的部分。

它不是缓存，而是“蓝图地址”和“真实建筑 ID”之间的绑定档案。
OpenTofu 官方文档对 state 的定义很直接：它用来把真实世界资源映射到配置，并保存元数据。

text
resource "aws_s3_bucket" "logs"
            |
            | 绑定关系
            v
实际桶 ID / ARN / 属性 / 依赖信息 / provider 引用
            |
            v
        state 档案

几个必须记住的事实：

  • 默认本地 state 文件名仍然常见为 terraform.tfstate，这是兼容历史，不是写错。
  • state 里可能包含敏感数据。
  • 本地 state 适合个人实验，不适合团队协作。
  • 团队应优先用远程 backend，把 state 放到共享且可锁定的位置。
  • 不要手改 JSON，优先用 tofu state 子命令处理高级场景。

一句话：没有 state，OpenTofu 就像没有地籍档案的工务署。

4. Plan：施工审批单

plan 的作用不是“顺便预览一下”，而是把“目标蓝图”和“当前城市”做一次正式比对，产出施工方案。

bash
tofu plan
tofu plan -out=tfplan

你可以把它理解为：

  • 哪些楼要新建
  • 哪些路要扩建
  • 哪些旧设施要拆
  • 顺序怎么排
  • 风险点在哪

更重要的是，保存下来的 plan 文件本身也可能包含敏感信息。OpenTofu 官方文档明确提醒，plan file 会包含完整配置、变更值和输入变量，所以它也是敏感制品。

5. Apply：开工令

apply 才是真正动手施工。

bash
tofu apply
tofu apply tfplan

两种模式要分清：

  • tofu apply：现场重新生成 plan，再问你要不要施工。
  • tofu apply tfplan：按之前保存好的审批单直接施工。

工程上更稳的习惯是：

bash
tofu init
tofu fmt
tofu validate
tofu plan -out=tfplan
tofu show tfplan
tofu apply tfplan

原因很简单：审批单和开工令最好绑定同一份计划。
否则你看到的 plan，和真正 apply 时重新计算出的 plan，不一定完全相同。

四、看一份最小但完整的 OpenTofu 蓝图

hcl
terraform {
  required_version = ">= 1.6.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket = "iac-state-prod"
    key    = "platform/network.tfstate"
    region = "ap-southeast-1"
  }
}

variable "region" {
  type    = string
  default = "ap-southeast-1"
}

provider "aws" {
  region = var.region
}

module "network" {
  source     = "./modules/network"
  cidr_block = "10.10.0.0/16"
}

resource "aws_s3_bucket" "logs" {
  bucket = "mizzen-platform-logs-prod"

  tags = {
    ManagedBy = "OpenTofu"
    Env       = "prod"
  }
}

output "log_bucket_name" {
  value = aws_s3_bucket.logs.bucket
}

这段代码里同时出现了：

  • provider
  • module
  • backend/state
  • resource
  • output

这就是一份典型工地蓝图：
先声明施工队，再确定档案馆位置，再调用标准图纸，最后补少量项目级资源。

补一句实战提醒：backend 的凭证不要硬编码。
OpenTofu 官方文档明确提醒，若把敏感 backend 配置直接写进配置或命令参数，它们可能进入 .terraform 子目录和 plan 文件。

五、OpenTofu 的真正价值，不只在“能不能用”，更在“谁来决定未来”

很多人把 OpenTofu 理解成“换个 CLI 名字”。这太浅了。

OpenTofu 的关键意义在于开源治理：

  • 许可证路线更清晰，法务和采购风险更可预期。
  • 项目由 Linux Foundation 托管，降低单一厂商控制风险。
  • 大变更不再只由单一商业公司拍板。
  • 社区可持续维护 IaC 语言和生态，而不是只能被动等待。

OpenTofu FAQ 里对治理也说得很直白：

  • 核心团队和技术负责人决定重点特性与 bug 修复优先级
  • steering committee 处理重大变化

这意味着它不是“没人负责的社区拼盘”，也不是“完全中心化的厂商产品”，而是更接近现代基础设施项目常见的开源治理模型。

对企业来说，这不是情怀问题，而是：

  • 法务可接受吗
  • 未来可迁移吗
  • 生态会不会被锁死
  • 团队标准是否能长期稳定

六、OpenTofu 适合什么，不适合什么

适合：

  • 你要做多云、混合云、SaaS 资源统一编排。
  • 你想把基础设施纳入 Git 审查、CI/CD、变更审批。
  • 你希望大量复用标准 module。
  • 你需要清晰的 plan/apply 审批流。
  • 你看重开源治理、许可证清晰度和可持续性。
  • 你团队原本就熟悉 Terraform/HCL 体系。

不太适合：

  • 你主要是单云 AWS，而且高度依赖 AWS 原生体系，CloudFormation/CDK 往往更贴近平台原语。
  • 你的基础设施逻辑高度程序化，充满复杂循环、抽象、条件分支和软件工程封装需求，Pulumi 往往更顺手。
  • 你真正需要的是主机内配置管理、补丁、软件安装、运行时收敛，这更像 Ansible/Chef 的地盘。
  • 你只是临时写几个一次性云脚本，直接 SDK/CLI 可能更轻。

七、最常见的误区

误区 1：OpenTofu 就是“更名版 Terraform”
不是。它确实承接 Terraform 语言与工作流，但已经是独立项目，未来特性路线不保证永远一致。

误区 2：state 只是缓存，丢了再生成
错。state 是资源绑定档案，丢失会让工务署失忆。

误区 3：plan 看过就行，apply 直接裸跑
错。没保存 plan 的 apply 会重新规划，自动化场景最好使用同一份 plan file。

误区 4：本地 state 也能团队协作
勉强能跑，不等于应该这么做。团队环境应优先远程 state 和锁。

误区 5：module 越抽象越高级
错。过度抽象会让调用方看不懂、调不动、改不起。好 module 应该像标准图纸，不像黑箱机器。

误区 6：手改 state JSON 很快
短期快，长期炸。优先用 tofu import、tofu state mv、tofu state rm 之类正式手段。

误区 7：OpenTofu 能解决所有运维问题
不能。它擅长“声明式基础设施编排”，不是万能运维总控台。

八、与 Terraform、Pulumi、CloudFormation 怎么选

工具 核心表达方式 生态与范围 状态模型 治理特征 更像什么
OpenTofu HCL 声明式 跨云、跨平台，延续 Terraform 生态习惯 显式 state + backend 社区驱动，Linux Foundation 托管，开源路线清晰 开源工务署
Terraform HCL 声明式 跨云、跨平台，生态成熟 显式 state + backend HashiCorp 主导，未来版本采用 BUSL 路线 商业总工院
Pulumi 通用编程语言 + YAML 跨云，开发者工程感更强 stack state + backend 开源 IaC + 可选平台能力 软件工程化施工系统
CloudFormation AWS 模板/Stack AWS 原生 stack 由 AWS 服务管理 AWS 官方服务 AWS 自营施工平台

选择建议可以直接记成一句：

  • 想要 HCL、跨云、成熟 IaC 心智、又重视开源治理，用 OpenTofu。
  • 已经深度绑定 HashiCorp 体系且组织允许其许可证路线，可继续 Terraform。
  • 基础设施像软件项目一样复杂，希望直接用 TypeScript/Python/Go/C# 等语言表达，用 Pulumi。
  • 只做 AWS，优先原生服务整合和官方托管体验，用 CloudFormation。

九、把整套工务署流程串起来

text
Git 仓库中的蓝图
      |
      v
  tofu init
  下载 provider / module
      |
      v
  tofu validate
  检查图纸是否合法
      |
      v
  tofu plan -out=tfplan
  生成施工审批单
      |
      v
  人工审查 / CI 审查
      |
      v
  tofu apply tfplan
  按审批单开工
      |
      v
  更新真实资源 + 更新 state 档案

只要你把这条链路记住，OpenTofu 就不再神秘：

  • 蓝图是配置
  • 施工队是 provider
  • 标准楼栋是 module
  • 档案室是 state
  • 审批单是 plan
  • 开工令是 apply

十、总结

OpenTofu 的本质，是一座面向现代基础设施的开源蓝图工务署。

它继承了 Terraform 时代成熟的 IaC 语言与工作流，但把“未来由谁决定”这个问题重新拉回开源治理。
学会 OpenTofu，真正要学会的不是几个 CLI 命令，而是这套心智：

  • 用声明描述目标，而不是手工堆步骤
  • 用 state 维护现实与蓝图的绑定
  • 用 plan 把风险前移到审批
  • 用 module 建立标准化复用
  • 用 provider 把蓝图翻译成各平台施工动作

当你真的按这套方式管理基础设施时，云资源就不再是一堆网页按钮，而会变成一座可以持续规划、审计、复用和演进的城市。

官方来源链接清单