はじめに
2022年末、openEuler Summit 2022において、日本のLinuxカーネルコミュニティで最も影響力のある開発者の一人である王文光博士が「フルシナリオOS向けビルドサービスのリリース」と題した基調講演を行い、openEulerの統合ビルドサービスEulerMakerを開発者に正式に公開しました。 EulerMaker
Linux Japanオープンソースコミュニティは、EulerMakerについてWu Fengguang博士にインタビューし、サミットで発表されたEulerMakerの背後にある興味深い詳細を発見しました。
Wu Fengguang博士は、著名なLinuxカーネル貢献者であり、ファーウェイのコンピューティングOSのチーフエキスパート、openEulerコミュニティの技術委員会のメンバーです。I/Oやメモリ管理、カーネルテストサービスなど、Linuxカーネルに多大な貢献をしています。彼のストーリーについては、『New Programmer』誌のインタビュー「Wu Fengguang Kills the Linux Kernel」をご覧ください。
openEuler の全貌
"30年前、サーバーOSと組込みOSの境界は、農地を挟んだ2つの村のように非常に明確でした。しかし、その後、ITは何千もの産業に深く深く入り込み、クラウド、エッジ、IoTの出現、さまざまなシナリオが出現し、オーバーラップが発生します。ですから、これはフルシーンOSを作る新たな歴史的チャンスだと思います」と呉鳳光氏。
OSのビルドシステムとは何ですか？
OSビルドシステムは、OSソースコードを入力とし、ユーザがインストール可能なソフトウェアサイロまたはOSImageを出力とします。
サーバ領域のOBSと組み込み領域のBitbakeは、それぞれの領域で長い歴史を持つ代表的なビルドシステムです。
なぜ新しいシステムが必要なのですか？
「OBSは当初、SUSEによってオープンソースで提供され、強力でした。OBSは当初、SUSEによってオープンソースで提供され、強力なものでした。しかし、より深く使用されるにつれて、複雑な新しい要件を改善することが困難であることが判明し、openEulerの進化が難しくなりました。"
一般的なOSの場合、OBSビルドは有用です。しかし、OSが完全なシナリオをサポートしなければならない場合、複雑さは著しく増し、ビルドシステムにより厳しい要件が課されます。
Dr. Wu FengguangはOBSとBitbakeを徹底的に研究しました。これらの古いビルドシステムがopenEulerのニーズを満たさない理由を説明しています：
「OBSのサーバー分野における主な機能は何ですか？RedhatやDebianのパッケージングなど、主要なLinuxディストリビューションをすべてサポートしています。互換性は、Linuxの多様化に適応するためのOBSの中核的な設計目標です。しかし、初期のLinuxにとっては多様性は良いことだと思いますが、長期的にはLinuxエコシステムの断片化は対処すべき問題です。"
「組み込み分野におけるBitbakeは、タスクおよびプロセス指向のDSL記述言語を使用しています。これは非常に柔軟で強力ですが、自由度が高く複雑すぎるため、学習曲線が急であることで知られています。現在一般的な哲学は、YAML、JSON、関数型プログラミングのような汎用的で宣言的な構成言語であり、障壁が低く、理解しやすく、制御され、再現可能なビルドプロセスを実現します。"
呉鳳光の見解では、30年後、建築システムは新たな時代の目標を掲げています。
EulerMaker ビルドシステム
OSのビルドシステムの中核となるプロセスは、ユーザーにパッケージのセットが与えられ、パッケージの依存関係に従って並列ビルドタスクを開始するというものです。"では、パッケージのビルドスケジューリングモジュールを積み重ねたKubernetesクラスタを構築すれば十分なのでは？"
「ソースパッケージ、バイナリパッケージ、ビルド環境に対する依存関係、ビルド依存関係、実行依存関係、パススルー依存関係、巨大なグラフを形成する何千もの依存関係があります。パッケージのビルドが進むにつれて、新しくエクスポートされた RPM パッケージは、後続の RPM パッケージビルドの環境になる必要があり、新しい依存関係情報が提供されて DAG グラフが動的に更新されます。また、さまざまなパッケージビルドの失敗シナリオを考慮する必要があり、マルチユーザーの同時タスク間の干渉や、任意のマシンやモジュールがクラッシュしていつでも再起動できるようにした後に、単一障害点を回避するためにどのように遅れを取り戻すかなど、きめ細かなアーキテクチャ設計一式が必要になります。"
このような難問を目の前にして、こぶしをこすりながら飛びつくエンジニアがいるかもしれません。しかし、パズルを前にしても呉鳳光は慌てず、ブレーキを踏んだ--。
「エンジンのことはひとまず置いておいて、ユーザーがクルマに本当に求めているものは何なのか？
アーキテクチャ設計では、まずユーザーのシナリオを考え、次に機能を導き出し、最後にデータとプロセスを決定します。すべてのユーザーニーズが総合的に考慮された設計であれば、データとプロセスは将来にわたって安定し、変わることはありません。
"ユーザーニーズへの配慮は本当に包括的か？"
Linux開発の初期段階では、機能が実装され、gcc/makeが実行されてビルドされ、ユーザーが使用しさえすれば、システム構築の作業は完了するというシンプルなものでした。当時、Linuxコミュニティはテストにあまり注意を払っておらず、CI/CDという概念もなかったため、テストは基本的にユーザが落とし穴を踏んでいくことに依存していました。今状況は異なっている、時代の要件が改善されている：開発者は、開発プロセス全体をカバーするために、ビルドのテストCI / CDの完全なセットを持って、テストを行うには、品質管理を期待し、ワンストップソリューションは、RPMパッケージのうち、テストされている、ユーザーが使用することを安心することができます。これはすでに開発者によって標準とみなされ、開発者の通常の期待です。"
ですから、新しいビルド・システムはテスト・プロセスを統合する予定です。
では、最近流行している一般的なCI/CDテストツールを統合するだけでは不十分なのでしょうか？
"市販の汎用的なCI / CDテストサービスは、上位レイヤのアプリケーションのテストに適しています。一方、オペレーティングシステムは、上位レイヤとベースソフトウェアの両方のテスト、アプリケーション開発者とカーネル開発者の両方、およびソフトウェアベンダー、ハードウェアベンダー、OSベンダーの両方が、独自のテストニーズを持ち、機能テストとパフォーマンステストの両方のテストが必要です。これらは、市販の一般的なCI/CDではできません。"
「そのため、上記のテストニーズをすべて満たすことができるフルスタックシステムが必要なのです」。
Compass-CIは、ビルド、機能テスト、性能テストなど様々なタスクを実行できる汎用タスク実行システムとして設計されました。また、物理マシン、仮想マシン、コンテナなど様々なリソースをスケジューリングできるヘテロジニアススケジューリングシステムとして設計されました。
"Compass-CIはすでに2020年にサービスとして稼動しており、その上にビルド関連のモジュールをパッチングすることで、openEulerビルドのEulerMakerバックエンドとして機能させることができます。"
"業界のすべての関係者のニーズに応えるシステムを使用することが可能になると、ハードウェアにリモートアクセスできるかどうかを尋ねるハードウェアベンダーが現れるでしょう。そして、開発者間、ベンダー間、開発者とベンダー間の分散コラボレーションを促進するために、クラウドをベースとした、作業マシンへのリモートアクセス、分散スケジューリング、データ共有をサポートし、あらゆる種類のオフラインサーバールーム、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 設定言語を導入し、パッケージを宣言的に記述します。そして、ユーザは OS パッケージの YAML ファイルの任意のフィールドを上書きしたり修正したりするために YAML ファイルを定義することができます。これはオープンなカスタマイズを可能にするだけでなく、ユーザーのカスタマイズオプションを YAML 設定ファイルに一元的に保存して管理したり、コード化された Git で管理したりすることもできます。"
しかし、それほど単純ではありません。
"ユーザーが任意のフィールドを非常に簡単にカスタマイズできるようになると、それに伴うリスクが発生します。多くのパッケージ・フィールドは、互いに条件付きの依存関係や制約を持っており、ユーザーが注意しなければ、これらの連想制約のいくつかを知らず知らずのうちに壊してしまいがちです。以前は、こうした制約の多くはGitログで暗黙のうちに管理されていました。例えば、開発者はまずSPECファイルのバージョン番号を変更し、古いバージョンにしか適用されないパッチを削除して、パッケージのアップグレードを一回で完了させます。カスタマイズ環境にさらされた場合、これは大きな脆弱性であり、自由にカスタマイズすることを事実上困難にしかねません。"
EulerMakerの解決策は、条件文を使ってパッケージのYAMLにパッチが適用されるバージョンの範囲を明示的に記述することです。"こうすることで、ユーザーはエラーなしにバージョン番号を自由に変更することができ、他の関連フィールドは適応的に変更されるため、自由なカスタマイズが可能になります。"
カスタマイズが可能な分、使い勝手はどうでしょう？
この問題に対するEulerMakerの解決策は以下の通りです：
「この専門分野の開発者やベンダーがコミュニティ内で提供するカスタマイズ項目のセットを、カスタマイズレイヤーと呼びます。各ハードウェアやシナリオは、このようなカスタマイズレイヤーを持つことができます。このようにして、シナリオベースOSの開発作業は、必要なレイヤーをメニューから選択し、ビルディングブロックのように組み合わせ、OSのシナリオベースのレイヤーカスタマイゼーションを簡単に完成させることができます。"
以上が、オイラーメーカーの全体的なアイデアです。最後に、呉鳳光はこう締めくくりました：
"優れたフルシーンOSは、エコ・コラボレーションの組織となるでしょう。まず、各シナリオのパブリックナレッジをBaseOSに沈め、記述を統一し、フィールド間の複雑で退屈な条件依存関係を収束させ、各シナリオで再利用しやすいようにします。baseOS＋多様なシナリオレイヤーは、openEulerコミュニティによって共同で保守・提供されるパブリックコンポーネントとなり、開発者はブロックを構築することでDIYメニューベースのカスタマイズを行うことができ、楽しいOS作成体験を実現します。OS作成体験"
読者にレイヤーカスタマイゼーションを直感的に理解してもらうために、呉鳳光は2つの例を挙げています：
1.Redisコンテナの調整：
env.CC: /usr/bin/musl-gcc -staticenv.CFLAGS: -I/usr/musl/includeenv.LDFLAGS: -L/usr/musl/libbuildRequires:- musl-gccsubpackage.redis-server:meta.summary: redis-serverfiles: %{_bindir}/%{name}-server
この例では10行のYAMLを使って1MBのRedisをカットしています。
2.カーネルのカスタマイズとメンテナンス：
env.kconfig: CONFIG_BTRFS_FS=ypatchset.my-xxx-improve: xxx.patch
この例では、2行でLinuxカーネルのカスタムメンテナンスを行うYAMLファイルを使用しています。
"あなたが大企業のインフラチームにいて、openEuler上のLinuxカーネルをカスタマイズし、kconfigを変更し、パッチを追加する必要があるとします。過去には、kernel.specのコピーを作成し、その上で直接変更を加えなければならなかったかもしれません。これは、何百行ものSPECファイルを管理し、時折アップストリームから新しい改良を丸め込むことを意味し、退屈で面倒なプロセスでした。現在、私たちはForkモードからBuilding Blocksモードに移行し、小さなkernel.yamlファイルを管理するだけになりました。そうすれば、新しいBaseOSのリビルドをプルするたびに、自動的にアップストリームのEulerカーネルから最新のバグフィックスを入手できます。これにより、開発とメンテナンスのコストが削減され、セキュリティが向上します。上流と下流が協力して進化する、より持続可能な方法なのです。"
ユニバーサルパッケージフォーマット
呉鳳光のプレゼンテーションで興味深かったのは、openEulerが独自のパッケージ仕様を模索していることです。
ご存知のように、openEulerは現在、業界をリードするパッケージ形式の1つであるRPMを使用しています。このパッケージ形式はRedhat Linuxだけでなく、openSUSE、OpenMandriva、Oracle Linux、Tizenなどでも使用されています。
openEulerでは、RPMパッケージはおなじみのサーバーやクラウドコンピューティングの領域だけでなく、組み込みなど他のシナリオでも使用されます。
パッケージ定義を統一するため、openEulerはパッケージ記述に新しいYAML設定言語を使用し、新しい開発者インターフェースとしてRPMのSPECファイルを引き継ぎます。SPECファイルには複雑なマクロ定義がたくさん使われていますが、EulerMakerはその複雑さをYAMLの背後に隠しています、とWu Fengguang氏は言います。言い換えれば、openEulerの新しい統合ビルド・システムで使用されるYAML設定言語は、より汎用的で柔軟なパッケージ定義を作成します。
これは、openEulerが徐々に独自のパッケージ形式を開発するということでしょうか？呉鳳光は、互換性を維持しながら、openEulerは独自の道を進むだろうと述べています。
新しいパッケージ・フォーマットをいきなり作るのは簡単ですが、新しい機能を開拓しながらも、既存のアーキテクチャとの互換性を保ち、さらに幅広いシナリオをサポートできるようになるのは、楽しみなことです。
オープンソースとオープン性を目指して
半年間の努力の結果、統一ビルドシステムサービスEulerMakerはオンラインになり、Eulerコミュニティの一翼を担っていますが、オープンソースコミュニティの産物として、より広いオープンソースコミュニティのためにオープンソース化されることを望みますし、オープンソースコミュニティの批判や貢献も受け入れたいと思います。これに対し、Wu Fengguang博士は、間違いなくオープンソース化されるだろうが、現時点ではさらに磨きをかけ、成熟させる必要があると述べています。呉鳳光博士のオープンソースコミュニティへの貢献は、常に素晴らしいことで知られています。強力で完璧なユニファイド・ビルディング・システムがまもなくオープンソース化されることをとても楽しみにしています。
