什么是基础架构即代码？

简单来说，“基础架构即代码”(IaC) 是使用代码在描述性模型而不是手动流程中管理和供应基础架构 (网络，虚拟机，负载均衡器，集群，服务和连接拓扑)。

通过 IaC, 配置文件定义了您的基础架构，这也使得编辑、共享和重用配置变得更加容易。通过对基础结构进行编码，您可以在每次避免未记录的临时配置更改时都供应相同的环境。

Schematics 利用开放式源代码 Ansible 和 Terraform 提供一组功能强大的 IaC 工具即服务，用于对云基础架构进行编程。通过 Schematics，您可以使用此丰富的 IaC 自动化功能集来构建云资源堆栈，管理其生命周期，管理其配置中的更改，部署应用程序工作负载以及执行 day-2 操作。

基础架构即代码的优势

采用 IaC 方法进行基础架构部署可解决供应基础架构的许多常见问题，并提供多种优势。Schematics 使您能够实现这些优点，而无需安装，运行和管理您自己的 IaC 工具。

可靠性和一致性: 以可靠方式供应新环境或基础结构。手动流程会导致错误。使用 IaC 时，会反复部署相同的配置，而不会产生任何差异。 IaC 可提高环境和部署之间的一致性。
速度: IaC 使您能够通过自动化快速设置完整的基础架构。您可以将其应用于每个环境，从开发到生产，登台，QA 等。随着部署，管理和维护环境的时间缩短，这可能会导致成本降低。
跟踪和责任: 在代码中对现有基础架构进行更改，并跟踪这些更改。与任何源代码文件一样，您具有对配置所作的更改的完全可跟踪性。
检测并更正环境漂移: 如果在代码外部手动修改了基础结构的一部分，那么可以使其在下次运行时与期望的状态保持一致。漂移检测是 Schematics 工作空间的功能部件。

最佳实践

采用 IaC 进行供应和配置管理时，有许多建议的实践。使用 Schematics时，完全支持这些实践。

在 IaC 中编纂所有内容

所有基础结构规范都应该在配置文件中显式编码，例如，作为 Terraform 配置或 Ansible 运行手册。配置文件是基础架构规范的单一事实来源，并描述在其配置中使用了哪些基础架构组件?

最小化文档

IaC 是文档。在 IaC 就绪的情况下，配置文件表示文档，并且始终是最新的，这将减少工作量。其余文档是关于该过程的。在版本控制系统中维护代码。

IaC 配置文件应保留在版本控制系统 (VCS) 中，例如 GitHub 或 GitLab。这提供了代码更改的审计跟踪，但也使您有机会在代码更改生效之前进行协作或同级复审并测试更改。

通过此实践，您可以通过增强的可跟踪性和可视性，轻松跟踪，管理和还原对系统的任何潜在更改。

测试

IaC 从软件开发中借用的实践之一是测试。对基础架构配置进行严格测试有助于减少部署后问题。与版本控制系统相结合时，每次在代码中有修改时都可以自动触发测试。

通过实施持续集成 (CI)，可以在多个环境 (例如 development，UAT，QA 或 production 环境) 中实施模板基础结构配置，并有效应用最少的更改。

模块化基础架构

将基础结构分解为模块允许复用，提高可靠性和更轻松的采用路径。类似于在编程语言中使用模块和包。以下是这一做法的好处。

经常使用的配置可以编码为模块，并在环境中多次重复使用。
随着使用时间的推移，随着模块的测试和硬化，可靠性会提高。
来自可复用模块的组合降低了采用 IaC 的技能障碍。
更易于在模块级别进行更改和测试。
随着配置更改的本地化，更改的风险会降低。

IaC 的声明式方法与命令式方法

采用 IaC, 需要考虑的一个方面是您的工具采用什么方法。有两种不同的风格，声明性或势在必行，有时也被描述为程序性。

声明式方法定义系统的期望状态，包括您需要的资源以及它们应该具有的任何属性，以及工具为您配置的属性。工具本身确定从任何起点进入期望状态的操作。

命令式方法改为定义实现所需配置所需的特定命令，然后需要以正确的顺序执行这些命令。

厨师被认为是一个势在必行的工具。 Terraform 被归为声明式。 Ansible 是声明式的，但也可以与命令一起使用。

声明式 Terraform 和生命周期管理

Schematics 支持 Terraform 和 Ansible 作为具有 Schematics 工作空间和操作的 IaC 工具。当生命周期管理对于定期启动和拆除环境非常重要时，建议将 Terraform 与 Schematics 工作空间配合使用。 Terraform 会保留已部署的云基础结构的当前状态的记录，并且 Schematics 能够以反向依赖关系顺序除去基础结构，而无需手动干预。

`Idempotence`

由 Terraform 和 Ansible 使用的声明式方法的优点是 idempotence。可以使用相同的最终结果多次执行幂等任务。无论故障后重新启动时的先前状态或启动位置如何，供应的基础结构和配置始终相同。此方面是确保使用 Schematics部署的环境的一致性和可重复性的关键。

如何使用工具以及使用的模块都对 idempotency 有影响。通常，Terraform 和 Ansible 模块编写为幂等。通过这两种工具，我们可以编写不会产生幂等结果的代码。在这种情况下，配置可能会从期望的目标状态漂移。使用 Terraform 时，当 null-resources 用于通过非幂等定制脚本扩展提供程序功能时，这种形式的漂移很有可能。

不可变性是一种 IaC 实践，可将从目标状态漂移的风险降至最低。

不可变

不可改变的基础架构是指管理服务和软件部署，在这些服务和软件部署中，资源 (例如容器或虚拟机) 将被替换而不是更改 (使用脚本)。这里对不可变性的主要渴望是避免配置漂移。由于本地或手动更改或自动化操作序列的差异而产生的不一致。这些更改使调试和解决问题变得更加困难，并增加支持成本。

为确保不可变性和消除漂移，应通过 Schematics IaC 配置进行所有更改，并且应在需要更新时重新部署 VSI 之类的资源。

后续步骤

现在，您对 IaC, 不如回顾一下 IaC 在 Schematics 中的使用：

了解有关 Schematics 的更多信息
浏览以下用例。