基础设施代码化（IaC）的自动化配置与编排

云上运维，那就是和云上资源和产品打交道，无疑会涉及到一系列的资源部署。比如简单地使用一台云服务器，就需要运维人员依次创建 VPC、VSwitch、安全组和云服务器实例，如果想创建一个集群，那还要进一步创建负载均衡、数据库和多个云服务器实例。

随着业务规模的不断扩大，IT 系统和环境日益复杂，人工一个一个创建资源的方式显然不可取，许多人正在转向自动化资源部署和配置的工具。

本文将基于基础设施即代码 IaC 理念，分享如何借助自动化编排工具实现自动化部署，使得云上运维工作更为高效。

手动/半手动云上运维的五大痛点

对于云上资源的部署，如果你的云上运维还处于手动或是半手动运维阶段，那么大部分工作是通过控制台选择特定资源规格参数进行创建，还有一部分是使用 CLI（如 aliyun-cli）或者 SDK 直接调用接口来创建资源。但随着企业的云上业务规模不断扩大，不论是哪种方式，或多或少都会遇到下述五个问题：

部署效率低。手动创建对于创建少量种类的资源来说倒是种很直观的方式，但一旦涉及到大量不同资源时，尤其是资源之间还有依赖关系，这时候会发现需要在不同的产品控制台之间来回切换，还要时刻关注创建进度，才能再去创建下一个依赖它的资源，整个过程所耗费的时间和精力可想而知，相信不少人有深有体会。

可复制性差。当手动创建好了一系列的资源后，如果需要针对不同的环境（如预发、测试和生产）或不同的地域（如北京和上海）创建完全相同的资源，则又需要花费很多时间一步步地进行操作，无法直接复制、做到一键部署。

一致性差。手动创建还有一个非常大的问题，那就是非常容易出现配置错误，很难保证两套环境中各个资源配置是完全相同的。

管理困难。资源的创建只是开始，可能还需要针对这批资源做扩缩容、更新特定资源的规格等操作。但手动运维的方式就导致没有统一管理这批资源的入口，仍需要分别到各产品控制台上操作。随着资源数越来越多，资源管理就愈发难以维护。

难以 DevOps。每次开发、测试或部署软件应用程序时都可能需要手动部署基础设施，既无法对基础设施进行版本控制，也无法对其变动进行评审，更无法做到敏捷部署。

其实，我们都知道这些问题的背后是因为资源的部署还未做到自动化。但这些问题也不断促使着我们思考应该通过什么样的方式来解决这些痛点，才能让整个资源部署过程自动化。

引入基础设施即代码 IaC 理念，实现云上资源自动化部署

在真正做到自动化部署之前，不妨回头看看所需要创建的云服务资源（如 VPC、VSwitch、ECS 实例等），它们相对于Web服务等应用程序来说都是云上的基础设施，如果把这些基础设施想象成一段“代码”，在“代码”中定义产品、规格、数量等信息，那么是不是就可以通过这段“代码”来管理整个基础设施了呢？

这就是基础设施即代码（Infrastructure as Code, IaC）的理念，将基础设施配置视为软件编程。Kief Morris 在《Infarftruce as Code》一书中对基础设施即代码是这么定义的：

“基础设施即代码是一种使用新的技术来构建和管理动态基础设施的方式。它把基础设施、工具和服务以及对基础设施的管理本身作为一个软件系统，采纳软件工程实践以结构化的安全的方式来管理对系统的变更。”

引入 IaC 的理念，运维人员可以将基础设施的部署和管理过程变得敏捷：

在模板（宽泛意义上的代码）中定义基础设施，即各类云资源及其规格、数量等属性、云资源之间的依赖；

使用版本控制（如 Git）管理模板，并提交评审；

通过评审后由自动化部署工具使用模板来创建/更新基础设施。

基础设施的部署和管理变得便捷后，上述提到的手动运维/半手动运维的痛点问题就能得到很好的解决：

提升部署效率。使用自动化部署工具进行部署，相对于人工部署的效率将大大提升。

标准化和一致性。将基础设施的内容通过模板的形式保存，对基础设施的变更由对模板的变更来实现，实现了基础设施管理的标准化。此外，使用相同的模板在不同地域部署，也能够保证资源的一致性。

易于管理。对基础设施的管理不再分散于各个产品控制台，而统一到单个模板，使得管理成本大大降低。

敏捷化工作流程。通过基础设施管理流程的规范化和标准化，资源部署的整个过程就变得敏捷。

审计和回滚。对模板进行版本管理，使得对基础设施变动的审计和回退到某个特定版本成为了可能。

文章来源：《电力系统自动化》 网址: http://www.dlxtzdhzz.cn/zonghexinwen/2021/0305/773.html