HashiCorp Terraform 采用声明式语言而非命令式语言。用户描述基础设施资源的期望最终状态,Terraform 处理其余部分。Terraform 自动生成执行计划、识别资源间依赖关系并按正确顺序部署组件。例如,若虚拟机 (VM) 依赖虚拟私有云 (VPC),Terraform 将确保先创建 VPC 再部署 VM。
相比之下,使用程序语言时,开发人员必须 逐步编写指令来配置基础设施。
可对 Terraform 配置文件进行版本控制、重用和共享。Terraform 管理低级别组件(例如,计算和存储资源)以及高级组件(例如,域名系统 (DNS) 条目和软件即服务 (SaaS) 功能)。
2025 年 2 月,IBM 收购了 HashiCorp 及其产品,包括 Terraform。
Terraform 通过应用程序接口 (API) 创建并管理云平台及其他服务上的资源。Terraform 几乎能与所有具备开放 API 的平台或服务协同工作,包括 Amazon Web Services (AWS)、Microsoft Azure、Google Cloud、GitHub、IBM Cloud 和 Docker。
Terraform 的核心工作流程包含三个阶段:
开发人员编写一个人类可读的配置文件来定义他们所需基础设施的资源配置。该文件是声明性的,这意味着开发人员描述了他们想要的基础设施,而不是描述如何配置它。
例如,开发人员若想为部署云托管应用程序配置基础设施,可能需要指定在虚拟私有云中配备虚拟机,并关联安全组与负载均衡器。
单个配置文件可管理位于多个云供应商和服务中的资源。
Terraform 会分析开发人员提供的书面配置以及组织基础设施的当前状态。然后,它会创建一个执行计划,描述它将如何从当前状态达到期望的最终状态。
执行计划本身以基础设施清单形式呈现,Terraform 将通过创建、更新或销毁这些资源,使现实环境与开发人员描述的配置保持一致。
以先前开发人员需要在虚拟私有云中部署虚拟机应用程序为例。Terraform 的执行计划可能包含以下操作:
开发人员可以在 Terraform 执行计划之前对计划进行审核和修改。
当计划获得批准后,Terraform 将按照正确的顺序执行建议的操作,同时考虑资源依赖关系。也就是说,如果资源 A 依赖于资源 B,则 Terraform 会确保在资源 A 之前创建资源 B。
例如,如果开发人员更新 VPC 的属性并更改该 VPC 中的虚拟机数量,Terraform 会在扩展虚拟机之前重新创建具有更新属性的 VPC。
Terraform 的主要组件包括:
配置文件是开发人员为本地部署和云环境定义所需资源的方式。这些文件告诉 Terraform 要使用哪些提供程序、要创建哪些基础设施以及要获取哪些数据。开发人员可以修改、复用和分享配置文件。
开发人员可以使用 JSON 或 HashiCorp 配置语言 (HCL) 编写配置文件。HCL 使用声明性语法:开发人员描述他们想要的基础设施,而不是指定如何配置它。HCL 类似于 JSON 的键值对,但它进行了优化,更加适合人类阅读。
模块则是多个常需共同使用资源的可复用容器。例如,一个模块可集成虚拟机、数据库、网络配置与安全设置于一体。这些模块以配置文件集合的形式进行存储。
使用 Terraform 模块,开发人员可创建复杂的基础设施,而无需每次都从头开始。相反,他们可以使用已经描述了他们需要的基础设施配置的模块。
Terraform 状态文件描述基础设施的当前状态,包括组件、配置以及资源之间的关系。
Terraform 生成执行计划时,首先会比对配置文件与状态文件。这使得 Terraform 能够确定需要实施哪些变更,才能使现有基础设施符合目标配置。
Terraform 服务提供商插件作为桥梁,让 Terraform 能够通过 API 与外部服务和平台进行交互。这些插件使 Terraform 能够管理基础设施即服务 (IaaS)、平台即服务 (PaaS) 及软件即服务 (SaaS) 环境中资源。每个提供商都包含 Terraform 连接服务、身份验证和调配资源所需的全部代码。
虽然开发人员可以编写自己的提供程序,但他们也可以使用由 HashiCorp 和其他 Terraform 用户编写的现有提供程序。大多数主流的私有云和公共云服务以及数据库、网络解决方案和其他常用工具都有预先构建的提供程序。
Terraform Registry 是提供程序、模块、策略规则和解决方案的存储库。
任何用户均可发布并使用公共 Terraform 注册中心内的资源。企业也可以创建私有注册中心,在内部共享专属模块与资源。
Terraform CLI 是用于使用 Terraform 管理基础设施的命令行界面 (CLI) 工具。开发人员可使用它来执行命令、生成执行计划、应用更改并与关键 Terraform 组件交互,例如配置文件、状态文件、提供程序和模块。
组织使用 Terraform 在整个生命周期中配置和管理基础设施。常见用例包括:
Terraform 可以部署和管理多层应用程序的基础设施,这样,组织将能够在统一工作流程中管理每一层的资源,同时考虑依赖关系。
例如,多层应用程序可能由一个 Web 服务器池、一个数据库层、一个 API 层、缓存服务器和一个路由层组成。Terraform 将会先配置数据库层,然后再配置依赖该数据库层的 Web 服务器。
Terraform 可以帮助组织对团队可以配置和使用的资源类型实施安全和合规策略。
例如,组织可以使用 Terraform 模块来编纂标准,以便在整个组织中部署和管理资源。当其他团队使用这些经批准的模块时,可以确保他们按照组织实践来部署资源。
组织可以将 Terraform 配置文件存储在版本控制系统 (VCS) 中,这样,开发运维团队将能够协作处理代码、审查定义、跟踪基础设施更改,并在必要时回滚到以前的基础设施版本。
Kubernetes 和 Terraform 是云环境的常见组件,它们都有助于自动执行与基础设施相关的任务。然而,两者之间的核心区别在于,Kubernetes 专注于容器化工作负载,而 Terraform 管理各种基础设施组件,包括 Kubernetes 集群本身。
Kubernetes 是一个开源的容器编排平台,用于调度和自动执行容器化应用程序的部署、管理和扩展。Terraform 是一种基础设施即代码工具,可自动预配和管理基础设施。
虽然这些是具有不同功能的不同工具,但它们通常在云环境中协同工作。例如,Terraform 可以在云平台上自动预配 Kubernetes 集群,而 Kubernetes 可管理这些集群中应用程序的部署。
Terraform 与 Ansible 同属基础设施即代码工具,都能实现自动执行核心基础设施任务。但二者采用不同语言且通常用途各异。Terraform 用于调配基础设施资源,Ansible 则常用于管理资源配置。
Terraform 采用纯声明式语言,Ansible 则结合了声明式与程序式语言。在程序式配置中,开发人员需要明确指定将资源配置至预期状态的具体步骤。程序式配置虽更费人力,但能提供更强的控制力。
利用通过 YAML 编写的 Ansible 运行手册,可对安装软件和更新系统设置等任务进行细粒度的控制。Ansible 还具有各种预构建模块,用于常见配置管理任务,包括包管理和操作系统更新。Ansible 可按幂等方式将更改应用于资源,这意味着,在第一次应用一个操作之后,同一操作的后续应用不会改变资源。
总而言之,这些特征有助于解释为什么 Ansible 是配置管理的常见选择。
虽然 Terraform 可以预配基础设施资源,但它不能像 Ansible 那样有效地管理资源内部的软件。例如,Terraform 可以定义新的虚拟机,包括实例类型和磁盘大小等属性,但它无法更新虚拟机上的操作系统。
但是,Terraform 可以与 Ansible 等配置管理工具协同工作,以简化和精简基础设施配置。例如,组织可以使用 Terraform 来预配虚拟机,并使用 Ansible 来配置这些计算机上的软件。
自动扩展现有 IT 基础架构,以更低的成本实现更高的性能。
了解 AI 如何为 IT 运营提供所需的洞察分析,帮助推动卓越的业务绩效。
不仅能实现简单任务的自动化,还能凭借内置的采用和扩展机制,处理备受关注且面向客户的创收流程。