SREWorks v1.3 版本發布 | 插件機制發布

2022 年 11 月 17 日
AI
深度學習

在v1.2版本發布之後，SREWorks團隊著手開始了v1.3版本的迭代。此次v1.3版本融合了較多用戶需求，以及對底座機制進行了較大調整和優化，故發版時間長了很多。下面讓我們切入正題，來看看這些大變化究竟是哪些？

1. 插件機制

插件包

在OAM應用體系中，組件(Component)和運維特徵(Trait)本身即屬於可插拔的部分。在v1.3版本中，SREWorks團隊優化了appmanager的載入機制，將這些插拔模組從appmanager的源碼中剝離出來，成為了獨立插件包。插件管理以及包結構如下圖：

├── definition.yaml                           /* 組件定義，描述了組件的元資訊 */
├── frontends
│   ├── deploy.json                           /* 組件部署時前端訂製交互 */
│   ├── build.json                            /* 組件構建方案的前端訂製交互 */
│   └── source.json                           /* 組件構建源的前端訂製交互 */
└── dynamicscripts
    ├── ComponentDeployHandler.groovy         /* 組件的部署腳本 */
    ├── ComponentBuildHandler.groovy          /* 組件的構建腳本 */
    ├── ComponentDestroyHandler.groovy        /* 組件運行時實例銷毀腳本 */
    └── ComponentHandler.groovy               /* 組件定義 */

在後續的小版本中，SREWorks團隊以及生態開發者們，會持續地將內置組件及運維特徵轉換成標準插件，預計遷移過程會持續1-2個版本。

鑒於當前插件的開發存在一定的學習門檻，v1.3版本還暫未對外公開插件的開發體系。待相應的開發者工具配套完善後，我們會將其與開發者手冊一起提供給社區。

插件可視化

通常一個插件會包含前端頁面，參照上圖插件的目錄結構，frontends目錄下即為插件獨有的前端訂製頁面。

以Helm組件為例，在選擇添加該組件後，用戶可以選擇兩種源，一種為該組件的訂製源：社區倉庫(Artifact Hub)，另外一種為通用源：程式碼倉庫。組件在進行構建的時候，appmanager會執行ComponentDeployHandler.groovy腳本，該腳本會自動從用戶選擇的源中拉取Helm包打包進應用包中。該組件添加可視化過程如下圖所示：

在完成組件添加之後，可以為該組件配置部署的參數基準線。這個參數基準線前端是由插件中的deploy.json控制：Helm的參數均被放置在values這個大變數中。同時，這些變數也可以利用OAM中的dataInputs機制由應用層的全局變數來傳入。

上述的一系列的配置完成後，OAM部署YAML(ApplicationConfiguration)會被自動生成，在應用構建頁面可以預覽到這份YAML文件。

PS: 這套插件的可視化機制也全部是利用前端低程式碼能力實現，有興趣的同學可以把企業應用管理(APP_ID: app)這個應用在【運維開發】中導入開發查看其前端低程式碼編排明細。

組件定義流程標準化

從插件可視化那裡，細心的同學可能會發現，我們的組件定義流程從單步變成了四步。是的，隨著組件的開發體系進一步完善，SREWorks團隊對組件的定義過程也進行了明確細化：

原本單步的組件定義拆了4+1步，4步如下圖所示

另外的+1步即組件部署基準線。SREWorks遵循OAM規範，將運維特徵(Trait)這種運行時(Runtime)的能力，嚴格地剝離到組件定義周期之外，作為部署基準線依附在組件上。比如一個組件需要使用Ingress或網關，這些與組件本身定義無關，只是運行時的運維特徵附加，而如果真的讓使用者到部署時候再去附加，又會增加部署的複雜度：於是以這種部署基準線的方式進行維護，使用者只需要在部署基準線之上，針對性地少量配置即可。

2. 應用機制優化

應用體系升級

SREWorks上線以來，由於【運維開發】中的應用和【應用開發】中的應用存在一些相似，會給使用者帶去一定的困擾，尤其是一些運維團隊。於是SREWorks團隊針對內部使用場景以及外部意見回饋，重新明確了一下這兩種應用，如下圖所示：

企業應用 -> 企業應用市場:

承載企業核心業務的雲原生應用
能夠被加持數智運維能力，展開進一步的數智化運維治理
市面上各類開源應用或大數據解決方案，會被以企業應用形式上架企業應用市場

運維應用 -> 運維應用市場:

使用SREWorks前端低程式碼模式構建的雲原生運維應用
能夠被快速嵌入集成運維中台能力
所有運維應用均經過開發及模型抽象，不會直接上架開源應用至運維應用市場。

企業應用市場

企業應用市場中的雲端倉庫在v1.3正式上線，依據上文的應用邊界定義，在企業應用市場上會上架各類開源應用的雲原生部署方案，讓使用者可以一鍵部署複雜應用支撐業務。

企業應用市場與運維應用市場使用同一套應用機制，應用包結構相同，但使用不同的連接串(endpoint)。同時在這套機制之上，也歡迎用戶構建自己的公司的雲原生應用市場。

運維應用市場

隨著應用體系的升級，原本內置運維應用也都被上架到了雲端運維應用市場。每個內置運維應用功能更新後，會被優先發布至雲端市場，用戶可以保持更快的更新頻率（運維應用的小版本迭代頻率會快於SREWorks大版本）。

同時後續版本中會進一步對SREWorks底座和運維應用進行解耦（底座不升級也可以通過雲端市場升級到最新），整體採取這樣的更新策略：底座更新頻率下降，運維應用更新頻率上升。

針對用戶回饋的孤島環境部署難的問題，我們在這個版本開放了離線運維應用包便捷導入導出的能力，進一步降低使用者應用交付門檻。如下圖為SREWorks 雲端/離線兩個應用分發渠道。

下圖為離線應用包的前端交互操作鏈路：

3. 前端組件自定義集成

很多用戶深度使用了運維應用的前端組件編排之後，覺得當前的通用前端組件還無法滿足需求，提出希望開發自己的前端組件。但進行嘗試的用戶需要將自行編寫的組件源碼合併到frontend的源碼目錄中重新編譯出包，這大大增加了用戶的開發成本。於是我們在底層結構上做了適配優化，支援組件可以用UMD包形態遠程載入。

這也就意味著，用戶可以直接將自己寫的組件打成UMD包，整個打包構建過程與frontend編譯無關，可以獨立完成。前端組件在構建完成後，支援在運維物料中一鍵快速導入，導入後使用體驗完全等同內置組件。

提供@sreworks/widget-cli 遠程組件開發腳手架，內置vue 和 react 工程初始化配置模板，用戶可根據自身技術棧自由選擇，將已有業務組件發布到npm或自定義私有倉庫，快捷集成使用，且方便版本管理，支援組件runtime在線升級更新。

4. 數據運維平台的流計算作業監控大盤

數據運維平台中的流計算部分基於開源VVP平台實現，由於其缺失有效的作業監控大盤，v1.3版本基於Grafana，以全託管方式新增VVP作業的監控大盤。

5. 其他

支援helm install SREWorks之後的進度跟蹤查詢
增加表格組件行高亮動態配置功能，支援5種顏色
增加前端組件: wordcloud 詞雲圖 / heatmap熱力圖，優化前端組件: Tab豎向過濾器支援
增加操作提交提示資訊自定義能力 //github.com/alibaba/SREWorks/issues/86
優化kankio容器構建機制
增加應用管理默認納管自身k8s集群
桌面背景伸縮適配優化

如何從當前版本升級到v1.3

升級包含底座，頁面可能會有5-10分鐘的不可訪問，請注意。
用戶自行開發的雲原生應用不會受影響(不重啟)，SREWorks網關到應用的流量會有中斷。

git clone //github.com/alibaba/sreworks.git -b v1.3 sreworks

cd sreworks
./sbin/upgrade-cluster.sh --kubeconfig="****"

如在使用過程中遇到問題，歡迎各位在GitHub中提出Issues或Pull requests。

SREWorks開源地址：//github.com/alibaba/sreworks

Tags: 深度學習

SREWorks v1.3 版本發布 | 插件機制發布

1. 插件機制