Terraform 是什么？

Terraform 可以被定义为一个工具，用于高效、安全地进行基础设施的版本控制、变更和构建。它可以管理流行的现有服务提供商以及自定义的内部解决方案。

配置文件会告诉 Terraform 需要执行哪些元素来运行我们的整个数据中心或单个应用程序。Terraform 会生成一个单一的执行计划，解释在运行以构建所需基础设施后，它将做什么来达到期望的状态。Terraform 能够确定哪些会发生变化，并生成可以用于配置修改的执行计划。

Terraform 可以处理低级元素，如网络、存储、计算实例，以及高级元素，如SaaS 功能、DNS 条目等。

Terraform 可以通过为每种云提供单一的工作流来支持多云。Terraform 管理的各种基础设施可以托管在 Google Cloud Platform、Microsoft Azure 和 Amazon Web Services 上，或者在 CloudStack、OpenStack 或 VMWare vSphere 等私有云中进行本地部署。Terraform 遵循IaC（基础设施即代码）原则。因此，我们无需担心基础设施会偏离期望的配置。

Terraform 架构

该架构包含以下组件：

Terraform Core： Terraform 的核心负责创建依赖图和读取配置。Terraform 在很大程度上依赖于现有的图论来管理依赖关系。Terraform 的核心是 GitHub 上的一个实际 Terraform 项目。

插件： Terraform 插件可以被定义为外部独立的静态二进制文件。Terraform 的核心在应用和规划阶段通过 RPC 接口与插件进行通信。如果您不熟悉 RPC，可以将其理解为插件是服务器，而 Terraform 的核心会向这些服务器发出 API 调用。最常见的插件类型是

Terraform Provider 插件。这些插件实现了资源以及任何基本的创建、读取、更新和删除（CRUD API）功能，以与各种第三方服务进行通信。

上游 API： 上游 API 可以被定义为第三方。它是一个外部 API 或服务。需要记住的是，Terraform 的核心从不直接与 API 交互。相反，Terraform 的核心会要求 Terraform Provider 插件执行任何操作。然后，这些插件会与上游 API 通信。这有助于清晰地划分职责。Terraform 的核心无需了解 API 的细微差别。Terraform Provider 插件也无需了解图论。

IaC（基础设施即代码）

IaC 或基础设施即代码已经获得了足够的关注，因为它有助于解决以前困扰基础设施管理的问题。

• 可重现的环境： 通过应用代码来生成基础设施，可以一次又一次地构建相同的环境。环境可能会偏离期望的状态，并且难以识别可能渗透到我们的发布流程中的问题。使用 IaC，可以轻松地销毁和创建新环境，并且不会有任何环境获得特殊待遇。
• 收敛性和幂等性： 幂等性可以被定义为一个特性，意味着无论我们使用 IaC 定义的配置如何，都不会对环境产生副作用。此外，收敛性可以被定义为一个特性，意味着在需要时才会采取行动。只有为了将环境带到期望的状态才需要执行的操作。如果环境已经处于期望的状态，则无需采取任何行动。
• 简化协作： 如果我们在 Git 等版本控制系统中拥有代码，这将允许团队协作管理基础设施。团队的各个成员都可以获取特定版本的代码并构建他们的环境进行测试和其他目的。
• 自助式基础设施： 云弹性允许按需构建资源。各种开发人员可以在需要时规划他们所需的基础设施。此外，IaC 通过允许开发人员应用基础设施模块来创建应用程序开发生命周期中的一致环境，从而改善了这种情况。基础设施模块可以与许多开发人员共享，并由运维团队构建。

其他 IaC 选项

通常，云提供商会提供原生的基础设施即代码解决方案。例如：

• Microsoft Azure 包含 Azure Resource Manager 模板。
• Google Cloud Platform 包含部署管理器。
• Amazon Web Services 包含 CloudFormation。

所有这些都包含一种定义基础设施即代码（IaC）的特定形式。对于 OpenStack 等各种私有云，也同样适用，它包含 Heat 来在代码中定义基础设施。

混合云更强大，因为它提供了一个通用的工作流和单一工具来管理基础设施。即使我们只使用一种云，也值得为未来做准备，以防我们以后使用不止一种云。

Terraform 支持的基础设施

Terraform 的基础设施集成允许管理服务和软件，包括数据库（如MySQL）、配置管理工具（如Chef）以及源代码控制系统（如GitHub）等等。

Terraform 的用例

让我们看几个 Terraform 的示例用例：

• 一次性环境： 通常有 QA 或暂存环境以及生产环境。这些类型的环境是生产环境的缩小克隆。但这些环境用于在发布到生产环境之前测试新应用程序。随着生产环境变得越来越复杂和庞大，维护一个最新的环境变得越来越困难。
  可以使用 Terraform 将生产环境进行代码化，并与开发、QA 或暂存环境一起启动。这些配置用于快速启动新环境进行测试，并可以轻松销毁。Terraform 可以支持减少管理并行环境的复杂性。此外，它还可以弹性地销毁和创建环境。
• 多云部署： 为了提高容错性，将基础设施分散到多个云上是很有创造性的。当使用单一云提供商或区域时，容错性受限于提供商的可用性。多云部署允许在整个提供商或区域发生故障时进行更多恢复。此外，当我们在本地运行私有云并利用任何公共云进行灾难恢复和业务连续性时，可以提高容错性。例如，运行一个辅助应用程序或数据库，在我们的本地主服务器发生故障时，可以访问信息、备份数据。此外，我们可能会遇到某些情况，某个公共云提供商拥有的服务在我们批准的公共提供商上不可用。实现多云部署可能非常困难，因为许多基础设施管理工具都是云特定的。此外，Terraform 是云无关的，允许使用一个配置来管理多个提供商。它简化了编排和管理，并支持操作人员创建大规模的多云基础设施。
• 多层应用程序： 常见的架构是 N 层架构。Web 服务器池是最常见的 2 层架构，使用数据库层。其他额外的层包括API 服务器、路由网格、缓存服务器等。这种安排是因为各层可以独立扩展并促进职责分离。Terraform 有助于管理和构建这些基础设施。所有层都可以被定义为一组资源。所有层之间的依赖关系会自动管理。Terraform 将确保在启动所有 Web 服务器之前数据库层就已存在。然后，通过更改单个计数配置值，所有层都可以通过 Terraform 进行高效扩展，因为任何资源的供应和创建都是自动化和代码化的。
• 资源调度器： 随着大规模基础设施的普及，应用程序的静态分配给机器变得越来越具挑战性。为了解决这个问题，有许多调度器，如Kubernetes、YARN、Mesos和Borg。这些调度器可用于调度 Docker 容器、Spark、Hadoop 等。Terraform 不局限于 AWS 等物理提供商。资源调度器可以被视为一个提供商，允许 Terraform 通过它们来声明资源。它还允许 Terraform 在各个层级内应用。它还用于设置运行调度器的各种物理基础设施，以及在调度网格上进行供应。

Terraform 产品流

Terraform 可以指代不同的层和产品。这些层和产品讨论如下：

• 基本产品是开源 Terraform 版本。它包含提供 IaC 所需的每个组件，并支持超过一百种基础设施集成。开源 Terraform 产品的源代码托管在 GitHub 平台，并使用 Go 语言编写。此版本提供命令行界面来管理基础设施。
• Terraform 的另一个产品是Terraform Enterprise。它有两种套餐。这些套餐增加了对各种团队有用的其他功能，并包含了开源版本的功能。
• Pro 是初始套餐。Pro 是SaaS（软件即服务）。它由 HashiCorp 管理，并在云端运行。Pro 套餐提供图形用户界面、用于基础设施变更的版本控制连接、用于将 Terraform 集成到工具中的 API 访问，以及一个私有基础设施模块注册表，用于在我们的组织中共享可重用模块。
• 第二个企业套餐是Premium。Premium 可以安装在我们的云基础设施上。目前它应该安装在 AWS 中。它包含了 Pro 的各个方面和代码。它提供了所有基础设施变更的审计日志。此外，我们还可以获得 HashiCorp 的优质支持。

Terraform CLI

版本特定的开源 Terraform 产品被编译成我们通过命令行与之交互的任何工具。命令行工具应用配置文件，这些文件描述了我们的 IaC（基础设施即代码）。

典型的 CLI 工作流

我们知道有配置文件和 CLI。本节将定义如果我们正在开发基础设施代码，如何应用 Terraform。

首先，我们可以修改基础设施的配置文件。这些配置文件声明了我们基础设施的目标状态。我们修改配置文件来声明我们希望如何修改任何现有基础设施。

如果我们对声明的配置感到满意，可以要求 Terraform 为其生成执行计划。此执行计划将告诉我们 Terraform 需要做什么修改才能将我们最新基础设施的状态更新到配置中发布的状态。它将规划一些必要的动作来使基础设施达到期望的状态。此外，Terraform 考虑依赖关系来确定修改的应用顺序。相对而言，计划状态比实际应用修改的成本要低。因此，在开发配置时，我们可以自由地应用 plan 命令来确定需要进行哪些修改。对于一些复杂的基础设施，计划状态可能需要一些时间。Terraform 需要通过创建 API 请求来获取我们基础设施中每个组件的最新状态。这是为了正确规划更改。如果我们遇到这种情况，有许多方法可以解决计划生成缓慢的问题。我们可以告诉 Terraform 仅定位基础设施的子集，或者在计划中使用过时的状态信息。
根据计划中看到的必要修改，我们可以接受或拒绝这些修改。Terraform 允许我们在应用修改之前先进行计划，从而避免不确定性和错误。
如果我们不喜欢计划，那么我们可以返回并修改我们的配置，而不会造成任何损害。
如果我们接受计划，我们可以指示 Terraform 应用修改。我们使用 apply 命令来完成此操作。apply 命令可以应用我们用 plan 命令生成的计划。如果我们不提供计划，apply 可以生成一个，并在应用修改之前要求我们接受计划。Terraform 将创建实施修改所需的 API 调用。如果出现问题，Terraform 不会尝试自动将基础设施回滚到执行 apply 之前的状态。这是因为 apply 遵循计划。如果计划中没有调用，它不会删除任何资源。如果我们对基础设施配置代码进行版本控制，我们可以使用我们配置的先前版本来回滚。我们也可以使用 taint 或 destroy 命令来分别定位需要重新创建或删除的组件。

Terraform 资源图

Terraform 创建一个资源图，它包含了我们基础设施中所有依赖关系的信息。通常，依赖关系会自然地从配置中表示出来。如果不存在依赖关系，Terraform 可以并行使用修改，并利用这些资源图尽可能吸引人地创建我们的基础设施。Terraform 可以提供一个图，我们可以对其进行可视化以更深入地了解我们的基础设施。该图说明了VPC、子网或实例之间的依赖关系。

Terraform 自动化工作流

Terraform 可以通过与持续集成或持续部署流水线的集成来提供自动化支持。例如，我们可以自动创建基础设施来部署新分支。
我们可以自动接受计划，以便在无人干预的情况下将基础设施更新包含到当前版本中。这对于生产环境来说可能不是一个好主意。
相反，我们可以选择手动进行审批步骤。利用生成的资源图和执行计划，可以有效地了解将要修改的内容以及修改的顺序。对于各种复杂的变更集，意外修改的可能性大大降低。
最后，我们可以只生成一个计划。这有助于审查拉取请求。通过检查任何计划，我们可以快速确定变更对我们最新基础设施的影响。

迁移到 Terraform

Terraform 可以支持我们将基础设施的控制转移到 Terraform。它支持通过 import 命令导入现有资源以将其纳入控制之下。我们可以尝试在 Terraform Lab 中导入 AWS 资源。在此实验中，我们将首先导入 AWS CloudFormation 处理的任何资源。