Apptainer - Linux向けアプリケーションコンテナ

• シンプルさ・速度・セキュリティを重視して設計されたオープンソースのコンテナプラットフォーム
  • HPC（高性能コンピューティング）と共有システム環境に最適化
• 不変（Immutable）な単一ファイルのコンテナイメージ形式を提供し、暗号化と署名をサポート
• 分離よりも統合された使いやすさに重点を置き、クラスター/サーバー環境でGPU、高速ネットワーク、並列ファイルシステムをそのまま利用可能
• OCI（Open Containers Initiative）レジストリからすべてのコンテナを取得でき、Dockerとの互換性を最大化
  • Docker Hub上の大半のコンテナを変更なしでpull、run、buildできるようサポート
• 既存のSingularityから名称変更され、Linux Foundationプロジェクトへ移管
• **SIF（Singularity Image Format）**ベースの単一ファイルコンテナにより、容易に移動・配布・共有が可能
• コンテナ内部と外部でユーザー権限が同一であり、デフォルトでホスト上の追加権限昇格が不可能な安全なセキュリティモデルを採用
• BSDライセンス

[galadbran]

Hacker Newsの意見で言及されている unregistry の記事:
Unregistry – 「docker push」をレジストリなしでサーバーに直接送信 | GeekNews

[GN⁺]

Hacker Newsの意見

• 私たちのチームはシリコン設計/検証向けのコンピュートクラスタで Apptainer を試したが、最終的には従来の TCL(Luaに移行) モジュールに戻った

  • いくつもの問題を経験した。
    • 第一に、コンテナ同士を相互利用できない。たとえば Make, GCC, Git のようなツールがそれぞれ別の Apptainer に入っていると、Make の中に入った時点で GCC が見えなくなる
    • 第二に、コンテナ内部に依存する成果物があると正常に動かない。GCC Apptainer でプログラムをビルドすると、ビルド済みバイナリが Apptainer 内部ライブラリにリンクされて実行できず、Cヘッダの問題 も発生した
    • 第三に、PATH の値がしばしばおかしくなり、Apptainer 外部の必要なパスやツールが見えなくなる問題が繰り返し起きた
    • 全体としてアイデアは良かったが、実運用での使い勝手 では面倒さばかりが目立ち、結局 古いOS(RHEL8) をそのまま使うほうがずっと楽だった
  • 私は Apptainer/Singularity を Docker に近いものだと考えている（ただしネットワーク設定はフルではない）。こうした問題は従来の Docker コンテナでも同様に起こる。
    • 私の HPC ワークフローでは Apptainer を Docker のドロップイン代替として使っており、この用途にはよく合っている
    • Apptainer の最大の利点は 非root権限コンテナ であること。複雑なネットワーキングはできないが、HPC のような マルチテナント環境 ではずっと 安全 だ
  • コンテナアプリを使っていて最大の不満が コンテナらしく動く ことなら、それはコンテナの本質だ
  • コンテナの断片を混ぜて使うべきではない。異なる Linux ディストリビューションのバイナリを混在させないのと同じだ
    • コンテナは単一の統合環境として開発に使うのが理想的だ。コンテナは 隔離された環境 なので、何かをコンパイルしたなら、その成果物は自分のコンテナ内にあるべきだ
    • ただし、同じ ベースイメージ を複数作ってファイル互換性を確保する方法は可能である（必要な 依存関係 をすべて含める場合に限る）

• Apptainer が注目されているのはうれしい。状況によっては Docker, Podman などより優れている

  • 複数のジョブを1つのコンテナで実行 したいとき（これは他のコンテナ技術では推奨されない）
  • HPC（そして一部の大学環境）
  • 単一ファイル配布モデル をサポートしていること（もちろん差分は未対応）
  • 別の外部サーバなしで SIFファイルを暗号署名可能
  • 強力なGPUサポート

• docker でも docker save と docker load コマンドで 単一ファイル配布 は可能だ。

  • 差分はサポートしないが、最近 "unregistry" というソリューションが HN にリンクされていて、これは Docker Registryなし でも "docker push" 機能と 差分反映 が可能だ

• Apptainer と singularity ce はどちらも HPC でよく使われている。両製品とも 旧Singularityプロジェクト から分岐したが、完全に同一ではない

  • 私たちは複数のスーパーコンピュータ(HPC)で singularity を使っており、一部の研究者はローカルに Apptainer をインストールして使っている
  • 最近、Python コード(matplotlib, xarray など)で タイムゾーンのバグ を見つけたが、singularity ce では問題があった一方、Apptainer では正常に動作した
  • 新しい Apptainer はコードベースは近いものの、バグ修正がより速く反映されている。たとえば singularity は ユーザーのタイムゾーン をシステムに上書きしてしまい、問題が起きていた
  • 参考リンク: singularity issue #3686
  • Apptainer は旧 Singularity プロジェクトの フォーク ではない。Apptainer が元の本流プロジェクトであり、コミュニティ投票で名前だけ変更された。Linux Foundation 傘下に移った
    • Sylabs が元の開発者を迎え入れてプロジェクトをフォークした事例が singularity ce だ
    • 参考: community announcement
  • それでも相互 コンテナ互換性 は維持されており、Apptainer でビルドしても Singularity で実行できる（逆も同様）

• Apptainer はつまり Singularity だ。関連論文は こちら

  • 大学や政府のクラスタで共有システムを使う場合、Apptainer は常にあるが Podman/Docker はほとんどない
  • こうした環境ではコンテナを使うより、システム管理者 と良い関係を築いてそのクラスタの運用方法を理解するほうが有利だ
  • なぜ Docker/Podman はあまり使われず、なぜコンテナ利用を避けたほうがよいのか気になる。もしかして 性能 が理由なのか

• Flatpak は OSTree からコンテナベースへ移行しようとしている。保守されているコンテナツーリングが大きな利点だという。だが、これが Apptainer とどう違うのか気になる

  • おそらく Flatpak の特徴は、xdg-dbus を通じた 細かな権限制御 など、個別 アプリサンドボックス制御 によってネイティブに近く使えることだ
    • Apptainer がそこまで完全に分離/隔離されるのかははっきりしない
    • containertoolbx のようなツールを使えば、コンテナ方式の違いはあまり意味を持たなくなる
    • 正直、ツール同士の機能の重なり は多いが、それ自体は悪くないと思う

• 私の使っている環境では Apptainer を使う最大の目的 は配布、隔離、ソフトウェア可用性とは関係ない。

  • 私たちの HPC クラスタでは各ユーザーごとに inode クォータ制限 があり、そのせいでファイル数が非常に多いソフトウェア（例: Anaconda）のインストールが難しい
  • しかし Apptainer イメージは squashfsベースの単一ファイル なので、inode クォータを気にせず複数置いておける
  • 同じソフトウェアを通常どおりインストールするほうが簡単ではあるが、クォータはあっという間に使い切ってしまう

• Havoc の意見に共感する。メッセージが曖昧だ。Apptainer がデスクトップ向け Flatpak の代替なのか、それともサーバー用途なのか分かりにくい

  • サーバー向けだ。ただし質問自体が曖昧だ
    • Apptainer は 固定(immutable)・rootless コンテナで CLI アプリを実行 するためのものだ
    • 最も近いツールは Fedora Toolbx だ
    • Apptainer の主用途は 科学計算ツールの配布と再利用。root 権限なしで使え、rootfs はコンテナごとに変更不可で、作業ディレクトリが自動でマウントされ、GPU もよくサポートしている（これは自分では未検証）
    • 参考: Fedora Toolbx

• "Apptainer" という名前は 発音しづらく、どこかしっくりこない感じがする

• 開発者なら 隔離用コンテナツール を探しているかもしれない

  • 私は Podman ベースで、異なる開発プロジェクトを隔離するツールを作ってみた。セキュリティテストや利用に必要なら コード または ブログ記事 を見てほしい
  • なぜ toolbox では十分でなかったのか気になる
    • 私は toolbox で、プロジェクトごとに開発環境をインストールする際に複数の隠しファイルシステムを管理する必要がない点が良かった

• SLURM クラスタや root 権限のないサーバーでは非常に有用だ

  • 私も SLURM クラスタで使った経験がある
    • 公式 ドキュメントが充実していて、入門には十分 だ
    • ただし fakeroot や sudo がないと、ローカルで Apptainer をビルドしてサーバーへ直接 転送 しなければならない煩わしさがあった