硬件虚拟化技术的全面普及催生出云基础设施托管这波全新机遇。云托管服务商开始直接为客户提供对于动态基础设施即服务（IaaS）平台的访问通道。随着这类平台的快速发展以及基础设施资产复杂性的不断提升，传统系统管理角色的工作内容也变得愈加繁复。大规模云基础设施的快速配置与统筹管理，开始成为困扰管理人员的新难题。

持续集成/持续部署（CI/CD）的成功激发了基础设施即代码（IaC），即使用代码对基础设施进行建模的新思路。DevOps则证明只要将代码提交至Git repo，再通过功能分支及pull请求即可建立极为高效的工作流。借助这类已经在软件开发自动化领域大放异彩的全新工作流，相信云系统的管理复杂度问题也将迎刃而解。

基础设施即代码是什么？

基础设施即代码是一套IT基础设施管理流程，强调将DevOps软件开发最佳实践引入云基础设施的资源管理当中，包括虚拟机、网络、负载均衡器、数据库及其他联网应用程序在内的各类基础设施资源均适用于这种新流程。

IaC代表着一种配置管理形式，可以将企业组织的基础设施资源编码为文本文件，再将这些基础设施文件提交至Git等版本控制系统。版本控制repo支持功能分支及pull请求等工作流，而这些正是建立CI/CD体系的基本要素。

基础设施即代码的实现，离不开云基础设施托管平台，特别是IaaS平台的兴起。IaaS允许我们通过远程API按需供应并申请云资源，这些API在本质上属于提交至基础设施的配置文件的属性设置模板。Iac的自动化功能则可获取这些配置文件，并针对远程IaaS API加以运行。

在团队将基础设施配置提交至版本控制repo后，即可将CI/CD实践应用于基础设施变更。基础设施的更新同样可以遵循DevOps工作流程。如果团队成员编辑了其中某一配置文本文件，则可以使用pull请求及代码审查工作流对编辑结果的正确性进行审核与验证。

基础设施即代码有何重要意义？

IaC的持续演进，是为了帮助用户解决“环境漂移”的问题。云应用程序在其发布生命周期的各个阶段中往往有着相互独立的部署环境，具体包括开发、登台、生产等环境类型，而不同环境又对应不同的网络资源，例如应用程序服务器、负载均衡器与数据库等。当这些特殊环境之间的基础设施未能同步时，即引发所谓环境漂移。

如果没有IaC的支持，基础设施管理将是一个混乱且脆弱的过程。系统管理员只能手动接入远程云服务商，并使用API或Web仪表板对新硬件及资源加以配置。这种手动工作流缺乏对应用程序基础设施的整体视图，管理员很可能在更改了一套环境后，却忘记了对另一环境做出相应变更。正是因为这样，环境漂移才会频频发生。

环境漂移是一种昂贵的商业浪费，错误与故障的根源永远是团队在登台或开发环境中的构建成果未能与最终部署时的生产环境相同步，迫使成员不得不耗费大量时间调查原因并补全缺失内容。

没有IaC，基础设施的手动管理在速度方面同样令人抓狂。受到环境漂移、流量峰值或者其他特定问题的影响，如果我们明确需要对基础设施做出某些变更，则系统管理员的响应与适配时长根本无法预测或控制。由此引发的服务中断会打击客户信心。而在IaC的帮助下，基础设施能够自动适应配置变化，并通过自动扩展功能对流量峰值做出反应。

基础设施即代码还为手动系统管理提供更理想的监督能力与可见性。在将基础设施配置文件提交至中央版本控制repo之后，所有团队成员都能查看并编辑基础设施数据，由此实现强大的审计能力。例如，如果团队需要接受PCI合规性审计，则应当明确基础设施中的特定部分是否使用SSL进行了加密。在IaC的支持下，可以快速查看SSL的配置方式并执行相关代码，确保当前基础设施与配置文件完全相符，即正确启用SSL。版本控制提交历史也可作为日志记录使用，用于审查各项变更何时添加、何时被移除。

基础设施即代码如何起效？

要全面实现基础设施即代码，我们需要准备一系列依赖项。

首先，也是最重要的依赖项，就是远程访问托管。配置管理工具需要接入并修改该远程主机。如果远程基础设施具备自我管理能力，我们就要确保团队能够随时访问其配置管理工具。而IaaS云托管平台则提供API，允许用户根据需要自动创建、删除及修改基础设施资源。配置管理工具同样可以访问这些API，借此将相关操作任务转为自动化形式。目前流行的IaaS平台包括Digital Ocean、Amazon AWS以及微软Azure。

实现IaC的下一项要求，则是接入IaaS API并负责自动执行常规任务的工具套件。团队当然可以自主创建一组脚本及工具，但这会带来大量的开发负担与后续维护成本，投资回报也往往不高。目前市面上已经有多种开源配置管理平台用于解决这类需求，包括Terraform、Ansible、Salt Stack以及Chef等。

最后是版本控制系统。配置管理平台使用以YAMl等标记语言编写的、人类及机器皆可读取的文本文件对平台将要执行的任务及序列做出声明。这类文本文件作为应用代码文件存在，并被存储在版本控制系统repo当中。这套repo相当于集中指定来源，同时支持pull请求及代码审查。目前最流行的版本控制系统当数Git。

有了以上依赖项，我们设想以下示例场景，其中开发人员希望向系统当中添加新的应用程序服务。下面来看IaC工作流演示：

1. 开发人员在选定的配置管理平台Terraform中编辑YAML配置文本文件，由此指定所需的新托管服务器。

2. 开发人员将编辑结果提交至Git repo中的功能分支。由于项目的Git repo托管在Bitbucket上，因此开发者会开启一项pull请求。其他团队成员负责审查这项pull请求，并发现其中包含基础设施变更。后者批准此项pull请求，而后由之前的开发人员将提交结合提交并合并至repo的主分支当中。

3. 到这里，我们需要使用配置平台以执行更新。这项更新可以由开发人员手动触发。本场景中的团队使用的是Bitbucket，因此可以访问Bitbucket Pipelines以使用管道自动执行此步骤。

4. 执行完成后，Terraform将与团队的IaaS进行交互。Terraform将针对IaaS API执行一系列命令，确保IaaS与预期的基础设施配置保持同步。

小结

IaC是一种高效的配置管理形式，专注于实现云IT基础设施的自动化管理。在IaC部署到位之后，即可用于实现CI/CD层级的自动化功能，高效调整项目的基础设施。IaC还针对基础设施变更当中的沟通及透明度因素提供多种有益见解。至于IaC在实现当中所需要的托管平台及自动化工具等依赖项，目前市面上已经有众多托管厂商提供广泛的解决方案以供选择。