为什么基础架构即代码对您的业务很重要

什么是基础设施即代码？
基础架构即代码 (IaC) 支持使用高级描述性代码语言自动配置和取消配置 IT 基础架构。它使组织能够更快地构建、部署和扩展云应用程序，同时降低安全风险和成本。从而消除了每次创建新软件或代码时对开发人员手动配置和管理服务器、数据库连接、操作系统、存储和其他基础设施元素的依赖。

2022 年全球云配置工具的使用情况，当前和计划。  
为什么我们需要基础设施即代码？
通过对代码进行最后阶段的一系列测试，将其部署到生产环境中，始终保持一致的一件事是基础设施配置。最佳实践是说我们的测试环境和开发环境必须模仿生产环境以避免配置漂移。 

让我们通过一个例子来理解它。假设我们正在云上构建一个应用程序，比如说公共云。在这个特定场景中，我正在考虑我的应用程序是基于 Kubernetes 构建的。因此，它是一个 Kubernetes 应用程序堆栈。为此，让我们以一个承载遗留应用程序的 VM 为例。现在要连接所有这些，我们需要一个 VPC（虚拟私有云）。现在我们已经建立了一个基本的基础设施。 

基础设施

期待测试应用，我们都知道Test环境一定要模仿Dev环境。 

测试环境必须模仿开发环境。

这一点至关重要，因为无论应用程序设计得多么好；如果环境不同，它会破裂。在构建过程中，我们的目标是记录基础设施的各个方面，但您多久看到一次勤奋工作？并非总是记录每次临时进行的更改。 

想象一下，您正在向应用程序添加一个新部分，以使客户体验无缝。为了实现这一点，我们在我们的防火墙和专有协议的服务器上打开一个通信端口，并在此过程中创建一个更改票。而且你没有记录它。在审计时，这个开放的端口最终会被质疑其性质和背后的原因。从表面上看，这似乎不是一个大问题。但是，如果您仔细查看，您需要推理安全团队在跟踪开放端口的来源上所花费的所有时间。如果这件小事被记录在案，您不仅可以为不必要的麻烦节省时间，还可以确保没有任何事情被忽视。以及不必要的时间浪费。

 为了解决这个问题，我们将基础设施即代码引入图片中。基本上有两种方法可以实现这一点

命令式方法
声明式方法
命令式方法
也称为程序方法。

在此，我们深入研究细节，逐步定义以开发特定状态的基础设施。现在，开发人员本能地选择了这种方法。原因是它可以控制定义每个基础设施元素的状态和其他方面。 

命令式方法

优势：
借助云工具的强大功能，定义变得更加高度可定制。 
使管理人员更容易理解与所开发代码有关的每一寸细节。
这使他们能够利用已经开发并已到位的配置脚本。
缺点：
构建它所涉及的定制水平和特殊性使得破坏它或扩展它有点困难。基本上，开发人员必须再次为每个部分创建自定义脚本以进行拆卸或放大。 
在创建和创建后更改/修改的意义上，这都是耗时的。
如果命令式脚本运行多次，我们最终会拥有多个环境。假设它在任何一步都失败了；我们必须创建自定义脚本才能完全拆除。 
声明式方法
也称为功能方法。

这成为大多数技术团队最喜欢的选项，因为它只涉及定义基础设施的最终状态，其余部分由Terraform等 IaC 工具处理。一些流行的选择配置管理工具是Puppet、Chef等。 

这些工具可以通过对配置进行必要的更改来启动 VM 或容器并安装和管理不同的资源。 

声明式方法

在这种方法中，我们定义了所有基础设施元素的资源。参考我们上面的示例，我们将定义 Kubernetes 资源、VM 资源和 VPC 资源。 

优点：
无论脚本运行多少次，每一个结果都将与我们定义的完全相同。 
进一步简化的是，它们是通过简单的配置映射进行管理的。这实质上意味着我们可以进行更改、添加或自定义更改，例如定义主机、子域等。
像一键拆解这样的原则更容易。这使我们能够在不需要自定义脚本的情况下扩展基础设施。
缺点：
这种方法的主要缺点是它需要熟练管理员的专业知识。他们通常专注于他们喜欢的解决方案。

理解命令式和声明式方法之间差异的示例
这类似于通过 GPS 查找路线或遵循转弯指示。对于 GPS，您可以提供最终目的地的详细信息，它会自动为您绘制出流量较低的最短路线。同时，根据个人经验创建转弯指令。要了解 GPS 为何采用某条路线，我们需要专家的知识。要了解逐向说明，您需要提供给您的人或参考文档中提供的说明。在这里，GPS 是声明式方法的象征，而转弯方向是命令式方法。

基础设施即代码在 DevOps 中的优势
更快的上市时间
在云上手动构建基础架构既耗时又容易出错。 
对其进行完全编码可确保 IT 基础架构的自动配置和取消配置。它还使扩展变得更容易。 
更少的配置漂移
通过版本控制系统，每一个更改和每一个细节都会被记录下来。
它使镜像开发环境、测试环境和生产环境变得更加容易。
减少客户流失
如果不通过工具完成，他们会被委派给一些熟练的工程师。
在这种情况下，如果他们离开了组织，重新创建所有内容将成为一项乏味的任务。 
将基础架构视为代码并自动化使组织能够保留供应智能。 
提高投资回报率
通过 IaC 工具，我们可以利用云计算的力量，让我们拥有基于消费的成本结构。

可重用性
通过对每个文档进行编码，自动化配置遗留基础设施变得非常方便。这将需要我们经历一个耗时的过程，比如拉票。

基础设施即代码的最佳实践
更喜欢不可变的基础设施方法而不是可变的基础设施方法
自动化基础架构时要考虑的一个重要方面是在不可变基础架构或可变基础架构之间进行选择。

什么是可变基础设施？
按照“可变”这个词的字面意思是可变的。因此，在这里我们可以对最初配置的基础设施进行更改/修改。这种级别的灵活性表面上看起来不错，但实际上考虑到它可能会让你不这么认为。为什么？ 

它破坏了 IaC 保持跨环境一致性的关键特性。
使基础设施版本跟踪变得更加困难。
可变基础设施

什么是不可变基础设施？
与可变基础设施完全相反。无法更改或修改最初配置的基础架构。如果您想实施更改，您必须构建一个全新的基础架构并替换它。这可能听起来既耗时又麻烦，但事实并非如此。在云工具（尤其是 IaC 工具）的帮助下，构建新环境变得更加容易和快捷。与可变基础架构相比，此选项更加可行和安全。 

团队喜欢它的原因：

它可以防止跨各种环境的配置漂移。 
它使回滚到任何以前的版本变得更加容易。
不可变的基础设施

基础设施的版本控制
根据上述更容易回滚的观点，我们需要一个版本控制系统来 

存储每个 IaC 文件的数据。这有助于跟踪所有更改，从而进一步帮助团队成员处理最新版本。这类似于开发人员在应用程序源代码中记录细节的方式。除此之外，将来可以参考它来了解当前基础架构版本的演变。

遵循模块化 IAC 规则
完全可以在一个 IaC 文件中定义基础设施的所有资源或方面。定义要安装的操作系统类型、要配置的用户帐户类别、要安装的应用程序、需要应用的网络策略等。 

仅仅因为它可以做到，它不是一个有效的方法。如果我们分解这些细节并将它们定义在单独的文件或模块中，生活会变得更简单！团队可以轻松地对特定元素执行自定义更改，而不是无处不在。 

为了更好地理解，假设有两台服务器需要安装相似的操作系统，但用户帐户不同。在这个用例中，不同的模块可以派上用场来实现自定义更改。

将 IaC 视为应用程序代码
归根结底，IaC 是一种代码，本质上意味着我们可以应用持续集成、测试和部署的规则。我们可以说我们正在进入 DevOps 周期。确保代码无错误，因为 IaC 文件中的错误可能会花费我们一大笔钱。 

因此，IaC 扫描可以合并到 CI/CD 管道中，从而确保 

合规监管；
代码中不存在数据库密码或秘密凭据。
秘密管理至关重要 
要配置某些资源，IaC 工具确实需要访问敏感信息，例如密码、加密密钥等。在 IaC 定义中包含机密可能看起来是最简单的方法，但这是您将做的最危险的事情。如果有人设法访问 IaC 文件，他们就可以读取这些敏感数据。 

考虑到安全性，我们需要使用秘密管理器。我们在一些 IaC 工具（如 Chef-vault of Chef）中内置了秘密管理。将 AWS Secret Manager 等第三方管理器与 IaC 工具结合使用也是一个明智的选择。因此，可以在需要时访问机密信息并防止被泄露。 

将基础架构的生命周期管理为代码
基础设施即代码符合 DevOps 方法；否则，我们可以将其表述为“赋予 DevOps 权力”。它能够以更低的成本和更高的安全性实现更快的部署。在整个实施过程中，我们需要出色的可观察性和监控。一个小错误可能导致重大责任。 

当我们能够以与处理应用程序代码相同的质量来对待基础设施时，可以引入大量更改，同时记录每一点。如果使用 CI/CD 管道构建，代码会经过自动化持续测试，如全面 CI 扫描、单元测试等。随着软件开发通过管道进行，不同的团队成员可以集成自定义更新，这通常是变化的情况客户要求。这再次经过测试并与源代码集成，从而产生更新的、无错误的 IaC 版本。 

包起来
基础设施即代码为我们的产品发布周期注入了效率和敏捷性。如果不引入 IaC，就无法想象数字化转型的敏捷实践。
快速、轻松地跟踪基础设施更改以及与 CI/CD 管道的轻松集成对于构建可扩展的基础设施至关重要。通过采用企业范围的自动化方法，我们不仅管理 IT 流程，还管理整个系统、团队和组织。