规模化环境Terraform状态管理技巧

关于Terraform的话题，其实很早就想找时间专门写一篇单独聊一下。早在一年多以前，笔者有幸参与一个软件交付项目，接触到了Terraform这款基础设施即代码软件。即便是在当时已经从事了多年DevOps专业工作的情况下，仍然被这款软件所蕴含的工程思想所触动。

在此前，笔者也曾主导过多个不同技术栈的软件项目从持续构建到持续部署的标准化方案落地。回顾之前从基础设施资源交付在到代码上线发布的流程管理，很少思考关于基础设施的状态管理，大量的配置变更依然处在“原始社会”，依赖于工程师的人肉执行以及那“薛定谔的文档”。而每一次新项目上线过程中的资源交付，更像是如临大敌般手忙脚乱。往往从开发、测试、再到预生产和生产环境的资源交付，需要几个环境通过不断试错，跌跌撞撞，在带有一些幸运属性去完成项目的交付。

在真正使用Infrastructure as Code（IaC：基础设施即代码）交付资源之前。笔者所工作过的绝大多数组织，都没有在基础设施管理上做的更好，直到今天，仍可以毫不夸张的说，绝大部分组织对于云上资源生命周期的管理依然是非常滞后的，如果能通过云厂商所提供的API接口去创建服务器、数据库等，那已经是一家所谓不错的“创新性互联网公司了”，可资源在创建后到销毁前的配置变更管理，并没有得到有效管理。

而笔者的观点则是Terraform在软件资源交付流程中的作用被大大的低估了。在与许多同行交流过程中，也曾不遗余力的推荐使用。但得到的反馈往往充满偏见。有人认为Terraform本质上只是对云厂商的API进行了封装，和自己对各云产品开发一套API没什么不同。这样的看法稍显片面，通过封装云厂商的API接口实现云平台资源全生命周期管理实际上是需要投入大量的人力成本，而这些所谓的“自研云管平台”往往也只是将云控制台的相关少量云服务配置参数简单封装之后，便搬到了组织内部，可能做了部分的定制，比如资源的批量创建等，但投入产出比非常不乐观，其边际效益并没有随着平台的成熟而获得更大的收益，相反可能会陷入无止境的后期迭代和维护成本。

也要人认为Terraform是好用的，通过一些特定领域的配置语言简化了基础设施管理平台的开发成本，但和Ansible并没有什么不同。

Terraform和Ansible最初的设计初衷都是为了解决在软件交付过程中的配置自动化问题。经过长时间生产环境验证，两者都被证明了是配置系统的最佳选择。然而，它们之间的配置过程及面向对象并不完全相同。

Terraform是一种声明式的模型工具，因此在某些方面使用（比如应用发布）时会带来一定的复杂性，不便于管理。当它作为整个交付流的一环，在执行某些偏操作系统及应用层的行为时实际上是无力的。比如说代码发布管理、安装软件补丁、日常维护等需要制定执行过程的操作行为。Ansible则可以非常容易的配置服务器、应用等，因此在整个端到端交付的过程中，往往给人的感觉是Ansible才被认为是DevOps流水线中工具的最佳选择。事实上，Terraform真正擅长的是它对于云上基础设施的管理，而Ansible在管理云上资源变更的过程中，稍显孱弱。

因此，两者面向的管理对象本质上是不同的。用Terraform管理云资源，应用层管理则使用Ansible，被看作是DevOps的一个最佳实践。

关于Terraform的工具优势，笔者认为主要有如下三点：

1. 一致性：

Terraform通过其状态管理机制，统一管理其创建的资源，同时所有变更操作必须通过修改Terraform代码配置生效，从而杜绝了任何非计划内的临时性配置变更，保证了所有配置变更均可追溯、可回滚。

另一方面，Terraform的一致性还体现在了基础设施资源能够被轻松复制上。无论是在原有环境下创建一台服务器、还是要将开发环境的基础设施克隆到测试环境，甚至是要将一个云账号下的所有资源均复制到另一个账号内，能够保证每个环境的资源配置都是一致的，并且整个环境的构建时间能在数分钟以内完成，极大地降低了实施成本。

2. 中立性：

相较于阿里云的ROC、AWS的Cloudformation，Terraform的另一优势在于跨厂商使用，这也意味