EulerMaker：構建 openEuler 全場景生態
引言
2022 年末，openEuler Summit 2022 上，中國 Linux 內核圈最有影響力的開發者之一——吳峰光博士做了名為《面向全場景操作系統的構建服務發布》的主題演講，正式向開發者披露了 openEuler 統一構建服務 EulerMaker。
Linux 中國開源社區就此采訪了吳峰光博士，為讀者挖掘到一些在峰會上亮相的 EulerMaker 背后的有趣細節。
?? 吳峰光博士是著名的 Linux 內核貢獻者、華為計算操作系統首席專家、openEuler 社區技術委員會委員。他在 Linux 內核領域上擁有卓越貢獻，在 I/O 和內存管理、內核測試服務方面做出了重要的貢獻。有關他的故事，可以參閱《新程序員》雜志的專訪《吳峰光殺進 Linux 內核》。
openEuler 的全場景
2021 年 9 月，openEuler 宣布將支持全場景，在服務器、云計算之外，還支持 IoT 和嵌入式場景，這就引來了很多人的關注，但也有一些懷疑的眼光。因為，服務器和嵌入式分處兩端，中間有著巨大的鴻溝。
“30 年前，服務器 OS、嵌入式 OS，界限非常清晰，像是兩個村，中間全是農田。但后來 IT 越來越深入千行百業，云、邊緣、IoT 興起，各種場景涌現，發生了交疊。所以我們認為這是一個新的歷史機會，來做一個全場景 OS。”吳峰光說。
?? 關于多場景的支持和融合，請參考我們之前對歐拉技術委員熊偉的采訪：《??操作系統專家解讀 openEuler 22.09 最新技術特性??》。
“要做全場景 OS，就引入了一個需求：原來的構建系統，如何轉化為全場景統一構建系統？”
什么是 OS 構建系統？
OS 構建系統以 OS 源代碼作為輸入，以用戶可安裝使用的軟件倉或OS鏡像作為輸出。
?? 服務器領域的 OBS、嵌入式領域的 Bitbake，是各自領域的代表性構建系統，歷史悠久。
為什么需要新的構建系統？
“openEuler 社區一開始是用 OBS 來構建的，”吳峰光介紹說，“OBS 最初由 SUSE 貢獻開源，功能強大。但隨著使用的深入，我們發現一些復雜的新需求很難在它上面改進，這就對 openEuler 的演進造成了困難。”
就一般的 OS 來說，OBS 構建可能夠用；但是當一個操作系統要支持全場景，復雜度就大大增加，對構建系統提出了更嚴苛的要求。
吳峰光博士對 OBS、Bitbake 做了深入調研。他解釋了這些老牌構建系統，為什么滿足不了openEuler的需求：
“服務器領域的 OBS 主打能力是什么？幾大主流的 Linux 發行版它都支持，比如可以給 Redhat 打包，也可以給 Debian 打包。兼容并包是它的核心設計目標，適應了 Linux 多樣化的現狀。但我們認為，多樣化在早期對 Linux 發展有利，但長期而言，Linux 生態的碎片化是一個需要被解決的問題。”
“嵌入式領域的 Bitbake 采用了面向任務和過程的 DSL 描述語言，這使得它非常靈活強大，但自由度和復雜性過高，以學習曲線陡峭知名。現在流行的理念是如 YAML、JSON 等通用、聲明式的配置語言，和函數式編程，以實現低門檻、易理解、可控可重復的構建過程。”
在吳峰光看來，在 30 年后的今天，構建系統有著新的時代目標。
2022 年 3 月，openEuler 團隊開始設計新的構建系統 EulerMaker。
EulerMaker 構建系統
OS 構建系統的核心流程是，用戶給定一組軟件包后，按照包依賴關系，對它們發起并行構建任務。“那么搭一個 Kubernetes 集群，上面疊加一個包構建調度模塊，是不是就可以了呢？”
“這里的包依賴管理和調度，的確非常復雜：既有源包的依賴，又有二進制包的依賴，還有構建環境的依賴；既有構建依賴，又有運行依賴，還有傳遞依賴；成千上萬的依賴關系，形成一個巨大的圖，要考慮怎么破環，把它變成一個有向無環圖（DAG），用于最大化并發調度。隨著包構建的推進，新輸出的 RPM 包需要成為之后 RPM 包構建的環境，還會提供新的依賴信息，動態更新這個 DAG 圖。還要考慮各種包構建的失敗情況，多用戶并發任務之間的干擾，或者任意機器、模塊隨時崩潰重啟后如何接力，避免單點故障，等等，這需要一整套精巧的架構設計。”
看到這樣的難題，可能有工程師大牛們要摩拳擦掌，躍躍欲試了。但是在難題面前，吳峰光不慌不忙，踩了一腳剎車——
“我們先把發動機放一邊，追根溯源，回到最初的那一個問題：用戶到底需要一輛什么車？”
做架構設計，首先要考慮用戶場景，然后推導出功能，最后才能確定數據和流程。設計時全盤考慮了所有的用戶需求，數據和流程在未來才會穩定，才不會變來變去。
“我們對用戶需求的考慮，真的全面了嗎？”
吳峰光繼續展開分析：“在 Linux 發展的最初階段，需求是簡單的：只要功能實現了，跑一下 gcc / make 能構建出來，用戶能用，構建系統的工作就完成了。那時侯 Linux 社區對測試不重視，也還沒有 CI / CD 的概念，測試基本全靠用戶踩坑。現在情況就不一樣了，時代的要求在提高：開發者期望有質量把控，要做測試，要有一整套的構建測試 CI / CD，要覆蓋一整個開發流程，一站式全部搞定，出來的 RPM 包已經是經過測試的、用戶能放心用的。這已經被開發者認為是標配，是開發者的正常預期。”
所以，新的構建系統要集成測試流程。
那么，是不是直接集成現在流行的通用 CI / CD 測試工具就可以了呢？
“市面上的 CI / CD 通用測試服務，適合測試上層的應用；而操作系統需要測試的，既有上層軟件，又有基礎軟件；既面向應用開發者，又面向內核開發者，還有軟件廠商、硬件廠商、OS 廠商，他們都有獨特的測試需求；既要做功能測試，還要做性能測試。這些不是市面上通用 CI / CD 能做的。”
“所以，我們需要一套全棧系統，既能構建，又滿足上述所有測試需求。”
早在 2020 年，吳峰光就綜合分析上述需求，設計了 Compass-CI。Compass-CI 被設計為一個通用的任務執行系統，可以執行構建、功能測試、性能測試等各類任務。Compass-CI 也被設計為一個異構調度系統，可以調度物理機、虛擬機、容器等各種資源。
“Compass-CI 已經在 2020 年上線服務，在這個基礎上補足構建相關的模塊，就可以作為 EulerMaker 的后端，服務 openEuler 的構建。”
“當我們可以用一套系統，來服務好業界各方的需求，就會有硬件廠商問我們，能不能遠程接入他們的硬件？然后，我們就需要支持工作機遠程接入，分布式調度，數據共享，立足云端，連接各類線下機房，x86、ARM 等各類硬件，方便開發者之間、廠商之間、開發者與廠商之間的分布式協作。”
“資源有了，功能有了，開發者來了，也會有很多需求：我打包了，能不能看見進展？出問題了能不能復現當時的環境？能不能登錄調試修復？能不能 DIY 驗證？這些需求都需要一一滿足大家。現在 EulerMaker 的可視化界面可以顯示構建的進展，每個包會顯示其依賴關系圖以及其構建的進度，哪些包已經構建了，哪些包還沒有構建，預計還有多少分鐘，它前面還有哪幾個依賴都一目了然。而且每個開發者都可以有專屬隊列，可以大大縮短等待時間。”
EulerMaker 怎么解決全場景
一個 OS 怎么支持全場景？
“首先這個 OS 要足夠通用。但這還不夠。”吳峰光繼續說到：“一個通用的 OS，所帶的軟件往往要求大而全，把常見的功能都編進去。但很多場合有著不同的需求，比如啟用一個不常用的功能，或者在嵌入式設備上，因為資源受限，需要把不必要的功能裁減掉。”
一個通用軟件，往往會提供一組編譯期的定制功能，方便不同場景的開發者和用戶針對自己的需求，構建出不同功能組合的二進制程序。
“類似的，當我們說一個 OS 支持全場景，是只需維護一套 OS 源代碼，通過源碼級 + 鏡像級定制，即可構建生成各類場景化的二進制 OS 發布。強大的定制能力，是賦能一套 OS 源碼支持全場景的‘究極魔法’。”
吳峰光進一步介紹什么是定制能力：
“最簡單的定制能力，體現在軟件打包上，就是對用戶提供定制選項。一般是把上游軟件的可選功能做一個封裝，讓用戶在做包構建的時候可以打開或者關閉。比如 RPM SPEC 文件中通過宏定義了 ??%{with xxx}?? 選項，用戶就可以通過 ??rpmbuild --with xxx?? 來打開 ??xxx?? 選項對應的軟件功能。”
“然而 SPEC 文件中往往只封裝了少量選項，對于沒有被 SPEC 維護者封裝的上游軟件功能，用戶就只好自行修改 SPEC 文件來實現定制，這樣就很雜亂了。”
“事實上 OS 的用戶和場景多種多樣，他們需要的定制項，往往遠超包維護者所能提供。比如有人想升級版本號，有人想加個補丁，有人想加個編譯選項，或者修改編譯器。我們需要一種開放式的定制規范，即允許用戶在不修改打包文件的情況下，實現對打包文件的定制，且允許定制任意字段，不限于包維護者事先提供的一個封閉選項集合。”
“這時候就會發現 SPEC 文件的定制能力不夠用了。”
EulerMaker 怎么解決這個問題呢？
“我們引入了開發者們都很熟悉的 YAML 配置語言，用它來聲明式的描述一個軟件包。然后允許用戶再定義一個 YAML 文件，來選擇性覆蓋或者修改 OS 軟件包 YAML 文件里的任意字段。這樣不但實現了開放式定制，而且用戶定制選項都可以以 YAML 配置文件的形式，集中存儲管理，或者代碼化 Git 管理。”
不過，事情并沒有這么簡單。
“當用戶可以非常方便的定制任意字段，隨之而來一個風險：很多包字段之間有條件依賴和約束，用戶一不小心，就容易在不知情的情況下，破壞一些關聯約束。在過去，很多這種約束在 Git 日志里隱式維護的。比如開發者首先修改一個 SPEC 文件里的版本號，同時去掉一個只適用于老版本的補丁，完成對軟件包的一次升級。當暴露在定制環境下，這就是一大脆弱性，會造成事實上難以自由定制。”
而 EulerMaker 的解決辦法，是把該補丁適用的版本范圍，用條件語句顯式的寫在軟件包 YAML 里。“這樣用戶隨便改版本號，都不會出錯，其它關聯字段會自適應的變化，從而實現定制自由。”
如此一來，定制能力是強大了，那么易用性又如何？
“一般用戶要的不是一堆零件，而是套裝。成千上萬的定制項，小白用戶眼花繚亂，不知道拿它們怎么辦，他可能只知道我用的是 OrangePI，那有沒有對應的一組定制項可以拿來就用的？”
針對這個問題，EulerMaker 的解決思路如下：
“這組定制項，要由這個專業領域的開發者或者廠商，在社區里提供，我們稱之為一個定制層。每一種硬件、場景都可以有這樣一個個的定制層。這樣場景化 OS 的開發任務就簡化為，菜單式選擇所需的層，像搭積木一樣組合，輕松完成 OS 的場景化分層定制。”
以上，就是 EulerMaker 解決全場景的整體思路。最后，吳峰光總結說：
“一個好用的全場景 OS，一定會是一種生態協作的組織形態。首先把各個場景的公共知識下沉到 BaseOS，統一描述，匯聚復雜枯燥的字段間條件依賴，方便在各個場景中復用。然后創建一個個薄薄的場景化定制層，簡單描述各場景下“我要什么”的問題。BaseOS + 多樣化場景層，成為 openEuler 社區共同維護和提供的公共組件，通過搭積木的方式，讓開發者的 DIY 菜單式定制，成就一個輕松愉悅的 OS 創造體驗。”
為了讓讀者們對分層定制有一個直觀的概念，吳峰光舉了兩個例子：
1、Redis 容器裁剪：
redis.yaml 示例
該示例使用不到十行的 YAML，即可裁剪出 1MB 的 Redis 。
2、內核定制維護：
kernel.yaml 示例
該示例使用一個 YAML 文件，兩行搞定Linux內核的定制維護。
“比如您在一家大公司的基礎設施團隊，需要在 openEuler 基礎上定制 Linux 內核，改一下版本，加一個補丁。在過去，您可能需要拷貝一份 ??kernel.spec??，然后直接在上面修改。這意味著維護上百行的 SPEC 文件，且時不時要從上游回合新的改進，這一過程枯燥而繁瑣。現在從 Fork 模式轉為搭積木模式，只需維護好一個小小的 ??kernel.yaml?? 文件。然后每次拉新的 BaseOS 重新構建，都會自動拿到上游歐拉內核的最新錯誤修復。這樣就很好的降低了開發維護成本，提高了安全性。是一種更加可持續的上下游協同演進方式。”
統一的包格式
在吳峰光的介紹中，我發現了一件令我很感興趣的事情，就是 openEuler 在探索自己獨有的軟件包規范。
我們知道，openEuler 現在采用的是業界主流的軟件包格式之一：RPM 。這種軟件包格式不僅僅被 Redhat Linux 使用，也被 openSUSE、OpenMandriva、Oracle Linux、Tizen 等使用。
而在 openEuler 中，RPM 軟件包不僅僅用在我們熟知的服務器、云計算領域，還應用在其它場景中，比如嵌入式。
為了一統軟件包的定義，openEuler 采用了新的 YAML 配置語言進行包描述，并接管 RPM 的 SPEC 文件，成為新的開發者界面。吳峰光說，SPEC 文件中采用了大量復雜的宏定義，而 EulerMaker 將這些復雜性隱藏到YAML后面。換言之，openEuler 新的統一構建系統采用的 YAML 配置語言制定了一種更通用、更靈活的包定義。
這是不是代表著 openEuler 會逐漸發展自己的軟件包格式？吳峰光表示，在保持兼容性的同時，openEuler 會走出一條自己的路。
別出心裁創建一種新的包格式容易，但是能在兼容既有架構的基礎上，又能開拓新的特性，乃至于支持更廣泛的場景，這應該很值得期待。
邁向開源開放
經過半年的努力，統一構建系統服務 EulerMaker 已經上線，已經在歐拉社區發揮作用，但是作為一個開源社區的產物，筆者更希望看到它能開源出來，惠及更廣大的開源社區，也接受開源社區的批評和貢獻。對此，吳峰光博士表示，一定是會開源的，但是目前還需要進一步打磨成熟。對于這樣的回應，筆者很認可，畢竟吳峰光博士對開源社區的貢獻一向以精益求精而著稱。非常期待能早日見到一個強大而完善的統一構建系統開源出來。
