基础设施即代码（Infrastructure as Code）

2000年之后，硬件虚拟化的兴起催生了云基础设施托管的新机遇。云厂商开始提供对动态Infrastructure as a Service（IaaS）平台的访问。随着这些平台的发展并开始提供更复杂的基础设施资产，传统系统管理角色的复杂性也在增加。快速配置和管理复杂的云基础设施的需求很快成为一项挑战。

CI/CD的成功激发了Infrastructure as Code（IaC）或使用代码建模基础设施的想法。DevOps证明了将代码提交到Git仓库然后运用功能分支和pull request工作流的效率。这些工作流为软件开发带来的自动化有助于降低云系统管理的复杂性。

Infrastructure as Code是什么？

Infrastructure as Code是一个IT基础设施管理流程，它将DevOps软件开发的最佳实践应用于云基础设施资源的管理。适用的基础设施资源包括了虚拟机、网络、负载均衡、数据库和其它应用程序。

IaC是一种配置管理形式，可将组织的基础设施资源编码为文本文件。然后将这些基础设施文件提交给Git等版本控制系统。版本控制存储库是CI/CD的基础，它支持功能分支和pull request工作流。

云基础设施托管平台（尤其是IaaS平台）的兴起使Infrastructure as Code成为可能。IaaS允许通过远程API按需供应和申请云资源，这些API为提交到基础设施配置文件的属性设置模板。IaC的自动化功能可以获取配置文件并针对远程IaaS API运行它们。

一旦团队将基础设施配置纳入到版本控制中，他们就可以在CI/CD中实现基础设施更改。基础设施更新可以遵循DevOps工作流程。如果团队成员修改了一个基础设施配置文件，则可以使用pull request和代码审查工作流来审核和验证修改的正确性。此外，支持DevOps的基础设施即代码系统可以自动完成基础设施部署和回滚。

Infrastructure as Code的重要性

IaC的发展是为了帮助解决“环境切换”的问题。云应用程序通常在其发布生命周期的各个阶段都有单独的部署环境。拥有开发、测试、预生产和生产环境是很常见的。这些环境由网络资源组成，如应用程序服务器、负载均衡和数据库等。当这些不同环境之间的基础设施不同步时，就会发生环境切换问题。

如果没有IaC，基础设施管理可能是一个混乱和脆弱的过程。系统管理员手动连接到远程云厂商并使用API或网页仪表板来配置新硬件和资源。此手工流程并未提供应用程序基础设施的整体视图。管理员可能会手动更改一个环境，而忘记同步到另一个环境。这就是环境切换问题的发生原因。

环境切换问题成为一种昂贵的商业浪费。错误和失败的发生是因为团队针对预生产或开发环境进行构建，然后在部署时发现生产环境不同步，这导致耗费大量时间来调查原因和找出丢失的内容。

如果没有IaC，手动基础设施管理是一个缓慢的过程。由于环境切换问题、流量高峰或某些其它问题，我们都可以变更系统所需的基础设施，但是系统管理员无法预计手动完成配置更改的时间。这会导致系统中断和客户体验下降。有了IaC，基础设施可以自动更改配置的变化，并通过自动扩展功能对流量高峰做出反应。

Infrastructure as Code比手动系统管理带来了更好的监测性和可见性。将基础设施配置文件提交到版本控制仓库后，所有团队成员都可以查看和编辑基础设施数据。这带来了强大的评审功能。例如，如果您的团队接受安全合规性审核，您需要知道基础设施的特定部分是否使用SSL加密。使用IaC，您可以快速查看SSL的配置方式并执行代码以确保实时基础设施与配置文件匹配，这会确定SSL是否已启用。版本控制提交历史记录还充当日志，以便在添加或删除它时进行审查。

Infrastructure as Code如何实现？

要完全实现基础设施即代码，有一些前提依赖。

远程访问主机或IaaS云托管平台
第一个也是最重要的依赖是远程访问服务器。配置管理工具需要连接并修改远程主机。如果远程基础设施是自我管理的，您的团队需要确保配置管理工具可以访问。支持IaaS的云厂商平台提供API，允许用户根据需要自动创建、删除和修改基础设施资源。配置管理工具也可以访问这些API，以进一步自动化这些任务。一些流行的IaaS平台示例包括Amazon AWS、Microsoft Azure，以及国内的主流云厂商。

配置管理平台
完成IaC的下一个要求是连接到IaaS API并自动执行常见任务的工具套件。一个团队可以创建一组脚本和工具。然而，这将需要大量的工作和未来的维护，而且投资回报可能很低。已经有很多开源配置管理平台解决了这个问题，包括Terraform、Ansible、Salt Stack和Chef等。

版本控制系统
配置管理平台使用以YAML等标记语言编写的人类和机器可读文本文件来声明平台要执行的任务和顺序。这些文本文件可以被视为应用程序代码文件并存储在版本控制系统仓库中。代码库作为唯一可信源，支持pull request和代码审查。目前最流行的版本控制系统是Git。

以上依赖准备就绪，让我们考虑一个演示IaC工作流的示例场景，开发人员想要向系统添加新的应用程序服务。

1. 开发人员在他们选择的配置管理平台Terraform中编辑YAML配置文件。编辑指定需要新的主机服务器。
2. 开发人员将更改提交到Git仓库中的功能分支。由于项目的Git仓库托管在Bitbucket上，因此开发人员创建了pull request。另一名团队成员审查pull request并了解新的基础设施更改。团队成员批准pull request，然后开发人员将提交合并到仓库的主分支。
3. 此时需要配置平台执行更新。更新可以由开发人员手动触发。因为该团队正在使用Bitbucket，所以他们还可以访问Bitbucket Pipelines，并且可以使用流水线自动执行此步骤。
4. 执行后，Terraform会与团队的IaaS进行交互。Terraform针对IaaS API执行一系列命令，以使IaaS与预期的基础设施配置保持同步。

总结

IaC是一种高效的配置管理形式，专注于自动化云IT基础设施管理。一旦IaC就位，CI/CD就能达到自动实现更改项目基础设施的级别。IaC为围绕基础设施变化的沟通和透明提供了许多有益的手段。IaC需要一些前提依赖，例如云平台和自动化工具，主流云厂商都可以提供这些功能。