为Terraform工程师打造的OpenTofu初级指南

2 年 ago

清, 扬

5 minutes

本文是《2023年Cloudworks节日日历》系列1的第4天的文章。

首先

爸爸，我只是想说「爸爸，我想放弃Terraform职人的工作，改行做豆腐职人来维持生计」，我是@minamijoyo。

2023年8月，HashiCorp宣布将其主要产品从MPL2开源许可证转变为BSL（商业源代码许可证），而Terraform从v1.6.0开始不再是开源软件。
在这一许可证变更之后，有一些人在寻求OSS版的Terraform，因此他们从MPL2的代码库中分叉了一个名为OpenTofu的项目进行开发。
HashiCorp的BSL实际上对竞争对手的商业利用进行了限制，尽管大多数普通用户没有直接的额外限制，但对Terraform生态系统的间接影响是不可忽视的。

筆者本身並不是 HashiCorp 或 OpenTofu 的競爭對手，而是中立的立場。但是多年來我一直在為 Terraform 的第三方工具做貢獻，甚至獲得了 HashiCorp 的肯定，成為核心貢獻者，這都是為了推動 Terraform 的開源生態系統的發展。

隨著近年來開源軟體遭受轉變的趨勢，HashiCorp 的授權變更往往被當作是對「免費掠奪開源軟體」的一般性評論。但至少就 Terraform 而言，這幾年我們從社群端提出的功能新增 Pull Request 很少被妥善地審查，只接受了一些輕微的錯誤修正。在他們終止免費掠奪之前，我個人希望他們能多一點向社群尋求幫助的誠意。

在这篇文章中，我们将讲解Terraform专家应了解的OpenTofu项目的概述和当前情况，并整理目前已知的来自Terraform的变化，以及对未来展望的个人见解。

本文写作时，OpenTofu的版本为v1.6.0-beta1。虽然还没有稳定版发布，但目前的发布计划是在12月中旬至1月中旬左右公布。至少在有稳定版发布之前，我认为几乎没有人会立即转向OpenTofu，但是对于那些对OpenTofu后续的发展情况感到关注的Terraform操作员们，如果我能提供一些参考那就太好了。

开放豆腐项目

总之

OpenTofu是一个开源的基础设施配置管理工具，它是在Terraform的BSL许可证变更之前的MPL2代码基础上进行分支开发的。作为Linux Foundation旗下的项目，它将继续以MPL2许可证进行开发。

官方网站：https://opentofu.org
代码库：https://github.com/opentofu/opentofu

这是一个基于社区的开源软件项目，在本文撰写时，由Gruntwork、Spacelift、env0、Scalr和Harness这5个公司作为指导委员会的核心开发。它宣称是Terraform的一种替代方案，可以直接使用现有的Terraform的tf文件和tfstate文件。关于与Terraform的差异等方面的变更将在后面提到。

经过

我虽然还没有太多的经历，但是会把项目的过程记录下来。

HashiCorp的许可证变更

2023年8月10日，HashiCorp宣布将其主要产品从MPL2开源许可证改为BSL（商业源代码许可证）。

注意：SPDX（软件包数据交换）正在推进软件元数据的标准化。MariaDB的BSL作为HashiCorp的BSL的基础，被标识为BUSL-1.1。而在SPDX中，BSL指的是Boost软件许可证，这是一种经过开源计划批准的开源许可证。因此，如果需要进行区分，会使用BUSL进行表述。由于本文中HashiCorp称之为BSL，因此我们将统一使用BSL进行表述，无需进行特别区分。

https://spdx.org/licenses/BUSL-1.1.html
https://spdx.org/licenses/BSL-1.0.html

在发表之时，许可证的措辞非常模糊，引发了巨大的混乱。因为实质上商业使用的条件即”Additional Use Grant”的描述如下所示：

您可以在生产中使用许可作品，前提是不与HashiCorp的产品竞争，并且不将许可作品以托管或嵌入的方式提供给第三方。

这里的“hosted”、“embedded”、和“competitive”具体指什么呢？
之后，FAQ中添加了很多补充说明。

可以在以下的社群論壇主題中感受到當時的混亂情況。

关于FAQ的重要部分，2023年10月17日的修订已反映在许可证的”Additional Use Grant”部分，并在本文撰写时如下所示。

https://www.hashicorp.com/bsl 的中文翻译如下：

您可以在生产中使用经过许可的工作，但您的使用不得包括以托管或嵌入方式向第三方提供经过许可的工作，以与HashiCorp的付费版本的经过许可的工作竞争。在本许可证的目的下：
“竞争产品”是指以付费方式向第三方提供的与HashiCorp的付费版本的经过许可的工作的能力有重叠的产品，包括通过付费支持安排提供的产品。如果您的产品在初次普遍提供时不是竞争产品，那么由于HashiCorp发布了新的具有额外能力的经过许可的工作版本，它将不会后来成为竞争产品。此外，未以付费方式提供的产品不算竞争产品。
“产品”是指以软件形式向终端用户提供的用于在其自己的环境中进行管理或以托管方式提供的服务。
“嵌入”是指在竞争产品中包含经过许可的工作的源代码或可执行代码。“嵌入”还意味着以这样的方式打包竞争产品，以使得竞争产品必须访问或下载经过许可的工作才能运行。
将经过许可的工作用于组织内部目的的托管或使用不被视为竞争产品。HashiCorp认为您的组织包括您控制下的所有关联公司。
有关在商业源代码许可下使用HashiCorp产品的约束性解释指南，请访问我们的常见问题解答。

只限于Terraform的背景，简而言之，对于Terraform Cloud的竞争对手，我理解为不要使用。但由于我不是法律专家，请各自负责解释许可证的理解。（承诺）

OpenTF宣言的发布

不久之后，自HashiCorp宣布许可证变更以来，包括Gruntwork、Spacelift、env0、Scalr、Digger、Massdriver、Terrateam等与Terraform相关的供应商联合发布了一份名为OpenTF宣言的文件。该文件是针对Terraform许可证变更的反对声明，内容表明如果不恢复原始的开放源代码许可证，他们将会分支出去。

以下是网站和GitHub上OpenTOFU组织宣言的链接：
https://opentofu.org/manifesto
https://github.com/opentofu/manifesto

在本文撰写时，放置有这份声明文件的 GitHub 存储库已经获得了36.2k个星标，显示了社区对其的浓厚兴趣。仅供参考，我们还可以以 hashicorp/terraform 这个官方 Terraform 存储库为例，该存储库获得了39.5k个星标。

为什么尽管只有极少数用户直接受到许可证更改的影响，却能获得如此大的支持？关于Terraform作为开源软件维护的重要性的论点可以在Gruntwork的博客中找到很好的概括。

我认为，在文中提到的最具印象的例子，大致的意思可以表达如下：

あなたがDevOps関連のベンダだとして、なぜTerraformを選ぶのか？ある日HashiCorpがあなたを競合だと言ってくるかもしれないのに。たぶん他の選択肢を探すだろう。

与 Spacelift、env0、Scalr 等无论是多么正式严肃的 Terraform Cloud 竞争对手不同，Gruntwork，负责开发Terragrunt和Terratest的公司，却引人注目地站在了前列。Gruntwork 提供 Terraform 的引导支持，从某种意义上讲可以说是 HashiCorp 的合作伙伴。最近日本有了 “解密 Terraform” 的翻译版，而原版的作者正是 Gruntwork 的创始人，可以毫不夸张地说是为 Terraform 的推广做出了巨大贡献。然而，遵循 Gruntwork 的最佳实践不可避免地会涉及到 Terragrunt，而 Terraform Cloud 却不支持 Terragrunt，因此 Terragrunt 的普及会导致支付给 Terraform Cloud 的用户减少。从这个意义上说，可以说它们是竞争对手。问题在于竞争与否由 HashiCorp 决定，而这种决定随时可能被改变，这是商业上的风险。

有些人提出了许可证措辞模糊的问题，尽管稍后在常见问题解答等方面得到了补充，但这并不改变HashiCorp可以随时单方面改变解释的事实。对于将Terraform作为业务核心的供应商来说，在其之上构建业务被认为是风险过高，从结构上讲是不可避免的。

如果Terraform Cloud是开源的，然后转换为BSL的话，我完全可以理解。但是，他们的主张是Terraform不仅仅是一个服务，而是一个CLI工具，甚至可以说是一种编程语言。当然，开发开源软件是需要资金的，也有人批评他们免费使用了开源软件，但是HashiCorp自己也依赖于诸多开源生态系统，例如Linux和Go等。HashiCorp的许多产品，包括Terraform在内，都是用Go语言实现的。如果Google突然说Go语言是竞争对手不准使用，竞争与否是由我们来决定，那会发生什么呢？从不同的角度看，每个人都有自己的正义，所以并不是一个简单的哪个是正确的问题。最后，一切都是经济不景气惹的祸啊。

Terraform Registry的使用条款已经更改。

Terraform Registry发布了Terraform提供程序和模块，其使用条款也已经更改，并附加了一条表明别使用于Terraform以外的内容的声明。

您可以从本网站下载供应商、模块、策略库和/或其他服务或内容，仅限用于HashiCorp Terraform的使用或支持。您可以仅限于个人非商业用途下载或复制内容（以及服务下载时显示的其他项目），前提是您保留其中包含的所有版权和其他通知。您不得以任何形式存储任何内容的重要部分。

现在看，最后更新日期为2023/08/24。但是，在2023/08/31时，当发现这个变更时，最后更新日期仍为2020/04/16，且在2022/12/20的网络存档中没有这个新增的文字。这个变化悄悄地改变了使用条款，OpenTF社区因此而热议不已。

由于注册表问题，OpenTofu向稳定版本的发布存在主要障碍，所以我们准确地补救了初始困境。不过，长远来看，我们应该在稳定版发布后意识到这一点，这样可能会更好。

将fork作为OpenTF的一个分支公开发布

由于在2023/08/25的截止日期前，OpenTF方面未收到HashiCorp的回复，因此决定采取分叉策略。然而，在这个时点，为了将Terraform重新命名为OpenTF以及修订社区指南，存储库暂时保持非公开状态。顺便提一下，从提交历史记录可以看出，虽然宣布了在2023/08/25分叉的计划，但实际上在此之前就已经进行了分叉并开始了改名工作。虽然OpenTF的存储库在一段时间内仍然是私有的，但在2023/09/05，它被公开了。

当HashiCorp宣布许可证变更时，Terraform的稳定版本是v1.5.5，因此有些人可能认为是从v1.5.5进行分叉，但实际上是从许可证变更之前的main分支提交中分叉，从Terraform v1.6.0-alpha等价版本开始进行的分叉。

尽管 Terraform v1.5 系的分支目前仍然使用 MPL2 许可证，但在撰写本文时，v1.5.7 版本仍然以 MPL2 许可证进行发布。虽然不确定 v1.5 系将持续维护多久，但我认为至少在下一个版本 v1.7 发布之前将会进行维护。

参加Linux Foundation，并将其更名为OpenTofu。

这个项目最初被称为OpenTF，但出现了商标侵权的担忧，即使仅有”TF”两个字符也可能存在风险。因此，在社区中征集了新的名字，结果得到了一种不知道是玩笑还是认真的意见的绝对支持：“为什么不叫tofu呢？简称就是tf，与terraform的韵味也不同。”因此，在2023/09/20加入Linux Foundation傘下的时候，该项目被重新命名为OpenTofu。

顺便说一下，豆腐在英文里也叫做tofu。OpenTofu的官方标志明明是一块厚炸豆腐，但是厚炸豆腐在英文里被称为”deep-fried thick tofu”或者”thick fried tofu”，如果忘记了”thick”这个词，就会变成油炸豆腐，所以要注意。以上，这就是一个无关紧要的豆知识。（毕竟是豆腐）

发布暂定的Registry的最新版本并公开了v1.6.0-alpha1的首个发布版。

由于Terraform Registry实际上几乎完全是GitHub Release的代理，所以我们匆忙地建立了临时的OpenTofu Registry。大多数第三方供应商不受影响，但是HashiCorp管理的官方供应商是通过HashiCorp的发布服务器进行分发的，而不是通过GitHub发布。然而，由于供应商的源代码仍然是MPL2许可证，所以我们也必须fork供应商的存储库，并从源代码重新构建全部版本，包括过去的版本。

例如，HashiCorp/AWS提供者

以下的opentofu/aws提供者已经被fork。

另外，OpenTofu的实现将访问registry.terraform.io隐式地替换为registry.opentofu.org，这样就可以与OpenTofu Registry进行通信，而不是与Terraform Registry进行通信。

2023年10月4日，暫定的註冊表已完成，並釋出了首個v1.6.0-alpha1版本。

採用与安定版本的Registry设计中，采用类似Homebrew的方案。

为了进行alpha版本发布，暂时的Registry被建立起来。然而，为了稳定版本的发布，Registry被重新设计了。

順便提一下，OpenTofu的开发团队最初是开发Terraform Cloud的竞争服务的，互相之间是竞争对手。为了确保没有一家公司拥有过于强大的权限，项目运营需要一定的治理。对于重要的设计性变更，我们引入了公开设计审查机制，即事先进行RFC（评论请求）并最终由Steering Committee进行决策的过程。

在安定版的Registry设计中，对于其中的三个RFC提出了建议，并于2023年11月2日选择了其中一个类似于Homebrew的方案。

这是一个使用GitHub的PullRequest为基础来管理提供程序和模块元数据，并尽可能自动化版本升级的策略，就像Homebrew所做的那样。选择这种方法的最重要原因是，Registry的API服务器不需要具有类似RDB的状态，而几乎只需通过CDN提供静态内容即可实现，从而保持高可用性，减轻核心团队的运营负担。

一方面，需要使用PullRequest来注册新的提供程序和模块，但考虑到提供程序和模块的维护者可能不是OpenTofu用户的情况，允许维护者以外的人员进行元数据的注册也是合理的。Homebrew也允许非工具作者自行注册，并且只需参考GitHub的发布中的校验和和签名密钥，就可以验证元数据的合法性，因此无需验证注册者的身份。

切换到 v1.6.0-beta1 版本进行发布并切换到稳定版的Registry。

v1.6.0-beta1于2023年11月30日发布，并于2023年12月01日切换到稳定版本的Registry。
虽然对于正式运营和工作流程尚不太了解，但我们正在以下存储库中管理元数据。

据看，已经注册了大量的Provider和Module，看起来像是自动批量注册到了Terraform Registry中。

顺便提一下，如果查看 registry.opentofu.org 的HTTP头，可以看到它使用了Cloudflare作为CDN，据说Cloudflare是它的赞助商。

（计划发布的稳定版本v1.6.0）

目前，根据公告，v1.6.0版本的稳定发布计划在2023年12月中旬至2024年1月中旬左右。由于稳定版本的Registry已发布，我们计划正式进入测试阶段。目前看来，不太可能大幅度改变方针。

来自Terraform的变更

在本文撰写时尚未出现稳定的发布版本，但会总结目前从Terraform中看到的变更。

将terraform命令改为tofu命令。

terraform命令作为CLI已更名为tofu命令。基本使用方法与terraform命令相同，只需将init/plan/apply等读作tofu init/plan/apply即可使用。

由于二进制文件的重命名，需要在使用第三方工具等调用terraform命令的情况下更换为tofu命令。例如，在我维护的tfmigrate中，可以通过设置环境变量TFMIGRATE_EXEC_PATH=tofu来启用tofu命令，版本需为v0.3.19或更高。

请查找每个工具的存储库问题等，以了解各自工具的兼容性情况。

将Terraform的标准输出和错误输出重命名为OpenTofu。

在标准输出和错误输出中，原本显示为Terraform的部分已被重命名为OpenTofu。

$ tofu version
OpenTofu v1.6.0-beta1
on darwin_arm64

我觉得只是作为普通用户使用没有问题，但对于通过第三方工具来解析标准输出和错误输出的情况，仅仅将alias terraform=tofu等同于原命令可能无法按照预期工作。请确保查看每个工具的兼容性情况。

此外当然，还有一些在Fork之后添加的错误信息等是不同的，所以Terraform ⇒ OpenTofu的重命名以外还存在差异。

版本号

由於OpenTofu是從Terraform v1.6.0-alpha分支分叉出來的，因此第一個穩定的版本預計會是v1.6.0。同時，也預計將包含Terraform v1.6.0的新功能，如test命令和s3後端的更改等。

由於授權問題，無法從Terraform複製源代碼，但預計在後續的實現中將添加Terraform引入的功能，並以外部規格維持相容性。雖然可以認為v1.6版本在分叉後幾乎是相容的，但目前來看，可以實現多少相容性而不重複使用代碼仍然不明確。

即使採用了與Terraform後續版本相同的次要版本號方針，但一旦OpenTofu需要進行破壞性更改，可能會被Terraform的發布周期所牽制，所以無論採取什麼策略來保持次要版本一致性，我們都覺得它最終可能會失敗。

登记处

如前所述，由于Terraform注册表（registry.terraform.io）的使用条款限制了其只能与Terraform一起使用，因此为了OpenTofu项目而建立了OpenTofu注册表（registry.opentofu.org）。为了保持对现有tf文件和tfstate的兼容性，与Terraform注册表的通信被偷偷地导向到了OpenTofu注册表。

在OpenTofu Registry的建立之前，未在Registry注册的提供程序和模块是无法使用的，但是已经在Terraform Registry注册的提供程序和模块已经进行了机械化的批量注册，因此现有的Terraform依赖应该还是可以使用的。对于将来新注册的内容可能会产生差异，但是通过采用类似Homebrew的注册表，即使不是维护者，也可以通过PullRequest的方式进行注册。

目前，OpenTofu Registry只有API，並沒有提供供應商或模塊等相關文檔的網站。這只是因為實施的優先級較低，但未來他們計畫在網站上提供相關文檔。

虽然细节非常微小，但OpenTofu注册表的协议与Terraform注册表存在一些差异。具体来说，Terraform注册表使用X-Terraform-Get HTTP响应头返回模块的下载地址，而OpenTofu注册表使用HTTP响应体进行返回。这是为了静态内容分发而故意进行的规范更改。为了保持兼容性，tofu命令可以通过在没有响应体的情况下回退到头部，从而与支持Terraform注册表协议的私有注册表进行通信。相反，我认为Terraform无法与OpenTofu注册表进行通信在实践中并不是一个问题，但对于使用第三方工具与Terraform注册表进行通信的情况，由于OpenTofu注册表协议与之并不完全相同，可能会出现兼容性问题。

购买者、供应商、提供方

只要Terraform Provider保持MPL2许可继续分发并且保持与提供程序协议的兼容性之间，Terraform Provider可以直接在OpenTofu上使用。此外，即使将来有协议变更，只要Terraform Plugin Framework和gRPC的proto文件继续以MPL2许可分发，也应该可以进行通信。

正如前面所述，由于Hashicorp官方没有在GitHub上发布供分发的提供商，因此OpenTofu在进行适配时需要对其进行fork，并从源代码重新构建。尽管Go编译器的版本和编译选项等细微差异可能存在，但在功能层面上这几乎不会导致问题。

.terraform.lock.hcl的汉语表达：

terraform的锁定文件.hcl

依赖的锁定文件名称仍然是 .terraform.lock.hcl，而不是 .tofu.lock.hcl。而且，正如前面所述，OpenTofu Registry的地址是 registry.opentofu.org，并且提供者是一个不同的二进制文件，所以在 .terraform.lock.hcl 中记录的哈希值也是不同的。根据我的测试，由Terraform创建的 .terraform.lock.hcl 文件在迁移时不必删除，因为在执行 tofu init 命令时会自动进行重写。

模块

使用在Terraform v1.5版本中创建的tf文件可以直接使用，文件扩展名仍为.tf，而非.tofu。在Terraform v1.6版本中，tf文件的语法没有大的变化，并且还包括了s3后端的内置模式的更改。

HCL库将继续以MPL2的形式进行分发，预计将直接包含HCL级别的更改。虽然无法保证细微的错误修复会在相同的补丁版本中纳入，但这几乎只是一些边缘情况。

未来的OpenTofu如果出现只有该语法才存在或相反情况的话，可以很容易地想象到会出现兼容性问题。特别是模块的required_version会暗示将其与Terraform和OpenTofu的版本号视为兼容，但从逻辑上讲它们是不同的。关于版本控制的具体计划目前尚不清楚。维护共享模块的人应该在目前只使用最低公共版本v1.5的子集是比较安全的选择。

tfstate 文件

由于Terraform v1.6中tfstate格式没有改变，因此可以直接使用Terraform创建的tfstate文件在OpenTofu中使用。

tfstate中包含了Terraform Registry的地址，但是如果直接加载并应用tfstate文件，Terraform会自动将Registry地址从registry.terraform.io/hashicorp/null转换为registry.opentofu.org/hashicorp/null。值得一提的是，转换后的命名空间不是opentofu/null，而是hashicorp/null。

再者，tfstate文件还记录了上一次apply时使用的terraform_version。但是经过测试，当我尝试使用Terraform v1.6.5创建的tfstate文件在OpenTofu v1.6.0-beta1中进行tofu apply操作时，tfstate文件中的terraform_version变成了v1.6.0。如果格式兼容的话，即使Terraform的版本号更高，也可能可以进行迁移。

tfstate是内部的实现细节，但如果将来有不兼容的更改，OpenTofu可以通过实现重新解释规则来支持从特定的Terraform版本迁移至OpenTofu。然而，如果HashiCorp继续忽视OpenTofu，则从OpenTofu迁移回Terraform可能存在较高的风险。这些tfstate兼容性问题可能会在版本差异较大时变得更加突出，但作为OpenTofu阵营，我们认为顺利迁移从Terraform至OpenTofu是最优先考虑的事项，因此将来可能会完善迁移指南等。

Terraform云端平台

云块和远程块的主机名默认值已更改为app.terraform.io，删除了隐含的默认值，并变为必填项。同样，豆腐登录/注销命令的主机名也变为必填项。

我认为可能没有人希望在Terraform Cloud中使用OpenTofu，但是您仍然可以继续使用与Terraform Cloud兼容的替代服务。

测试框架

对于Terraform v1.6的一个主要功能terraform test命令的对应功能tofu test命令已经实现。这个功能从Terraform v1.6.0-alpha分支派生时就已经部分实现了，但最终完善是通过各个项目完成的。由于这个过程，可能存在功能差异，但我还没有详细调查。无论如何，对于Terraform v1.6及以后的功能，即使有相同的功能，也不应过度期待互操作性。

另外还有一些小bug

因为无法在源代码级别进行复制粘贴，所以其他细小的错误有时会被修复，有时则不会被修复。由于每个项目都会基于报告进行修正，所以根本没有被报告的问题也可能不会被修复。尽管被称为drop-in replacement，但我认为在一般使用情况下，tf文件和tfstate文件在OpenTofu中能够直接运行是现实可行的。

未来的展望

基于OpenTofu项目目前的情况，我将提出个人对未来展望的见解。由于涉及多种猜测，请将其视为谣言级别的期望值进行阅读。

加入CNCF。

OpenTofu项目加入Linux Foundation旗下的目的，当然是为了主张正统性并得到权威认可，但真正的目的是与CNCF（Cloud Native Computing Foundation）站在一起。作为与容器技术和Kubernetes相关的生态系统，CNCF也是组织结构上属于Linux Foundation，主要的云服务提供商如AWS、Google和Microsoft都参与其中。目前，Terraform提供程序的许可证仍然采用MPL2进行开发，但这将持续多久尚不明确。由于Terraform的便利性依赖于丰富的提供程序生态系统，因此确保与云服务提供商之间的沟通渠道非常重要。

Terraform的许可证更改成为了云计算中的单点故障（SPOF），突然的许可证更改也是新供应链的风险。对于Linux Foundation来说，对于最近开源软件的脱离潮流，我们需要传达的信息是我们随时可以进行分叉。因此，两方的想法达成了一致。

尽管在撰写本文时，OpenTofu尚未正式加入CNCF，但我们观察到为什么明年2024年3月举办的KubeCon + CloudNativeCon Europe已经计划了OpenTofu Day活动，我认为这已经基本确定了。

在OSS项目中扩大招聘

HashiCorp的BSL实质上对竞争对手的商业利用进行了限制，对大多数普通用户没有直接的额外限制，大多数Terraform用户可能不会关注是否是OSS。另一方面，OSS项目对软件许可证非常敏感，也有一些项目采取了排除对非OSS依赖的策略。

例如，Homebrew正在讨论一个政策，即停止注册HashiCorp产品，并将依赖转移到OpenTofu上的Terraform。

在CNCF中，目前正在进行HashiCorp授权变更所产生影响的组件调查。

尽管用户可能并不直接需要，但OpenTofu的采用作为默认的组件将逐渐扩大。

进行库化

在OpenTofu的宣言中，列举了以下五个作为项目开发方针。

Backwards-compatible: so that the existing code can drive value for years to come

在这个内容中，关于“Layered and modular”一部分，我认为因为它与其他部分有些不同，所以可能需要补充一下背景信息。

Terraform自v0.15.4版起，几乎所有的Go包都被迁移到了internal/目录下，并且禁止从外部作为库进行导入。internal/目录名称不仅仅是一个约定，而是在Go编译器级别上禁止从外部进行导入。这导致许多以前通过导入Terraform内部实现并进行再利用的第三方工具，很难跟随最新版本的Terraform v1.x及以后版本的迭代。

一方，OpenTofu的开发团队最初是开发与Terraform相关的周边工具和服务的人员，因此对于将OpenTofu进行库化持积极态度。虽然我不认为他们会立即开始，但从长远来看，周边第三方工具的生态系统有望得到发展的土壤将会被创造出来。

OpenTofu的新功能

自从Terraform之前的许可证变更以来，近年来基本上不接受社区的设计级别变更，只接受修复错误等较小修补程序的整合。此外，设计文档是非公开的，实施仅以PullRequest的形式出现，因此很难从社区中引入较大的功能。由于Terraform不再是OSS，外部贡献的动力可能进一步降低。

在另一方面，OpenTofu采取了一种策略，即通过RFC的形式提出设计变更，从而使长期以来被Terraform搁置的问题被重新提起并在OpenTofu方面进行讨论。例如，关于tfstate的加密，在2016年就已经在Terraform中提出了，但至今仍未实施。

这个问题已经在OpenTofu方面再次进行了讨论，那些在Terraform中的PullRequest未被采纳的贡献者也向OpenTofu方面提交了PullRequest，OpenTofu的核心团队似乎对引入这个功能持积极态度。

同样地，关于Registry的设计，还有一个提议是将Provider和Module的保存位置设置为OCI Registry，这样可以将其保存在OCI Registry中。OCI Registry最初是为了标准化类似Docker Hub和GitHub Container Registry这样的容器映像存储位置而创建的，但现在它已经逐渐被用作通用文件存储位置，不仅限于容器，还可以用来存放应用程序库等。在保存私有的Provider和Module时，自己托管一个私有Terraform Registry会增加很多额外的负担，所以如果能够将其保存在类似GitHub Container Registry的OCI Registry中将会非常方便。

最近也在考虑是否可以使用Sigstore的无需密钥签名来替代当前使用GPG密钥进行Provider的签名。

由于Terraform是一个有相当历史的软件，因此不可否认它在设计方面存在一些陈旧之处。我认为这是一个用新视角审视技术栈的好机会。

在 OpenTofu v1.6.0 的稳定版本发布之前，我们决定不先加入新功能，大部分讨论都还处于待决状态，但在稳定版本发布后，讨论将积极展开。以上只是一个例子，这些功能是否被采纳尚未确定。我想表达的是，关键不在于这些功能是否被采纳，而是讨论参与者和决策者的不同，最终导致 OpenTofu 与 Terraform 具有不同的功能。

对于大多数普通用户来说，对许可证是否是纯粹的开源软件可能没有兴趣。毕竟，他们更关心的是自己想要的功能是在Terraform还是OpenTofu中？如果将工具选择因素化为差异化要素，那么新功能将被积极地纳入使用。

中国的OpenTofu项目正在与各大公司合作，合力推进开发，以克服Terraform许可变更所带来的困境。他们承诺将为未来五年投入18名全职工程师的开发资源，因此除非公司倒闭，否则很难停止开发。虽然Terraform核心团队只有大约5个人，从人数上来说，OpenTofu处于优势，但他们是否能以缺乏对现有代码的见解的人员击败对手，仍存在疑问。对于这一点，我在短期内持悲观态度，但在长期上则持乐观态度。我认为他们可能会在学习中不断失败，因为他们缺乏对既有代码基础的正确理解，可能会做出错误的设计决策。但随着贡献门槛的降低，即使有些不稳定，只要社区规模扩大，就可以通过人力来应对。与保守且完美的设计相比，如果能在90%的使用案例中良好运行，不断引入新功能并注重速度可能会加快进化，并赢得用户的支持。这种情况下，OpenTofu可能不再是Terraform的开源版本派生出来的，而是作为独立的基础设施即代码工具，放弃与Terraform的兼容性，走上另一条道路。

Terraform的新功能 (Terraform de

让我们对Terraform未来可能添加的功能做个快速了解。当前的主分支是v1.7.0-alpha，在这个版本中已经看到了将要合并进v1.7的改进，如terraform test命令的改善和removed块。其他要进入v1.7的功能现在还不清楚，但在2023年10月举行的HashiConf 2023中，已经提到了未来的路线图，其中包括自定义提供程序函数（专用于提供程序的内置函数）和堆栈（类似于Terragrunt，用于批量部署多个模块）等话题。

由于OpenTofu标榜自己是Terraform的替代品，因此其追加的功能是在Terraform之后添加的。虽然不清楚仅仅模仿外部的规范而不使用Terraform的源代码有多实际，但是使用fork的v1.6及以后版本的功能，最好将其视为与原功能相似，而不是完全相同。

保守的的人可以暂时保持在Terraform v1.5的范围内观察情况，不过我认为从Terraform v1.6或v1.7等版本开始，应该会准备好迁移到OpenTofu的路径，所以目前暂缓升级到Terraform的最新版本似乎并没有必要性。但是如果考虑将来进行迁移的话，应该谨慎依赖v1.6及以上的功能。

最后(一句话)

本文介绍了Terraform的开源版本分支OpenTofu。

虽然OpenTofu界内目前还有些混乱，但自从Terraform发布1.x版本后，它的稳定性和可靠性让人感到安心乏味。如果你不介意做一些试验，那么将OpenTofu作为选择之一也是一个不错的考虑。