什么是基础设施即代码（IaC）？

基础设施即代码（IaC） 是一种将底层 IT 基础设施通过代码形式进行管理和配置的 IT 实践。它使开发人员和运维团队能够自动管理、监控和供应资源，从而替代了手动配置硬件设备、操作系统、应用程序和服务的方式。IaC 也被称为可编程或软件定义的基础设施。

IaC 的概念类似于编程脚本，后者用于自动化 IT 流程。然而，脚本主要用于在多个服务器上重复执行一系列静态步骤。IaC 则使用更高级的描述性语言来编码更通用、适应性更强的供应和部署流程。

例如，IT 管理和配置工具 Ansible 包含的 IaC 功能可以安装 MySQL 服务器、验证其是否正常运行、创建用户帐户和密码、设置新数据库以及删除不需要的数据库。

这种基于代码的基础设施自动化过程类似于软件设计实践，应用开发团队在其中编写声明性代码、控制代码版本、测试迭代，并在软件获准用于生产之前限制其部署。

IaC 也追求与云计算相同的目标，即抽象化 IT 资源，但它自动化了整个流程——从供应和配置到部署和管理。IaC 也用于供应和管理云基础设施，利用云提供商的应用程序编程接口（API）来访问和交互其资源与服务。

基础设施即代码如何工作？

简而言之，IaC 使用软件代码来供应和管理 IT 基础设施。通过使用代码定义所需的 IT 结果，组织可以提高基础设施的一致性、安全性、自动化程度和性能。

手动供应和配置服务器、存储、网络、操作系统、应用程序以及其他设备和服务（如数据库、负载均衡器和防火墙）需要投入大量时间和精力。人类可能需要数小时甚至数天才能为企业工作负载和数据提供合适的部署环境。这种手动操作容易在许多方面出现人为错误，导致以下问题：

• 结果不一致，每个环境都不同。
• 设置和配置错误导致安全漏洞。
• 基础设施文档缺失或记录不全导致故障排除困难。
• 安全和故障排除问题引发的合规性和业务持续性风险。
• 管理和变更控制困难。

IaC 将构建和部署所需 IT 环境的所有指令都具体化为一个软件实体。开发人员和 IT 人员可以创建详细的指令来评估所需步骤并衡量代码的结果。

基础设施代码可以产生可重复的结果，并且可以通过按钮触发或在特定条件下执行。它为供应和管理带来了高度的自动化。

变更管理变得更加容易，因为对基础设施代码的任何修改都会产生一个新的版本，这个版本有完善的文档记录，并且可以通过任何标准的版本控制系统进行管理。如果变更导致问题，可以通过运行先前已知良好的代码版本来纠正。这简化了故障排除，并改善了企业的合规性和安全性。

通常结合使用以下四种基本类型的 IaC：

• 脚本： 通常用于自动执行简单的临时任务。
• 配置管理代码： 定义并自动化设备（如服务器）的安装和配置。
• 供应代码： 自动化设置整体基础设施，将环境中的各个方面连接起来。
• 容器代码： 依赖模板来定义包含部署和执行应用程序所需的库和依赖项的镜像文件。

IaC 过程通常涉及以下三个步骤：

1. 开发人员使用领域特定语言为所需的基础设施创建规范。
2. 将规范文件发送或暂存到服务器或仓库（如 GitHub）或 API。
3. IaC 平台使用规范文件（自动或按需）创建和配置预期的基础设施。

IaC 方法：声明式与命令式

基础设施即代码工具采用声明式和命令式方法运行。

声明式方法 声明式编程方法概述了基础设施所需的预期状态，但并未明确列出达到该状态的步骤。它声明一个预期目标，并允许底层 IaC 工具决定如何实现这些目标。一种广为人知的声明式编程语言是结构化查询语言（SQL）。Amazon Web Services (AWS) 的 CloudFormation 模板等就是以声明式风格编写的基础设施即代码。

命令式方法 命令式编程方法定义了使基础设施达到期望状态的命令。它定义了实现预期结果的精确步骤及其顺序，并且不偏离这些步骤。面向对象的语言，如 C++ 和 Java，可用于命令式编程。像 Chef 这样的工具既可以按声明式使用，也可以根据需要按命令式使用。

在这两种方法中，IaC 都在模板上进行配置，用户在模板中指定基础设施中每个服务器所需的资源。模板用于验证系统是否正确配置或是否已正确设置。模板可以构建为一组资源层，例如在 AWS CloudFormation 中构建堆栈。

IaC 最佳实践

IaC 涉及具有高度自动化的基础设施配置和管理。虽然没有统一的 IaC 部署和使用方法，但许多最佳实践有助于简化这些部署。标准 IaC 最佳实践包括：

• 使用版本控制。 通过软件供应和配置基础设施意味着 IaC 遵循许多软件开发最佳实践，例如严格的版本控制。组织应为 IaC 文件使用仓库、全面的版本控制以及严格的文档和记录，以跟踪谁访问了文件以及版本之间发生了哪些更改。
• 不要共享密钥。 IaC 涉及的许多配置元素都需要密码或加密证书。这些内容通常未经保护就包含在 IaC 文件中，可能会暴露敏感系统并危及安全。应使用单独的密钥管理器以受保护的方式存储身份和访问管理详细信息。
• 确保文件安全。 IaC 旨在与其他 DevOps 和敏捷软件设计一样，秉持协作精神。然而，IaC 文件很可能包含知识产权、密钥或其他敏感内容。务必确保它们与业务使用的其他源代码一样安全。
• 测试和验证文件。 IaC 文件绝不应被想当然。它们应在发布到生产环境之前，以与其他软件相同的方式进行测试和验证。这通常涉及使用持续集成/持续交付、DevOps 和敏捷技术。
• 使用较小的文件。 可以使用几个较小的 IaC 文件来执行特定任务，然后通过脚本或另一个 IaC 模板将它们连接起来。使用数量较多的小文件可以实现更好的模块化，并促进 IaC 文件的重用，而不是创建和维护一个庞大的通用文件来处理所有事情。
• 监控和纠正漂移。 当正确实施并严格关注不可变性时，IaC 理想情况下不应允许配置漂移。然而，由于系统问题、故障排除和人为错误，漂移仍可能发生。必须监控基础设施环境，将环境与 IaC 定义进行比较以发现漂移实例，并记录和纠正任何此类实例。
• 将代码作为单一事实来源。 IaC 应作为基础设施配置的参考点。将 IaC 代码视为单一事实来源应有助于确保环境之间的一致性，最大限度地减少依赖关系，并减少可能手动发生的错误。
• 关注不可变基础设施。 软件定义了基础设施。使用 IaC 时，应采用不可变基础设施方法。一旦代码被供应和部署，就不应对基础设施进行更改。如果需要更改，应删除当前的基础设施，并使用新版本的 IaC 文件部署新的基础设施。这样可以防止任何配置漂移的可能性。

不可变与可变基础设施

可变基础设施 指的是在生产环境中更改组件，而整体服务或应用程序正常运行。不可变基础设施 则组装并设置组件和资源以创建完整的服务或应用程序。如果任何组件需要更改，不会直接修改或重新配置它；而是更新所有组件并有效地重新部署一个实例。一个新的迭代被组装、测试、验证和启动，而旧的迭代被停用，其资源被释放以供重用。

不可变基础设施已获得青睐，特别是在云和微服务环境中，这些环境高度可扩展，并且涉及许多相互依赖的组件和服务。为解决特定问题而进行的任何一次性更新都可能导致配置漂移，并在更新被迅速推送到生产环境时产生级联效应。重新发布一组不可变的服务和组件比修补和重新配置单个基础设施组件更高效。IaC 强调使用不可变基础设施技术，尽管不可变性并非 IaC 的先决条件。

基础设施即代码的优势与挑战

IaC 具有许多优势，从自动化效率到其与现代 IT 实践相结合的灵活性。其他 IaC 优势包括：

• 速度和效率。 自动化的供应和管理比手动流程更快、更高效。这延伸到供应的资源、虚拟化、数据库、网络、用户帐户管理以及其他关联服务。IaC 还可以包含根据需求自动扩展或在不必要时关闭环境和资源的代码。
• 一致性。 软件开发人员可以使用代码根据业务实践和政策来供应和部署服务器及应用程序——而不是依赖 DevOps 环境中的系统管理员。在运维接手进行生产环境的实时部署之前，开发人员可能会创建一个配置文件来供应和部署新的应用程序以进行质量保证或实验性部署。
• 可追溯性。 代码和相应的仓库管理为 IaC 代码文档化提供了坚实的基础。很容易看到诸如谁开发了每个版本以及 IaC 代码版本之间发生了哪些更改等因素。这加强了业务合规性和代码质量标准。
• 投资回报。 实施 IaC 需要大量投资，但在速度、效率、一致性、合规性、故障排除和自动化方面的回报通常是值得的。IaC 将一个可能需要数小时的手动流程替换为一个可以以分钟计时的自动化流程。它消除了与手动基础设施供应和配置相关的许多问题。
• 与 DevOps 理念契合。 作为代码编写的基础设施设置可以经历与开发人员用于应用程序代码相同的版本控制、自动化测试和 CI/CD 流水线的其他步骤。组织可以将 IaC 与容器相结合，容器在操作系统级别将应用程序与基础设施抽象分离。由于操作系统和硬件基础设施是自动供应的，并且应用程序被封装，这些技术被证明在针对不同部署目标（如测试、暂存和生产环境）时是互补的。
• 资源共享。 IaC 改进了跨使用相同资源的其他系统复制基础设施的能力。在这种用途中，IaC 提供了一致性，并有助于简化故障排除过程。

尽管有这些好处，IaC 也带来了一些缺点，包括：

• 需要额外工具。 基础设施即代码需要额外的 IaC 特定或支持 IaC 的工具，例如配置管理工具以及自动化和编排系统，这可能会引入学习曲线和错误。错误可能会通过服务器迅速扩散，特别是在广泛自动化的情况下，因此监控版本控制和执行全面的发布前测试至关重要。
• 功能缺失。 IaC 工具提供了各种强大的功能和能力，但其中一些可能不完整或缺失。评估和审查工具非常重要，尤其是要对照业务需求，并仔细监督每个工具提供商的产品或功能路线图。
• 现有工具复杂性。 在 DevOps 和运维环境中引入新工具、流程和标准可能会给已普遍存在工具和平台的领域增加复杂性。企业范围内的支持对于 IaC 为企业提供持久且有意义的好处至关重要。
• 潜在的配置漂移。 如果管理员在设定的 IaC 模板之外更改服务器配置，在没有额外变更管理工具的情况下，可能会发生配置漂移。将 IaC 完全集成到系统管理、IT 运维和 DevOps 实践中，并配有完善记录的政策和程序非常重要。如果遗留的安全和监控工具无法处理 IaC，这将需要投资于更多工具，并进行额外的培训和测试以将其集成到工作流程中。
• 能力差距。 IaC 要求开发人员承担更多责任，以理解如何编写能够无缝转化为生产环境的高效代码。他们还必须深入了解用于 IaC 的语言，包括 JSON、YAML、Ruby、C++ 和 SQL。经验丰富的人员可能更难找到和留住。

基础设施即代码工具

IaC 工具用于配置和自动化基础设施供应。这些自动化工具可以自动执行基础设施部署，例如具有编排功能的服务器。它们还可以配置和监控先前供应的系统。

IaC 工具使用推送或拉取方法来强制实施模板中的设置。在推送方法中，中央服务器将所需的配置发送到一个或多个特定系统。拉取方法是由基础设施中的一个或多个系统向中央服务器发起请求。工具通常在默认情况下设计用于推送或拉取代码部署，但它们可以针对特定实例设置为相反的方式。这些工具还应能够在更新的意外问题发生时回滚代码更改。

以下是 IaC 工具的示例：

• AWS CloudFormation。
• Chef。
• Google Cloud Deployment Manager。
• Microsoft Azure Resource Manager。
• Puppet。
• Red Hat Ansible Automation Platform。
• HashiCorp 的 Terraform。
• VMware Tanzu Salt。

有些工具依赖于领域特定语言，而其他工具则使用标准模板格式，例如 JSON 和 YAML。

组织应考虑目标部署环境并为该环境选择工具。例如，AWS CloudFormation 专为在 AWS 上供应和管理基础设施而设计，并与其他 AWS 产品配合使用。同样，Microsoft Azure Resource Manager 管理 Azure 平台上的基础设施，而 Google Cloud Deployment Manager 是 Google 的基础设施部署服务。另外，Chef 可与本地服务器和多个云提供商的基础设施即服务产品配合使用。

IT 运维可以超越 IaC，采用基于代码的方法来管理其所有资源。