基础设施即代码：一场变革即将到来

admin

自软件行业形成至今，已有几十年光景，几乎每隔一段时间就会出现一些重大事件，我们可以将其称为范式转变。在这种不断的转变过程中，软件开发对基础设施管理提出了日益严苛的要求：产品要能跟上市场需求，基础设施的响应速度必须提高；持续交付和DevOps的盛行，要求产品团队需对部署和运维有更高的自主性；技术的不断迭代使基础设施的配置愈发频繁且烦琐……随着以上问题不断加剧，便逐渐衍生出了基础设施即代码这一概念，即在确保基础设施安全可靠的同时，也要具备灵活管理的特点。

基于Thoughtworks公司云实践领导人Kief Morris在《基础设施即代码》一书中对基础设施即代码的定义：“基础设施即代码是一种使用新的技术来构建和管理动态基础设施的方式。它把基础设施、工具和服务以及对基础设施的管理本身作为一个软件系统，采纳软件工程实践以结构化、安全的方式来管理系统变更”，我们可将其理解为一种基于软件开发实践的基础设施自动化方法，主要强调系统及其配置的日常置备和变更具有一致性和可重复性，允许开发人员使用任意语言描述的配置管理虚拟化基础设施和辅助服务，同时这些配置文件通常托管在源代码库中。

基础设施提供渠道的演变
基础设施即代码发展至今，从概念到落地，从小众到普及，每一次推进都与软件行业的变化分不开。

虚拟化
在虚拟化早期阶段，开发人员需要根据需求文档，经历漫长的瀑布式开发周期才能生产出软件。期间，运维团队需要搭建服务器、提供基础设施组件、安装所有软件并完成配置等工作。然而，在这一时期，开发和运维这两个团队的工作通常没有联系，交流主要通过任务单和往返邮件，非常不便利（见图1）。

图1 虚拟化早期阶段，开发和运维团队的工作方式
敏捷与开发运维的开端
后来，我们经历了敏捷运动，随之而来的就是开发运维文化。如今，开发人员在给运维团队发送应用程序时，还会送上一份配置手册，甚至更先进的团队还会合作开发自动化工具（见图2）。在基础设施自动化工具的早期，Chef和Puppet等工具非常流行。这种方式无疑是巨大的进步，但这往往会建立非常孤立的环境，责任也很分散。

图2 敏捷与开发运维文化时期，开发和运维团队的工作方式
公共云与容器编排
随着公共云的普及和自动化越来越强大，这一切才逐渐步入正轨。大多数运维团队都会选择Terraform，与几年前的情况相比，这是一个巨大的进步，基础设施的数量也呈指数增长。

整体而言，这种方式在很长一段时间里都近乎完美，唯在两个方面还有所缺失：

开发和运维团队的经验稍显不足。精心创建的基础设施一旦出现问题，就需要耗费大量的人工和维护成本。

开发人员必须学习新语言，努力将运维工具整合到工作流程中。社区成员聚集在一起，提出创造性的解决方案、检测问题并提高系统自动化和可观察性等。单独来看，他们提出的所有这些工具和项目都很优秀，可惜并没有形成标准。

那么该如何改进呢？要如何再一次实现飞跃，构建出更伟大、更优秀的产品？答：处于云原生时代下，自然要利用容器化和容器编排，以此实现狭义的打包（容器映像）与运行时（Kubernetes Pod）的标准化。为便于理解，本文将以Crossplane为例，说明基础设施即代码变革中缺失的一环该如何补齐。

补齐基础设施即代码变革中的缺失
开源云原生控制平面项目Crossplane在2021年9月由CNCF技术监督委员会（TOC）投票决定将其提升为CNCF的孵化项目，是Upbound在2018年开发的混合云环境下通用控制平面项目，于2020年7月成为CNCF沙箱项目。Crossplane用于跨环境、集群、区域和云来管理云原生应用程序和基础设施，其强大之处在于，它采用了云原生开放标准和最流行的工具，方便开发人员（应用程序团队）和运维人员（平台团队）展开协同工作，同时又无须相互依赖（见图3）。

图3 利用Crossplane之后，开发和运维团队的工作方式
在我看来，Crossplane具备以下特点：

其一，建立在Kubernetes之上，而Kubernetes的真正力量在于其强大的API模型和控制平面逻辑（控制循环），因此Crossplane通过Kubernetes的控制平面将应用程序团队和平台团队串到了一起，可实现无缝协作，这是最大的优点。

其二，实现了从基础设施即代码到基础设施即数据的转变。这两者之间的区别在于，基础设施即代码需要编写代码来描述应用程序的配置，而基础设施即数据则可以编写纯数据文件（Kubernetes的YAML），并提交给控制组件（Kubernetes的操作器）进行封装和执行配置逻辑。

图4为Crossplane的组件模型及其基本交互。
图4 Crossplane组件模型及其基本交互
要想补齐基础设施即代码变革中缺失的一环，Crossplane的组合功能尤为合适：使用Crossplane的组合功能有助于将基础设施的复杂性抽象出来，转移给平台团队，从而减轻开发人员的负担。具体实操如下。

首先，需要AWS，并在本地机器上配置CLI（注：如果想要了解部署组件以及Kubernetes资源模型，需要具备AWS的基本知识）。本地需安装VS Code以及远程容器插件devcontainer，如果使用Windows系统，则还需要WSL2（具体安装设置可参照Crossplane官网说明）。

安装工作完成后，可部署一个RDS实例——一种由AWS托管的Kubernetes资源，类似于Pod、服务和副本集等，可通过Octant或命令行工具查看部署的进度。随后，再部署EKS集群，需要创建很多组件，如VPC、子网、IAM角色、节点池、路由表、网关等。这一过程可能有些麻烦，不是理想的开发者体验，但正所谓“磨刀不误砍柴工”。

除却创建必要组件这一步不可省略，开发者在部署EKS集群时的其他工作都极大减轻了。

无须全面掌握庞大且复杂的EKS整体架构，仅需了解其中部分组成（见图5），将复杂易错的工作交给专门从事Kubernetes和云提供商的平台团队管理。

图5 开发人员需了解的部分EKS架构
在相关准备工作完成后，部署EKS集群变得非常简单，仅需一条命令：kubectl create -f ./aws（若成功部署，可见图6状态）。

图6 EKS集群的部署状态
结语
总体看来，之所以我认为Crossplane能弥补基础设施即代码变革中的缺失，不仅在于它融入了开发运维文化，促进了应用程序团队与平台团队之间的松散耦合协作，其资源模型、打包、配置都经过了深思熟虑，更是因为它还有一些特别的优势：

可组合的基础设施

自助服务

提高自动化程度

标准化协作

通用语言（Kubernetes API）

因为这些优势，充分发挥了云计算的潜力，得以将基础配置中的复杂性转移到了专业的平台团队，将开发和运维人员从较易出错的任务中解放出来。同时，通过与Kubernetes的紧密集成，Crossplane也进一步推动了云原生时代下基础设施即代码的变革，使基础设施即代码的概念提升到了一个新的水平。