服務(wù)器太多了不好管？UCloud基于Terraform的資源編排工具詳解

背景

隨著用戶在 UCloud 上資源用量的指數(shù)增長，傳統(tǒng) API/SDK 手動編寫腳本的資源管理方式已經(jīng)無法滿足其需要。為此，UCloud 研發(fā)團隊基于 Terraform 編寫了一套自己的資源編排工具，幫助用戶降低云上資源的管理成本，為其提供安全可靠、高度一致的產(chǎn)品使用體驗，盡可能消除遷移上云時的風險。

Terraform 代表了業(yè)界前沿的技術(shù)和標準，我們基于此，并配合 UCloud CLI 等工具，編寫了新一代 UCloud 資源編排工具，進一步拓展 Terraform 的功能，實現(xiàn)基礎(chǔ)設(shè)施可編程。在一個通過 ULB 卸載流量至云主機的案例中，相比于傳統(tǒng)方式，新方案下的構(gòu)建時間從原先的 3 分 20 秒縮短至 43 秒，編排的效率、穩(wěn)定性和可描述性都得到了顯著提升。

Terraform是什么?

Terraform 是 Hashicorp 公司開源的一種多云資源編排工具，目前已經(jīng)形成完整生態(tài)，并與AWS、Microsoft Azure、Google、阿里云以及UCloud等多家主流云廠商建立合作。

使用者通過一種特定的配置語言(HCL, Hashicorp Configuration Language)來描述基礎(chǔ)設(shè)施，由 Terraform 工具統(tǒng)一解析，構(gòu)建資源之間的關(guān)系，生成執(zhí)行計劃，并通過調(diào)用 UCloud 公有云 API 來完成整個基礎(chǔ)設(shè)施生命周期的管理。

相對于其它的云上資源管理方式，Terraform 的主要特點有：

1. 有廣泛的兼容性，目前海內(nèi)外累計已有超過 40 家公有云廠商支持，其中包括 UCloud 在內(nèi)的 4 家國內(nèi)云廠商，另有 200 多個軟件服務(wù)商為其提供支持。

2. 基于 IaC(基礎(chǔ)設(shè)施即代碼，Infrastructure as Code)的設(shè)計，可以將基礎(chǔ)設(shè)施以一種領(lǐng)域特定語言描述出來，消除了在基礎(chǔ)設(shè)施自動化時描述語義上的歧義，同時減輕人為因素造成的不確定影響。

3. Terraform 在執(zhí)行編排動作前，會生成一份可讀性良好的執(zhí)行計劃，關(guān)鍵基礎(chǔ)設(shè)施的變更可以得到充分審查，保證了基礎(chǔ)設(shè)施的可靠性。

4. 基于 DAG(有向無環(huán)圖，Directed Acyclic Graph)描述資源與資源之間的關(guān)系，由于 DAG 良好的拓撲性質(zhì)，當資源屬性與資源關(guān)系發(fā)生改變時，變更動作將被充分并行地執(zhí)行。

下圖是一張資源編排與傳統(tǒng)資源管理方式的對比表：

　　圖1：資源編排與傳統(tǒng)資源管理方式對比

可以看出，在自動化 DevOps 環(huán)境下，資源編排相對傳統(tǒng)資源管理方式具有明顯優(yōu)勢，目前已覆蓋了 IaaS 層的核心產(chǎn)品，但隨著時間的推移，將來 UCloud 資源編排會支持更多的產(chǎn)品。

應(yīng)用場景

用戶可以很容易的從Terraform受益，因為初始化云服務(wù)時若缺少資源編排工具，將投入大量的時間成本，而且對于云上資源的變更，往往需要很復雜的變更邏輯以保證基礎(chǔ)設(shè)施的安全性。

UCloud 資源編排工具能夠很好地解決如下常見的問題：

– CI/CD 自動化資源管理

– 高峰期應(yīng)用縮擴容

– 部署復雜資源拓撲(例如兩地三中心的應(yīng)用架構(gòu))

例如，驛氪作為一家SaaS解決方案提供商，已經(jīng)將UCloud Terraform編排系統(tǒng)接入自身業(yè)務(wù)。

下圖是驛氪業(yè)務(wù)架構(gòu)的示意圖。它同時使用了多家云服務(wù)，需要統(tǒng)一的資源管理平臺進行多云管理，而獨立研發(fā)一套資源管理平臺，需要對接各云廠商接口，同時還要研發(fā)人員深入了解各家云服務(wù)的產(chǎn)品細節(jié)，這無疑會加重企業(yè)的研發(fā)成本和運營成本。

　　圖2: 驛氪業(yè)務(wù)架構(gòu)的示意圖

而在應(yīng)對SaaS 業(yè)務(wù)時，Terraform可以靈活的動態(tài)調(diào)整資源，用戶只需要調(diào)整部分參數(shù)，就可以利用模板進行非常快速的資源管理，相較于自建管理平臺，UCloud Terraform可以極大節(jié)省用戶的運營成本和效率。

生命周期

以首次執(zhí)行 Terraform 創(chuàng)建 UCloud 云上資源為例，這一資源編排動作的生命周期如下圖所示：

　　圖3：Terraform 生命周期

圖中立方體所示分別為：

–Terraform 核心進程：負責資源定義文件，構(gòu)建有向無環(huán)圖，管理狀態(tài)存儲;

–Provider 進程：即提供資源編排能力的進程，包括由云廠商實現(xiàn)的能力(比如 UCloud 的資源編排實現(xiàn))，和應(yīng)用程序提供的能力(比如 TLS 自簽名證書)等;

–Provisioner 進程：即提供資源編排后處理操作的進程，比如執(zhí)行 Shell 命令，上傳文件等。

以中央的有向無環(huán)圖為分界線，左側(cè)的部分是 Terraform 本身提供的能力，右側(cè)是由云廠商提供的能力。

Terraform 核心的良好抽象，保證了資源編排的安全和穩(wěn)定，為 UCloud 資源編排提供了堅實的工程基礎(chǔ)。

UCloud資源編排實踐

在一個生產(chǎn)環(huán)境的資源編排系統(tǒng)中，往往要依賴數(shù)目龐大的云資源后臺管理服務(wù)。資源編排的工程實現(xiàn)中，以下幾個方面的根本訴求需要首先得到保障：

– 保障資源編排在復雜終端環(huán)境下的成功率。這個是最基本也是最核心的訴求。

– 保障產(chǎn)品的一致性。使用戶可以平滑遷移，變更無感知。

– 保障產(chǎn)品的工程質(zhì)量。資源編排作為關(guān)鍵基礎(chǔ)設(shè)施的接入方式，本身需要足夠穩(wěn)定可靠。

下文，我們將詳細分享 UCloud 在基于 Terraform 的資源編排工具研發(fā)中，在容錯能力、接入能力和工程能力優(yōu)化上的一些實踐。

容錯能力優(yōu)化

容錯能力是衡量系統(tǒng)可用性的一個重要維度，資源編排作為 UCloud 服務(wù)的入口，本身必須足夠穩(wěn)定，具有對故障可以做出合理應(yīng)對的能力，包括對上游服務(wù)異常的容錯能力，以及對于輸入異常的糾錯能力。

首先，Terraform 的殺手級特性是執(zhí)行計劃與過程分離，用戶在執(zhí)行真正的資源編排動作變更現(xiàn)網(wǎng)基礎(chǔ)設(shè)施之前，可以先生成執(zhí)行計劃，比較資源定義文件和當前資源狀態(tài)的差異，檢查關(guān)鍵基礎(chǔ)設(shè)施的變更。

UCloud 在實現(xiàn)資源編排的過程中，借助 Terraform 執(zhí)行計劃的 CustomDiff 特性，自定義了部分資源的 Diff 過程。比如，兩個地域之間僅能存在一條高速通道(UDPN)，如果執(zhí)行編排動作前已經(jīng)存在了一條高速通道(UDPN)，將會把所有的編排動作阻止在執(zhí)行計劃階段，提高終端用戶的使用效率。

　　圖4：自定義 Diff 以在執(zhí)行計劃中檢查輸入

對于錯誤的處理，UCloud 編排工具通過梳理整個編排工作流的生命周期，將錯誤信息嚴格壓縮在(動詞、附加動作、資源名、ID)這個形式化的四元組中，轉(zhuǎn)化為人類可讀的描述信息反饋給使用者，對于輸入異?？梢栽谔峁┮欢ǖ慕换ゼm錯能力的前提下，精確定位到源碼行。

　　圖5：錯誤信息四元組的自然語言表示樣例

其次，UCloud 通過下文介紹的 API 一致性工程，識別出了所有操作的冪等性質(zhì)(即該操作是否存在副作用，導致真正的資源創(chuàng)建)，并對所有冪等(無副作用的)操作執(zhí)行自動重試，大幅提升了編排工具的容錯能力，同時保證了自動重試機制是真正安全的。對于非冪等操作，得益于 Terraform 的狀態(tài)管理機制，可以簡單地重新執(zhí)行編排計劃，僅重試失敗的創(chuàng)建過程。

UCloud 編排工具還提供對于異步操作的同步封裝，使用 Terraform 內(nèi)建的等待機制，創(chuàng)建資源后，將會輪詢等待資源完成可以查詢方才返回成功，保證操作的原子性和資源狀態(tài)的一致性。

最后，對于上述的重試或等待機制，使用指數(shù)級增長的間隔(Exponential Backoff)，以及優(yōu)雅退出(Gracefully Shutdown)的方案，進一步提升資源編排的容錯能力。

接入能力優(yōu)化

基于 Terraform 的資源編排有一定固有的局限性，比如其本身更適合基礎(chǔ)設(shè)施的構(gòu)建，不適合 adhoc 的臨時日常工作，比如列表查詢和開關(guān)機這樣的操作。

如要批量重啟主機，使用 Terraform 的做法是使用 data source 查詢出對應(yīng)的數(shù)據(jù)，定義輸出變量，再將輸出變量值作為參數(shù)傳遞給外部的腳本。在這樣的即席查詢場景下，相對于 Ansible 等配置管理工具并沒有明顯的優(yōu)勢。

因此 UCloud 在資源編排之外，開發(fā)了 UCloud CLI 工具來擴展資源編排的能力。例如，使用 CLI 來查詢和重啟通過 UCloud 編排工具創(chuàng)建的資源：

　　圖6：使用 CLI 來查詢和重啟通過 UCloud 編排工具創(chuàng)建的資源

UCloud 實現(xiàn)了資源編排與 UCloud CLI 的集成，資源編排工具可以直接使用 CLI的權(quán)限配置信息。也可以通過編排工具的特性，調(diào)用 UCloud CLI 進行額外的資源管理操作。

　　圖7：Terraform 與 CLI 集成用法示例

打通資源編排與 UCloud CLI 之后，資源編排可以復用 CLI 即席查詢的能力，而CLI 可以復用資源編排所持有的資源拓撲信息，例如主機列表，網(wǎng)絡(luò) CIDR 信息等，極大拓展了雙方的的產(chǎn)品接入能力。

工程能力優(yōu)化

UCloud 資源編排從立項之初，就將終端用戶使用上的一致性和可用性作為核心訴求。要滿足這些訴求，在工程上必須攻破幾個關(guān)鍵的技術(shù)難關(guān)：

1. 盡可能使用戶實現(xiàn)跨版本、跨云的平滑遷移。

2. 同時對資源編排工具所依賴的基礎(chǔ) API 的實現(xiàn)自動化管理，從源頭上提高編排工具的可用性。

3. 資源編排作為關(guān)鍵基礎(chǔ)設(shè)施的接入方式，本身需要足夠的質(zhì)量保障措施。

· 平滑遷移

首先，對于資源編排工具的升級，UCloud 嚴格按照 Terraform 的 Schema 變更策略，每當資源的屬性有破壞性的變更，都會隨之提供版本遷移的實現(xiàn)，使終端用戶在升級工具時，自動將其資源狀態(tài)平滑遷移至新版本。

其次，對于云平臺之間的遷移，UCloud 實現(xiàn)了通用的風格轉(zhuǎn)換函數(shù)，通過將 UCloud 接口的大寫駝峰(Camel)命名，統(tǒng)一映射成 Terraform 常用的小寫下劃線(Snake)風格，并使用 Terraform 建議的產(chǎn)品命名法，降低用戶的跨云遷移成本。終端用戶只需要少量改動模板，即可通過資源編排工具平滑接入 UCloud。

· 變更自動化

資源編排作為 UCloud 重要的產(chǎn)品接入方式，對于 UCloud 全線產(chǎn)品都有很強的依賴，接口變更對接時的一點微小錯誤，都可能導致破壞性的后果。

所以一致性工程的重要目標是，快速響應(yīng)產(chǎn)品新特性的變更，同時盡可能降低人工成本，使變更自動化，減少錯誤的發(fā)生。

為了使 API 能夠得到統(tǒng)一管理，同時防止產(chǎn)品間豎井式的信息隔離，UCloud 很早以前就打造了公共、統(tǒng)一的 API 管理平臺，將所有現(xiàn)網(wǎng) API 的定義收斂至統(tǒng)一的 API 注冊中心上，使用自定義的格式來形式化地描述 API Schema。API 管理平臺將 API 的場景抽象成測試集(Test Set)，一次 API 的調(diào)用抽象成測試用例(Test Case)，并使用自定義的表達式語法構(gòu)造隨機的參數(shù)注入到用例中執(zhí)行。

　　圖8：API 管理平臺示意圖

基于 API 管理平臺，UCloud 資源編排團隊編寫了 API SDK 的自動化生成程序，通過嚴格形式化的 API 定義，轉(zhuǎn)譯成 Go SDK 代碼。同時通過編寫一個遞歸下降的表達式解析器，將測試用例中表達式語法，轉(zhuǎn)譯成等價的 Go 代碼。實現(xiàn)了 API 定義和 Go 代碼的直接映射，低成本同步上游變更。

　　圖9：通過編寫 API 建模工具轉(zhuǎn)譯 API SDK 代碼

此外在這個過程中，UCloud 通過在 API 管理平臺與 SDK 之間編寫 API 建模工具，用以抽象出一個中間層，在該層統(tǒng)一標注出 API 的冪等性質(zhì)，為資源編排工具提供了真正安全的重試機制。

這樣就完成了整個調(diào)用鏈路上的接口一致性工程建設(shè)，實現(xiàn)了從 API 管理平臺到 SDK 到 Terraform 的完整語義映射，降低了 SDK 的開發(fā)和維護成本，同時消除了人為變更帶來的不確定影響。

· 質(zhì)量工程建設(shè)

資源編排作為大規(guī)模云上資源管理的推薦方式，涉及到關(guān)鍵基礎(chǔ)設(shè)施的操作與管理，編排工具本身的質(zhì)量十分關(guān)鍵。

　　圖10：資源編排持續(xù)集成檢查表

如表2所示，作為一個開源項目，UCloud 資源編排工具共有三個質(zhì)量周期，

– 開源協(xié)作周期，使用 Travis CI 進行代碼風格檢查和單元測試，不會發(fā)起真正的 API 請求;

– 合并主分支周期，UCloud 使用 Gitlab CI on Kubernetes 進行風格檢查、單元測試和集成測試，其中集成測試會調(diào)用現(xiàn)網(wǎng) API 操作真正的云上資源，并在每天凌晨進行 Daily Regression;

– 發(fā)布正式 Release 到 Terraform 官方倉庫周期，合作方 Hashicorp 使用 TeamCity 進行全量驗收測試，當所有測試完成后，發(fā)布新版本。

為了保證代碼不會隨時間腐化，提前清除一些隱患，比如拼寫錯誤、安全密鑰泄露、抽象不合理等等，UCloud 接入產(chǎn)品團隊選取了三種不同維度的靜態(tài)檢查工具來量化代碼質(zhì)量，其中包括：

– GoReportCard，用來做最基本的風格檢查

– SonarCloud，發(fā)現(xiàn)代碼的 Bug 和安全問題

– Gocyclo，計算函數(shù)的圈復雜度(圈復雜度是用來衡量一個函數(shù)復雜程度的指標，和控制流的復雜程度相關(guān))

并通過周期性的代碼優(yōu)化，將代碼質(zhì)量的量化指標始終維持在A+ 評級。

　　圖11

寫在最后

經(jīng)過長時間的發(fā)展，Terraform 已經(jīng)成為一個業(yè)內(nèi)通用的資源編排工具，且近年來海內(nèi)外的友商也陸續(xù)開始支持基于 Terraform 的資源編排系統(tǒng)，證明了業(yè)內(nèi)對通用資源編排系統(tǒng)的強需求。

UCloud 深入研究了 Terraform 的內(nèi)部機理，并基于此為 UCloud 下一代資源編排系統(tǒng)進行了深度的探索，在研發(fā)過程中多次優(yōu)化，打通整個鏈路上的基礎(chǔ)工程建設(shè)，最后通過充分的質(zhì)量工程實踐，為資源編排的可靠性與穩(wěn)定性保駕護航。UCloud Terraform 的具體使用細節(jié)和樣例請點擊閱讀原文至 UCloud 資源編排官方文檔查閱。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。