Zenn
🦭

ルートレス、デーモンレスなコンテナツール「podman」を触ってみる

に公開
podman
devcontainer
tech

ルートレス、デーモンレスがどんなものか興味があったのでpodmanを触ってみた。

実はdockerでもrootless modeというのがあって、一般ユーザ権限でコンテナを動かすことはできる。できるのだが、説明が長そうだったのでこれはまた今度試そうと思う。
Rootless mode | Docker Docs

podmanはルートレスでデーモンレスらしい。dockerグループを追加したり、sudoで実行したり、ということは必要ない。さらに、podmanはdocker CLIと同じような使い勝手でCLIが使える。学習コストも低く、dockerから移行するハードルも低そうに見える。

なぜ「ルートレス」が便利なのか

今回「ルートレス」なツールを触ってみたかった理由は2つある。

  • 開発環境での利便性
  • セキュリティ

開発環境での利便性

普段、私は開発にdevcontainerを使う上で不便に感じるのが、ファイルの所有ユーザ・グループの扱いだ。ホストコンテナのUID・GIDを一致させる必要がある。

例えば、何も考えずにコンテナ内でルートユーザで作業をすると、コンテナ内で作ったファイルの所有者がルートユーザになっていて、ホスト上の一般ユーザでは編集・削除できない、というようなことが起こる。

基本的にはコンテナ上で開発するけど、ホスト上でもファイルを触りたいことは多いので、これは不便だ。

この問題を回避するために、イメージをビルドする際にUID・GIDを渡すような工夫をすることもある。

それ以外にも、devcontainerには updateRemoteUserUID というオプションがあり、この問題を緩和してくれる。
Dev Container metadata reference

これは、ざっくりいうと下記のことをやってくれるオプションだ。

  • コンテナ上のユーザ・グループIDがホスト上のユーザ・グループIDと一致するように変更する
  • chmod を -R オプション付きでを実行して、コンテナ上のユーザのホームディレクトリの所有者を変更する
    しかし、ホームディレクトリ以外は変更しないので、これだけで全てが解決するわけじゃない。

セキュリティ

ホスト上でroot権限を持っていることの危険さはよく知られているけど、コンテナ上のルートユーザでアプリケーション動作させることもセキュリティリスクになり得る。

もちろん、ルートユーザであってもコンテナの中から見えるリソースは限られていて、例えばファイルやプロセスはコンテナ内のものしか見えない。しかしユーザ自体はホスト上のルートユーザと同一のものだ。

$ mkdir container-exp && cd $_

# コンテナの中でファイルを作ってみる…
$ docker run -v .:/host -w /host ubuntu touch hello.txt

# 所有者がルートユーザになってる！
$ ls -l
total 0
-rw-r--r-- 1 root root 0 Jun 24 23:22 hello.txt

なのでコンテナエスケープが成立すれば、ホスト上で大暴れできてしまう。

Linuxの「ユーザ名前空間」という機能を使えばこの問題を解決できる。これはコンテナ上のユーザ・グループをホスト上の別のユーザ・グループにマップすることができる仕組みだ。

podmanもこの機能を使っている。

podmanを試してみる

さて、podmanを試してみよう。ubuntuならaptでインストールできる。

$ sudo apt install podman

ユーザ名前空間が動作することを確認する

さっきやったことをpodmanでもやってみる。dockerコマンドをpodmanコマンドに置き換えるだけ。

$ podman run -v .:/host -w /host ubuntu touch hello-podman.txt

# 所有者が一般ユーザになってる！
$ ls -l
total 0
-rw-r--r-- 1 musou1500 musou1500 0 Jun 24 23:24 hello-podman.txt

devcontainerで使ってみる

ソースコードはこれ。
musou1500/try-podman

Dockerfileはこんな感じ。

FROM node:22-bookworm AS base
WORKDIR /app
RUN chown -R node:node /app
USER node
COPY package*.json ./
RUN npm i
COPY . .
CMD ["npm", "start"]

devcontainerを開くと、諸々のファイルの所有者が nodeユーザになっているし、コンテナ内でファイルを作っても所有者がホスト上のユーザと一致するようになっている。

仮にコンテナ上でルートユーザを使うようにDockerfileを変更してみても同じ結果になる。
ユーザのマッピング方法は --usernsオプションで指定できる。デフォルトは keep-id で、コンテナのUID・GIDはホスト上のUID、GIDにマップされる。

keep-id: creates a user namespace where the current rootless user’s UID:GID are mapped to the same values in the container. This option is not allowed for containers created by the root user.
podman-run — Podman documentation

蛇足だけど、WSLでやってみるとなぜか動かなかった。ログはこれ。

[2025-06-24T16:18:36.908Z] Start: Starting container
[2025-06-24T16:18:36.908Z] Start: Run: podman run --sig-proxy=false -a STDOUT -a STDERR --mount source=/home/xxx/code/try-podman,target=/app,type=bind,consistency=cached --mount type=volume,src=vscode,dst=/vscode -l devcontainer.local_folder=\\wsl.localhost\Ubuntu\home\xxx\code\try-podman -l devcontainer.config_file=/home/xxx/code/try-podman/.devcontainer/devcontainer.json --security-opt label=disable --userns=keep-id --entrypoint /bin/sh vsc-try-podman-7ed9c4b341460b05072adecee7d0738cf4107d58a197097c14f2ab6d4eb2d877 -c echo Container started
[2025-06-24T16:18:43.088Z] Error: could not find slirp4netns, the network namespace can't be configured: exec: "slirp4netns": executable file not found in $PATH

slirp4netnsがインストールされているのは確認済みなので、原因は別にあると思う。.zshrcに書いていた、tmuxの自動起動の設定を消すとなぜかエラーは出なくなったけど、その先で処理が終わらずに先に進まない現象が発生する。ログを見ると podman runを実行したところで止まっている。

[7349 ms] Start: Run: podman run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,source=/home/xxx/code/try-podman,target=/workspaces/try-podman --mount type=volume,src=vscode,dst=/vscode -l devcontainer.local_folder=\\wsl.localhost\Ubuntu\home\xxx\code\try-podman -l devcontainer.config_file=/home/xxx/code/try-podman/.devcontainer/devcontainer.json --security-opt label=disable --userns=keep-id --entrypoint /bin/sh vsc-try-podman-7ed9c4b341460b05072adecee7d0738cf4107d58a197097c14f2ab6d4eb2d877 -c echo Container started
Container started

感想

podman自体の触り心地はとても良い。インストールで躓くこともなかったし、使い方もほぼdockerで移行のハードルも低い。当初期待していたファイルの権限周りの問題も解決できそうだった。

ただ、WSL環境での不具合の件など、エコシステムが追いついていない感はあって、今後なんとかなってほしい。この件については詳しく調査しようと思ったが、vscodeの拡張機能の方はソースコードが公開されておらず、なんともならなさそうだった。

コンテナ周りの仕様が規格化される流れがあるし、いろんなツールの開発もあってdocker一辺倒な状況も変わりつつあるように見えるので、今後に期待したい。

Discussion