什么是基础设施即代码 (IaC)？

IaC 将基础设施视为软件。团队使用 IaC 对基础设施进行版本控制、测试和部署，采用与应用程序代码相同的做法。

这种方法使团队能够绕过传统的手动配置，这可能很麻烦且容易出错。手动配置通常涉及单独的服务器设置、基于控制台的管理和未记录的更改。

相反，团队会在配置文件中定义基础设施需求，这些文件会指定所需的资源（如服务器、网络、数据库、安全策略）以及如何对它们进行配置。这些文件随后存储在版本控制系统中，提供跟踪、评论和回滚功能。

IaC 是基础设施自动化更广泛实践的重要组成部分，它使用代码和自动化来管理整个生命周期的 IT 基础设施。有了 IaC，开发人员不再需要在每次开发、测试或部署应用程序时手动预配置基础设施组件。这种自动化有助于组织控制成本、降低风险并快速响应新的商机。

随着组织采用云原生架构，IaC 变得越来越重要。IT 环境现在跨越多个云、数千个容器和分布式微服务。曾经管理几台服务器的手动流程无法处理这些架构，在这些架构中，团队每天频繁部署数百个应用程序，并不断地配置、扩展和退役基础设施。

IaC 通过三种重要方式帮助管理这些复杂环境：

• 大规模运营：跨多个环境配置和维护数千台服务器、容器和云资源。
  
  
• 缩短部署周期：即时扩展基础设施以满足需求，无需耗时的手动配置。
  
  
• 确保一致性：消除可能导致安全漏洞、合规违规和服务中断的人为错误和配置偏差。

例如，一家零售公司正在为黑色星期五做准备，可能需要在数小时内扩展 100-1,000 台服务器。借助 IaC，这种扩展可以根据预定义的模板在本地部署和云中自动进行。这种扩展能力有助于确保每台新服务器保持相同的安全性和合规性配置。

根据 IBM 商业价值研究院的数据，65% 的高管表示 IaC 等自动化技术正在提高 IT 团队的生产力。

IaC 将可重复的工作流与自动化工具相结合。工作流程（编写、版本、配置和部署）定义了团队如何从基础设施需求移动到部署的资源。配置文件、版本控制系统和自动化引擎等工具提供了定义、跟踪和创建基础设施的机制。

这些元素共同将基础设施管理从一个容易出错的手动流程转变为自动化、可重复的功能。团队将基础设施编写为代码，具有与软件相同的独特版本，并根据需要部署相同的环境。

IaC 工作流遵循四个阶段：

开发人员使用诸如 HCL、YAML 或 JSON 等语言来编写 IaC 脚本，这与他们使用 Java™ 或 Python 编写应用程序代码的方式类似。团队编写基础设施定义，指定他们需要哪些资源以及如何配置这些资源。他们通常在集成开发环境 (IDE) 中编写这些文件，这些环境提供错误检查和自动完成功能。

代码存储在版本控制系统（也称为源代码控制或源代码存储库）中，例如 Git 或 GitHub。版本控制跟踪更改，维护替代版本，并使团队能够在出现问题时恢复到早期版本。

自动化引擎会读取配置文件，并为指定的基础设施资源进行配置。此阶段将代码转换为实际的基础设施，创建虚拟机 (VM) 、配置网络、设置数据库和建立安全组。预配置过程具有幂等性，这意味着它可以运行多次而不会创建重复的资源。

团队执行脚本在各种环境中部署基础设施，其中 IaC 有助于确保跨环境的一致配置。脚本的一致性在使用持续部署时最有帮助，其中应用程序的软件更改会自动发布到生产环境中。

自动化工具提供了通过代码定义、跟踪和创建基础设施的机制。

配置文件定义基础设施。它们可以使用 HCL、JSON、YAML 或特定领域的语言来编写。这些文件是蓝图，准确描述了您所需的基础设施（包括服务器数量、规格、网络设置等）以一种自动化工具可以读取和执行的格式呈现。

这些文件成为团队的单一可信信息源，有助于确保跨多个环境的一致性。随着团队添加更多资产，可以更新、重复使用或更改它们以进行新安装。

版本控制系统存储每个文件的历史记录。他们追踪原始代码和对它的任何更改，包括更改了什么、由谁更改以及何时更改。这种跟踪使团队能够了解更改、恢复删除并在出现问题时回滚。

版本控制使组织能够将基础设施划分为通过自动化组合的模块。这种模块化方法有助于构建、更新复杂的环境并确定其版本，同时减少重复，并使脚本更易于测试和重用。

自动化引擎使用预定义的代码自动执行预配置和配置。它们执行配置文件中的基础设施定义，从而将代码转化为实际的 IT 资源，如服务器、网络和数据库。

有些引擎是特定于云的，例如 AWS CloudFormation、Azure Resource Manager 或 Google Cloud 部署 Manager。其他的则在所有云上运行，例如 Terraform、OpenTofu（Terraform 的一个开源分支）或 Pulumi（使用 Python 等通用编程语言）。

这些自动化引擎通常与编排工具（例如 Kubernetes）配对，以规模化协调资源和工作量。

IaC 工具通常通过应用程序编程接口 (API) 与云平台集成。这些 API 连接允许 IaC 工具直接与云服务通信，从而以编程方式创建和管理资源，而不是通过手动控制台交互。

IaC 还采用标准软件开发实践，以帮助确保可靠性。自动化测试可以在部署前帮助验证基础设施配置，识别可能导致系统中断或安全漏洞的错误。一些版本控制系统可以在代码发生变更时自动触发这些测试，有助于确保每项修改在进入生产环境之前都得到验证。

在实施 IaC 时，组织主要做出两个选择：如何定义基础设施（声明式与命令式），以及基础设施是否可以在部署后修改（可变与不可变）。

声明式方法和命令式方法在编写基础设施代码的方式上有所不同。

声明式方法（又称功能性方法或声明式 IaC）是最常用的方法。用户描述所需状态：“我需要 3 台具有这些规格的服务器”，然后 IaC 负责实现。它会自动创建资源、安装必要的软件、解决相互依赖关系并自动管理版本控制。

命令式方法也称为程序式方法，要求用户编写逐步配置基础设施的指令。精确的命令是按照精确的顺序指定的：“首先创建服务器，然后安装此软件，然后配置这些设置。”这种方法需要更多的专业知识，并且会使保持一致性变得更加困难。

可变基础设施可以在预配置后修改，而不可变基础设施在预配置后无法修改。

可变基础设施为临时更改提供灵活性，例如满足特定应用程序要求或发布紧急安全补丁。但是，这种灵活性可能会损害一致性并导致版本跟踪变得困难。

大多数组织选择不可变基础设施。要更改服务器或配置，团队必须使用新资源替换整个基础设施。

虽然这听起来让人望而却步，但事实上，出于几个原因，这可能是有益的。首先，不可变基础设施消除了配置偏差。漂移是可变基础设施的一个常见问题，其中手动更改会随着时间的推移而累积，从而更难在不同环境中保持一致性。

其次，不可变基础设施提供可靠的版本跟踪和回滚能力，因为每一次变更都会创建一个新的版本控制实例。这意味着团队可以立即恢复到以前的任何配置。

最后，借助基于云的 IaC，新的基础设施可以快速配置完成，通常只需几分钟，因此重新配置所有基础设施资源比最初看起来要实用得多。

通过使用代码自动化基础设施管理，IaC 提供了若干优势：

IaC 对 DevOps 实践至关重要，因为它使基础设施能够以软件开发的速度进行变更。

如果没有 IaC，基础设施配置可能会成为瓶颈。虽然代码可以在几分钟内部署，但基础设施的设置可能需要数小时或数天。例如，添加新数据库可能需要向基础设施团队提交申请并需等待数天。

IaC 通过将持续整合和持续部署 (CI/CD) 应用于基础设施整合来消除这一差距。基础设施和应用程序代码可以并行一起测试、验证和部署，而不是作为不同的流程进行测试、验证和部署。

在实践中，基础设施代码通常与应用程序代码一起存在于版本控制中。当开发人员提交更改时，CI/CD 管道可以使用 IaC 模板配置测试基础设施，运行自动化测试并使用相同的模板部署到生产环境。这有助于确保每个环境（开发、测试、暂存、生产）都具有相同的基础设施配置。

主要优点是统一性。如果没有 IaC，当测试环境与生产不匹配时，可能会发生环境漂移，从而导致部署失败。IaC 有助于确保在测试中有效的方法在生产中也能有效，因为两者都使用相同的基础设施定义。团队可以通过拉取请求来审查基础设施的更改，跟踪修改，并在需要时回滚，以与应用程序代码同样严格的方式管理基础设施。

IaC 工具分为两大类：创建和部署基础设施的预配置工具，以及在部署后维护基础设施的配置管理工具。

一些工具可在所有云上运行（跨多个提供商工作），而另一些工具则特定于平台。

组织通常会结合这两类工具来构建完整的 IaC 管道。

预配置工具创建和部署基础设施资源：服务器、网络和存储空间系统。他们专注于基础设施组件的初始设置和配置，将基础设施需求转化为运行资源。

IBM 旗下公司 HashiCorp 的 Terraform 是一款 IaC 工具，可以在所有云上运行，并使用声明性配置来跨多个平台管理基础设施。

团队使用 HCL（HashiCorp 配置语言）编写基础设施定义，并可以将相同的代码部署到 AWS、Azure、Google Cloud 或本地部署的数据中心。这种可移植性使组织能够避免供应商锁定，并根据其优势混合使用云供应商，例如，使用 AWS 进行计算，使用 Google Cloud 进行机器学习。

Terraform 还可以通过同时跨多个提供商配置资源来加快部署速度。它分析资源之间的依赖关系并并行创建独立的依赖关系。例如，如果部署 10 个 AWS 服务器和 5 个没有依赖关系的 Azure 数据库，Terraform 会立即而不是按顺序创建所有 15 个资源，从而减少部署时间。

AWS CloudFormation 是 Amazon 用于 AWS 基础设施的原生 IaC 解决方案。团队使用 JSON 或 YAML 模板定义整个应用程序堆栈（从 EC2 实例到 Rational Directory Server 数据库）。CloudFormation 自动处理资源依赖关系，以正确的顺序创建资源，并在发生错误时将其回滚。

虽然仅限于 AWS，但 CloudFormation 提供与 AWS 服务的深度整合，并对新服务提供即时支持。致力于 AWS 的组织可能更喜欢其原生性能和专有功能的访问。

Azure Resource Manager (ARM) 是 Microsoft 针对 Azure 基础设施的原生 IaC 工具。虽然仅限于 Azure，但它提供了与平台的整合。

组织使用 ARM 模板（JSON 格式）来定义、部署和管理 Azure 资源。ARM 提供内置功能，包括基于角色的安全访问控制、组织的资源标记、防止意外删除的锁定和依赖关系映射，以帮助确保资源以正确的顺序部署。

Google Cloud Deployment Manager 是 Google 的原生 IaC 工具，它使用 YAML 或 Python 模板来编排 Google Cloud 部署。尽管它依赖于特定平台，但能够在多个服务之间创建和配置资源（如用于数据的 Cloud Storage、用于虚拟机的 Compute Engine、用于数据库的 Cloud SQL），从而帮助确保这些组件作为一个完整的技术堆栈协同工作。

配置管理工具可在配置后维护基础设施，帮助确保系统保持正确配置、打补丁和一致性。

Ansible® 是 Red Hat® 推出的一款自动化工具，它无需目标系统上的智能体即可管理配置。换句话说，Ansible 不需要在其管理的服务器上安装特殊软件。它使用 SSH 直接连接来执行命令。

这种无智能体方式意味着 Ansible 可以在云端、本地和混合环境中运行。团队编写 YAML 运行手册来定义所需状态，Ansible 帮助确保系统符合这些状态。它在管理 Docker 容器和 Kubernetes 部署方面很受欢迎。

Puppet 使用声明性配置来管理云、本地部署和数据中心环境中的大型基础设施。

它持续检查数千台服务器，以帮助确保它们符合其定义的配置，并自动修复任何偏差。Puppet 可以生成详细的报告，显示发生的变化以及变化的时间，从而可以有效地用于更大规模的部署。

Chef 使用“食谱”和“菜谱”来定义任何环境（云、本地部署或混合）的基础设施配置。

组织经常求助于 Chef 来获取其测试框架。团队可以在进入生产环境之前在测试环境中验证配置。这种“及早发现问题”的方法在那些需要频繁进行基础设施更新、并重视强大测试框架的组织中，往往颇受欢迎。