EulerMaker：構(gòu)建openEuler全場景生態(tài)

導讀：2022 年末，openEuler Summit 2022 上吳峰光博士正式向開發(fā)者披露了 openEuler 統(tǒng)一構(gòu)建服務 EulerMaker。

引言

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

Linux 中國開源社區(qū)就此采訪了吳峰光博士，為讀者挖掘到一些在峰會上亮相的 EulerMaker 背后的有趣細節(jié)。

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

openEuler 的全場景

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

“30 年前，服務器 OS、嵌入式 OS，界限非常清晰，像是兩個村，中間全是農(nóng)田。但后來 IT 越來越深入千行百業(yè)，云、邊緣、IoT 興起，各種場景涌現(xiàn)，發(fā)生了交疊。所以我們認為這是一個新的歷史機會，來做一個全場景 OS。”吳峰光說。

關(guān)于多場景的支持和融合，請參考我們之前對歐拉技術(shù)委員熊偉的采訪：《操作系統(tǒng)專家解讀 openEuler 22.09 最新技術(shù)特性》。

“要做全場景 OS，就引入了一個需求：原來的構(gòu)建系統(tǒng)，如何轉(zhuǎn)化為全場景統(tǒng)一構(gòu)建系統(tǒng)？”

什么是 OS 構(gòu)建系統(tǒng)？

OS 構(gòu)建系統(tǒng)以 OS 源代碼作為輸入，以用戶可安裝使用的軟件倉或OS鏡像作為輸出。

服務器領(lǐng)域的 OBS、嵌入式領(lǐng)域的 Bitbake，是各自領(lǐng)域的代表性構(gòu)建系統(tǒng)，歷史悠久。

為什么需要新的構(gòu)建系統(tǒng)？

“openEuler 社區(qū)一開始是用 OBS 來構(gòu)建的，”吳峰光介紹說，“OBS 最初由 SUSE 貢獻開源，功能強大。但隨著使用的深入，我們發(fā)現(xiàn)一些復雜的新需求很難在它上面改進，這就對 openEuler 的演進造成了困難?！?/p>

就一般的 OS 來說，OBS 構(gòu)建可能夠用；但是當一個操作系統(tǒng)要支持全場景，復雜度就大大增加，對構(gòu)建系統(tǒng)提出了更嚴苛的要求。

吳峰光博士對 OBS、Bitbake 做了深入調(diào)研。他解釋了這些老牌構(gòu)建系統(tǒng)，為什么滿足不了openEuler的需求：

“服務器領(lǐng)域的 OBS 主打能力是什么？幾大主流的 Linux 發(fā)行版它都支持，比如可以給 Redhat 打包，也可以給 Debian 打包。兼容并包是它的核心設計目標，適應了 Linux 多樣化的現(xiàn)狀。但我們認為，多樣化在早期對 Linux 發(fā)展有利，但長期而言，Linux 生態(tài)的碎片化是一個需要被解決的問題。”

“嵌入式領(lǐng)域的 Bitbake 采用了面向任務和過程的 DSL 描述語言，這使得它非常靈活強大，但自由度和復雜性過高，以學習曲線陡峭知名?，F(xiàn)在流行的理念是如 YAML、JSON 等通用、聲明式的配置語言，和函數(shù)式編程，以實現(xiàn)低門檻、易理解、可控可重復的構(gòu)建過程?！?/p>

在吳峰光看來，在 30 年后的今天，構(gòu)建系統(tǒng)有著新的時代目標。

2022 年 3 月，openEuler 團隊開始設計新的構(gòu)建系統(tǒng) EulerMaker。

EulerMaker 構(gòu)建系統(tǒng)

OS 構(gòu)建系統(tǒng)的核心流程是，用戶給定一組軟件包后，按照包依賴關(guān)系，對它們發(fā)起并行構(gòu)建任務。“那么搭一個 Kubernetes 集群，上面疊加一個包構(gòu)建調(diào)度模塊，是不是就可以了呢？”

“這里的包依賴管理和調(diào)度，的確非常復雜：既有源包的依賴，又有二進制包的依賴，還有構(gòu)建環(huán)境的依賴；既有構(gòu)建依賴，又有運行依賴，還有傳遞依賴；成千上萬的依賴關(guān)系，形成一個巨大的圖，要考慮怎么破環(huán)，把它變成一個有向無環(huán)圖（DAG），用于最大化并發(fā)調(diào)度。隨著包構(gòu)建的推進，新輸出的 RPM 包需要成為之后 RPM 包構(gòu)建的環(huán)境，還會提供新的依賴信息，動態(tài)更新這個 DAG 圖。還要考慮各種包構(gòu)建的失敗情況，多用戶并發(fā)任務之間的干擾，或者任意機器、模塊隨時崩潰重啟后如何接力，避免單點故障，等等，這需要一整套精巧的架構(gòu)設計?！?/p>

看到這樣的難題，可能有工程師大牛們要摩拳擦掌，躍躍欲試了。但是在難題面前，吳峰光不慌不忙，踩了一腳剎車——

“我們先把發(fā)動機放一邊，追根溯源，回到最初的那一個問題：用戶到底需要一輛什么車？”

做架構(gòu)設計，首先要考慮用戶場景，然后推導出功能，最后才能確定數(shù)據(jù)和流程。設計時全盤考慮了所有的用戶需求，數(shù)據(jù)和流程在未來才會穩(wěn)定，才不會變來變?nèi)ァ?/p>

“我們對用戶需求的考慮，真的全面了嗎？”

吳峰光繼續(xù)展開分析：“在 Linux 發(fā)展的最初階段，需求是簡單的：只要功能實現(xiàn)了，跑一下 gcc / make 能構(gòu)建出來，用戶能用，構(gòu)建系統(tǒng)的工作就完成了。那時侯 Linux 社區(qū)對測試不重視，也還沒有 CI / CD 的概念，測試基本全靠用戶踩坑?，F(xiàn)在情況就不一樣了，時代的要求在提高：開發(fā)者期望有質(zhì)量把控，要做測試，要有一整套的構(gòu)建測試 CI / CD，要覆蓋一整個開發(fā)流程，一站式全部搞定，出來的 RPM 包已經(jīng)是經(jīng)過測試的、用戶能放心用的。這已經(jīng)被開發(fā)者認為是標配，是開發(fā)者的正常預期?！?/p>

所以，新的構(gòu)建系統(tǒng)要集成測試流程。

那么，是不是直接集成現(xiàn)在流行的通用 CI / CD 測試工具就可以了呢？

“市面上的 CI / CD 通用測試服務，適合測試上層的應用；而操作系統(tǒng)需要測試的，既有上層軟件，又有基礎軟件；既面向應用開發(fā)者，又面向內(nèi)核開發(fā)者，還有軟件廠商、硬件廠商、OS 廠商，他們都有獨特的測試需求；既要做功能測試，還要做性能測試。這些不是市面上通用 CI / CD 能做的?！?/p>

“所以，我們需要一套全棧系統(tǒng)，既能構(gòu)建，又滿足上述所有測試需求?！?/p>

早在 2020 年，吳峰光就綜合分析上述需求，設計了 Compass-CI。Compass-CI 被設計為一個通用的任務執(zhí)行系統(tǒng)，可以執(zhí)行構(gòu)建、功能測試、性能測試等各類任務。Compass-CI 也被設計為一個異構(gòu)調(diào)度系統(tǒng)，可以調(diào)度物理機、虛擬機、容器等各種資源。

“Compass-CI 已經(jīng)在 2020 年上線服務，在這個基礎上補足構(gòu)建相關(guān)的模塊，就可以作為 EulerMaker 的后端，服務 openEuler 的構(gòu)建。”

“當我們可以用一套系統(tǒng)，來服務好業(yè)界各方的需求，就會有硬件廠商問我們，能不能遠程接入他們的硬件？然后，我們就需要支持工作機遠程接入，分布式調(diào)度，數(shù)據(jù)共享，立足云端，連接各類線下機房，x86、ARM 等各類硬件，方便開發(fā)者之間、廠商之間、開發(fā)者與廠商之間的分布式協(xié)作?！?/p>

“資源有了，功能有了，開發(fā)者來了，也會有很多需求：我打包了，能不能看見進展？出問題了能不能復現(xiàn)當時的環(huán)境？能不能登錄調(diào)試修復？能不能 DIY 驗證？這些需求都需要一一滿足大家?，F(xiàn)在 EulerMaker 的可視化界面可以顯示構(gòu)建的進展，每個包會顯示其依賴關(guān)系圖以及其構(gòu)建的進度，哪些包已經(jīng)構(gòu)建了，哪些包還沒有構(gòu)建，預計還有多少分鐘，它前面還有哪幾個依賴都一目了然。而且每個開發(fā)者都可以有專屬隊列，可以大大縮短等待時間?！?/p>

EulerMaker 怎么解決全場景

一個 OS 怎么支持全場景？

“首先這個 OS 要足夠通用。但這還不夠?！眳欠骞饫^續(xù)說到：“一個通用的 OS，所帶的軟件往往要求大而全，把常見的功能都編進去。但很多場合有著不同的需求，比如啟用一個不常用的功能，或者在嵌入式設備上，因為資源受限，需要把不必要的功能裁減掉。”

一個通用軟件，往往會提供一組編譯期的定制功能，方便不同場景的開發(fā)者和用戶針對自己的需求，構(gòu)建出不同功能組合的二進制程序。

“類似的，當我們說一個 OS 支持全場景，是只需維護一套 OS 源代碼，通過源碼級 + 鏡像級定制，即可構(gòu)建生成各類場景化的二進制 OS 發(fā)布。強大的定制能力，是賦能一套 OS 源碼支持全場景的‘究極魔法’。”

吳峰光進一步介紹什么是定制能力：

“最簡單的定制能力，體現(xiàn)在軟件打包上，就是對用戶提供定制選項。一般是把上游軟件的可選功能做一個封裝，讓用戶在做包構(gòu)建的時候可以打開或者關(guān)閉。比如 RPM SPEC 文件中通過宏定義了%{with xxx}選項，用戶就可以通過rpmbuild --with xxx來打開xxx選項對應的軟件功能。”

“然而 SPEC 文件中往往只封裝了少量選項，對于沒有被 SPEC 維護者封裝的上游軟件功能，用戶就只好自行修改 SPEC 文件來實現(xiàn)定制，這樣就很雜亂了。”

“事實上 OS 的用戶和場景多種多樣，他們需要的定制項，往往遠超包維護者所能提供。比如有人想升級版本號，有人想加個補丁，有人想加個編譯選項，或者修改編譯器。我們需要一種開放式的定制規(guī)范，即允許用戶在不修改打包文件的情況下，實現(xiàn)對打包文件的定制，且允許定制任意字段，不限于包維護者事先提供的一個封閉選項集合?！?/p>

“這時候就會發(fā)現(xiàn) SPEC 文件的定制能力不夠用了?！?/p>

EulerMaker 怎么解決這個問題呢？

“我們引入了開發(fā)者們都很熟悉的 YAML 配置語言，用它來聲明式的描述一個軟件包。然后允許用戶再定義一個 YAML 文件，來選擇性覆蓋或者修改 OS 軟件包 YAML 文件里的任意字段。這樣不但實現(xiàn)了開放式定制，而且用戶定制選項都可以以 YAML 配置文件的形式，集中存儲管理，或者代碼化 Git 管理?！?/p>

不過，事情并沒有這么簡單。

“當用戶可以非常方便的定制任意字段，隨之而來一個風險：很多包字段之間有條件依賴和約束，用戶一不小心，就容易在不知情的情況下，破壞一些關(guān)聯(lián)約束。在過去，很多這種約束在 Git 日志里隱式維護的。比如開發(fā)者首先修改一個 SPEC 文件里的版本號，同時去掉一個只適用于老版本的補丁，完成對軟件包的一次升級。當暴露在定制環(huán)境下，這就是一大脆弱性，會造成事實上難以自由定制?！?/p>

而 EulerMaker 的解決辦法，是把該補丁適用的版本范圍，用條件語句顯式的寫在軟件包 YAML 里?！斑@樣用戶隨便改版本號，都不會出錯，其它關(guān)聯(lián)字段會自適應的變化，從而實現(xiàn)定制自由?！?/p>

如此一來，定制能力是強大了，那么易用性又如何？

“一般用戶要的不是一堆零件，而是套裝。成千上萬的定制項，小白用戶眼花繚亂，不知道拿它們怎么辦，他可能只知道我用的是 OrangePI，那有沒有對應的一組定制項可以拿來就用的？”

針對這個問題，EulerMaker 的解決思路如下：

“這組定制項，要由這個專業(yè)領(lǐng)域的開發(fā)者或者廠商，在社區(qū)里提供，我們稱之為一個定制層。每一種硬件、場景都可以有這樣一個個的定制層。這樣場景化 OS 的開發(fā)任務就簡化為，菜單式選擇所需的層，像搭積木一樣組合，輕松完成 OS 的場景化分層定制?！?/p>

以上，就是 EulerMaker 解決全場景的整體思路。最后，吳峰光總結(jié)說：

“一個好用的全場景 OS，一定會是一種生態(tài)協(xié)作的組織形態(tài)。首先把各個場景的公共知識下沉到 BaseOS，統(tǒng)一描述，匯聚復雜枯燥的字段間條件依賴，方便在各個場景中復用。然后創(chuàng)建一個個薄薄的場景化定制層，簡單描述各場景下“我要什么”的問題。BaseOS + 多樣化場景層，成為 openEuler 社區(qū)共同維護和提供的公共組件，通過搭積木的方式，讓開發(fā)者 DIY 菜單式定制，成就一個輕松愉悅的 OS 創(chuàng)造體驗?！?/p>

為了讓讀者們對分層定制有一個直觀的概念，吳峰光舉了兩個例子：

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 。

2、內(nèi)核定制維護：

env.kconfig: CONFIG_BTRFS_FS=y

patchset.my-xxx-improve: xxx.patch

kernel.yaml 示例

該示例使用一個 YAML 文件，兩行搞定 Linux 內(nèi)核的定制維護。

“比如您在一家大公司的基礎設施團隊，需要在 openEuler 基礎上定制 Linux 內(nèi)核，改一下 kconfig，加一個補丁。在過去，您可能需要拷貝一份kernel.spec，然后直接在上面修改。這意味著維護上百行的 SPEC 文件，且時不時要從上游回合新的改進，這一過程枯燥而繁瑣?，F(xiàn)在從 Fork 模式轉(zhuǎn)為搭積木模式，只需維護好一個小小的kernel.yaml文件。然后每次拉新的 BaseOS 重新構(gòu)建，都會自動拿到上游歐拉內(nèi)核的最新錯誤修復。這樣就很好的降低了開發(fā)維護成本，提高了安全性。是一種更加可持續(xù)的上下游協(xié)同演進方式?！?/p>

統(tǒng)一的包格式

在吳峰光的介紹中，我發(fā)現(xiàn)了一件令我很感興趣的事情，就是 openEuler 在探索自己獨有的軟件包規(guī)范。

我們知道，openEuler 現(xiàn)在采用的是業(yè)界主流的軟件包格式之一：RPM 。這種軟件包格式不僅僅被 Redhat Linux 使用，也被 openSUSE、OpenMandriva、Oracle Linux、Tizen 等使用。

而在 openEuler 中，RPM 軟件包不僅僅用在我們熟知的服務器、云計算領(lǐng)域，還應用在其它場景中，比如嵌入式。

為了一統(tǒng)軟件包的定義，openEuler 采用了新的 YAML 配置語言進行包描述，并接管 RPM 的 SPEC 文件，成為新的開發(fā)者界面。吳峰光說，SPEC 文件中采用了大量復雜的宏定義，而 EulerMaker 將這些復雜性隱藏到Y(jié)AML后面。換言之，openEuler 新的統(tǒng)一構(gòu)建系統(tǒng)采用的 YAML 配置語言制定了一種更通用、更靈活的包定義。

這是不是代表著 openEuler 會逐漸發(fā)展自己的軟件包格式？吳峰光表示，在保持兼容性的同時，openEuler 會走出一條自己的路。

別出心裁創(chuàng)建一種新的包格式容易，但是能在兼容既有架構(gòu)的基礎上，又能開拓新的特性，乃至于支持更廣泛的場景，這應該很值得期待。

邁向開源開放

經(jīng)過半年的努力，統(tǒng)一構(gòu)建系統(tǒng)服務 EulerMaker 已經(jīng)上線，已經(jīng)在歐拉社區(qū)發(fā)揮作用，但是作為一個開源社區(qū)的產(chǎn)物，筆者更希望看到它能開源出來，惠及更廣大的開源社區(qū)，也接受開源社區(qū)的批評和貢獻。對此，吳峰光博士表示，一定是會開源的，但是目前還需要進一步打磨成熟。對于這樣的回應，筆者很認可，畢竟吳峰光博士對開源社區(qū)的貢獻一向以精益求精而著稱。非常期待能早日見到一個強大而完善的統(tǒng)一構(gòu)建系統(tǒng)開源出來。

審核編輯 ：李倩