Crossplane vs Terraform

Crossplane经常被比作HashiCorp的Terraform。对于企业平台团队来说，当Terraform满足不了需求并寻找替代方案时，他们通常会找到Crossplane，所以这两个开源项目之间存在着相似之处：

• 两者都允许工程师将其基础设施建模为声明式配置
• 两者都支持使用“提供者”插件管理大量不同的基础设施
• 两者都是具有强大社区的开源工具

关键的区别在于Crossplane是一个控制平面，而Terraform是一个命令行工具——一个控制平面的界面。这篇文章触及了一些企业在扩展Terraform时通常会遇到的痛点，并强调了Crossplane是如何解决这些问题的。

协作

企业通常通过他们的运营团队采用Terraform。对于一个小的工程师团队来说，这是开始讨论他们组织的基础设施的好方法。将基础设施表示为声明式配置可以让运营团队从软件工程最佳实践中受益——将配置保持在修订控制中，在必要时可以对更改进行同行评审和恢复。

当更多的工程师需要合作来管理他们组织的基础设施时，Terraform可能会崩溃。Terraform依赖于一个单体的状态文件来将所需的配置映射到实际运行的基础设施。在应用配置时，必须持有此状态文件上的锁，而应用Terraform配置是一个阻塞过程，可能需要几分钟才能完成。在此期间，任何其他实体——任何工程师——都不能对配置进行更改。类似地，Terraform使用一个单体的“apply”过程——没有推荐的方法只修改配置中的一个基础设施。如果你使用相同的配置来管理你的缓存和数据库，你必须始终更新两者——你不能只更新你的缓存。

Terraform建议将一个整体配置分解为越来越多的颗粒配置。因此，虽然运营团队可能从代表“production”的Terraform配置开始，但他们被鼓励将其分解为“production billing”和“production auth”等范围配置。很难在一开始就做到这一点，因此随着时间的推移，它需要大量的重构，并经常导致复杂的地形配置网格，它们的输入和输出耦合在一起。

协作在Crossplane能够扩展，因为XRM（Crossplane Resource Model）促进松耦合和最终的一致性。在Crossplane中，基础设施的每个部分都是支持创建、读取、更新和删除操作的API端点。Crossplane不需要计算依赖关系图来进行更改，因此即使使用Crossplane管理整个生产环境，也可以轻松地操作单个数据库。

自助服务

现代组织正从基础设施的集中管理演变为自助服务模型，在这种模型中，运营团队（通常称为平台团队）定义了其支持的开发团队可以按需使用的自认为的基础设施抽象。Terraform通过使用模块来支持这个模型。模块与软件库没有什么不同。像Crossplane一样，Terraform资源是外部API资源的高保真表示。模块在这些资源的更广泛配置之上提供了一个简化的抽象——例如，RDS模块将8个不同的Terraform资源抽象为一个单一的“RDS实例”概念。

将应用程序团队视为Terraform配置“库”的消费者意味着他们受制于Terraform的协作约束。应用程序开发人员被邀请在他们组织的基础设施上进行协作，就像他们是一个关注范围更窄的运营团队一样。平台团队邀请应用程序开发团队共享他们的工作流程，而不是为他们提供服务。这意味着应用程序团队必须学习一种新的、特殊用途的工具集和语言——Terraform和HashiCorp配置语言（HCL）。它还提高了应用程序开发人员的配置抽象级别，而不提高访问控制抽象级别。尽管平台团队可以发布一个模块，允许应用程序团队管理“RDS实例”，但访问控制仍然停留在云提供商API级别，因此围绕“数据库子网组”和“数据库参数组”进行框架设置。

Terraform模块的Crossplane同等特性是一个XR（Composite Resource）。每个XR作为API端点暴露。平台团队可以定义和记录每个XR（每个API）的OpenAPI模式，并在API级别执行基于角色的访问控制（RBAC）。这意味着，如果平台团队决定将提供给开发团队的抽象框架定义为“AcmeCo PostgreSQL数据库”，则他们可以授予RBAC访问权限以创建、读取、更新或删除AcmeCo PostgreSQL数据库，而不必管理各种基础云概念的访问权限，例如RDS实例或子网组。因为Crossplane构建在久经考验的Kubernetes RBAC系统上，所以平台团队可以在一个控制平面内轻松地支持多个应用程序开发团队。每个团队只能被授予对他们需要的抽象的访问权——一些团队可能只能管理存储桶，而另一些团队可能被允许管理缓存和数据库。

自助服务在Crossplane上扩展得更远，因为任何一个XR都可以提供多个服务类别。Crossplane将XR的输入和输出（Kubernetes术语中XR的规格和状态）从由组合（Composition）描述的实现中解耦出来。如果一个应用开发人员被授予了创建AcmeCo PostgreSQL数据库的权限，他们可以很容易地从任何服务类中选择——任何组合——他们的平台团队已经声明与该数据库兼容。这些服务类别可以表示生产、登台和开发；AWS、Azure和GCP；快和慢；或任意组合。

集成和自动化

Terraform调用有很多API，但它没有提供自己的API。这导致许多团队通过将Terraform配置提交到版本控制（git），并将Terraform作为CI/CD流水线的一部分执行来实现自动化。相对于在笔记本电脑上运行Terraform的团队来说，这是一个进步，但它暴露了组织在尝试扩大Terraform使用时面临的一个关键问题。Terraform是一个命令行工具-不是一个控制平面。因为它是一个短暂的、一次性的过程，所以它只会在被调用时尝试使你想要的配置与实际的基础设施相编排。无论是在CI/CD流水线上运行还是在笔记本电脑上运行，通常只有在工程师认为基础设施需要更新时才会调用。

Terraform保守的、“按需”的方法来编排理想的与实际基础设施状态，这可能会导致一种新颖的僵局。回想一下，应用Terraform配置的过程是一个要么全有要么全无的过程——如果你在相同的配置中描述了缓存和数据库，则必须始终更新两者以更新其中任何一个。这意味着，如果你组织中的任何一个人绕过了Terraform，那么下一个触发Terraform运行的人将面临一个令人惊讶的计划，当它试图撤销更改。例如，考虑这样一个场景，一位工程师在半夜收到寻呼机信息需要处理一个事件，通过AWS控制台对生产缓存配置进行一些快速编辑，然后忘记在Terraform中反映这些更改。基础设施的漂移如此之大，以致于应用Terraform配置成为一个危险的、令人生畏的提议，这并非闻所未闻。

另一方面，Crossplane是由一系列长期存在的、始终处于运行状态的控制循环组成的。它不断地观察和纠正组织的基础设施，以匹配其所需的配置，不管是否期望更改。这抑制了团队规避Crossplane的积极性。当要求Crossplane管理一个基础设施时，任何在它之外进行的更改都将自动且持久地恢复。

在组织面对Terraform的痛点中，一个持续的主题是它没有提供API。与Terraform集成具有挑战性，因为它使用领域特定语言（DSL） HCL进行配置，并通过命令行工具进行调用。Crossplane暴露了一个REST API——自动化的通用语言。无论团队主要编写shell脚本、Python还是Erlang，都将存在用于与REST API集成的通用模式和库，从而与Crossplane集成。

Crossplane不暴露任何旧的REST API。在Kubernetes API上构建意味着团队可以使用kubectl这样的工具来编排他们所有的基础设施——云或其他。他们使用同样的工具来编排他们的容器化应用程序。Crossplane甚至可以暴露应用程序连接到基础设施所需的细节，作为Kubernetes的秘密，以简化集成。它可以与ArgoCD、Gatekeeper或Velero等项目配对，以启用GitOps、高级策略和备份。需要定制的自动化？利用许多文档化良好的框架之一来构建与Crossplane集成的Kubernetes操作器。

为什么不两个一起用呢?

Crossplane和Terraform都可以编排组织的基础设施。两者之间有相似之处，但是每个项目采用不同的编排方式。Terraform为控制平面API提供了一个命令行界面，而Crossplane本身就是一个控制平面，可以用来在其他控制平面上构建抽象。因为Crossplane能够让平台团队提供自己的控制平面，所以它能够避免平台团队在扩展Terraform时所面临的许多挑战。

精明的读者可能会注意到，这两个项目可以相互补充——Terraform是一个控制平面的接口，它的Kubernetes提供商允许编排Kubernetes控制平面！这意味着可以将Terraform与Crossplane结合起来，例如，如果你的组织更喜欢HCL而不是YAML，那么你的平台团队可以使用Terraform来定义XR和组合，而你的应用程序团队可以使用Terraform来计划并应用对Crossplane的期望状态的更改！

我们认为对于平台团队来说，Crossplane是一种很好的方式，可以让他们支持的开发人员自助服务他们的基础设施需求。如果你想尝试一下Crossplane，请查看我们的入门指南[1]，如果你对Crossplane有任何问题或反馈，请在Slack联系我们[2]。