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

引言

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

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

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

openEuler 的全場(chǎng)景

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

“30 年前，服務(wù)器 OS、嵌入式 OS，界限非常清晰，像是兩個(gè)村，中間全是農(nóng)田。但后來 IT 越來越深入千行百業(yè)，云、邊緣、IoT 興起，各種場(chǎng)景涌現(xiàn)，發(fā)生了交疊。所以我們認(rèn)為這是一個(gè)新的歷史機(jī)會(huì)，來做一個(gè)全場(chǎng)景 OS?！眳欠骞庹f。

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

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

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

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

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

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

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

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

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

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

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

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

2022 年 3 月，openEuler 團(tuán)隊(duì)開始設(shè)計(jì)新的構(gòu)建系統(tǒng) EulerMaker。

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

OS 構(gòu)建系統(tǒng)的核心流程是，用戶給定一組軟件包后，按照包依賴關(guān)系，對(duì)它們發(fā)起并行構(gòu)建任務(wù)?！澳敲创钜粋€(gè) Kubernetes 集群，上面疊加一個(gè)包構(gòu)建調(diào)度模塊，是不是就可以了呢？”

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

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

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

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

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

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

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

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

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

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

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

“Compass-CI 已經(jīng)在 2020 年上線服務(wù)，在這個(gè)基礎(chǔ)上補(bǔ)足構(gòu)建相關(guān)的模塊，就可以作為 EulerMaker 的后端，服務(wù) openEuler 的構(gòu)建?！?/p>

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

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

EulerMaker 怎么解決全場(chǎng)景

一個(gè) OS 怎么支持全場(chǎng)景？

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

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

“類似的，當(dāng)我們說一個(gè) OS 支持全場(chǎng)景，是只需維護(hù)一套 OS 源代碼，通過源碼級(jí) + 鏡像級(jí)定制，即可構(gòu)建生成各類場(chǎng)景化的二進(jìn)制 OS 發(fā)布。強(qiáng)大的定制能力，是賦能一套 OS 源碼支持全場(chǎng)景的‘究極魔法’?！?/p>

吳峰光進(jìn)一步介紹什么是定制能力：

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

“然而 SPEC 文件中往往只封裝了少量選項(xiàng)，對(duì)于沒有被 SPEC 維護(hù)者封裝的上游軟件功能，用戶就只好自行修改 SPEC 文件來實(shí)現(xiàn)定制，這樣就很雜亂了?！?/p>

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

“這時(shí)候就會(huì)發(fā)現(xiàn) SPEC 文件的定制能力不夠用了。”

EulerMaker 怎么解決這個(gè)問題呢？

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

不過，事情并沒有這么簡(jiǎn)單。

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

而 EulerMaker 的解決辦法，是把該補(bǔ)丁適用的版本范圍，用條件語句顯式的寫在軟件包 YAML 里。“這樣用戶隨便改版本號(hào)，都不會(huì)出錯(cuò)，其它關(guān)聯(lián)字段會(huì)自適應(yīng)的變化，從而實(shí)現(xiàn)定制自由。”

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

“一般用戶要的不是一堆零件，而是套裝。成千上萬的定制項(xiàng)，小白用戶眼花繚亂，不知道拿它們?cè)趺崔k，他可能只知道我用的是 OrangePI，那有沒有對(duì)應(yīng)的一組定制項(xiàng)可以拿來就用的？”

針對(duì)這個(gè)問題，EulerMaker 的解決思路如下：

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

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

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

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

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)核定制維護(hù)：

env.kconfig: CONFIG_BTRFS_FS=y

patchset.my-xxx-improve: xxx.patch

kernel.yaml 示例

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

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

統(tǒng)一的包格式

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

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

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

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

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

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

邁向開源開放

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

審核編輯 ：李倩