越来越多的运维和开发人员发现，无法实现自动管理的基础设施已成为业务敏捷上线的阻碍。

对于基础架构运维人员来说，日常维护时，创建、回收虚拟机这一类工作的重复性很高。在创建业务虚拟机时，运维人员需要考虑资源放置最佳实践，如哪台服务器的 CPU 和内存资源比较多，以便将其优先放置。在为业务系统置备虚拟机时，也需要尽可能保证在不同的云平台上进行创建，避免因云平台故障而导致业务异常。

对于应用系统开发人员来说，现在已经在使用 DevOps 进行业务系统的敏捷开发和测试。针对一个版本的测试，在 CI/CD 流程中可以自动根据源码打包应用并进行版本的测试。但是虚拟机创建无法实现自动化——开发人员若想使用虚拟机，需要等待运维人员先成功创建虚拟机，这将阻塞 CI 的工作流。如果想要实现虚拟机生命周期的自动化管理，需要根据私有云厂商的 API 来整理自动化创建虚拟机的脚本。但是如果企业拥有多个云平台，就需要参考各个厂商的 API 来开发基础设施资源管理的功能，这就会比较繁琐。

所以，是否能将基础设施也交给代码来进行自动化管理？这样既能减轻运维人员的工作压力，也使得开发人员可以真正按需置备基础设施的资源。

这里读者可能会有一个疑问：难道一个商业的云管系统不能满足这些需求吗？其实在云平台管理上，几乎每个用户的需求都不完全一致。比如，一个用户可能希望云管平台能够和自己的 CMDB 结合，进行资源的监控，而另外一个用户则可能希望云管平台能够和自己的 OA 系统结合，进行资源的审批。一些用户还可能希望能自动将业务系统同时部署在 VMware 和 SmartX 集群上，在基础架构层做到高可用。但这些其实对于云管平台来说都有些难以实现。而且这里还有一个很关键的问题：云管平台系统是需要收费的，这无疑将增加金钱成本。

为了帮助更多企业以低成本、高效率实现“基础设施即代码”，这篇文章将为大家介绍一款强大的工具——Terraform，并通过金融机构实践说明如何利用 Terraform 实现 SmartX 超融合基础设施的自动化管理。

Terraform 的工作流及优势

Terraform 是 HashiCorp 推出的的基础架构自动化编排工具，可以通过配置文件定义基础设施资源，根据配置文件来进行资源的创建、更改和回收，从而帮助用户实现“基础设施即代码”。用户可以使用相同的工作流程，配置并管理所有的基础架构，并且还可以对资源进行版本的控制。Terraform 不仅支持 AWS、GCP、阿里云等公有云厂商，还支持 VMware、路坦力、SmartX 等私有云厂商，同时还可以进行 Kubernetes、Docker 等基础设施的置备，涵盖了公有云、私有云、数据库、安全、日志、监控等基础设施在内的诸多领域。

Terraform 不仅功能强大，能够对较多的基础设施进行管理，它的使用也非常简单，主要分为三个步骤：

编写：通过一种可读性较强的语言来编写配置文件，定义基础设施所需要的资源。
计划：结合基础设施当前的状态和预定义的配置文件，初始化配置，并使用 Terraform Plan 这个命令来预览基础设施资源的规划。
应用：应用配置文件，完成资源的创建、更新和销毁。

图片来源：“How does Terraform work?” by HashiCorp

在定义基础设施的时候，用户可以同时对多个厂商的资源进行置备，如同时定义 AWS 和阿里云的弹性计算，使得基础设施能够同时在不同的云厂商上置备资源，以满足业务对于基础设施冗余的要求。而且 Terraform 的配置是声明式的，因此对其他资源和变量的引用不会依赖于他们在配置文件中定义的顺序。

举个例子，如果用户要为运行在阿里云上的业务置备一组资源，需要创建 VPC、安全组、虚拟机、镜像、对象存储等等一系列的资源。这些资源在配置文件中的先后顺序并不重要，Terraform 会自动遵从资源的依赖关系，来确保资源可以成功地进行创建。

至此，我们总结一下 Terraform 的优势：

本质为基础设施置备工具：与 Ansible 或 Saltstack 这类虚拟机配置工具不同，Terraform 主要帮助用户对基础设施进行置备，如对虚拟机进行全生命周期的管理。而 Ansible 更擅长虚拟机的配置，如批量升级一批 Linux 的 Open SSH 的版本。这两类工具并不冲突，用户也可以结合使用。
用于管理不可变基础设施：大多数“基础设施即代码”的工具可以创建可发生变动的基础设施，来适应一些中间件的升级或增加磁盘这一类的变更。而可变基础设施的缺点在于配置会发生偏离。随着多次变更的叠加，实际供应的基础设施可能偏离原始配置，从而导致在出现问题时很难诊断、纠正配置的错误之处，以及排查性能问题。Terraform 提供的是不可变基础设施架构，随着环境每一次变化，当前配置都将替换为负责本次变更的新配置，并重新供应新的基础设施。而且，先前的配置也可以保留为版本，以便后续需要的时候进行回滚。
简单易用：Terraform 不仅使用起来简单，同时使用声明式的语言，而且语法的可读性也非常高。
“云无关”特性：Terraform 与云厂商是解耦的，可以实现使用相同的工作流来管理不同云厂商的基础设施。在前期构建好一套工作流，后期引入其他云厂商的产品时，仍然可以使用这套工作流，无需学习多个云厂商技术，快速地维护新厂商的基础设施产品。
免费且开源：Terraform 的开源社区非常活跃，现在 2400 多个 Provider 中，有 2200 多个都是由社区来进行共建的。同时，社区中的贡献者为了这个平台构建了大量的插件，整个社区的活跃也使得产品迅速发展，可以不断地引入新的功能、改进功能。

基于 Terraform 实现 SmartX 超融合“基础设施即代码”

正如前文所述，Terraform 也支持 SmartX 超融合的自动管理，这需要配合 SmartX 原生管理平台 CloudTower 来实现。

以 SmartX 超融合基础设施为例，用户首先使用代码在配置文件中声明资源。Terraform 在运行时会读取所有具备 .tf 扩展名的配置文件，并且将它们连接在一起。随后，Terraform 会根据配置文件调用 CloudTower 的 Provider，在 SmartX 超融合基础设施上去创建和管理对应的资源。其中，Provider 是 Terraform 的插件，不同的云厂商会基于自身云平台的 API 提供对应的 Provider，而 Terraform 通过使用不同云厂商提供的 Provider，从而实现在不同的基础设施上进行资源的创建和管理。

这一方案具有以下优点：

通用配置：适用于多云方案，在现有工作流中可快速编排 CloudTower 资源。仅需替换 Provider 就可管理其他平台。
降低自动化难度：运维人员无需了解 CloudTower API 细节，降低了自动化运维的部署难度。业务人员仅需关心对资源的配置，无需关心资源的创建步骤和过程。
开箱即用：CloudTower 提供了原生的 Modules 和 Examples，覆盖虚拟机管理、虚拟磁盘管理、快照管理、内容库管理等日常使用场景。

我们通过以下 demo 具体演示如何使用 Terraform CLI 批量管理 CloudTower 平台虚拟机，以及如何在 Jenkins 中使用 Terraform 快速置备虚拟机。

金融机构基于 Terraform 的“基础设施即代码”探索

在 Jenkins 的 demo 中我们可以看到，用户只需在 Jenkins 中填写资源的参数，Jenkins 就可以通过后台预先整理的脚本，将这些参数写入到配置文件中。Terraform 则会根据配置文件自动生成虚拟机，并且可以进行企业微信的通知。

顺着这个思路，用户在此基础上追加一些功能，就可以打造一个企业级的自服务管理平台。比如，用户可以加入 CMDB：在生成配置文件之前，先在 CMDB 中查询哪些服务器的资源比较充足，从而优先利用，并将一个应用相同功能的不同虚拟机分别放置在不同的集群上。用户也可以使用 Ansible 提前整理虚拟机应用配置的剧本（Playbook）。在虚拟机创建成功之后，用户还可以在虚拟机上安装 MySQL、Redis 或者 Kafka 等应用。

除此之外，用户还可以加入申请、审批和交付流程。应用人员只需登录到前端页面就可申请资源（预申请虚拟机数量、CPU、内存和存储需求等）、选择是否需要部署应用，和提交资源的申请。之后就是一系列自动流程：申请会进入公司的 OA 流程，开始审批；审批通过后，自动开始置备虚拟机，并且按需部署应用；资源创建成功后，自动反馈虚拟机和应用的关键信息，方便应用人员直接进行使用。这就实现了企业级的自服务管理平台。

金融行业用户实践：基于 Terraform + CloudTower 实现自服务

某金融行业用户基于上述架构，使用 Terraform + CloudTower 自主开发了符合公司需求的基础架构运维平台，并结合 CMDB 实现了资源的使用、统计和规划。

整个运维平台的后端使用了 Terraform 管理虚拟机的生命周期、使用 Ansible 管理虚拟机的配置、使用 Python 编写企业应用的部署脚本、使用 CMDB 存储资源生命周期的配置记录，并为虚拟机置备的集群、存储、服务器提供了最佳的放置建议。同时，用户按照公司业务模式特点，增加了自身所需要的功能，包括 IP 地址、网络、用户和权限的管理。

通过这一运维平台，用户实现了基础架构云平台上虚拟机和企业级应用的自动化交付。整个交付流程实现了标准化、自动化、流程化以及数据化，极大地缩短了交付周期，在减轻运维人员工作量的同时方便了后续资源的审计和追溯。