服務器太多了很差管？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的各類需求、使用、疑難等。