圖1：資源編排與傳統(tǒng)資源管理方式對比
可以看出，在自動化 DevOps 環(huán)境下，資源編排相對傳統(tǒng)資源管理方式具有明顯優(yōu)勢，目前已覆蓋了 IaaS 層的核心產品，但隨著時間的推移，將來 UCloud 資源編排會支持更多的產品。
應用場景
用戶可以很容易的從Terraform受益，因為初始化云服務時若缺少資源編排工具，將投入大量的時間成本，而且對于云上資源的變更，往往需要很復雜的變更邏輯以保證基礎設施的安全性。
UCloud 資源編排工具能夠很好地解決如下常見的問題：
– CI/CD 自動化資源管理
– 高峰期應用縮擴容
– 部署復雜資源拓撲（例如兩地三中心的應用架構）
例如，驛氪作為一家SaaS解決方案提供商，已經將UCloud Terraform編排系統(tǒng)接入自身業(yè)務。
下圖是驛氪業(yè)務架構的示意圖。它同時使用了多家云服務，需要統(tǒng)一的資源管理平臺進行多云管理，而獨立研發(fā)一套資源管理平臺，需要對接各云廠商接口，同時還要研發(fā)人員深入了解各家云服務的產品細節(jié)，這無疑會加重企業(yè)的研發(fā)成本和運營成本。
圖2: 驛氪業(yè)務架構的示意圖
而在應對SaaS 業(yè)務時，Terraform可以靈活的動態(tài)調整資源，用戶只需要調整部分參數，就可以利用模板進行非?？焖俚馁Y源管理，相較于自建管理平臺，UCloud Terraform可以極大節(jié)省用戶的運營成本和效率。
生命周期
以首次執(zhí)行 Terraform 創(chuàng)建 UCloud 云上資源為例，這一資源編排動作的生命周期如下圖所示：
圖3：Terraform 生命周期
圖中立方體所示分別為：
–?Terraform 核心進程：負責資源定義文件，構建有向無環(huán)圖，管理狀態(tài)存儲；
–?Provider 進程：即提供資源編排能力的進程，包括由云廠商實現的能力（比如 UCloud 的資源編排實現），和應用程序提供的能力（比如 TLS 自簽名證書）等；
–?Provisioner 進程：即提供資源編排后處理操作的進程，比如執(zhí)行 Shell 命令，上傳文件等。
以中央的有向無環(huán)圖為分界線，左側的部分是 Terraform 本身提供的能力，右側是由云廠商提供的能力。
Terraform 核心的良好抽象，保證了資源編排的安全和穩(wěn)定，為 UCloud 資源編排提供了堅實的工程基礎。
UCloud資源編排實踐
在一個生產環(huán)境的資源編排系統(tǒng)中，往往要依賴數目龐大的云資源后臺管理服務。資源編排的工程實現中，以下幾個方面的根本訴求需要首先得到保障：
– 保障資源編排在復雜終端環(huán)境下的成功率。這個是最基本也是最核心的訴求。
– 保障產品的一致性。使用戶可以平滑遷移，變更無感知。
– 保障產品的工程質量。資源編排作為關鍵基礎設施的接入方式，本身需要足夠穩(wěn)定可靠。
下文，我們將詳細分享 UCloud 在基于 Terraform 的資源編排工具研發(fā)中，在容錯能力、接入能力和工程能力優(yōu)化上的一些實踐。
容錯能力優(yōu)化
容錯能力是衡量系統(tǒng)可用性的一個重要維度，資源編排作為 UCloud 服務的入口，本身必須足夠穩(wěn)定，具有對故障可以做出合理應對的能力，包括對上游服務異常的容錯能力，以及對于輸入異常的糾錯能力。
首先，Terraform 的殺手級特性是執(zhí)行計劃與過程分離，用戶在執(zhí)行真正的資源編排動作變更現網基礎設施之前，可以先生成執(zhí)行計劃，比較資源定義文件和當前資源狀態(tài)的差異，檢查關鍵基礎設施的變更。
UCloud 在實現資源編排的過程中，借助 Terraform 執(zhí)行計劃的 CustomDiff 特性，自定義了部分資源的 Diff 過程。比如，兩個地域之間僅能存在一條高速通道（UDPN），如果執(zhí)行編排動作前已經存在了一條高速通道(UDPN)，將會把所有的編排動作阻止在執(zhí)行計劃階段，提高終端用戶的使用效率。
圖4：自定義 Diff 以在執(zhí)行計劃中檢查輸入
對于錯誤的處理，UCloud 編排工具通過梳理整個編排工作流的生命周期，將錯誤信息嚴格壓縮在（動詞、附加動作、資源名、ID）這個形式化的四元組中，轉化為人類可讀的描述信息反饋給使用者，對于輸入異?？梢栽谔峁┮欢ǖ慕换ゼm錯能力的前提下，精確定位到源碼行。
圖5：錯誤信息四元組的自然語言表示樣例
其次，UCloud 通過下文介紹的 API 一致性工程，識別出了所有操作的冪等性質（即該操作是否存在副作用，導致真正的資源創(chuàng)建），并對所有冪等（無副作用的）操作執(zhí)行自動重試，大幅提升了編排工具的容錯能力，同時保證了自動重試機制是真正安全的。對于非冪等操作，得益于 Terraform 的狀態(tài)管理機制，可以簡單地重新執(zhí)行編排計劃，僅重試失敗的創(chuàng)建過程。
UCloud 編排工具還提供對于異步操作的同步封裝，使用 Terraform 內建的等待機制，創(chuàng)建資源后，將會輪詢等待資源完成可以查詢方才返回成功，保證操作的原子性和資源狀態(tài)的一致性。
最后，對于上述的重試或等待機制，使用指數級增長的間隔（Exponential Backoff），以及優(yōu)雅退出（Gracefully Shutdown）的方案，進一步提升資源編排的容錯能力。
接入能力優(yōu)化
基于 Terraform 的資源編排有一定固有的局限性，比如其本身更適合基礎設施的構建，不適合 adhoc 的臨時日常工作，比如列表查詢和開關機這樣的操作。
如要批量重啟主機，使用 Terraform 的做法是使用 data source 查詢出對應的數據，定義輸出變量，再將輸出變量值作為參數傳遞給外部的腳本。在這樣的即席查詢場景下，相對于 Ansible 等配置管理工具并沒有明顯的優(yōu)勢。
因此 UCloud 在資源編排之外，開發(fā)了 UCloud CLI 工具來擴展資源編排的能力。例如，使用 CLI 來查詢和重啟通過 UCloud 編排工具創(chuàng)建的資源：
圖6：使用 CLI 來查詢和重啟通過 UCloud 編排工具創(chuàng)建的資源
UCloud 實現了資源編排與 UCloud CLI 的集成，資源編排工具可以直接使用 CLI的權限配置信息。也可以通過編排工具的特性，調用 UCloud CLI 進行額外的資源管理操作。
圖7：Terraform 與 CLI 集成用法示例
打通資源編排與 UCloud CLI 之后，資源編排可以復用 CLI 即席查詢的能力，而CLI 可以復用資源編排所持有的資源拓撲信息，例如主機列表，網絡 CIDR 信息等，極大拓展了雙方的的產品接入能力。
工程能力優(yōu)化
UCloud 資源編排從立項之初，就將終端用戶使用上的一致性和可用性作為核心訴求。要滿足這些訴求，在工程上必須攻破幾個關鍵的技術難關：
1. 盡可能使用戶實現跨版本、跨云的平滑遷移。
2. 同時對資源編排工具所依賴的基礎 API 的實現自動化管理，從源頭上提高編排工具的可用性。
3. 資源編排作為關鍵基礎設施的接入方式，本身需要足夠的質量保障措施。
· 平滑遷移
首先，對于資源編排工具的升級，UCloud 嚴格按照 Terraform 的 Schema 變更策略，每當資源的屬性有破壞性的變更，都會隨之提供版本遷移的實現，使終端用戶在升級工具時，自動將其資源狀態(tài)平滑遷移至新版本。
其次，對于云平臺之間的遷移，UCloud 實現了通用的風格轉換函數，通過將 UCloud 接口的大寫駝峰（Camel）命名，統(tǒng)一映射成 Terraform 常用的小寫下劃線（Snake）風格，并使用 Terraform 建議的產品命名法，降低用戶的跨云遷移成本。終端用戶只需要少量改動模板，即可通過資源編排工具平滑接入 UCloud。
· 變更自動化
資源編排作為 UCloud 重要的產品接入方式，對于 UCloud 全線產品都有很強的依賴，接口變更對接時的一點微小錯誤，都可能導致破壞性的后果。
所以一致性工程的重要目標是，快速響應產品新特性的變更，同時盡可能降低人工成本，使變更自動化，減少錯誤的發(fā)生。
為了使 API 能夠得到統(tǒng)一管理，同時防止產品間豎井式的信息隔離，UCloud 很早以前就打造了公共、統(tǒng)一的 API 管理平臺，將所有現網 API 的定義收斂至統(tǒng)一的 API 注冊中心上，使用自定義的格式來形式化地描述 API Schema。API 管理平臺將 API 的場景抽象成測試集（Test Set），一次 API 的調用抽象成測試用例（Test Case），并使用自定義的表達式語法構造隨機的參數注入到用例中執(zhí)行。
圖8：API 管理平臺示意圖
基于 API 管理平臺，UCloud 資源編排團隊編寫了 API SDK 的自動化生成程序，通過嚴格形式化的 API 定義，轉譯成 Go SDK 代碼。同時通過編寫一個遞歸下降的表達式解析器，將測試用例中表達式語法，轉譯成等價的 Go 代碼。實現了 API 定義和 Go 代碼的直接映射，低成本同步上游變更。
圖9：通過編寫 API 建模工具轉譯 API SDK 代碼
此外在這個過程中，UCloud 通過在 API 管理平臺與 SDK 之間編寫 API 建模工具，用以抽象出一個中間層，在該層統(tǒng)一標注出 API 的冪等性質，為資源編排工具提供了真正安全的重試機制。
這樣就完成了整個調用鏈路上的接口一致性工程建設，實現了從 API 管理平臺到 SDK 到 Terraform 的完整語義映射，降低了 SDK 的開發(fā)和維護成本，同時消除了人為變更帶來的不確定影響。
· 質量工程建設
資源編排作為大規(guī)模云上資源管理的推薦方式，涉及到關鍵基礎設施的操作與管理，編排工具本身的質量十分關鍵。
圖10：資源編排持續(xù)集成檢查表
如表2所示，作為一個開源項目，UCloud 資源編排工具共有三個質量周期，
– 開源協作周期，使用 Travis CI 進行代碼風格檢查和單元測試，不會發(fā)起真正的 API 請求；
– 合并主分支周期，UCloud 使用 Gitlab CI on Kubernetes 進行風格檢查、單元測試和集成測試，其中集成測試會調用現網 API 操作真正的云上資源，并在每天凌晨進行 Daily Regression；
– 發(fā)布正式 Release 到 Terraform 官方倉庫周期，合作方 Hashicorp 使用 TeamCity 進行全量驗收測試，當所有測試完成后，發(fā)布新版本。
為了保證代碼不會隨時間腐化，提前清除一些隱患，比如拼寫錯誤、安全密鑰泄露、抽象不合理等等，UCloud 接入產品團隊選取了三種不同維度的靜態(tài)檢查工具來量化代碼質量，其中包括：
– GoReportCard，用來做最基本的風格檢查
– SonarCloud，發(fā)現代碼的 Bug 和安全問題
– Gocyclo，計算函數的圈復雜度（圈復雜度是用來衡量一個函數復雜程度的指標，和控制流的復雜程度相關）
并通過周期性的代碼優(yōu)化，將代碼質量的量化指標始終維持在?A+ 評級。
圖11
寫在最后
經過長時間的發(fā)展，Terraform 已經成為一個業(yè)內通用的資源編排工具，且近年來海內外的友商也陸續(xù)開始支持基于 Terraform 的資源編排系統(tǒng)，證明了業(yè)內對通用資源編排系統(tǒng)的強需求。
UCloud 深入研究了 Terraform 的內部機理，并基于此為 UCloud 下一代資源編排系統(tǒng)進行了深度的探索，在研發(fā)過程中多次優(yōu)化，打通整個鏈路上的基礎工程建設，最后通過充分的質量工程實踐，為資源編排的可靠性與穩(wěn)定性保駕護航。UCloud Terraform 的具體使用細節(jié)和樣例請點擊閱讀原文至 UCloud 資源編排官方文檔查閱。
