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

Guixパッケージのためのモジュール：過去から未来へ

私たちのソフトウェアの世界には、時代を超えて通用するものがあります。古くからあるEnvironment Modulesもその一つです。過去30年間、ハイパフォーマンスコンピューティング（HPC）クラスターを使用したことがあるなら、おそらくこれに馴染みがあるでしょう。Modulesは、Guixと同様に、あるいはより正確にはguix shellのように、ソフトウェア環境を管理するためのものです。

GuixにModulesとの互換性レイヤーが追加されたことを知って、喜ぶか驚くかのどちらかでしょう。

［画像: Environment 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を指すかもしれません。また、3番目のクラスターではまったく異なる名前を持つかもしれません。同様に、上記の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 install guix-modules
export 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コマンドを放置することはできませんでした。ユーザーは、使用するモジュールの由来を判断できるべきだと考えています。HPCの実務家がよく経験する、記事公開から6か月後に、関連モジュールがアップグレードまたは削除されてしまい、それらを再現する方法がわからなくなるというシナリオを避けたいのです。

したがって、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  643 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はGCCの-march=skylakeオプションを使用してSkylake用にビルドされます（OpenBLAS自体は*実行時に最適化されたルーチンを選択するため、影響を受けません）。

「しかし、再現性はどうなるのか？」とあなたは尋ねるでしょう。選択されたパッケージ変換オプション（この場合は--tune）は、由来データの一部としても記録されます。これがmodule helpが表示するものです。

$ module help gsl

----------- Module Specific Help for 'gsl/2.7' --------------------

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  643 A2A0 6DF2 A33A 54FA")))))

Package transformations:

  ((tune . "skylake"))

「Package transformations」の部分は自己説明的です。マニフェストのoptions->transformationにそのまま渡すことができます。

私たちは、パフォーマンスと再現性のどちらかを選択する必要はないと強く信じており、この機能セットがそれをサポートしています。

なぜこれほど騒ぐのか？

Guixは10周年を迎え、Guix-HPC自体も今年で5周年を迎えるので、なぜ長年経ってからModules互換性レイヤーを追加するのか疑問に思うかもしれません。結局のところ、guix shellは、上記例のようなGCCとPythonを使用するシェルを開始するために、module loadに匹敵する方法でソフトウェア環境をオンザフライでセットアップできます。

guix shell gcc-toolchain@11 python@3.8

より一般的に、Guixはユーザーをコントロール下に置きます。ユーザーは望むときにアップグレードでき、時間旅行を可能にし、パッケージをカスタマイズでき、そして同じ環境を他の場所や異なる時点でも再現できます。

Guixを直接使用することは、依然としてユーザーにとって最も強力なアプローチですが、Guixパッケージから作成されたモジュールファイルは、多くのユーザーのニーズを満たすことができます。

1. ユーザーの習慣に合わせる。 一部のコミュニティでは、新しいコマンドを学ぶ必要がない（たとえそれがそれほど違わず、より多くの機能を提供する場合でも）ことは大きな利点です。クラスター管理者がその理由で、Guixや他のツールに加えてModulesを提供するということは珍しくありません。
2. 段階的なソフトウェア環境構築をサポートする。 moduleを使用すると、モジュールを「ロード」および「アンロード」して目的の環境を取得できますが、guix shellは現在、事前にパッケージのリストを期待しています。問題空間を探索する際には、段階的なモードの方が便利かもしれません。実際、guix shellで段階的なモードをサポートするためのパッチが最近議論されました。
3. シンプルなGuixyクラスターセットアップをサポートする。 Guixの典型的なクラスターセットアップでは、ビルドデーモンを実行し、ソースまたはバイナリをダウンロードするためにネットワークにアクセスできることを確認し、フロントノードおよび（オプションで）ビルドノードからアクセス可能にし、いくつかのNFSエクスポートを設定する必要があります。それを行いたくないシステム管理者は、代わりにguix module createを使用し、これらのモジュールをユーザーに提供できます。/gnu/storeディレクトリは引き続きNFS経由でエクスポートする必要がありますが、それは読み取り専用のエクスポートであり、それだけが必要です。これはよりシンプルなセットアップです。

HPCクラスターのユーザーまたはシステム管理者であれば、guix-scienceメーリングリストまたはLibera.chatの#guix-hpcチャンネルでご意見をお聞かせいただければ幸いです！

別途記載がない限り、このサイトのブログ記事はそれぞれの著者に著作権があり、CC-BY-SA 4.0ライセンスおよびGNU Free Documentation License（バージョン1.3以降、変更不可セクション、表紙テキスト、裏表紙テキストなし）の条件の下で公開されています。