Terraform 在许多人心中的地位，就像朋友和爱人，或是仇人。无论你的工作是维护整个组织的 Terraform 配置，还是偶尔需要编写一些配置，它永远都在那，等着毁了你的一天。对于那些喜欢它的人来说，你可能患有斯德哥尔摩综合症（译者注：指被害者对加害者产生好感、依赖，甚至协助加害者）。对于那些讨厌它的人，我理解你的痛苦。 以上话语并不是要贬低基础设施即代码，我的意思是，一定有更好的方式来做这件事。事实上，Terraform 通过将 IaC 带给大众，为行业做出了巨大的贡献。它确实占据了市场的主导地位，但这就像说 Van Halen 因为受欢迎才创作好音乐一样（抱歉跑题了）。Terraform 已经完成了它的使命，但现在是时候让它退休了。以下是原因以及你应该考虑的替代方法。 定制模式 每个 Terraform 配置和模块都有独特的结构，彼此各不相同。一个团队可能会使用符号链接和复杂的文件夹结构来管理跨环境变更（将在下文介绍），而另一个团队可能会选择将所有内容都放在一个文件中。变量、输出和版本可以选择是自己的文件、分散在多个文件中、或全部打包在同一个文件中。（虽然官方）提供了一些模式和惯例，但它们更像是简单的建议。模块是完全不同的另一概念，具有自己的特性。 支持多环境 我认为大家都知道，除了环境变量之外，管理相同配置的多个实例也有合法的用例。同样，也可以通过复杂的目录和分支结构来解决这个问题，但团队很少了解通过其环境管理升级和发布的模式。Terraform Enterprise 在某种程度上有所帮助，但仍常常让人感觉像是一个巨大的黑客程序，难以跟进。开箱即用的不便程度几乎让人觉得是故意为之。 漂移管理 我对支持漂移的 API 有疑问，可以说它根本不存在。跳转到状态文件（其中机密通常以纯文本形式存储）并手动修改结构或值，并不是一个可靠的安全解决方案。这背后有着巨大风险！人们对此讨论得还不够多。 解决漂移或状态不一致问题，通常需要花费一整天的时间来完成复杂的工作流程：从 Terraform 状态中删除资源，在环境中推广，从代码中删除引用，在每个环境中再次应用配置，将资源重新添加到代码中，并将配置再次应用于每个环境。计划和应用之间的期望不一致使这一切变得更加令人抓狂。 HCL HCL 是一种有趣的“语言”。它介于配置规范格式和编程语言之间。它是伪声明式的。你有一些形式的流程控制，但行为并不总是容易预测。你无法为悄然出现的复杂逻辑编写测试程序，甚至看不出复杂逻辑潜入。在生态系统中，支持开发的工具通常很差，诸如“validate”之类的命令只能检查基本语法问题。 将基础设施作为代码来读取和编写应该更容易— —它至关重要，影响范围广，而且一般更难回滚。考虑一下循环和索引的工作方式。这很复杂，而且你几乎没有方法验证其行为。维护代码库所面临挑战更加严峻，因为资源引用的资源名称通常会长达 100 个字符。这是由于名称需要包含资源类型，且需要唯一性和足够的描述性才能提供上下文。 随着时间推移，你可能想要重构代码。这可能是因为对如何构建模块更加熟悉，可能是Terraform 配置正在增长和演变，也可能是因为想让事情更加模块化。重构代码库有很多正当理由，如果曾经重构过大型 Terraform 配置，你就会知道这多么具有挑战性。 忽略非确定性 API 这与其说是说模块本身不好，不如说是框架不允许使用 API 的一致模式。当我使用 Terraform 模块时，除了无效的语法和 Terraform plan 问题之外，还有哪些方式会导致应用时失败？如果不了解应用失败模式，就很难进行尽职调查。 我并不是要求可以查看一些非确定性结果并预测会发生什么的魔法。我只想要模块提供的一致性和文档能够告诉我，在某些条件不满足的情况下可能发生的故障甚至灾难性后果。如果应用命令失败后的迭代周期不那么令人沮丧，也许这就不是问题了。 “云不可知论者” 这种好处充其量是夸大其词。无论你的云平台是什么，你都可以使用相同的 HCL 语言，甚至相同的 Terraform CI/CD 工具。说它是“云不可知论”就好比说 YAML、Python 或 Java 与云无关——它们确实能够在任何平台上运行。事实上，每个云平台提供商都有自己的特性和细微差别。 你仍然需要学习和了解每个平台提供商的所有这些细微差别，这还不够，通常还需要深入了解云平台，应对调试应用问题或配置错误等情况。 由于 Terraform 引入了一个伪装成不可知论的抽象层，因此你可能无法将 API 清晰地引入至基础架构更自然的思维方式。 协作和权限 这一部分与漂移管理和 HCL 等板块相关，但具体来说是围绕管理任务展开的。Terraform 常常让人感觉，它是一个具有老派守门人运营思维的 TF 沙皇管理而设计的。当然，作为运营团队的典型代表，TF 沙皇拥有极高的权限。执行 SDLC 或权限通常需要额外的工具或更复杂的存储库结构。在此之前，要进行缜密的思考和规划。 例如，考虑运行导入或导出命令。这不应该由从未执行过的开发人员完成。事实上，所有命令通常应该只通过 CI/CD 工具来执行，但是一般公司需要花费大量时间和投资，才能将 CI/CD 工具完善到只通过自动化的方式运行。因此，最终结果是，公司要么花费大量投资使这些管理命令成为自助服务，要么扩大其运营团队的规模，成为 Terraform 的“统治者”。 （管理）与协作息息相关。为了支持协作，你需要将代码构建为更小的基础设施堆栈。在同一 Terraform 配置下工作的人越多，由于变更和状态冲突而导致的协作难题就越多。你是否经常尝试推广变更，却发现其他人将测试（或生产！）环境置于半损坏状态，导致无法使用更新版本的 Terraform？ 拆分基础架构配置的一大弊端是，这往往会导致对来自其他配置中组件的各种硬编码引用四处传播。最终的结果是，虽然理论上可以重新部署到新环境，但在实践中，这可能是一项艰巨的任务，需要一遍又一遍地应用许多配置，直到保持一致。这很痛苦，因为所使用的工具通常不是为这种方式而设计的。 大多数组织都依赖 Terraform 作为其灾难恢复策略的核心组件。理论上，我们可以在几分钟内启动一个新环境，因为基础设施是声明式定义的。然而，实际情况是，庞大而复杂的配置往往需要数天时间才能完全应用和运行，尤其在很少有组织真正定期执行其灾难恢复计划时。 有一两个人管理一个堆栈时，Terraform 使用效果最佳。 许可纠纷和社区分裂 围绕开源产品建立可持续发展的业务极其困难。对于风险投资公司资助的初创公司来说，这尤其具有挑战性，因为它们筹集了数亿美元的资金，预期是“独角兽或破产”。首次公开募股（IPO）可能意味着投资者的大规模退出，但对于实际业务而言，实现盈利是一条漫长而艰难的道路。 HashiCorp 为进一步推进 IaC 并使我们走向更具声明化的基础设施管理模型做了很多工作。他们的工具之所以得到广泛采用，部分原因在于工具开源并允许其他公司围绕它进行构建、扩展和提供支持。很少有产品在社区支持方面取得像他们这样的成功。但现在，HashiCorp 发现自己正走在这条漫长而艰难的盈利之路上。 去年，HashiCorp 宣布其产品将从宽松的开源许可证转向更严格的商业源代码许可证。虽然他们完全有权这样做，而且这可能是实现投资者所期望财务业绩的必要条件，但这并不能改变这样一个事实：他们背弃了最初取得成功的初衷。在涉及大额资金危机之前，人们很容易对开源大加赞赏。 事实上，这一许可变更目前不会影响大多数 Terraform 用户，更多是针对围绕 Terraform 创建竞争产品的公司。尽管如此，它还是引发了一系列问题，让 Terraform 社区陷入激烈讨论中。目前尚不清楚会产生什么后果，但几乎可以肯定，这是 HashiCorp 转型为企业软件公司的初始阶段。它已经导致了 Terraform 社区分叉，即 OpenTofu，旨在成为 Terraform 的开源替代方案。分裂已经开始。 还有一件事…… 上面提到的许多问题与使用 Terraform 的组织如何实施和管理 Terraform 更密切相关。然而，大多数公司最初并不知道如何使用它，而且由于从一个项目复制到另一个项目，意外地在内部传播了不良模式。只有在使用一段时间后，适合特定组织及其工具的模式才会出现。此时，上述困难就会变得极具问题性和挑战性。而组织会因前期投入而难以修正问题，陷入僵局。 一个好的框架应该让人难以（或至少痛苦地）被错误使用。它不应该建立一道付费墙，以摆脱通过黑客手段来解决基本问题的用户需求，并且它应该在各公司之间具备良好的模式。它应该允许组织在以后重组或重构其基础设施，同时不会造成重大麻烦。 建议 不提供替代方案的抱怨只是抱怨——现在我可以称之为“行动号召”。一种流行的方法是 Kubernetes operator模式。每个主要的云提供商都提供 operator，让你可以像管理 Kubernetes 应用程序一样管理云基础设施。 这些 operator 使用控制循环定期协调你的资源，从而自动纠正偏差。资源是以 YAML 格式指定和配置的，它们能够以随着项目增长而扩展的方式使用资源引用。你可以使用专为支持更复杂需求和用例而设计的工具，也可以利用 Kubernetes 内置的 RBAC 控件来实现安全限制并实现合理的自助服务模型。你可以在整个组织内强制执行资源标准并为开发人员提供默认设置（而不是依赖于 Checkov 等策略扫描器）。 最后，在需要时，它还能让你在同一个项目中管理特定于服务的基础架构以及应用程序代码，而不必担心与其他服务共享资源时，需要重构或将资源定义移动到更高级别。它并不完美，但在使用这个模式之后，感觉整体上有了改进，并朝着正确方向迈进了一大步。 总结 总之，虽然 Terraform 在推广基础设施即代码和简化部署流程方面发挥了重要作用，但其缺点也日益明显。从定制模式到漂移管理问题，Terraform 带来的挑战阻碍了高效的基础设施管理和团队内部协作。此外，最近的许可变更和社区分裂也为其未来增加了不确定性。 然而，这种批评并非没有提出解决方案。Kubernetes operator 模式提供了一种引人注目的替代方案。通过利用 Kubernetes 的控制循环和 YAML 配置，这些 operator 可以简化基础架构管理、自动纠正偏差并改善协作。虽然采用这种方法本身也存在复杂性，但它代表着在解决 Terraform 的局限性和推进基础设施管理实践方面迈出了充满希望的一步。 归根结底，随着技术的发展和新解决方案的出现，组织必须严格评估其工具和方法，确保它们与企业目标保持一致。从 Terraform 过渡到 Kubernetes operator 模式可能为现代时代更高效、可扩展和弹性的基础设施管理提供一条途径。 作者丨Eric Larssen 编译丨onehunnit 来源丨blog.realkinetic.com/its-time-to-retire-terraform-30545fd5f186 *本文为dbaplus社群编译整理，如需转载请取得授权并标明出处！欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn