Terraform 对许多人来说就像一个朋友、亲人，甚至可能是敌人一样存在。无论是你的工作是维护整个组织的 Terraform 配置，还是偶尔需要写一些配置，它总是在那里，随时准备让你的一天变得糟糕。那些喜欢它的人可能患上了斯德哥尔摩综合征。那些讨厌它的人，我能感同身受。

现在，我并不是要贬低基础设施即代码。我只是说，必须有更好的方法来做这件事。实际上，Terraform 为行业做出了巨大的贡献，将 IaC 带给了大众。它确实占据了市场的大部分份额，但这就像说 Van Halen 因为很受欢迎所以他们的音乐很好一样（对不起，跑题了）。Terraform 已经完成了它的使命，是时候退役了。以下是一些原因，以及你应该考虑的另一种方法。

每个 Terraform 配置和模块都有自己独特的结构，并且彼此不同。一个团队可能会使用符号链接和复杂的文件夹结构来创建一种管理跨环境变更推广的方法（我们接下来会讲到这一点），而另一个团队可能会选择将所有内容放在一个文件中。变量、输出和版本可以选择各自独立为文件，也可以分散在多个文件中，或者全部放在同一个文件中。有一些模式和约定，但更像是轻柔的建议。模块则是一个完全不同的领域，有自己的独特之处。

我认为我们都可以同意，管理同一配置的不同变体（不仅仅是环境变量）确实有正当的使用场景。虽然可以通过复杂的目录和分支结构来解决这个问题，但很少有团队能够理解如何通过这些环境来管理升级和发布。Terraform Enterprise 在某种程度上有所帮助，但它仍然常常感觉像是一个巨大的补丁，并且跟随其操作可能会非常混乱。开箱即用的不便程度几乎让人感觉是故意为之。

我在支持漂移（drift）的API方面遇到了问题，也就是说，目前没有任何支持。进入状态文件后，发现密钥通常以明文形式存储，手动修改结构或值并不是一个安全的做法。这存在巨大的风险！这个问题并没有得到足够的重视。解决漂移或状态不一致的问题通常需要花费你一整天的时间来处理复杂的流程：从Terraform状态中移除资源，将其推广到各个环境，从代码中移除对该资源的引用，然后在每个环境中重新应用配置，将资源重新添加到代码中，再在每个环境中重新应用配置。计划（plan）和应用（apply）之间的期望不一致使得这一切变得更加复杂。

HCL 是一种有趣的“语言”。它介于配置规范格式和编程语言之间。它是伪声明式的。你有一些形式的流程控制，但并不总是容易预测行为。你不能为渗入的复杂逻辑编写测试，甚至可能没有意识到复杂逻辑已经渗入。生态系统中通常缺乏支持开发的工具。诸如“验证”之类的命令仅检查基本的语法问题，而没有更多功能。

它应该更容易阅读和编写基础设施即代码——这非常重要，影响范围广，且通常更难回滚。考虑循环和索引的工作方式。它很复杂，你几乎没有办法验证其行为。由于资源引用通常会包含长达100个字符的资源名称（因为名称需要包含资源类型，以确保其唯一且具有描述性，以便提供上下文），因此维护代码库的难度进一步加大。

随着时间的推移，你可能希望重构你的代码。这可能是因为你学到了更多关于如何构建模块的知识。也可能是因为你的 Terraform 配置正在增长和演变。还可能是因为你希望使代码更加模块化。重构代码库有很多正当的理由，如果你曾经重构过一个大型的 Terraform 配置，你就会知道这有多么具有挑战性。

这并不是因为模块本身不好，而是框架没有允许一致的模式来消费API。我的意思是，当我使用Terraform模块时，除了无效的语法和terraform计划问题之外，还有哪些方式可能仅在应用时失败？由于不了解应用失败模式，很难做到尽职调查。我不是在要求某种神奇的解决方案，可以预测一些非确定性结果会发生什么。我只是希望模块能够提供一致性和文档，告诉我如果某些条件不满足，可能发生的潜在失败——甚至是灾难性的失败。如果失败应用命令的迭代周期不那么令人沮丧，也许这不会成为一个问题。

最好的情况下，这种好处也被夸大了。无论你的云平台是什么，你都使用相同的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宣布它将从宽松的开源许可证转向更严格的商业源代码许可证。虽然他们有权这样做，而且这可能是为了满足投资者期望的财务结果所必需的，但这并不改变这样一个事实：这违背了他们最初成功的基础。在有大量资金在争夺之前，谈论开源是多么美好很容易。

事实上，这次许可变更目前对大多数Terraform用户没有影响。它更多地针对的是围绕Terraform创建竞争产品的公司。然而，这开启了一个问题，这已经让Terraform社区陷入了一片混乱。尚不清楚会有哪些后果，但几乎可以肯定的是，这是HashiCorp转型为企业软件公司的开始阶段。这已经导致了一个社区分叉版本的Terraform，即OpenTofu，旨在成为一个开源替代品。碎片化已经开始。

上述许多问题与组织如何实施和管理Terraform密切相关。然而，大多数公司在最初并不知道如何使用它，因此在项目之间复制错误模式，导致内部模式的泛滥。只有在运行一段时间后，适合特定组织及其工具的模式才会出现。这时，上述一些问题变得非常棘手和具有挑战性，导致组织陷入对Terraform的承诺。一个好的框架应该让错误使用变得困难（或至少痛苦）。它不应该需要付费才能消除解决根本性挑战的黑客手段，而且它应该拥有可以在公司之间共享的良好模式。它应该允许组织在以后重构或重构其基础设施而不引起重大头痛。

没有提供替代方案的抱怨只是抱怨——现在我可以称之为“行动呼吁”了。一种正在流行的方法是 Kubernetes 操作符模式。每个主要的云提供商都提供了操作符，允许你以管理 Kubernetes 应用程序相同的方式来管理你的云基础设施：GCP Config Connector，AWS Controllers for Kubernetes (ACK)，和 Azure Service Operator。许多基础设施供应商也纷纷效仿，例如 Mongo Atlas，Confluent Kafka，和 Elastic。

我们一直在使用Config Connector，感到非常满意。事实上，我们经常对基础设施的整体稳定性和可调试性印象深刻。如果你有现有的模板和部署Kubernetes YAML文件的模式，管理你的基础设施将类似于管理你的其他服务部署。我们在名为Konfig的企业级GitLab和GCP集成中广泛使用Config Connector。

这些操作器使用控制循环定期同步你的资源，自动纠正漂移。资源通过 YAML 文件指定和配置，并且能够以可扩展的方式使用资源引用，随着项目规模的增长而扩展。你能够访问设计用于支持更复杂需求和用例的工具。你能够利用 Kubernetes 内置的 RBAC 控制来实现安全限制和启用合理的自助服务模型。你能够强制执行资源标准，并在整个组织中为开发人员提供默认设置（而不是依赖于像 Checkov 这样的策略扫描工具）。最后，在需要时，它允许你在同一个项目中管理特定服务的基础设施和应用程序代码，无需担心重构或在需要与其他服务共享时将资源定义提升到更高层次。这并不是完美的，但在使用这种模式后，感觉整体上有所改进，并朝着正确的方向迈出了一大步。

总之，虽然 Terraform 在推广基础设施即代码和简化部署流程方面发挥了重要作用，但其缺点也越来越明显。从定制模式到漂移管理问题，Terraform 呈现出的挑战阻碍了高效的基础设施管理和团队协作。此外，最近的许可变更和社区分裂也为其未来增添了不确定性。

然而，这种批评并非没有提出解决方案。由 GCP Config Connector、AWS Controllers for Kubernetes (ACK) 和 Azure Service Operator 等产品所体现的 Kubernetes 操作符模式提供了一个有说服力的替代方案。通过利用 Kubernetes 的控制循环和 YAML 配置，这些操作符简化了基础设施管理，自动化了漂移校正，并改善了协作。虽然这种方法也有其自身的复杂性，但采用这种模式代表了在解决 Terraform 的局限性并推进基础设施管理实践方面的一个有希望的步骤。

最终，随着技术的发展和新解决方案的出现，组织必须批判性地评估其工具和方法，以确保它们仍然符合其目标和目标。从 Terraform 转向 Kubernetes 操作员模式可能为在现代时代实现更高效、可扩展和有弹性的基础设施管理提供一条途径。如果您需要帮助从 Terraform 迁移，我们可以提供帮助。