服务器太多了很差管？UCloud基于Terraform的资源编排工具详解

背景

随着用户在 UCloud 上资源用量的指数增加，传统 API/SDK 手动编写脚本的资源管理方式已经没法知足其须要。为此，UCloud 研发团队基于 Terraform 编写了一套本身的资源编排工具，帮助用户下降云上资源的管理成本，为其提供安全可靠、高度一致的产品使用体验，尽量消除迁移上云时的风险。

Terraform 表明了业界前沿的技术和标准，咱们基于此，并配合 UCloud CLI 等工具，编写了新一代 UCloud 资源编排工具，进一步拓展 Terraform 的功能，实现基础设施可编程。在一个经过 ULB 卸载流量至云主机的案例中，相比于传统方式，新方案下的构建时间从原先的 3 分 20 秒缩短至 43 秒，编排的效率、稳定性和可描述性都获得了显著提高。

Terraform是什么？

Terraform 是 Hashicorp 公司开源的一种多云资源编排工具，目前已经造成完整生态，并与多家主流云厂商创建合做。

使用者经过一种特定的配置语言（HCL, Hashicorp Configuration Language）来描述基础设施，由 Terraform 工具统一解析，构建资源之间的关系，生成执行计划，并经过调用 UCloud 公有云 API 来完成整个基础设施生命周期的管理。

相对于其它的云上资源管理方式，Terraform 的主要特色有：

1. 有普遍的兼容性，目前海内外累计已有超过 40 家公有云厂商支持，其中包括 UCloud 在内的 4 家国内云厂商，另有 200 多个软件服务商为其提供支持。

2. 基于 IaC（基础设施即代码，Infrastructure as Code）的设计，能够将基础设施以一种领域特定语言描述出来，消除了在基础设施自动化时描述语义上的歧义，同时减轻人为因素形成的不肯定影响。

3. Terraform 在执行编排动做前，会生成一份可读性良好的执行计划，关键基础设施的变动能够获得充分审查，保证了基础设施的可靠性。

4. 基于 DAG（有向无环图，Directed Acyclic Graph）描述资源与资源之间的关系，因为 DAG 良好的拓扑性质，当资源属性与资源关系发生改变时，变动动做将被充分并行地执行。

（图片来源于Terraform）

下图是一张资源编排与传统资源管理方式的对比表：

表格1：资源编排与传统资源管理方式对比

能够看出，在自动化 DevOps 环境下，资源编排相对传统资源管理方式具备明显优点，目前已覆盖了 IaaS 层的核心产品，但随着时间的推移，未来 UCloud 资源编排会支持更多的产品。

应用场景

用户能够很容易的从Terraform受益，由于初始化云服务时若缺乏资源编排工具，将投入大量的时间成本，并且对于云上资源的变动，每每须要很复杂的变动逻辑以保证基础设施的安全性。

UCloud 资源编排工具可以很好地解决以下常见的问题：

– CI/CD 自动化资源管理

– 高峰期应用缩扩容

– 部署复杂资源拓扑（例如两地三中心的应用架构）

例如，驿氪做为一家SaaS解决方案提供商，已经将UCloud Terraform编排系统接入自身业务。

下图是驿氪业务架构的示意图。它同时使用了多家云服务，须要统一的资源管理平台进行多云管理，而独立研发一套资源管理平台，须要对接各云厂商接口，同时还要研发人员深刻了解各家云服务的产品细节，这无疑会加剧企业的研发成本和运营成本。

而在应对SaaS 业务时，Terraform能够灵活的动态调整资源，用户只须要调整部分参数，就能够利用模板进行很是快速的资源管理，相较于自建管理平台，UCloud Terraform能够极大节省用户的运营成本和效率。

生命周期

以首次执行 Terraform 建立 UCloud 云上资源为例，这一资源编排动做的生命周期以下图所示：

图：Terraform 生命周期

图中立方体所示分别为：

– Terraform 核心进程：负责资源定义文件，构建有向无环图，管理状态存储；

– Provider 进程：即提供资源编排能力的进程，包括由云厂商实现的能力（好比 UCloud 的资源编排实现），和应用程序提供的能力（好比 TLS 自签名证书）等；

– Provisioner 进程：即提供资源编排后处理操做的进程，好比执行 Shell 命令，上传文件等。

以中央的有向无环图为分界线，左侧的部分是 Terraform 自己提供的能力，右侧是由云厂商提供的能力。

Terraform 核心的良好抽象，保证了资源编排的安全和稳定，为 UCloud 资源编排提供了坚实的工程基础。

UCloud资源编排实践

在一个生产环境的资源编排系统中，每每要依赖数目庞大的云资源后台管理服务。资源编排的工程实现中，如下几个方面的根本诉求须要首先获得保障：

– 保障资源编排在复杂终端环境下的成功率。这个是最基本也是最核心的诉求。

– 保障产品的一致性。使用户能够平滑迁移，变动无感知。

– 保障产品的工程质量。资源编排做为关键基础设施的接入方式，自己须要足够稳定可靠。

下文，咱们将详细分享 UCloud 在基于 Terraform 的资源编排工具研发中，在容错能力、接入能力和工程能力优化上的一些实践。

容错能力优化

容错能力是衡量系统可用性的一个重要维度，资源编排做为 UCloud 服务的入口，自己必须足够稳定，具备对故障能够作出合理应对的能力，包括对上游服务异常的容错能力，以及对于输入异常的纠错能力。

首先，Terraform 的杀手级特性是执行计划与过程分离，用户在执行真正的资源编排动做变动现网基础设施以前，能够先生成执行计划，比较资源定义文件和当前资源状态的差别，检查关键基础设施的变动。

UCloud 在实现资源编排的过程当中，借助 Terraform 执行计划的 CustomDiff 特性，自定义了部分资源的 Diff 过程。好比，两个地域之间仅能存在一条高速通道（UDPN），若是执行编排动做前已经存在了一条高速通道(UDPN)，将会把全部的编排动做阻止在执行计划阶段，提升终端用户的使用效率。

图：自定义 Diff 以在执行计划中检查输入

对于错误的处理，UCloud 编排工具经过梳理整个编排工做流的生命周期，将错误信息严格压缩在（动词、附加动做、资源名、ID）这个形式化的四元组中，转化为人类可读的描述信息反馈给使用者，对于输入异常能够在提供必定的交互纠错能力的前提下，精肯定位到源码行。

图：错误信息四元组的天然语言表示样例

其次， UCloud 经过下文介绍的 API 一致性工程，识别出了全部操做的幂等性质（即该操做是否存在反作用，致使真正的资源建立），并对全部幂等（无反作用的）操做执行自动重试，大幅提高了编排工具的容错能力，同时保证了自动重试机制是真正安全的。对于非幂等操做，得益于 Terraform 的状态管理机制，能够简单地从新执行编排计划，仅重试失败的建立过程。

UCloud 编排工具还提供对于异步操做的同步封装，使用 Terraform 内建的等待机制，建立资源后，将会轮询等待资源完成能够查询方才返回成功，保证操做的原子性和资源状态的一致性。

最后， 对于上述的重试或等待机制，使用指数级增加的间隔（Exponential Backoff），以及优雅退出（Gracefully Shutdown）的方案，进一步提高资源编排的容错能力。

接入能力优化

基于 Terraform 的资源编排有必定固有的局限性，好比其自己更适合基础设施的构建，不适合 adhoc 的临时平常工做，好比列表查询和开关机这样的操做。

如要批量重启主机，使用 Terraform 的作法是使用 data source 查询出对应的数据，定义输出变量，再将输出变量值做为参数传递给外部的脚本。在这样的即席查询场景下，相对于 Ansible 等配置管理工具并无明显的优点。

所以 UCloud 在资源编排以外，开发了 UCloud CLI 工具来扩展资源编排的能力。例如，使用 CLI 来查询和重启经过 UCloud 编排工具建立的资源：

UCloud 实现了资源编排与 UCloud CLI 的集成，资源编排工具能够直接使用 CLI的权限配置信息。也能够经过编排工具的特性，调用 UCloud CLI 进行额外的资源管理操做。

图：Terraform 与 CLI 集成用法示例

打通资源编排与 UCloud CLI 以后，资源编排能够复用 CLI 即席查询的能力，而CLI 能够复用资源编排所持有的资源拓扑信息，例如主机列表，网络 CIDR 信息等，极大拓展了双方的的产品接入能力。

工程能力优化

UCloud 资源编排从立项之初，就将终端用户使用上的一致性和可用性做为核心诉求。要知足这些诉求，在工程上必须攻破几个关键的技术难关：

1. 尽量使用户实现跨版本、跨云的平滑迁移。

2. 同时对资源编排工具所依赖的基础 API 的实现自动化管理，从源头上提升编排工具的可用性。

3. 资源编排做为关键基础设施的接入方式，自己须要足够的质量保障措施。

平滑迁移

首先，对于资源编排工具的升级，UCloud 严格按照 Terraform 的 Schema 变动策略，每当资源的属性有破坏性的变动，都会随之提供版本迁移的实现，使终端用户在升级工具时，自动将其资源状态平滑迁移至新版本。

其次，对于云平台之间的迁移，UCloud 实现了通用的风格转换函数，经过将 UCloud 接口的大写驼峰（Camel）命名，统一映射成 Terraform 经常使用的小写下划线（Snake）风格，并使用 Terraform 建议的产品命名法，下降用户的跨云迁移成本。终端用户只须要少许改动模板，便可经过资源编排工具平滑接入 UCloud。

变动自动化

资源编排做为 UCloud 重要的产品接入方式，对于 UCloud 全线产品都有很强的依赖，接口变动对接时的一点微小错误，均可能致使破坏性的后果。

因此一致性工程的重要目标是，快速响应产品新特性的变动，同时尽量下降人工成本，使变动自动化，减小错误的发生。

为了使 API 可以获得统一管理，同时防止产品间竖井式的信息隔离，UCloud 很早之前就打造了公共、统一的 API 管理平台，将全部现网 API 的定义收敛至统一的 API 注册中心上，使用自定义的格式来形式化地描述 API Schema。API 管理平台将 API 的场景抽象成测试集（Test Set），一次 API 的调用抽象成测试用例（Test Case），并使用自定义的表达式语法构造随机的参数注入到用例中执行。

图：API 管理平台示意图

基于 API 管理平台，UCloud 资源编排团队编写了 API SDK 的自动化生成程序，经过严格形式化的 API 定义，转译成 Go SDK 代码。同时经过编写一个递归降低的表达式解析器，将测试用例中表达式语法，转译成等价的 Go 代码。实现了 API 定义和 Go 代码的直接映射，低成本同步上游变动。

图：经过编写 API 建模工具转译 API SDK 代码

此外在这个过程当中，UCloud 经过在 API 管理平台与 SDK 之间编写 API 建模工具，用以抽象出一个中间层，在该层统一标注出 API 的幂等性质，为资源编排工具提供了真正安全的重试机制。

这样就完成了整个调用链路上的接口一致性工程建设，实现了从 API 管理平台到 SDK 到 Terraform 的完整语义映射，下降了 SDK 的开发和维护成本，同时消除了人为变动带来的不肯定影响。

质量工程建设

资源编排做为大规模云上资源管理的推荐方式，涉及到关键基础设施的操做与管理，编排工具自己的质量十分关键。

表格2：资源编排持续集成检查表

如表2所示，做为一个开源项目，UCloud 资源编排工具共有三个质量周期，

– 开源协做周期，使用 Travis CI 进行代码风格检查和单元测试，不会发起真正的 API 请求；

– 合并主分支周期，UCloud 使用 Gitlab CI on Kubernetes 进行风格检查、单元测试和集成测试，其中集成测试会调用现网 API 操做真正的云上资源，并在天天凌晨进行 Daily Regression；

– 发布正式 Release 到 Terraform 官方仓库周期，合做方 Hashicorp 使用 TeamCity 进行全量验收测试，当全部测试完成后，发布新版本。

为了保证代码不会随时间腐化，提早清除一些隐患，好比拼写错误、安全密钥泄露、抽象不合理等等，UCloud 接入产品团队选取了三种不一样维度的静态检查工具来量化代码质量，其中包括：

– GoReportCard，用来作最基本的风格检查

– SonarCloud，发现代码的 Bug 和安全问题

– Gocyclo，计算函数的圈复杂度（圈复杂度是用来衡量一个函数复杂程度的指标，和控制流的复杂程度相关）

并经过周期性的代码优化，将代码质量的量化指标始终维持在 ** A+ 评级。**

写在最后

通过长时间的发展，Terraform 已经成为一个业内通用的资源编排工具，且近年来海内外的友商也陆续开始支持基于 Terraform 的资源编排系统，证实了业内对通用资源编排系统的强需求。

UCloud 深刻研究了 Terraform 的内部机理，并基于此为 UCloud 下一代资源编排系统进行了深度的探索，在研发过程当中屡次优化，打通整个链路上的基础工程建设，最后经过充分的质量工程实践，为资源编排的可靠性与稳定性保驾护航。UCloud Terraform 的具体使用细节和样例请点击阅读原文至 UCloud 资源编排官方文档查阅。

欢迎添加小助手微信rocsun，加入UCloud Terraform群，和咱们一块儿畅谈关于Terraform的各类需求、使用、疑难等。