什么是基础设施即代码（IaC）？
基础设施即代码（IaC）是一种IT实践，它将底层IT基础设施作为软件进行编码和管理。它使开发人员和运维团队能够自动管理、监控和调配资源，而不是手动配置硬件设备、操作系统（OS）、应用程序和服务。IaC也被称为可编程或软件定义的基础设施。
IaC的概念类似于编程脚本，后者用于自动化IT流程。然而，脚本主要用于自动化一系列静态步骤，这些步骤需要在多个服务器上重复多次。IaC使用更高级的描述性语言来编写更通用、适应性更强的供应和部署流程的代码。
例如，IT管理和配置工具Ansible内置的IaC功能可以安装MySQL服务器、验证其是否正常运行、创建用户账户和密码、设置新数据库以及删除不需要的数据库。
这种基于代码的基础设施自动化过程类似于软件设计实践，即应用程序开发团队开发声明式代码、控制代码版本、测试迭代，并在软件获批用于生产之前限制其部署。
IaC也与云计算有着相同的抽象IT资源的目标，但它自动化了从供应、配置到部署和管理的整个过程。IaC还用于供应和管理云基础设施，利用云提供商的应用程序编程接口（API）来访问和交互其资源与服务。
基础设施即代码如何工作？
简单来说，IaC使用软件代码来供应和管理IT基础设施。通过使用代码定义期望的IT结果，组织可以提高基础设施的一致性、安全性、自动化和性能。
手动供应和配置服务器、存储、网络、操作系统、应用程序以及其他设备和服务（如数据库、负载均衡器和防火墙）涉及大量的时间和精力。人类可能需要数小时甚至数天才能为企业工作负载和数据提供合适的部署环境。人工错误可能潜入此手动工作的许多方面，导致以下问题：
- 结果不一致，没有两个环境是相同的。
- 设置和配置不正确时产生安全漏洞。
- 基础设施文档不佳或缺失时造成故障排除困难。
- 由安全和故障排除问题引发的合规性和业务连续性问题。
- 有问题的管理和变更控制。
IaC将所有构建和部署期望IT环境所需的指令体现为一个软件实体。开发人员和IT人员可以创建详细的指令来评估所需的步骤并衡量代码的结果。
基础设施代码提供可重复的结果，并且可以通过按一下按钮或响应特定条件来执行。它为供应和管理带来了高水平的自动化。
变更更容易管理，因为对基础设施代码的任何修改都会产生一个新版本，该版本有良好的文档记录，并且可以使用任何标准版本控制系统进行管理。如果由于更改而出现问题，可以通过运行先前已知良好的代码版本来纠正。这简化了故障排除，并提高了业务的合规性和安全性。
以下四种基本类型的IaC通常结合使用：
- 脚本：常用于自动化简单的临时任务。
- 配置管理代码：定义并自动化设备（如服务器）的安装和配置。
- 供应代码：自动化设置整体基础设施，将环境的各个方面联系起来。
- 容器代码：依靠模板来定义包含部署和执行应用程序所需的库和依赖项的镜像文件。
IaC过程通常涉及以下三个步骤：
- 开发人员使用特定领域语言为所需的基础设施创建规范。
- 规范文件被发送或暂存到服务器或存储库（如GitHub）或API。
- IaC平台使用规范文件（自动或按需）创建和配置预期的基础设施。
IaC使IT团队能够将数据中心的物理资源、服务和离散配置转化为代码，以自动供应和管理这些资源。
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文件绝不应被视为理所当然。在发布到生产环境之前，应像测试其他软件一样对它们进行测试和验证。这通常涉及使用持续集成/持续交付（CI/CD）、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的语言有深入的了解，包括JavaScript对象表示法（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。
- Terraform by HashiCorp。
- VMware Tanzu Salt。
一些工具依赖于特定领域语言，而其他工具则使用标准模板格式，如JSON和YAML。
组织应考虑目标部署环境并为该环境选择合适的工具。例如，AWS CloudFormation专为在AWS上供应和管理基础设施而设计，并与其他AWS产品配合使用。同样，Microsoft Azure Resource Manager管理Azure平台上的基础设施，而Google Cloud Deployment Manager是谷歌的基础设施部署服务。或者，Chef适用于本地服务器和多个云提供商的基础设施即服务产品。
IT运营可以超越IaC，采用基于代码的方法来管理其所有资源。了解一切即代码如何工作，并看看它是否适合您的组织。