钟合

现阶段，云计算基础设施的自動化已成为企业的“必要措施”。快速的自动化过程是由市场上有效且有用的IT/云计算自动化工具的激增所带动的。但是，在选择工具时会遇到很多挑战，例如缺乏强大的计算功能、数据监视不一致、网络问题，以及故障排除等。

由于基础设施的多个方面需要与这些关键痛点一起管理，因此没有一种工具可以完成所有的工作。缺乏合适的工具将会增加停机时间，影响业务运营。根据PagerDuty公司发布的数字运营状况调查报告，40.4%的受访者称，就IT问题造成的损失而言，销售部门受到了极大的影响，这将直接影响企业的利润。

许多企业认为，在使用容器技术之前使用基础设施自动化技术，只是临时性的应对措施。标准化和自动化在IT行业中并非新的概念，但基础设施自动化如今却成为了热门的关键技术，这缘于容器、编排和其他现代化技术使基础设施自动化的功能得到了扩展。

Red Hat公司的首席技术官Gordon Haff表示，“企业的标准操作环境（SOE）和配置管理工具可以自动配置操作环境及监控。但为了完成特定的任务，仍然需要使用很多的服务器，即使配置管理软件试图保持合规性，部署的容器镜像仍会随时间的推移而转移。”

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

容器和编排

云原生的生态系统已经非常庞大，并且仍在持续增长的过程中。在这种背景下，基础设施自动化有两个主要方面值得关注，那就是容器和Kubernetes。

在运行多个容器或多个编排选项时，使用Kubernetes作为默认选项不失为一种好的选择，因为Kubernetes已成为容器编排的明确“领导者”，而容器编排则是现代基础设施自动化的重要组成部分。

不变的基础设施

以云计算为中心的技术为基础设施铺平了道路，这意味着一旦部署了基础设施，就不会在生产中遭受更改，而是根据需求将其替换为新版本。如果使用类似Kubernetes的工具，管理员就可以为自己的应用程序和基础结构声明所需的状态，然后编排平台以高度自动化的方式管理这些状态。

微服务架构

微服务架构本质上的意义是将应用程序分解为更小的离散组件，这些组件可以作为较大系统的一部分，同时协同系统工作。微服务架构可以使运营团队独立管理较小的服务，不必在每次更改时重新进入、部署整个应用程序。微服务与容器非常匹配，由于每个服务都可以独立地实现容器化。但值得注意的是，并非每个应用程序都适合微服务架构。

如果企业在起始阶段部署单一的应用程序组合，那便不要将基础设施自动化视为短期项目。反之，可以将其视为单一过程，尤其是当企业需要将现有应用程序分解为微服务时。

OpsRamp公司产品经理Michael Fisher说：“在通向‘不变的基础设施道路过程中，可能会花费许多时间，特别是在基于容器的应用程序扩散和普及前部署应用程序的企业。但尽管如此，却并不意味着架构规划和研发团队可以就此处于停滞状态，研发团队会将应用程序进行重新配置，使其可以独立的在微前端和后端上运行。企业的研发团队会迭代性地对服务进行优先级划分和容器化改进，直到整个应用程序完全转换。”

基础设施自动化的创新方法取决于云平台和工具的相应转变。Michael Fisher将这种转变阶段视为一种创新过程。Michael Fisher说：“这一过程不仅仅是技术的创新，还需要人们对容器化内容的理解，以及对应用程序的核心服务和构建块的熟悉。”

容器化的发展有许多途径，特别是当企业将一个或多个应用程序重构为微服务时。Fisher说：“实现应用程序重构的最好方法之一，是了解终端用户在用户界面（UI）、用户体验（UX）中最常访问的位置，然后向下移动。这种方法被称为“微前端”，一旦企业了解实现容器化需求，就可以利用大量的工具可以帮助其横向扩展运行服务的基础设施。”

持续集成、交付，构建管道、工件

如果企业已经将适配的工作负载容器化，并使用商业Kubernetes平台。那么对于不变的基础设施，则需要停止使用服务器等传统术语，即使其在技术上仍具有相关性。

反之，企业则需要考虑构建管道及工件问题，这是企业自动部署、停用，或用“不变的基础设施”替换该内容。持续集成（CI）、持续交付（CD），已经成为关键的实践工具，构建管道及工件阶段是持续集成、持续交付管道的基础。

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

从本质上来说，持续集成、持续交付管道是容器化应用程序从代码到存储库、生产的过程，这一过程无需花费太多人力。Snow Software公司首席设施师Jesse Stockall表示，管理容器化应用程序和不可变基础设施重要方法，都说明了容器和编排如何防止在标准操作环境（SOE）中仍然可能发生的转移。

Stockall说：“容器映像应该基于可信任的基本容器，构建可重复的、自动化的管道，该管道使用私有映像存储库作为构建输出。在企业需要更多控制权时，基本镜像也可以复制到私有注册表中，并阻止对公共注册表的访问。构建系统还应该实时检测是否有新版本的基础映像可用，以便及时的审查、更改、更新映像配置。”持续集成、持续交付管道的关键要素还包括测试和验证/合规性。Stockall说：“企业的容器注册表应该对其已知的易受攻击的软件执行扫描操作，并阻止外部上传的不良镜像，同时，还应该使用对映像配置和部署清单的静态分析，来检测常见的错误配置。”

云原生工具

单一的工具和流程不一定能让企业在基础设施自动化方面达到其预期的效果。这一现状与网络安全性相似，如果企业使用与十年前的外围防火墙和终结点防病毒软件，并且从未进行更新，则很难达到其目的。

无独有偶，基础设施也是如此。现今，越来越多的企业使用混合云，这项技术既可以解决云原生的开发问题，又可以解决诸多私有云和内部部署基础设施工作负载的适配问题。并且有大量成熟的工具可以帮助企业进行管理。

Haff说：“由于在Kubernetes已经成为容器编排的标准时，人们又发明出专门针对‘容器化世界设计的自动化工具，故而这一技术革新导致了企业对基础设施自动化布局的重新思考。”

在云计算时代，从构建到安全再到部署，一个项目或平台依赖于另一个项目或平台，特别是当其开源的时候。这给基础设施自动化带来了“滚雪球”效应。Haff说：“许多企业正在考虑在其持续集成、持续交付领域的项目使用Kubernetes原生开发模式和流程来构建和部署管道。这其中包括Tekton管道以及专门针对部署自动化的较新项目。”