共计 1683 个字符，预计需要花费 5 分钟才能阅读完成。
Terraform 提供了一个资源和服务商的灵活的抽象层。该模型允许可以表示从物理硬件，虚拟机和容器到邮件和 DNS 提供商的所有信息。因为灵活性，Terraform 可以被用于解决许多不同的问题。这意味着许多已存在的工具与 Terraform 功能重叠。我们对比了 Terraform 和大量此类工具，但是需要注意到 Terraform 与其他系统并不是互斥的。它可以被用来管理单个应用程序或整个数据中心。
使用左边的导航来阅读 Terraform 与其他特定系统对比。
Terraform 与 Chef，Puppet 等
配置管理工具在已存在的机器上安装和管理软件。Terraform 不是一个配置管理工具，并且它允许现有的工具专注于自己的优势：引导和初始化资源。
使用 provisioners，在资源被创建以后，Terraform 可以使任意配置管理工具可以被用于配置和初始化资源。Terraform 专注于数据中心和相关服务的更高层次的抽象，而不牺牲配置管理工具来做他们最擅长事情的能力。它也拥抱这些工具所负责的成功编排，使整个基础设施的部署简单可靠。
Terraform 与 CloudFormation, Heat 等
像 CloudFormation, Heat 这样的工具。允许将基础设施的细节编写为配置文件。配置文件允许基础设施被弹性创建，修改和销毁。Terraform 受其所解决问题的启发。
Terraform 同样使用配置文件配置基础设施细节，但是它更进一步与云平台无关并且能够结合多 provider 和多服务编排。例如：Terraform 可以同时编排 AWS 和 OpenStack 集群，开启第三方 provider 像 Cloudflare 和 DNSimple 集成 CDN 和 DNS 服务。这使 Terraform 可以利用其支持的服务来表现和管理整个基础设施，而不是仅仅已存在于单个 provider 里的子集。它提供一种统一的语法，而不是需要运维为每个平台和服务使用独立且不可相互交互的工具。
Terraform 通过使用执行计划的概念将计划语法和执行阶段分开。通过执行 terraform plan，更新当前状态并查询配置文件生成新的执行计划。该计划包含所有将要被执行的动作：将被创建，销毁和变更的资源。运维可以检查其状态以确保其符合预期。使用 terraform graph，该计划将被可视化并按顺序输其出依赖关系。一旦计划被获取，执行语法会被限制在计划中的动作内。其他工具将计划和执行阶段结合在一起，这意味着运维人员被迫在心里推断变更带来的影响，这在一个大型基础架构中会很快变得难以追溯。Terraform 让运维人员有信心应用变更，因为他们事前可以确切知道将会发生什么。
Boto，Fogd 等
像 Boto, Fog 这样的库，被用于原生访问云提供商和服务所提供的 API。一些库强制专注于特定的云，有些则尝试打通所有的云并隐藏于以上的不同。使用客户端工具仅提供对于 API 的低级访问，需要应用程序开发者创建他们自己的工具来构建和管理他们的基础设施。
Terraform 不打算提供对于提供商的低级编程访问，而已提供一个高级语法来描述云资源和服务如何被创建，制备和结合。Terraform 非常灵活，使用一个基于插件的模型支持 providers 和 provisioners，赋予它支持几乎所有服务 API 的能力。
自定义解决方案
Terraform 的设计旨在解决这些挑战。它提供了一个简单，统一的语法，允许管理几乎任意资源而不需要学习一个新工具。通过捕获所有资源，他们之间的依赖关系可以被自动解决，所以运维人员不需要记住和推理。消除构建工具的负担使运维人员专注于他们的基础设施而不是工具。
此外，Terraform 是一款开源工具。除了 HashiCorp 公司，Terraform 社区也在帮助扩展它的功能，修复 bug，完善文档和使用案例。Terraform 帮助解决每个组织都存在的一个问题并提供一种适用的标准以避免不同组织间重复造轮子。它的开源特性确保它可以长远发展。
<!– more –>
<!–// 硬啃官方文档产物，若有不妥之处，欢迎指正，请以官方文档为准！//–>
