很多机构从手工管理基础架构逐步开始使用一些简单的脚本或者基于Web界面的工具。但随着基础架构的不断扩大,任何手工管理方式都变得既容易出错也很繁琐,很多机构开始自研工具来自动化所涉及的机械化的操作过程。
尽管这些工具需要时间和资源来对其进行开发和维护,但这些工具对于他们来说又是必需的,这代表着他们所迫切需要的最小化可性特性,而且通常仅用于处理突发性需求而构建,因此这些工具难以扩展和维护。这些工具必须随着基础架构或者任何新功能的变化而跟新,这也成为基础架构演进速度的限制因素。
Terraform 围绕应对以上种种挑战和困难设计而成,提供简单的、统一的语法,在不再需要学习其他新的工具的情况下可是实现对几乎所有的资源进行管理。通过遍历所有所需资源,他们之间的依赖关系可以被很好地自动解决,因此运维人员无需进行记忆和论证它们,这样也是运维人员从构建工具的负担重解脱出来,使他们可以专注于基础架构本身的工作。
此外,Terraform 是一款开源工具,除 HashiCorp 之外,围绕 Terraform 的社区帮助扩展它的功能,问题修复以及编写新的使用场景。Terraform 帮助每个企业解决现有问题的同时,形成可用于在其他组织机构进行推广的标准实践,避免重复造轮子,其开源特性也保证了该工具可以长久发展。
Boto、Fog 等之类的开发库通过调用云提供商或者服务的 API 来提供对他们的本地访问。其中一类库针对特定的云平台,还有一类库试图采用统一的接口来屏蔽语义上的差异。因此,这类客户端开发库只能提供底层的访问接口,仍需要开发人员创建自己的应用程序来构建和管理他们的基础架构。
然而,Terraform 并不打算对提供商进行底层编程访问,而是提供一套高级的语法来描述如何创建、部署和组合云资源和服务。Terraform 非常灵活,使用基于插件的模型来对不同的供应商进行支持,使其能够提供平台或服务几乎所有 API 所支持的能力。
CloudFormation、Heat 之类的工具将基础架构详细信息编码成配置文件。此配置文件可以将基础架构进行弹性创建、修改和删除。Terraform 的灵感也来自于它们所要解决的问题。
类似地,Terraform 也利用配置文件来描述基础架构配置的详情,但更进一步既与具体的云服务解耦又可以支持多个提供商以及服务进行组合和编排。例如,Terraform 可用于同时编排 AWS 和 OpenStack 集群,并且还可以与类似 Cloudflare 和 DNSimple 之类的第三方提供商进行集成来提供CDN 和 DNS 服务。这使得 Terraform 能够用它所支持的服务来表示并管理整个基础架构,而不是仅仅是其中的一部分。它提供统一的配置描述语言语法,而运维人员无需采用各平台和服务单独的、不可互操作性的工具对多种平台、多种服务进行操作。
Terraform 还通过执行计划的概念将计划阶段与执行阶段实现分离。通过执行 terraform plan 命令可以进行状态更新并对比生成执行计划。该计划包括所有需要执行的动作:哪些资源需要创建、删除或者修改。运维人员可以据此检查该计划是否完全符合预期。利用 terraform graph 命令来可视化地展示执行计划的顺序和依赖关系。一旦该计划被确认,执行阶段的所有动作则严格按照该计划执行严格执行。其他工具将计划和执行合并成一个步骤,这将意味着强制运维人员在脑海中对变更所带来的影响了如指掌,这对于大型的基础架构变的异常棘手。Terrform 可以让运维人员事先对即将执行的动作及其影响得到全面了解,因此在实施变更时才会有足够的自信。
配置管理工具可以在已存在的服务器上安装和管理软件,而 Terraform 并不是一款配置管理工具,与之不冲突,现有工具在引导和初始化资源方面仍可以继续发挥其长处。
利用部署工具,Terraform 允许任何配置管理工具在资源创建完成之后进行进一步地设置。Terraform 侧重于对数据中心以及辅助服务进行高级抽象,而不用牺牲配置工具所擅长的能力。但同时它仍采用相同的编码方式来保障这些工具成功执行,从而使整体基础架构的部署更加易用和可靠。
Terraform 提供对资源和提供商进行灵活的抽象能力。该模型可用于表征任何资源,从物理设备、虚拟机、容器到邮箱、DNS 提供商等等,因此,Terraform 可以用于解决很多不同的问题。这将意味着很多现有工具与 Terraform 的功能有重合的部分。我们与很多工具做了比较,值得注意的是 Terraform 与其他系统都不冲突,它既可以用于管理简单的一个应用程序,也可以是整个数据中心。