未来への回帰: Guixパッケージのためのモジュール (2022)

私たちのソフトウェアの世界には、時代を超越したものがいくつかあります。 古くからあるEnvironment Modulesもその一つです。 過去30年間、ハイパフォーマンスクラスターを使用したことがあるなら、おそらくそれに精通しているでしょう。 Modulesは、Guixと同様に、ソフトウェア環境の管理に関するものです。あるいは、より正確には、guix shellに関するものです。 GuixにModulesとの互換性レイヤーができたことを知って、喜ぶか、驚くでしょう。 Modulesの遺産 Furlaniの1991年の入門論文が説明しているように、Modulesは、特にハイパフォーマンスコンピューティング（HPC）において、Unixユーザーにとって重要なイネーブラーでした（そして今もそうです）。 moduleコマンドは、ユーザーがパッケージの観点からソフトウェア環境を操作できるようにし、Unixやシェルに精通している必要はありません。 それらは、他のユーザーに干渉することなく、パッケージを構成し、好みのソフトウェア環境を構築することを可能にします。 Unixだけでは提供できない柔軟性を提供します。 コマンドラインインターフェースは理解しやすいです。 module load gcc/11.2 GCC 11.2をシェルに「ロード」します。 必要に応じてソフトウェアコンポーネントを「ロード」および「アンロード」できます。 module load python/3.8 module unload gcc インターフェースとして、Modulesは使いやすく理解しやすいです。 しかし、それらはソフトウェアを展開する作業をシステム管理者に（時にはユーザーに）任せます。 一般的なアプローチは、システム管理者がModulesが参照するソフトウェアを自分でビルドしてインストールすることでした。 最終的な結果として、モジュールはマシンごとに異なります。 例えば、上記のgccモジュールは、あるクラスターではGCC 11.2を指し、別のクラスターではGCC 8を指すかもしれません。 別のクラスターでは、まったく異なる名前かもしれません。 同様に、上記のpython/3.8モジュールは、Python 3.8の異なるパッチレベルバージョンを指すか、異なる依存関係や異なるビルドフラグでビルドされたPythonのバリアントを指すかもしれません。 これらの問題は、EasyBuildやSpackのようなパッケージマネージャーによって大幅に軽減されてきました。 どちらもパッケージビルドを自動化し、どちらもモジュールファイルを生成できます。 モジュールを「ロード」する際に設定する環境変数を定義するTclスニペットです。 EasyBuildとSpackを使用すると、デプロイメントとモジュールファイル生成を自動化できるだけでなく、異なるマシンに類似したソフトウェアをデプロイすることも可能になります。 「類似」ですが、「同一」ではありません。 SpackやEasyBuildでビルドされたソフトウェアは、ホストシステムですでに利用可能なソフトウェアに依存します。 それは、CentOS 7.4（2017年リリース）やUbuntu 22.04、あるいはそれ以外の何であれ、GNU/Linuxディストリビューションの上に構築されています。 したがって、これらのツールでインストールされたソフトウェアは、ビルド時および実行時に、基盤となるディストリビューションによって提供されるソフトウェアに依存します。 この「隠れた依存関係」により、異なるマシンや異なる時点に同じ環境を再デプロイすることが困難になります。 同じビルドプロセスが失敗するか、成功しても結果として得られるソフトウェアの動作が異なる可能性があります。 Guixでの私たちの方法は、その「隠れた依存関係」を持たないことです。 代わりに、Guixが操作するパッケージ依存関係グラフは自己完結型です。 ユーザーランドで使用する可能性のあるすべてのソフトウェアのパッケージ定義が含まれています。 GuixからModulesへ 今日のニュースは、Guixパッケージからモジュールファイルを生成するための新しいツールであるGuix-Modulesのリリースです。 EasyBuildやSpackのモジュールファイル生成ツールと同様に、主な目標は、HPCクラスターのシステム管理者がユーザーにモジュールのセットを提供することを容易にすることです（以下で詳しく説明します）。 Guix-ModulesはGuixの拡張機能です。 使用するには、インストールしてGUIX_EXTENSIONS_PATH環境変数を設定する必要があります。 GUIX_EXTENSIONS_PATH="$HOME/.guix-profile/share/guix/extensions" これにより、新しいguix moduleサブコマンドが利用可能になります。 例えば、選択したパッケージのモジュールを/opt/modulesに生成したいとします。 次のコマンドを実行することで実行できます。 guix module create -o /opt/modules \ coreutils gcc-toolchain python python-numpy すべてのGuixコマンドと同様に、パッケージがまだ利用できない場合はビルドまたはダウンロードし、/opt/modulesを多数のモジュールファイルで埋めます。 /opt/modulesがすでに存在していた場合、/var/guix/profilesの下にバックアップされ、変更を後悔した場合に以前のモジュールにロールバックできます。 管理者として、次のコマンドを実行してモジュールのセットを定期的に更新できます。 guix pull guix module create -o /opt/modules … 良い点は、ユーザーは明示的に削除するまで、/var/guix/profilesの下で以前のモジュールセットにアクセスできることです。 これらの長いguix module createコマンドラインの代わりに、バージョン管理下に置くことができるマニフェストファイルに興味のあるパッケージをリストすることを選択できます。 ほとんどの他のguixコマンドと同様に、マニフェストを次のように渡すことができます。 guix module create -m my-modules.scm -o /opt/modules モジュールが生成されたら、慣れ親しんだmoduleサブコマンドを使用して、それらをロードおよびアンロードできます。 unset MODULEPATH module use /opt/modules module load gcc-toolchain/11.2.0 module load python/3.9.9 これで完了です！システム管理者であれば、ユーザーに習慣を変えるよう依頼することなく、科学ソフトウェアを提供する新しい方法があります。 生成されたモジュールファイルは、「オリジナルの」Module実装とLmodの両方で同様に機能します。 プロビナンス追跡 私たちGuix開発者は、優れたプロビナンス追跡サポートを備えたデプロイメントツールを提供することに誇りを持っているので、guix moduleコマンドが不明なプロビナンスのモジュールファイルを生成するままにはできませんでした。 ユーザーは、使用するモジュールのプロビナンスを判断できるはずだと考えています。 私たちは、記事を公開してから6か月後に、関連するモジュールがアップグレードされたり、足元から削除されたりして、それらを再現する方法がわからないため、計算結果を再現できなくなるという、多くのHPC実務家がよく知っているシナリオを避けたいと考えています。 したがって、guix module createは、生成するモジュールファイルにプロビナンスデータを記録します。 module helpを実行することで、その情報を表示できます。 $ module help openblas ----------- Module Specific Help for 'openblas/0.3.18' ------------ This module was generated from a GNU Guix package. Provenance data (channels): (list (channel (url "https://git.savannah.gnu.org/git/guix.git") (branch "master") (commit "4ba35ccd18f90314caa76ea1833ffc383559401c") (name 'guix) (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) module helpが表示するのは、この特定のパッケージがビルドされたチャネルのリストです。 この情報は、guix time-machineがすぐに消費できる形式になっています。 （list (channel …））スニペットをchannels.scmというファイルに保存すると仮定します。 後で別のマシンに移動し、このコマンドでまったく同じソフトウェアをデプロイできます。 guix time-machine -C channels.scm -- \ shell gcc-toolchain openblas ユーザーにとって、これは大きな違いをもたらします。 モジュールはもはや一時的なものではありません。 それらは、いつでもどこでもGuixで再デプロイできる再現可能な成果物になりました。 カスタマイズ HPCユーザーは、ソフトウェアビルドプロセスをカスタマイズすることに関して、しばしば要求が厳しいです。 Guixは、コマンドラインおよびプログラミングインターフェースから利用可能なさまざまなパッケージ変換オプションで、このニーズをサポートします。 良いニュースは、guix module createがパッケージ変換オプションを尊重することです。 それらの中でも、関連パッケージをホストのマイクロアーキテクチャ用に最適化するようにGuixに指示する--tuneオプションは便利かもしれません。 クラスターにSkylake CPUのみが含まれていることがわかっている場合は、関連パッケージがSkylake用に最適化されていることを確認したいでしょう。 これを行うには、次のように実行します。 guix module create --tune=skylake \ gcc-toolchain openblas gsl この特定のケースでは、GSLはSkylake用にビルドされ、GCCの-march=skylakeオプションを使用します（OpenBLAS自体は実行時に最適化されたルーチンを選択するため、影響を受けません）。 「しかし、再現性はどうですか？」とあなたは尋ねます。 選択されたパッケージ変換オプション（この場合は--tune）