基于 Tosca 和 Terraform 的多云资源编排探索

2024-01-08
江苏
本文字数：5353 字
阅读完需：约 18 分钟

01 导言

随着企业采用多云战略和迁移到云平台，需要依赖不同的云资源来支持业务系统。传统的手动开通和配置资源关联关系的方法在多云环境下变得耗时且复杂，给运维带来困难。

为了应对多云环境中基础设施管理的复杂性，寻找一种高效的多云资源编排方法至关重要。资源编排可以对混合云资源进行编排，实现快速部署和管理，并降低管理复杂性、人工成本和运维成本。核心过程是设计蓝图、编排资源，并将编排结果作为实施模板传递给云平台，实现资源的统一开通、变更和回收。

尽管资源编排是降低成本和提高效率的有效方法，但在实施过程中也面临一些困难和挑战。以下是其中的几个主要方面：

多云平台的异构性：不同的云服务提供商之间存在差异，这意味着在跨多个云平台进行资源编排时，需要处理不同的语法和语义，增加了编排模板的复杂性和学习成本。
依赖关系管理：资源之间可能存在复杂的依赖关系，这需要准确定义和管理，处理依赖关系可能涉及解决循环依赖、处理资源创建的先后顺序等问题。
配置参数的灵活性：不同的云服务和场景可能需要不同的配置参数和选项。资源编排需要提供灵活的配置能力和对需求的个性化定制能力，增加了编排模板的复杂性。

为了解决上述困难，可以采用两个标准来进行多云资源编排：标准描述文件和标准云平台对接。通过这两个标准对云平台的差异进行统一定义，使混合云编排变得简单可操作。在业界中，TOSCA 和 Terraform 是两个备受关注的资源编排工具。

TOSCA 提出了蓝图拓扑编排标准规范，定义了资源之间的拓扑关系和依赖关系，可以实现对复杂应用和服务的编排。Terraform 则可以对资源编排的产物进行简化的实施部署，实现基础设施即代码（IaC）的理念，可以通过编写可重复使用的代码来描述和管理基础设施资源。

本文将基于 TOSCA 和 Terraform 这两个工具进行多云资源编排的探索与讨论，以帮助企业更好地实现混合云环境下的资源编排和管理。

02 TOSCA 规范与 Terraform 工具

TOSCA 规范

TOSCA（Topology and Orchestration Specification for Cloud Applications）是由 OASIS 组织制定的云应用拓扑编排规范。它定义了云资源编排的拓扑结构、组件关系、属性和操作等信息，以便于方便地描述云资源的拓扑结构和行为。

简而言之，TOSCA 旨在制定一套蓝图拓扑编排标准规范，通过使用统一标准来描述云平台上应用的拓扑结构。TOSCA 有以下一些优点：

高度可扩展性：TOSCA 可以在多个层次上描述云原生应用程序，包括服务部署、网络拓扑等。因此，它非常适合在复杂的分布式系统中管理和编排应用程序。
独立于云平台：TOSCA 模板可以在多个云平台上运行，因为它是一个独立于云平台的标准。
生命周期管理：TOSCA 模板中的工作流可以描述应用程序的整个生命周期，从创建部署环境到在生产环境中运行的监视和维护，可以进行全生命周期管理。

但是，TOSCA 也有一些缺点，例如：

相对复杂：TOSCA 需要编写 XML 或 YAML 格式的模板，语法和语义相对复杂，因此需要一定的技术水平。
缺少良好的工具支持：目前，TOSCA 的工具生态系统尚不够完善，使用起来可能会比较困难。
更适合应用程序描述：TOSCA 更适合描述和管理整个应用程序，而不是管理云基础架构。

TOSCA 的主要概念包括两个要素：节点（Node）和关系（Relationship）。TOSCA 规范定义了一系列原生的节点类型（Node Types），用于表示云应用中的不同组件和功能。TOSCA 规范中定义了一些原生节点类型，这些原生的节点类型提供了一种描述云资源中不同类型组件属性和行为的方式，便于进行模板编写和云资源管理。通过使用和派生这些节点类型，可以更加方便和标准化地描述和管理云资源中的各个组件。

Terraform 工具

Terraform 是由 HashiCorp 开发的开源工具，旨在管理云基础架构。它采用声明式编程风格，使用户能够编写基础架构模板，以描述需要部署的所有资源及其相互关系。这样的模板描述方式允许用户以可重复、可维护的方式定义和管理云基础架构，确保资源的一致性和可扩展性。

Terraform 通过描述文件进行直接实施部署，即通过定义 Terraform 的描述文件（.tf 文件），可以将其发送给 Terraform 服务进行执行（terraform apply），从而与云平台进行无缝对接，实现对描述文件中所定义的资源进行部署和开通。这种方式能够简化和自动化云资源的管理过程，使得部署和配置变得更加高效和可靠。

它具有以下优点：

易于使用：Terraform 采用声明式编程风格，用户可以更简单、清晰地定义和管理基础架构。
可扩展：Terraform 具有通过插件机制工作的灵活性，可以很容易地集成到其他工具和流程中。
模块：Terraform 将基础架构的各种组件以模块的方式进行封装，从而更容易地重用。

但是，Terraform 也存在一些缺点：

更适合管理基础架构：Terraform 更适合管理云基础架构，而不是管理完整的应用程序。
学习成本高：虽然 Terraform 的语言很简单，但功能十分丰富。这意味着使用它需要一定的学习成本。
非标准: Terraform 并不是一个标准，需要在不同的云平台上学习相应的 DSL。

目前，Terraform 已经得到了多个云平台的支持，包括公有云、专有云、Docker、Kubernetes。通过 Terraform 的统一管理，用户能够在多个云平台和基础设施上进行资源的配置和部署，实现跨平台、跨服务商的自动化管理。

应用场景

在实际应用中，TOSCA 和 Terraform 在不同场景下发挥着各自的作用。TOSCA 主要适用于管理和编排云原生应用程序，而 Terraform 则更适用于管理更底层的基础架构。以下是两种工具常见的应用场景：

云原生资源编排：TOSCA 模板能够描述云原生应用程序的完整生命周期，包括部署、配置和管理等过程。通过 TOSCA，多个组件和服务可以被编排成一个完整的云原生应用程序。

云基础架构管理：Terraform 可以以模块化的方式编排云基础架构资源，使得各种资源和服务能够更清晰地进行管理。通过使用 Terraform，可以通过代码来管理多个云基础架构，实现对基础设施的统一管理。

03 结合资源编排和实施部署

在实际应用中，TOSCA 和 Terraform 可以分别应用于不同的资源编排场景。由于 TOSCA 和 Terraform 各自具有优势和劣势，可以将它们的长处结合起来形成更优的解决方案。例如，TOSCA 在蓝图编排方面表现出色，可以利用其优势为多云资源编排提供标准化的蓝图编排规范，实现跨平台的编排。而 Terraform 则拥有丰富的社区生态和良好的云平台对接模式，可以快速与不同的云平台进行集成。

主要思路是采用 TOSCA 进行蓝图设计模式，通过蓝图编排将业务所需的云产品组件组织成符合 TOSCA 1.3 YAML 规范的蓝图模板。然后，将该模板转换为符合 Terraform 实施描述文件的统一格式，以便进行实施。具体架构如下所示：

第一步：首先根据 TOSCA 规范定义云产品组件，并进行蓝图编排，以生成符合 TOSCA 规范的蓝图描述文件（YAML 格式）。

第二步：利用配置转换器，将 TOSCA 描述文件转换为 Terraform 描述文件。可以借助报文转换器等工具来进行此转换，具体细节不再详述。

第三步：利用 Terraform 描述文件和 Terraform 服务进行云产品的编排和实施部署。

04 阿里公有云蓝图编排实施部署实操

下面将通过一个实操来简要描述如何利用 TOSCA 蓝图编排并使用 Terraform 进行开通操作。假设需要部署一个 web 网站，该网站依赖三个云资源：虚拟专有网络（VPC）、虚拟交换机（VSwitch）和云服务器（ECS）。案例将模拟在阿里云杭州节点上进行这三个虚拟产品的实施部署，其中 ECS 将部署在 VSwitch 下方，而 VSwitch 的网络分配依赖于 VPC。

在过去的情况下，可能需要先在阿里云上开通 VPC，然后在 VPC 上创建一个 VSwitch，并最后创建一个 ECS。简单来说，这需要三个单独的实施部署操作。

通过资源编排的方式，可以将 VPC、VSwitch 和 ECS 编排在一个蓝图拓扑描述文件中，遵循 TOSCA 规范。然后，可以将这个蓝图描述文件转换为 Terraform 的描述文件，以实现统一的开通操作。这样一来，就可以通过资源编排来简化整个部署过程，实现快速而一致的云资源开通。

实践步骤一：TOSCA 蓝图编排

根据需求背景，使用可视化的蓝图设计工具（或手动编排拓扑文件，或使用基于 TOSCA 的开源编排工具，例如 Cloudify），编排出符合 TOSCA 规范的蓝图描述文件，如下所示：

该描述文件定义了一个包含 VPC、VSwitch 网络关系的 ECS（Elastic Compute Service）规范，其中包括三个自定义云资源节点类型：

alicloud.nodes.VPC：派生 tosca.nodes.Network 节点类型，表示网络。具有属性，如 CIDR。

alicloud.nodes.vSwitch：派生 tosca.nodes.Network 节点类型，表示虚拟交换机。具有属性，如 CIDR。

alicloud.nodes.ECSInstance：派生 tosca.nodes.Compute 节点类型，表示 ECS 实例。具有属性，如镜像 ID、实例类型和实例名称。

其中，组件定义的属性可以作为用户填写，如果有其他需要输入属性，也可在该节点增加。在 relationships 节点上，描述了三者的关系和互相依赖前提。

该描述文件采用 YAML 格式，其中节点描述继承了 TOSCA 规范的派生节点，后续可以不断扩展与继承。描述文件简单通过节点和关系来描述蓝图拓扑的节点、属性和关联关系，使其具有较高的通用性。

实践步骤二：把 TOSCA 转换成 Terraform 描述文件

将 TOSCA 规范描述文件转换为 Terraform 描述文件目前没有现成开源解决方案。因此，需自研定制化接口进行转换。当然，TOSCA 规范也支持自定义接口实现，以调用其他开源组件进行开通操作。

下面是通过转换工具生成的 Terraform 描述文件 main.tf 的示例：

在这里需要介绍的是，Terraform 核心文件包括两个部分。首先是编排执行文件，其文件后缀名采用 tf（在本案例中为 main.tf）。该文件用于定义和执行资源编排的操作。其次是本地状态文件，其文件后缀名采用 tfstate。本地状态文件用于记录当前资源的状态和配置信息。

后缀名 tf 文件：业务编排的主文件，可以将所有内容合并到一个 tf 文件中，也可以根据不同的云产品将其划分为多个文件。无论是合并还是划分，只要文件后缀名为 tf，它们之间可以相互引用和调用。

后缀名 tfstate：本地状态文件，它由 Terraform 服务在实施部署后自动创建。该文件记录了实施部署生成的实例信息和状态。

在 tf 文件中，可以观察到以下几个节点，将对它们进行简单介绍：

terraform 节点：用于指定要下载的云平台提供的 provider。这些 provider 是各大云平台在 Terraform 生态圈中开源提供的工具，通过使用这些 provider，我们可以无缝对接云平台进行资源的开通。

provider 节点：主要用于提供授权信息，包括企业或个人云平台账号的 AK/SK（Access Key/Secret Key）。这些信息用于进行云平台的认证和授权。

data 节点：用于在云平台中进行查询操作。在许多情况下，开通某种云产品需要使用已部署的其他云产品的属性进行关联。通过 data 节点，我们可以根据属性值查询云平台的数据，以便于提供即将开通的资源所需的信息。

resource 节点：用于描述将要实施部署的资源节点信息。这些资源节点可以是将要部署、变更或删除的资源。在执行 Terraform 时，根据该节点的信息与本地状态文件以及远程云平台的状态信息进行比对，决定是进行新的部署、变更部署还是回收部署。

output 节点：用于返回实施部署后的一些资源实例信息。在这里，我们定义了返回的三个资源实例的 ID，以方便进行多云产品的资源管理记录。

实践步骤三：通过 Terraform 服务执行描述文件

准备好了 Terraform 描述文件后，可以通过 Terraform 服务进行执行。Terraform 的执行过程主要包括三个关键步骤：init、plan 和 apply。

(1) terraform init：这一步是进行 provider 的初始化。在本案例中，我们描述了对接阿里公有云且使用 1.204.1 版本的情况。由于在此之前没有进行提前下载，因此在执行该命令时，Terraform 将自动进行下载。以下是示例输出：

(2) terraform plan: 这一步用于检查 main.tf 中的逻辑是否合理，并且可以在 plan 执行日志中查看将要进行的资源状态变更情况。根据案例的执行日志可以看到 terraform 根据模板计划新增了 4 个实例（Plan: 4 to add, 0 to change, 0 to destroy）。执行该命令后的输出如下所示：

(3) terraform apply：通过使用 terraform apply 命令，可以执行实施部署。如果需要传递参数，可以通过 apply 命令进行传递，例如 AK/SK 等敏感信息不适合明文写入文件中，这里只是为了演示方便。执行该命令后，可以观察到 terraform 已根据描述文件中的关联关系自动推算出实施部署云产品的依赖顺序。这也是 terraform 的一个重要优势，在混合云编排场景中，各种云产品之间的相互依赖以及执行顺序的复杂分析都可以通过 terraform 直接解决。以下是具体的执行日志：