Podman で Singularity コンテナを動かすまでの覚書
Podman で SIF (Singularity Image File) フォーマットのコンテナが実行できるという記事があったため、自分でも試してみた。
SIF コンテナの実行はハマるところがなかったものの、(rootless) Podman を動かすまでに結構ハマりどころがあった。
以下は Ubuntu 22.04 環境 (WSL, OrbStack) を想定しているが、他でもおそらく(ハマりどころも含めて)同様のはず。
Podman のインストール
基本的には公式のドキュメントに従えば良い。
注意点としては、Ubuntu 22.04 で提供されている Podman 3.4.4 は SIF コンテナに対応していないため、Kubic project の apt-line を追加して最新版をインストールする必要がある[1]。
$ sudo apt update && sudo apt install -y gnupg # 環境によっては gnupg が入っていない場合があるので注意
# 以下は公式ドキュメントに従う
$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL "https://download.opensuse.org/repositories/devel:kubic:libcontainers:unstable/xUbuntu_$(lsb_release -rs)/Release.key" \
| gpg --dearmor \
| sudo tee /etc/apt/keyrings/devel_kubic_libcontainers_unstable.gpg > /dev/null
$ echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/devel_kubic_libcontainers_unstable.gpg]\
https://download.opensuse.org/repositories/devel:kubic:libcontainers:unstable/xUbuntu_$(lsb_release -rs)/ /" \
| sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:unstable.list > /dev/null
$ sudo apt-get update -qq
$ sudo apt-get -qq -y install podman
これでインストールできるが、環境によってはこれでは動かない。
ハマりどころの事前確認
subuid, subgid の設定の確認
rootless Podman は newuidmap という機能を使うことで、コンテナ内の UID, GID と、ホストの UID, GID のマッピングを行う。
このマッピングは /etc/subuid
および /etc/subgid
の設定をもとに行われる。
例えば以下のように、各ファイルに中身がある場合は問題ない。
$ cat /etc/subuid
tom-tan:100000:65536
$ cat /etc/subgid
tom-tan:100000:65536
対応するファイルがない場合やファイルの中身が空の場合には、上記のような内容を記載する必要がある。
/
の mount propagation 設定の確認
mount propagation は、bind mount したディレクトリ内でさらに何かが mount/unmount された時の挙動に関わる設定で、shared
, slave
, private
の三種類が存在する[2]。
Podman は /
の mount propagation が shared
であることを要求するが、例えば WSL 上の Ubuntu などではデフォルトが private
になっている場合があるため注意が必要となる[3]。
この設定は findmnt
コマンドで確認できる。以下の出力であれば問題ない。
$ findmnt -o PROPAGATION /
PROPAGATION
shared
最後の行が private
になっている場合、Podman 実行時に以下の警告が表示される[4]。
$ podman version
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
...
これを解決するためには、/etc/fstab
で /
のマウント設定を変更するか、例えば以下の systemd のユニットファイルを作成して起動時に実行させればよい。
[Unit]
Description=Mount rshared for rootless containers
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/mount --make-rshared /
TimeoutSec=30s
[Install]
WantedBy=multi-user.target
上記ファイルを /etc/systemd/system/rshared.service
に配置して次のコマンドを実行することで、次回起動時から /
の mount propagation 設定が shared
になる。
$ sudo systemctl enable rshared
$ sudo systemctl start rshared
systemd の Linger 設定の確認
Linger はユーザー権限で動くデーモン (systemd --user
の制御下にあるユニット) の寿命に関わる設定で、no
の場合はデーモンの寿命はユーザーセッションと同様で、yes
の場合はシステム起動から終了までがデーモンの寿命になるらしい[5]。
現在のユーザーの Linger 設定は以下のコマンドで確認できる。
$ loginctl user-status $USER | grep Linger
Linger: yes
Linger: yes
であれば問題ないが、Linger: no
の場合、ログイン直後は問題ないのに、ログイン後しばらくしてから突然 podman が以下の警告を出して動かなくなる[6]。
$ podman version
WARN[0000] Failed to get rootless runtime dir for DefaultAPIAddress: lstat /run/user/1000: no such file or directory
...
これは、ログイン後しばらくすると自動的に User Manager
[7][8] が勝手に止められてしまうのが原因で起こっている。
これを解決するには、以下のコマンドで Linger を有効化すればよい。
$ loginctl enable-linger $USER
ようやく動作確認
Singularity Container Services から適当なイメージをダウンロードして実行してみる。
今回は godlovedc/demo/lolcow を godlovedc_demo_lolcow.sif
としてダウンロードして動作確認を行った。
$ podman run -t sif:godlovedc_demo_lolcow.sif
Getting image source signatures
Copying blob 0ad7292ab5b5 done
Copying config a71e681d6e done
Writing manifest to image destination
_______________________________________
/ You'll wish that you had done some of \
| the hard things when they were easier |
\ to do. /
---------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
やったぜ。
まだなんか警告が出てるぞ!
環境によっては、実行時に以下の警告が出る場合がある[9]。
$ podman version
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
...
これは dbus-user-session
パッケージをインストールすることで解決する。
$ apt install -y dbus-user-session
$ sudo reboot -h now
-
Ubuntu 24.04 で提供予定の Podman 4.3.1 では SIF コンテナが動くはずなので、apt-line を追加する必要はなくなるはず。 ↩︎
-
より正確な解説は以下: https://tech.retrieva.jp/entry/2019/04/16/155828#余談1-Mount-Propagationについて ↩︎
-
少なくとも自分の環境ではそうだった。WSL では systemd の有効・無効が時期や設定によって異なっていたり systemd の実体が異なっていたりするため、自分の環境がどうなっているか確認するほうがよい。 ↩︎
-
Arch Linux の記事 によるとそのように読める。 ↩︎
-
Ubuntu on WSL で遭遇。 ↩︎
-
journalctl -e
のログ中でこの名前を確認できる。実体はsystemd --user
か? ↩︎ -
つまり WSL では、ログインしてしばらく経つとセッションが切れた扱いになっている?どういうことなの… ↩︎
Discussion