Podman

関連記事

• systemd-nspawn
• Linux Containers
• Docker
• Buildah
• Vagrant

Podman は Docker の代わりになるプログラムで、同じようなインターフェイスを提供します。ルートレスコンテナと docker-compose の shim サービスをサポートします。

インストール

podman パッケージをインストールしてください。コンテナイメージを作成したい場合は Buildah も見てください。

コンテナのネットワーキングに関しては、cni-plugins または v4.0 からは netavark をインストールしてください。

Docker を置き換えたい場合は、docker バイナリを模倣する podman-docker を man ページと共にインストールできます。

Docker と異なり、Podman はデーモンを必要としませんが、cockpit-podman を介して cockpit のようなサービスに API を提供するものは存在します。

デフォルトでは Podman コンテナを実行できるのは root だけです。root 以外のユーザーでコンテナを実行したい場合は #ルートレス Podman を参照してください。

設定

コンテナの挙動を設定する設定ファイルは /usr/share/containers/ にあります。編集する前に /etc/containers にコピーする必要があります。Podman によって使われるネットワークブリッジインターフェイスを設定したいときは /etc/cni/net.d/87-podman.conflist を見てください。

ルートレス Podman

警告: ルートレス Podman は非特権ユーザーの名前空間の使用 (CONFIG_USER_NS_UNPRIVILEGED) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は セキュリティ#アプリケーションのサンドボックス化 を参照してください。

デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは root だけです。ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。podman(1) § Rootless mode も参照してください。

追加の依存関係

slirp4netns が、rootless 環境内で Podman を実行するための依存パッケージとしてインストールされます。

Podman が netavark ネットワークバックエンド (containers.conf(5) を参照) を使用する場合、rootless コンテナで名前解決を行うために aardvark-dns をインストールする必要があります。

ネイティブな rootless オーバーレイを有効化する

以前は、rootless 環境で FUSE オーバーレイをマウントするために fuse-overlayfs パッケージを使用しなくてはなりませんでした。しかし、Podman と Linux カーネルの最近のバージョンはネイティブな rootless オーバーレイをサポートしており、これはより高パフォーマンスです。fuse-overlayfs から移行するには、次を実行してください:

$ podman system reset

残念ながら、このコマンドは pull されたコンテナをすべて削除してしまいます。また、Podman が overlay ドライバを使用し、かつ containers-storage.conf(5) で mount_program パラメータが定義されていないことを確認してください。さらに、Docker#ネイティブ overlay diff エンジンを有効化する の指示に従う必要があるかもしれません。

ネイティブな rootless オーバーレイが有効化されていることを確認するには、次を実行してください:

$ podman info

graphDriverName: overlay と Native Overlay Diff: "true" が出力される必要があります。

kernel.unprivileged_userns_clone を有効にする

まず、次のコマンドを実行して kernel.unprivileged_userns_clone の値を確認します:

$ sysctl kernel.unprivileged_userns_clone

現在、0 に設定されている場合は、sysctl またはカーネルパラメータで 1 を設定して有効にします。

ノート: linux-hardened では kernel.unprivileged_userns_clone がデフォルトで 0 に設定されています。

subuid と subgid を設定する

ルートレスで Podman を動かすには、Podman を使用するユーザー毎に subuid(5) と subgid(5) の設定エントリが存在していなければなりません。useradd(8) を使って作成された新しいユーザーには、これらのエントリがデフォルトで存在します。

ノート:

• shadow 4.11.1-3 より前の時点で作成されたユーザーは、/etc/subuid と /etc/subgid 内にエントリがデフォルトで存在しません。usermod(8) コマンドを使うか、これらのファイルを手動で変更することで、エントリを作成することができます。

以下のコマンドは、username というユーザとグループが Podman コンテナ (あるいは他の種のコンテナ) を実行できるようにします。このコマンドは、指定された範囲の UID と GID を、指定されたユーザとグループに割り当てます。

# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 username

username に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず /etc/subuid と /etc/subgid を調べて、すでに予約されている範囲を見つけてください。

• 多くのイメージはマッピングのために65536個の UID と GID を必要とします (特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の UID と GID を割り当てることをお勧めします。
• systemd-homed を使用している場合、コンテナ用の UID と GID の最小値は 524288 以上でなければなりません (userdbctl の出力で "begin container users" を確認してください)。[1]

subuid と subgid の変更を伝播する

ルートレス Podman は非特権名前空間を存続させるために pause プロセスを使用します。これにより、/etc/subuid および /etc/subgid ファイルへの変更は、pause プロセスの実行中にルートレスコンテナに伝播されるのを防ぎます。これらの変更を伝播するには、以下のコマンドを実行します。

$ podman system migrate

この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。

SYS_CHROOT ケイパビリティを追加する (任意)

リリース 4.4 から、以前はデフォルトであった一部のケイパビリティが (SYS_CHROOT を含めて) 無くなりました (公式のブログ投稿で説明されています)。これは、chroot を使用するコンテナ (archlinux:base など) に影響を与え、コンテナ内での pacman の操作 (すなわち、インストール後のスクリプトを実行するパッケージのインストール) が失敗してしまいます。このような問題は、podman でビルドする際にビルド中に以下のようなエラーが発生する場合、特定できます:

...
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
...

これを解決するには、/etc/containers/containers.conf を編集してリストに SYS_CHROOT を追加してください:

/etc/containers/containers.conf

default_capabilities = [
  "CHOWN",
  "DAC_OVERRIDE",
  "FOWNER",
  "FSETID",
  "KILL",
  "NET_BIND_SERVICE",
  "SETFCAP",
  "SETGID",
  "SETPCAP",
  "SETUID",
  "SYS_CHROOT",
]

また、podman-build(1) を実行する際にコマンドラインから --cap-add sys_chroot を使うことで、一時的に SYS_CHROOT ケイパビリティを付与することができます。

ストレージ

コンテナイメージとインスタンスの保存方法と保存場所の設定は、/etc/containers/storage.conf にあります。

ノート: #ルートレス Podman を使用する場合、ストレージ設定のオーバーライドをユーザーごとに $XDG_CONFIG_HOME/containers/storage.conf に追加できます。

ストレージに使用しているファイルシステムに応じて driver を設定します (containers-storage.conf(5) § STORAGE_TABLE を参照)。

外部のアーキテクチャ

Podman は、Wikipedia:binfmt_misc システムを使用することで、使用中のホストとは異なる CPU アーキテクチャ用にビルドされたイメージを実行することができます。

これを有効化するには、qemu-user-static と qemu-user-static-binfmt をインストールしてください。

systemd には、新しいルールを有効化する systemd-binfmt.service サービスが同梱されています。

binfmt ルールが追加されたことを確認してください:

$ ls /proc/sys/fs/binfmt_misc

DOSWin        qemu-cris        qemu-ppc      qemu-sh4eb        status
qemu-aarch64  qemu-m68k        qemu-ppc64    qemu-sparc        
qemu-alpha    qemu-microblaze  qemu-riscv64  qemu-sparc32plus  
qemu-arm      qemu-mips        qemu-s390x    qemu-sparc64      
qemu-armeb    qemu-mipsel      qemu-sh4      register

これで、Podman は外部のアーキテクチャのイメージを実行できるようになったはずです。ほとんどのコマンドは、--arch オプションが渡されたときに、外部のアーキテクチャを使用します。

例:

# podman run --arch arm64 'docker.io/alpine:latest' arch

aarch64

Docker Compose

Podman 3.0.0 では、docker-compose サポートが追加されました。これには、Docker を模倣する Podman ソケットを有効化する必要があります。podman.service ユニットを起動してください。ルートレスコンテナの場合は、代わりに podman.service ユーザーユニットを起動し、DOCKER_HOST 変数を設定する必要があります:

$ export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"

コンテナ間でのホスト名解決を行うには、podman-dnsname をインストールしてください。

ノート: buildkit を docker 内で有効化している場合、統合は機能しません。buildkit を無効化する必要があります: $ export DOCKER_BUILDKIT=0

NVIDIA GPU

NVIDIA Container Toolkit は、NVIDIA GPU 用のコンテナランタイムを提供します。nvidia-container-toolkit^AUR パッケージをインストールしてください。

セットアップをテストしてください:

$ podman run --rm nvidia/cuda:12.0.0-runtime-ubuntu20.04 nvidia-smi

Podman でルートレスコンテナを実行できるようにするには、/etc/nvidia-container-runtime/config.toml で no-cgroups の設定を true に設定しなければなりません。

イメージ

ノート: イメージのレジストリプレフィックスは省略できます。Podman は /etc/containers/registries.conf の unqualified-search-registries に定義されている全てのレジストリからイメージを自動で (定義されている順番で) 検索します。以下に記述しているイメージは設定に docker.io がなくても使えるように全てプレフィックスを付けています。

Arch Linux

以下のコマンドで Arch Linux x86_64 イメージが Docker Hub から取得されます。

# podman pull docker.io/archlinux

利用可能なタグの全リストや、ビルドツールあるなしのバージョンについては Docker Hub のページを見てください。

README.md も参照してください。

Alpine Linux

Alpine Linux はコンテナイメージとして容量が小さく、静的バイナリとしてコンパイルされたソフトウェアに適しています。以下のコマンドで最新の Alpine Linux イメージが Docker Hub から取得されます:

# podman pull docker.io/alpine

Alpine Linux はほとんどの Linux ディストリビューションで使われている glibc libc 実装の代わりに musl libc 実装を使っています。Arch Linux は glibc を使っているため、Arch Linux ホストと Alpine Linux コンテナにはパフォーマンスからソフトウェアの正確性まで様々な影響がある違いが存在します。差異については https://wiki.musl-libc.org/functional-differences-from-glibc.html で文書化されています。

Arch Linux (や glibc を使用する他の環境) で動的リンクでビルドしたソフトウェアは Alpine Linux (や他の libc を使用する環境) で実行したときにバグやパフォーマンスの問題が発生する可能性があります。例としては [2]、[3]、[4] を見てください。

CentOS

以下のコマンドによって最新の CentOS イメージが Docker Hub から取得されます:

# podman pull docker.io/centos

CentOS のリリースを指定するタグについては Docker Hub のページを見てください。

Debian

以下のコマンドによって最新の Debian イメージが Docker Hub から取得されます:

# podman pull docker.io/debian

利用可能なタグについては Docker Hub のページを見てください。各 Debian リリース毎に standard と slim バージョンが存在します。

トラブルシューティング

Add pause to process

WARN[0000] Failed to add pause process to systemd sandbox cgroup: Process org.freedesktop.systemd1 exited with status 1 

これは以下により解決できます: https://github.com/containers/crun/issues/704

# echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control

コンテナ DNS が有効化されない

WARN[0000]  binary not found, container DNS will not be enabled

Podman のネットワークバックエンドとして netavark を使用している場合、aardvark-dns をインストールする必要があります。

シェルがログアウトするとコンテナが終了してしまう

マシンからログアウトすると、一部のユーザで Podman コンテナが停止されます。これを防ぐには、コンテナを実行しているユーザに対してlinger を有効化してください。

podman-auto-update(1) § EXAMPLES で説明されているように、ユーザ systemd ユニットを作成することもできます。

Failed to move rootless netns

$ docker-compose up

ERRO[0000] failed to move the rootless netns slirp4netns process to the systemd user.slice: Process org.freedesktop.systemd1 exited with status 1

podman.service を起動/有効化することで解決できます。

Podman を 3.x から 4.0 にアップグレードした後に pause イメージのビルドでエラー

Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH

catatonit パッケージをインストールすれば、このエラーを修正できます。

3.x から 4.0 へのアップグレードに関する詳細は、公式のブログ記事を参照してください。

ルートレスモードでのコミット時にエラー

Error committing the finished image: error adding layer with blob "sha256:02823fca9b5444c196f1f406aa235213254af9909fca270f462e32793e2260d8": Error processing tar file(exit status 1) permitted operation

ストレージドライバがストレージ設定でオーバーレイされていることを確認してください。

ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー

AppArmor を使用している場合、dnsname プラグインを有効にしてブリッジネットワークを使用してコンテナを作成すると、問題が発生する可能性があります:

$ podman network create foo

/home/user/.config/cni/net.d/foo.conflist

$ podman run --rm -it --network=foo docker.io/library/alpine:latest ip addr

Error: command rootless-cni-infra [alloc 89398a9315256cb1938075c377275d29c2b6ebdd75a96b5c26051a89541eb928 foo festive_hofstadter    ] in container 1f4344bbd1087c892a18bacc35f4fdafbb61106c146952426488bc940a751efe failed with status 1, stdout="", stderr="exit status 3\n"

これは、次の行を /etc/apparmor.d/local/usr.sbin.dnsmasq に追加することで解決できます:

owner /run/user/[0-9]*/containers/cni/dnsname/*/dnsmasq.conf r,
owner /run/user/[0-9]*/containers/cni/dnsname/*/addnhosts r,
owner /run/user/[0-9]*/containers/cni/dnsname/*/pidfile rw,

そして、AppArmor プロファイルをリロードします:

# apparmor_parser -R /etc/apparmor.d/usr.sbin.dnsmasq
# apparmor_parser /etc/apparmor.d/usr.sbin.dnsmasq

イメージが見つからない

Podman パッケージ内のファイルは上流からやってくるので、デフォルトではレジストリリストが存在しません。すなわち、デフォルトの状態でレジストリを指定せずにイメージを pull しようとすると、以下のようなエラーが発生してしまうのです:

Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

始めの構成は以下のような感じでしょう:

/etc/containers/registries.conf.d/00-unqualified-search-registries.conf

unqualified-search-registries = ["docker.io"]

/etc/containers/registries.conf.d/01-registries.conf

[[registry]]
location = "docker.io"

これは docker のデフォルト設定と等価です。

あるいは、あまり便利ではないが、レジストリ名の省略が設定されていないシステムと高い互換性がある方法として、Containerfile や Dockerfile で完全なレジストリパスを使用することもできます。

Containerfile

FROM docker.io/archlinux/archlinux

Permission denied: OCI permission denied

$ podman exec openvas_openvas_1 bash

Error: crun: writing file `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/user.slice/libpod-b3e8048a9b91e43c214b4d850ac7132155a684d6502e12e22ceb6f73848d117a.scope/container/cgroup.procs`: Permission denied: OCI permission denied

以下で解決できます: BBS#253966

$ env DBUS_SESSION_BUS_ADDRESS= podman ...
$ env DBUS_SESSION_BUS_ADDRESS= podman-compose ...

Pushing images to Docker Hub: access denied/authentication required

podman push を使用してコンテナイメージを Docker Hub に push する際に、次のエラーが発生することがあります: Requested access to the resource is denied または Authentication required。以下のヒントが問題を修正する助けになるかもしれません:

• ローカルイメージにタグをつける:

  # podman tag <localImage> docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>

• タグ付きイメージを push する:

  # podman push docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag> docker://docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>

• docker.io、Docker Hub リポジトリ、Docker Hub Registry サーバにログインする:

# podman login -u <DockerHubUsername> -p <DockerHubPassword> registry-1.docker.io
# podman login -u <DockerHubUsername> -p <DockerHubPassword> docker.io/<dockerHubUsername>/<dockerHubRepository>
# podman login -u <DockerHubUsername> -p <DockerHubPassword> docker.io

• ログイン前に全レジストリからログアウトする。例:

  # podman logout --all

• リポジトリの Docker Hub Collaborators タブで <dockerHubUsername> を協力者 (collaborator) として追加する。

WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers

ルートレスで実行中の Buildah/Podman は、バインドマウントが共有されていることを期待します。バインドマウントが private に設定されていないか確認してください:

$ findmnt -o PROPAGATION /

PROPAGATION
private

その場合、mount(8) § Shared_subtree_operations を参照し、以下を実行して一時的にマウントを共有させることができます:

# mount --make-shared /

恒久的に共有させたい場合は、/etc/fstab を編集して、対象のマウントに shared オプションを追加し、再起動してください。以下のようなエントリになります:

/etc/fstab

# <device>                                <dir> <type> <options> <dump> <fsck>
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 /     ext4   defaults,shared   0      1

参照

• 公式ウェブサイト

翻訳ステータス: このページは en:Podman の翻訳バージョンです。最後の翻訳日は 2023-04-10 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。