背景

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

Terraform 代表了業(yè)界前沿的技術(shù)和標(biāo)準(zhǔn)，我們基于此，并配合 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 良好的拓?fù)湫再|(zhì)，當(dāng)資源屬性與資源關(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ù)時若缺少資源編排工具，將投入大量的時間成本，而且對于云上資源的變更，往往需要很復(fù)雜的變更邏輯以保證基礎(chǔ)設(shè)施的安全性。

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

– CI/CD 自動化資源管理

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

– 部署復(fù)雜資源拓?fù)?例如兩地三中心的應(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)品細(xì)節(jié)，這無疑會加重企業(yè)的研發(fā)成本和運營成本。

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

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

生命周期

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

　　圖3：Terraform 生命周期

圖中立方體所示分別為：

–Terraform 核心進程：負(fù)責(zé)資源定義文件，構(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)中，以下幾個方面的根本訴求需要首先得到保障：

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

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

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

下文，我們將詳細(xì)分享 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í)行計劃，比較資源定義文件和當(dāng)前資源狀態(tài)的差異，檢查關(guān)鍵基礎(chǔ)設(shè)施的變更。

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

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

對于錯誤的處理，UCloud 編排工具通過梳理整個編排工作流的生命周期，將錯誤信息嚴(yán)格壓縮在(動詞、附加動作、資源名、ID)這個形式化的四元組中，轉(zhuǎn)化為人類可讀的描述信息反饋給使用者，對于輸入異常可以在提供一定的交互糾錯能力的前提下，精確定位到源碼行。

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

其次，UCloud 通過下文介紹的 API 一致性工程，識別出了所有操作的冪等性質(zhì)(即該操作是否存在副作用，導(dǎo)致真正的資源創(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 之后，資源編排可以復(fù)用 CLI 即席查詢的能力，而CLI 可以復(fù)用資源編排所持有的資源拓?fù)湫畔?，例如主機列表，網(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 嚴(yán)格按照 Terraform 的 Schema 變更策略，每當(dāng)資源的屬性有破壞性的變更，都會隨之提供版本遷移的實現(xiàn)，使終端用戶在升級工具時，自動將其資源狀態(tài)平滑遷移至新版本。

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

· 變更自動化

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

所以一致性工程的重要目標(biāo)是，快速響應(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)，并使用自定義的表達(dá)式語法構(gòu)造隨機的參數(shù)注入到用例中執(zhí)行。

　　圖8：API 管理平臺示意圖

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

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

此外在這個過程中，UCloud 通過在 API 管理平臺與 SDK 之間編寫 API 建模工具，用以抽象出一個中間層，在該層統(tǒng)一標(biāo)注出 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ēng)格檢查和單元測試，不會發(fā)起真正的 API 請求;

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

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

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

– GoReportCard，用來做最基本的風(fēng)格檢查

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

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

并通過周期性的代碼優(yōu)化，將代碼質(zhì)量的量化指標(biāo)始終維持在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 的具體使用細(xì)節(jié)和樣例請點擊閱讀原文至 UCloud 資源編排官方文檔查閱。

生成海報

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