EulerMaker：構建 openEuler 全場景生態

引言

2022 年末，openEuler Summit 2022 上，中國 Linux 內核圈最有影響力的開發者之一——吳峰光博士做了名為《面向全場景操作系統的構建服務發布》的主題演講，正式向開發者披露了 openEuler 統一構建服務 EulerMaker。

Linux 中國開源社區就此採訪了吳峰光博士，為讀者挖掘到一些在峰會上亮相的 EulerMaker 背後的有趣細節。

? 吳峰光博士是著名的 Linux 內核貢獻者、華為計算操作系統首席專家、openEuler 社區技術委員會委員。他在 Linux 內核領域上擁有卓越貢獻，在 I/O 和內存管理、內核測試服務方面做出了重要的貢獻。有關他的故事，可以參閱《新程序員》雜誌的專訪《吳峰光殺進 Linux 內核》。

openEuler 的全場景

2021 年 9 月，openEuler 宣布將支持全場景，在伺服器、雲計算之外，還支持編譯計算和嵌入式場景，這就引來了很多人的關注，但也有一些懷疑的眼光。因為，伺服器和嵌入式分處兩端，中間有著巨大的鴻溝。

「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 容器裁剪：

env.CC: /usr/bin/musl-gcc -static
env.CFLAGS: -I/usr/musl/include
env.LDFLAGS: -L/usr/musl/lib

buildRequires:
    - musl-gcc

subpackage.redis-server:
    meta.summary: redis-server
    files: %{_bindir}/%{name}-server

redis.yaml 示例

該示例使用十行 YAML，即可裁剪出 1MB 的 Redis 。

​以下視頻演示了分層定製 Redis 的過程：

2、內核定製維護：

env.kconfig: CONFIG_BTRFS_FS=y
patchset.my-xxx-improve: xxx.patch

kernel.yaml 示例

該示例使用一個 YAML 文件，兩行搞定 Linux 內核的定製維護。

「比如您在一家大公司的基礎設施團隊，需要在 openEuler 基礎上定製 Linux 內核，改一下 kconfig，加一個補丁。在過去，您可能需要拷貝一份 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 已經上線，已經在歐拉社區發揮作用，但是作為一個開源社區的產物，筆者更希望看到它能開源出來，惠及更廣大的開源社區，也接受開源社區的批評和貢獻。對此，吳峰光博士表示，一定是會開源的，但是目前還需要進一步打磨成熟。對於這樣的回應，筆者很認可，畢竟吳峰光博士對開源社區的貢獻一向以精益求精而著稱。非常期待能早日見到一個強大而完善的統一構建系統開源出來。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive