如何实现基础设施自动化

有些人认为在使用容器之前，基础设施自动化只是一个临时应对措施。但是如今，IT部门可以实现这一目标。

标准化和自动化在IT行业中并不是什么新概念。那么，为什么基础设施自动化如今成为一个热门话题?

其答案是：容器、编排和其他现代化技术已使基础设施自动化功能得到了扩展，除了提供其他好处之外，这些功能还使标准化得以实施。

Red Hat公司的首席技术官Gordon Haff解释说，“有人可能说在使用容器之前，基础设施及其自动化的标准化是一项临时的措施。当然组织拥有的标准操作环境(SOE)和配置管理工具，可以自动配置这些标准操作环境(SOE)及其持续监控。但是，完成特定任务仍然需要很多服务器，即使配置管理软件试图使它们保持合规性，部署的容器映象仍会随时间推移而转移。”

他指出，在长期追求有效的基础设施自动化的过程中，容器化和编排为这一旅程注入了新的活力。

现代基础设施自动化的三个基础知识

以下介绍了现代基础设施自动化的三个基础知识，这些基础知识主要针对仍在快速掌握使用云原生技术实现基础设施自动化新方法背后的概念(适用于混合云或多云场景)的IT领导者和团队，并提供了一些入门建议。

(1)关键概念：容器和编排

尽管云原生生态系统已经非常庞大(并且仍在增长)，但是在这种情况下谈论基础设施自动化时，有两个主要方面值得关注：容器和Kubernetes。有多个容器运行时和多个编排选项，但对于后者，将使用Kubernetes作为默认选择，因为它已成为容器编排的明确领导者，而容器编排是现代基础设施自动化的重要组成部分。

• 不变的基础设施

这些以云计算为中心的技术为Haff先前提到的不变的基础设施铺平了道路。这意味着一旦部署了基础设施，就不会在生产中对其进行更改，而是根据需要将其替换为新版本。并且可以使用Kubernetes之类的工具自动启动(或关闭)这一功能，这样管理员就可以为自己的应用程序和基础结构声明所需的状态，然后编排平台以高度自动化的方式管理这些状态。

• 微服务架构

这里的另一个关键概念是微服务架构，它本质上意味着将应用程序分解为更小的离散组件，这些组件可以作为较大系统的一部分协同工作。除了获得其他好处之外，微服务使团队可以独立管理那些较小的服务，而不必在每次更改时都必须重新进入(并重新部署)整个应用程序。微服务与容器非常匹配，因为每个服务都可以独立地实现容器化。应该注意的是，并不是每个应用程序都非常适合微服务架构，但这无关紧要。

有些人提出一些建议：如果组织是从单一的应用程序组合开始的，则不要将基础设施自动化视为短期项目。与其相反，可以将其视为逐个过程，尤其是当组织要将现有应用程序分解为微服务时。

OpsRamp公司产品经理Michael Fisher说，“通向不变的基础设施的道路可能会花费一些时间，特别是对于那些拥有比基于容器的应用程序的扩散和普及更早的应用程序的组织来说。但是，这并不意味着架构规划和开发处于停滞状态，直到将应用程序配置为可以在独立的微前端和后端上运行。组织的团队应该迭代地对服务进行优先级划分和容器化，直到整个应用程序完成转换为止。”

基础设施自动化的现代方法取决于向云平台和工具的相应转变。但是并不是一蹴而就的事情。

Fisher表示，他将这个阶段视为一个创新过程，而不仅仅将其视为技术过程：人们要理解容器化的内容，就需了解应用程序的核心服务和构建块。

对于容器化的正确路径有许多观点，特别是当组织将一个应用程序(或多个应用程序)重构为微服务时。

Fisher说：“实现这一点的最好方法之一是了解终端用户在用户界面(UI)/用户体验(UX)中最常访问的位置，然后向下移动。这种方法通常被称为‘微前端’，一旦了解了什么需要实现容器化，就有大量的工具可以帮助组织横向扩展运行服务的基础设施，而Kubernetes是最流行的工具。”

(2)关键概念：持续集成(CI)/ 持续交付(CD)、构建管道和构建工件

即使组织已经开始将合适的工作负载实现容器化并学习Kubernetes或使用商业Kubernetes平台，仍然有很多工作要做。

对于不变的基础设施，需要停止使用服务器等传统术语，即使它们在技术上仍然相关。与其相反，组织需要开始考虑构建管道以及另一方面的问题：构建工件。这是组织自动部署、停用和/或用不变的基础设施替换的内容。

持续集成(CI)/ 持续交付(CD)已经成为这方面的关键实践和工具。构建阶段实质上是强大的持续集成(CI)/ 持续交付(CD)管道的基础。

一般来说，管道概念是考虑基础设施自动化的一种有用方法：一旦部署到位，组织代码以及正确运行所需的一切都应贯穿管道的每个阶段(从构建到测试再到安全再到部署)，只有在组织指定的步骤中，或者当某些内容不符合标准时，才会有人积极参与。

从本质上来说，持续集成(CI)/ 持续交付(CD)管道是容器化应用程序如何从代码到存储库或生产的过程，而无需花费太多人力。

Snow Software公司首席设施师Jesse Stockall解释了管理容器化应用程序和不可变基础设施的一些重要方法。这些方法都说明了容器和编排如何防止即使在标准操作环境(SOE)中仍然可能存在的转移。

Stockall说：“容器映像应该使用可重复的、自动化的构建管道从可信的基本容器构建，该管道使用私有映像存储库作为构建输出。为了获得更多控制，基本映像也可以复制到私有注册表，并阻止对公共注册表的访问。构建系统还应该检测何时有较新版本的基础映像可用，以便可以审查更改并更新映像配置。”

持续集成(CI)/ 持续交付(CD)管道的其他关键要素包括测试和验证/合规性。如果做得好，安全性对于每个阶段都是不可或缺的。

Stockall说：“组织的容器注册表应该对已知的易受攻击的软件执行扫描，并阻止不良图像被上传。应该使用对映像配置和部署清单的静态分析来检测常见的错误配置和遗漏，例如基本映像的版本丢失或部署的资源限制。”

(3)关键概念：云原生工具

虽然有些原则保持不变，但单一的工具和流程不一定能让组织在基础设施自动化方面达到其想要的目的。

这有点像安全性：如果组织使用与十年前运行的相同的外围防火墙和终结点防病毒软件，并且根本没有更新，那么只能顺其自然。

基础设施也是如此。如今越来越多的组织使用混合云，既可以解决云原生开发问题，又可以解决许多更适合私有云和内部部署基础设施的工作负载。并且有大量成熟的工具可以帮助组织管理这一切。

Haff说：“这一巨变导致了对基础设施自动化的重新思考。Kubernetes已经成为容器编排的标准。这反过来又产生了专门为容器化世界设计的各种自动化工具。”

“生态系统”这个术语在科技界往往使用得很宽松。但是，在云计算时代，从构建到安全再到部署，一个项目或平台依赖于另一个项目或平台，特别是当它们是开源的时候。这给基础设施自动化带来了“滚雪球”效应。

Haff说：“持续集成(CI)/ 持续交付(CD)领域的项目正在考虑使用Kubernetes原生开发模式和流程来构建和部署管道。这其中包括Tekton管道以及专门针对部署自动化的较新项目，例如Argo CD和Keptn。组织还会采用许多新的安全工具(例如Aqua和Snyk)，它们针对这种相对较新的基础设施进行了优化。”