「Podman」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎ルートレス Podman: タイトルのみ飜訳)
(同期)
 
(2人の利用者による、間の28版が非表示)
10行目: 10行目:
 
{{Related|Vagrant}}
 
{{Related|Vagrant}}
 
{{Related articles end}}
 
{{Related articles end}}
Podman は [[Docker]] の代わりになるプログラムで、同じようなインターフェイスを提供します。ルートレスコンテナとdocker-compose の shim サービスをサポートします。
+
Podman は [[Docker]] の代わりになるプログラムで、同じようなインターフェイスを提供します。ルートレスコンテナと ''docker-compose'' の shim サービスをサポートします。
   
 
== インストール ==
 
== インストール ==
16行目: 16行目:
 
{{Pkg|podman}} パッケージを[[インストール]]してください。コンテナイメージを作成したい場合は [[Buildah]] も見てください。
 
{{Pkg|podman}} パッケージを[[インストール]]してください。コンテナイメージを作成したい場合は [[Buildah]] も見てください。
   
[[Docker]] と異なり、Podman はデを必要とませんが、{{Pkg|cockpit-podman}} など {{Pkg|cockpit}} のようなサビスのための API は提供しています
+
コンテナのネットワグに関ては、{{Pkg|cni-plugins}} または v4.0 からは {{Pkg|netavark}} をインストしてください。
   
  +
[[Docker]] を置き換えたい場合は、docker バイナリを模倣する {{Pkg|podman-docker}} を man ページと共にインストールできます。
デフォルトでは Podman を実行できるのは root だけです。root 以外のユーザーでコンテナを実行したい場合は[[#ルートレス Podman|ルートレス Podman]] を参照。
 
  +
  +
[[Docker]] と異なり、Podman はデーモンを必要としませんが、{{Pkg|cockpit-podman}} を介して [[cockpit]] のようなサービスに API を提供するものは存在します。
  +
  +
デフォルトでは Podman コンテナを実行できるのは root だけです。root 以外のユーザーでコンテナを実行したい場合は [[#ルートレス Podman]] を参照してください。
   
 
== 設定 ==
 
== 設定 ==
   
コンテナの挙動を設定する設定ファイルは {{ic|/usr/share/containers/}} にあります。編集する前に {{ic|/etc/containers}} にコピーする必要があります。Podman によって使われるネットワークブリッジインターフェイスを設定したいときは {{ic|/etc/cni/net.d/87-podman-bridge.conflist}} を見てください。
+
コンテナの挙動を設定する設定ファイルは {{ic|/usr/share/containers/}} にあります。編集する前に {{ic|/etc/containers}} にコピーする必要があります。Podman によって使われるネットワークブリッジインターフェイスを設定したいときは {{ic|/etc/cni/net.d/87-podman.conflist}} を見てください。
   
 
=== ルートレス Podman ===
 
=== ルートレス Podman ===
28行目: 32行目:
 
{{Warning|ルートレス Podman は非特権ユーザーの名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は [[セキュリティ#アプリケーションのサンドボックス化]] を参照してください。}}
 
{{Warning|ルートレス Podman は非特権ユーザーの名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は [[セキュリティ#アプリケーションのサンドボックス化]] を参照してください。}}
   
デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは {{ic|root}} だけです。
+
デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは {{ic|root}} だけです。ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。{{man|1|podman|Rootless mode}} も参照してください
  +
  +
==== 追加の依存関係 ====
  +
  +
{{Pkg|slirp4netns}} が、[https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md rootless 環境]内で Podman を実行するための依存パッケージとしてインストールされます。
  +
  +
Podman が {{Pkg|netavark}} ネットワークバックエンド ({{man|5|containers.conf}} を参照) を使用する場合、rootless コンテナで名前解決を行うために {{Pkg|aardvark-dns}} をインストールする必要があります。
  +
  +
==== ネイティブな rootless オーバーレイを有効化する ====
  +
  +
以前は、rootless 環境で [[FUSE]] オーバーレイをマウントするために {{Pkg|fuse-overlayfs}} パッケージを使用しなくてはなりませんでした。しかし、Podman と Linux カーネルの最近のバージョンは''ネイティブな'' rootless オーバーレイを[https://www.redhat.com/sysadmin/podman-rootless-overlay サポート]しており、これはより高パフォーマンスです。{{Pkg|fuse-overlayfs}} から移行するには、次を実行してください:
  +
$ podman system reset
   
  +
残念ながら、このコマンドは pull されたコンテナをすべて削除してしまいます。また、Podman が {{ic|overlay}} ドライバを使用し、かつ {{man|5|containers-storage.conf}} で {{ic|mount_program}} パラメータが定義されていないことを確認してください。さらに、[[Docker#ネイティブ overlay diff エンジンを有効化する]] の指示に従う必要があるかもしれません。
Podman コンテナを root を使わずに操作したい場合、まずコンテナを使いたいユーザーとグループを決めて、適切なエントリを {{ic|/etc/subuid}} と {{ic|/etc/subgid}} に追加してください。
 
   
  +
ネイティブな rootless オーバーレイが有効化されていることを確認するには、次を実行してください:
以下の例では {{ic|podman}} ユーザーとグループによる Podman コンテナの実行を有効化します。165536 から 169631 までの UID/GID が {{ic|podman}} ユーザー・グループにそれぞれ割り当てられます。詳しくは {{man|5|subuid}} や {{man|5|subgid}} を見てください。
 
  +
$ podman info
  +
{{ic|graphDriverName: overlay}} と {{ic|Native Overlay Diff: "true"}} が出力される必要があります。
   
 
==== kernel.unprivileged_userns_clone を有効にする ====
 
==== kernel.unprivileged_userns_clone を有効にする ====
   
First, check the value of {{ic|kernel.unprivileged_userns_clone}} by running:
+
まず、次のコマンドを実行して {{ic|kernel.unprivileged_userns_clone}} の値を確認します:
   
 
$ sysctl kernel.unprivileged_userns_clone
 
$ sysctl kernel.unprivileged_userns_clone
   
  +
現在、{{ic|0}} に設定されている場合は、[[sysctl]] または[[カーネルパラメータ]]で {{ic|1}} を設定して有効にします。
If it is currently set to {{ic|0}}, enable it by setting {{ic|1}} via [[sysctl]] or [[kernel parameter]].
 
   
{{Note|{{pkg|linux-hardened}} has {{ic|kernel.unprivileged_userns_clone}} set to {{ic|0}} by default.}}
+
{{Note|{{Pkg|linux-hardened}} では {{ic|kernel.unprivileged_userns_clone}} がデフォルトで {{ic|0}} に設定されています。}}
   
 
==== subuid と subgid を設定する ====
 
==== subuid と subgid を設定する ====
   
  +
ルートレスで Podman を動かすには、Podman を使用するユーザー毎に {{man|5|subuid}} と {{man|5|subgid}} の設定エントリが存在していなければなりません。{{man|8|useradd}} を使って作成された新しい[[ユーザー]]には、これらのエントリがデフォルトで存在します。
In order for users to run rootless Podman, a {{man|5|subuid}} and {{man|5|subgid}} must be set for each user that wants to use it. These information must, ultimately, be stored in {{ic|/etc/subuid}} and {{ic|/etc/subgid}} which lists the UIDs for their user namespace.
 
   
  +
{{Note|
{{ic|/etc/subuid}} and {{ic|/etc/subgid}} do not exist by default. If they do not exist yet in your system, create them by running:
 
  +
* {{Pkg|shadow}} {{ic|4.11.1-3}} より前の時点で作成されたユーザーは、{{ic|/etc/subuid}} と {{ic|/etc/subgid}} 内にエントリがデフォルトで存在しません。{{man|8|usermod}} コマンドを使うか、これらのファイルを手動で変更することで、エントリを作成することができます。
  +
:以下のコマンドは、{{ic|''username''}} というユーザとグループが Podman コンテナ (あるいは他の種のコンテナ) を実行できるようにします。このコマンドは、指定された範囲の UID と GID を、指定されたユーザとグループに割り当てます。
  +
:{{bc|# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ''username''}}
  +
:{{ic|''username''}} に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず {{ic|/etc/subuid}} と {{ic|/etc/subgid}} を調べて、すでに予約されている範囲を見つけてください。
  +
* 多くのイメージはマッピングのために65536個の UID と GID を必要とします (特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の UID と GID を割り当てることをお勧めします。
  +
* [[systemd-homed]] を使用している場合、コンテナ用の UID と GID の最小値は 524288 以上でなければなりません ({{ic|userdbctl}} の出力で "begin container users" を確認してください)。[https://www.reddit.com/r/podman/comments/uwgkb1/tip_systemdhomed_with_rootless_subuidsubgid/]
  +
}}
   
# touch /etc/subuid /etc/subgid
+
==== subuid subgid の変更を伝播する ====
   
  +
ルートレス Podman は非特権名前空間を存続させるために pause プロセスを使用します。これにより、{{ic|/etc/subuid}} および {{ic|/etc/subgid}} ファイルへの変更は、pause プロセスの実行中にルートレスコンテナに伝播されるのを防ぎます。これらの変更を伝播するには、以下のコマンドを実行します。
{{Note|The above command is required, because the ''usermod'' used below do not create them.}}
 
   
  +
$ podman system migrate
The following command enables the {{ic|''username''}} user and group to run Podman containers (or other types of containers in that case). It allocates a given range of UIDs and GIDs to the given user and group.
 
   
  +
この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。
# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ''username''
 
   
  +
==== SYS_CHROOT ケイパビリティを追加する (任意) ====
{{Tip|Instead of using ''usermod'' command, this could be achieved either by editing {{ic|/etc/subuid}} and {{ic|/etc/subgid}} directly.}}
 
   
  +
リリース 4.4 から、以前はデフォルトであった一部のケイパビリティが ({{ic|SYS_CHROOT}} を含めて) 無くなりました ([https://blog.podman.io/2022/12/dropping-capabilities-making-containers-more-secure/ 公式のブログ投稿]で説明されています)。これは、chroot を使用するコンテナ (''archlinux:base'' など) に影響を与え、コンテナ内での pacman の操作 (すなわち、インストール後のスクリプトを実行するパッケージのインストール) が失敗してしまいます。このような問題は、podman でビルドする際にビルド中に以下のようなエラーが発生する場合、特定できます:
Now, you should have the following content (replacing {{ic|''username''}} with the given username):
 
   
  +
...
{{hc|/etc/subuid|
 
  +
could not change the root directory (Operation not permitted)
''username'':100000:65536
 
  +
error: command failed to execute correctly
  +
...
  +
  +
これを解決するには、{{ic|/etc/containers/containers.conf}} を編集してリストに {{ic|SYS_CHROOT}} を追加してください:
  +
  +
{{hc|/etc/containers/containers.conf|2=
  +
default_capabilities = [
  +
"CHOWN",
  +
"DAC_OVERRIDE",
  +
"FOWNER",
  +
"FSETID",
  +
"KILL",
  +
"NET_BIND_SERVICE",
  +
"SETFCAP",
  +
"SETGID",
  +
"SETPCAP",
  +
"SETUID",
  +
"SYS_CHROOT",
  +
]
 
}}
 
}}
   
  +
また、{{man|1|podman-build}} を実行する際にコマンドラインから {{ic|--cap-add sys_chroot}} を使うことで、一時的に SYS_CHROOT ケイパビリティを付与することができます。
{{hc|/etc/subgid|
 
  +
''username'':100000:65536
 
  +
=== ストレージ ===
  +
  +
コンテナイメージとインスタンスの保存方法と保存場所の設定は、{{ic|/etc/containers/storage.conf}} にあります。
  +
  +
{{Note|[[#ルートレス Podman]] を使用する場合、ストレージ設定のオーバーライドをユーザーごとに {{ic|$XDG_CONFIG_HOME/containers/storage.conf}} に追加できます。}}
  +
  +
ストレージに使用しているファイルシステムに応じて {{ic|driver}} を設定します ({{man|5|containers-storage.conf|STORAGE_TABLE}} を参照)。
  +
  +
=== 外部のアーキテクチャ ===
  +
  +
Podman は、[[Wikipedia:binfmt_misc]] システムを使用することで、使用中のホストとは異なる CPU アーキテクチャ用にビルドされたイメージを実行することができます。
  +
  +
これを有効化するには、{{Pkg|qemu-user-static}} と {{Pkg|qemu-user-static-binfmt}} をインストールしてください。
  +
  +
[[systemd]] には、新しいルールを有効化する {{ic|systemd-binfmt.service}} サービスが同梱されています。
  +
  +
binfmt ルールが追加されたことを確認してください:
  +
  +
{{hc|$ 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 は外部のアーキテクチャのイメージを実行できるようになったはずです。ほとんどのコマンドは、{{ic|--arch}} オプションが渡されたときに、外部のアーキテクチャを使用します。
{{Note|Many images require 65536 uids / gids for mapping (notably the base busybox and alpine images). It is recommended that you allocate at least that many uids / gids for each user to maximize compatibility with docker.}}
 
   
  +
例:
==== subuid と subgid の変更を伝える ====
 
   
  +
{{hc|# podman run --arch arm64 'docker.io/alpine:latest' arch|
Rootless Podman uses a pause process to keep the unprivileged namespaces alive. This prevents any change to the {{ic|/etc/subuid}} and {{ic|/etc/subgid}} files from being propagated to the rootless containers while the pause process is running. For these changes to be propagated it is necessary to run:
 
  +
aarch64
  +
}}
   
  +
=== Docker Compose ===
$ podman system migrate
 
   
  +
Podman 3.0.0 では、''docker-compose'' サポートが追加されました。これには、Docker を模倣する Podman ソケットを有効化する必要があります。{{ic|podman.service}} ユニットを[[起動]]してください。ルートレスコンテナの場合は、代わりに {{ic|podman.service}} [[ユーザーユニット]]を[[起動]]し、{{ic|DOCKER_HOST}} 変数を設定する必要があります:
After this, the user/group specified in the above files is able to start and run Podman containers.
 
   
  +
$ export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"
== イメージ ==
 
{{Note|イメージのレジストリプレフィックスは省略できます。Podman は {{ic|/etc/containers/registries.conf}} の {{ic|registries.search}} に定義されている全てのレジストリからイメージを自動で (定義されている順番で) 検索します。以下に記述しているイメージは設定に {{ic|docker.io}} がなくても使えるように全てプレフィックスを付けています。}}
 
   
  +
コンテナ間でのホスト名解決を行うには、{{Pkg|podman-dnsname}} をインストールしてください。
=== Arch Linux ===
 
   
  +
{{Note|1=
以下のコマンドで [https://hub.docker.com/_/archlinux/ Arch Linux] x86_64 イメージが [https://hub.docker.com/ Docker Hub] から取得されます。ネットワークなどを除外した縮小版の Arch となっています。
 
  +
buildkit を docker 内で有効化している場合、統合は機能しません。buildkit を無効化する必要があります:
   
  +
$ export DOCKER_BUILDKIT=0
# podman pull docker.io/archlinux
 
   
  +
}}
[https://github.com/archlinux/archlinux-docker/blob/master/README.md README.md] も参照してください。
 
   
  +
=== NVIDIA GPU ===
完全な Arch イメージを使いたい場合、リポジトリを複製して自分自身のイメージを作成してください。
 
   
  +
[https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#podman NVIDIA Container Toolkit] は、NVIDIA GPU 用のコンテナランタイムを提供します。{{AUR|nvidia-container-toolkit}} パッケージをインストールしてください。
$ git clone https://github.com/archlinux/archlinux-docker.git
 
   
{{Pkg|devtools}} パケージインストールしてください
+
トアップストしてください:
  +
  +
$ podman run --rm nvidia/cuda:12.0.0-runtime-ubuntu20.04 nvidia-smi
  +
  +
Podman でルートレスコンテナを実行できるようにするには、{{ic|/etc/nvidia-container-runtime/config.toml}} で {{ic|no-cgroups}} の設定を {{ic|true}} に設定しなければなりません。
  +
  +
== イメージ ==
  +
  +
{{Note|イメージのレジストリプレフィックスは省略できます。Podman は {{ic|/etc/containers/registries.conf}} の {{ic|unqualified-search-registries}} に定義されている全てのレジストリからイメージを自動で (定義されている順番で) 検索します。以下に記述しているイメージは設定に {{ic|docker.io}} がなくても使えるように全てプレフィックスを付けています。}}
  +
  +
=== Arch Linux ===
  +
  +
以下のコマンドで [https://hub.docker.com/_/archlinux/ Arch Linux] x86_64 イメージが [https://hub.docker.com/ Docker Hub] から取得されます。
  +
  +
# podman pull docker.io/archlinux
   
  +
利用可能なタグの全リストや、ビルドツールあるなしのバージョンについては Docker Hub のページを見てください。
{{ic|packages}} ファイルを編集して 'base' とだけ記述し、以下のコマンドを実行:
 
   
  +
[https://gitlab.archlinux.org/archlinux/archlinux-docker/blob/master/README.md README.md] も参照してください。
# make rootfs
 
# podman build -t archlinux .
 
   
 
=== Alpine Linux ===
 
=== Alpine Linux ===
108行目: 190行目:
 
# podman pull docker.io/alpine
 
# podman pull docker.io/alpine
   
Alpine Linux はほとんどの Linux ディストリビューションで使われている [https://www.gnu.org/software/libc/ glibc] libc 実装の代わりに [https://musl.libc.org/ musl] libc 実装を使っています。Arch Linux は glibc を使っているため、Arch Linux ホストと Alpine Linux コンテナにはパフォーマンスからソフトウェアの正確性まで様々な影響がある違いが存在します。C ライブラリの差異については [https://wiki.musl-libc.org/functional-differences-from-glibc.html こちら] に記述されています。
+
Alpine Linux はほとんどの Linux ディストリビューションで使われている [https://www.gnu.org/software/libc/ glibc] libc 実装の代わりに [https://musl.libc.org/ 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 を使用する環境) で実行したときにバグやパフォーマンスの問題が発生する可能性があります。例としては [https://bugs.python.org/issue32307], [https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image], [https://pythonspeed.com/articles/alpine-docker-python] を見てください。
+
Arch Linux (や glibc を使用する他の環境) で動的リンクでビルドしたソフトウェアは Alpine Linux (や他の libc を使用する環境) で実行したときにバグやパフォーマンスの問題が発生する可能性があります。例としては [https://bugs.python.org/issue32307][https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image][https://pythonspeed.com/articles/alpine-docker-python] を見てください。
   
 
=== CentOS ===
 
=== CentOS ===
   
以下のコマンドによって最新の [https://hub.docker.com/_/centos Centos] イメージが [https://hub.docker.com/ Docker Hub] から取得されます:
+
以下のコマンドによって最新の [https://hub.docker.com/_/centos CentOS] イメージが [https://hub.docker.com/ Docker Hub] から取得されます:
   
 
# podman pull docker.io/centos
 
# podman pull docker.io/centos
130行目: 212行目:
 
== トラブルシューティング ==
 
== トラブルシューティング ==
   
  +
=== Add pause to process ===
=== イメージが見つからない ===
 
   
  +
WARN[0000] Failed to add pause process to systemd sandbox cgroup: Process org.freedesktop.systemd1 exited with status 1
By default the registry list is not populated as the files in the package come from upstream. This means that by default, trying to pull any image without specifying the registry will result in an error similar to the following:
 
   
  +
これは以下により解決できます: https://github.com/containers/crun/issues/704
Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
 
   
  +
# echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control
A starting configuration could be the following:
 
   
  +
=== コンテナ DNS が有効化されない ===
{{hc|1=/etc/containers/registries.conf.d/00-unqualified-search-registries.conf|2=
 
unqualified-search-registries = ["docker.io"]
 
}}
 
   
  +
WARN[0000] binary not found, container DNS will not be enabled
{{hc|1=/etc/containers/registries.conf.d/01-registries.conf|2=
 
  +
<nowiki>[[registry]]</nowiki>
 
  +
Podman のネットワークバックエンドとして {{Pkg|netavark}} を使用している場合、{{Pkg|aardvark-dns}} をインストールする必要があります。
location = "docker.io"
 
  +
  +
=== シェルがログアウトするとコンテナが終了してしまう ===
  +
  +
マシンからログアウトすると、一部のユーザで Podman コンテナが停止されます。これを防ぐには、コンテナを実行しているユーザに対して[[systemd/ユーザー#systemd のユーザーインスタンスを自動起動|linger を有効化]]してください。
  +
  +
{{man|1|podman-auto-update|EXAMPLES}} で説明されているように、ユーザ systemd ユニットを作成することもできます。
  +
  +
=== Failed to move rootless netns ===
  +
  +
{{hc|$ 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
 
}}
 
}}
   
  +
{{ic|podman.service}} を[[起動/有効化]]することで解決できます。
This is equivalent to the default docker configuration.
 
   
  +
=== Podman を 3.x から 4.0 にアップグレードした後に pause イメージのビルドでエラー ===
=== コンテナがシェルログアウトで終了する ===
 
   
  +
Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH
It may happen that after logging out from machine, Podman containers are stopped. To prevent that, user lingering should be enabled for user running containers:
 
   
  +
{{Pkg|catatonit}} パッケージを[[インストール]]すれば、このエラーを修正できます。
$ loginctl enable-linger
 
   
  +
3.x から 4.0 へのアップグレードに関する詳細は、公式の[https://podman.io/blogs/2022/02/04/network-usage.html ブログ記事]を参照してください。
You can also create user systemd unit as described: https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html#examples
 
  +
  +
=== ルートレスモードでのコミット時にエラー ===
  +
  +
Error committing the finished image: error adding layer with blob "sha256:02823fca9b5444c196f1f406aa235213254af9909fca270f462e32793e2260d8": Error processing tar file(exit status 1) permitted operation
  +
  +
ストレージドライバが[[#ストレージ|ストレージ設定]]でオーバーレイされていることを確認してください。
   
 
=== ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー ===
 
=== ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー ===
   
  +
[[AppArmor]] を使用している場合、{{ic|dnsname}} プラグインを有効にしてブリッジネットワークを使用してコンテナを作成すると、問題が発生する可能性があります:
If you are using [[AppArmor]] you might end up with problems when creating container using a bridge network with the {{ic|dnsname}} plugin enabled:
 
   
 
{{hc|$ podman network create foo|
 
{{hc|$ podman network create foo|
169行目: 266行目:
 
}}
 
}}
   
This can be solved by adding the following lines to {{ic|/etc/apparmor.d/local/usr.sbin.dnsmasq}}:
+
これは、次の行を {{ic|/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/*/dnsmasq.conf r,
175行目: 272行目:
 
owner /run/user/[0-9]*/containers/cni/dnsname/*/pidfile rw,
 
owner /run/user/[0-9]*/containers/cni/dnsname/*/pidfile rw,
   
  +
そして、AppArmor プロファイルをリロードします:
And then reloading the AppArmor profile:
 
   
 
# apparmor_parser -R /etc/apparmor.d/usr.sbin.dnsmasq
 
# apparmor_parser -R /etc/apparmor.d/usr.sbin.dnsmasq
 
# apparmor_parser /etc/apparmor.d/usr.sbin.dnsmasq
 
# apparmor_parser /etc/apparmor.d/usr.sbin.dnsmasq
   
  +
=== イメージが見つからない ===
=== ルートレスモードでのコミット時にエラー ===
 
   
  +
Podman パッケージ内のファイルは上流からやってくるので、デフォルトではレジストリリストが存在しません。すなわち、デフォルトの状態でレジストリを指定せずにイメージを pull しようとすると、以下のようなエラーが発生してしまうのです:
Error committing the finished image: error adding layer with blob "sha256:02823fca9b5444c196f1f406aa235213254af9909fca270f462e32793e2260d8": Error processing tar file(exit status 1) permitted operation
 
   
  +
Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
Check that the storage driver is overlay in the [[#Storage]] configuration.
 
   
  +
始めの構成は以下のような感じでしょう:
=== Error building pause image after Podman upgrade 3.x to 4.0 ===
 
   
  +
{{hc|/etc/containers/registries.conf.d/00-unqualified-search-registries.conf|2=
Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH
 
  +
unqualified-search-registries = ["docker.io"]
  +
}}
   
  +
{{hc|/etc/containers/registries.conf.d/01-registries.conf|<nowiki>
[[Install]] the {{Pkg|catatonit}} package to fix the error.
 
  +
[[registry]]
  +
location = "docker.io"
  +
</nowiki>}}
   
  +
これは docker のデフォルト設定と等価です。
For details on upgrading from 3.x to 4.0, see the official [https://podman.io/blogs/2022/02/04/network-usage.html blog article]
 
   
  +
あるいは、あまり便利ではないが、レジストリ名の省略が設定されていないシステムと高い互換性がある方法として、{{ic|Containerfile}} や {{ic|Dockerfile}} で完全なレジストリパスを使用することもできます。
=== Container dns will not be enabled ===
 
   
  +
{{hc|Containerfile|
WARN[0000] binary not found, container dns will not be enabled
 
  +
FROM docker.io/archlinux/archlinux
  +
}}
   
  +
=== Permission denied: OCI permission denied ===
If you installed {{Pkg|netavark}} as podman network backend you need to install {{Pkg|aardvark-dns}}
 
   
  +
{{hc|$ podman exec openvas_openvas_1 bash|
=== failed to move rootless netns ===
 
  +
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
  +
}}
   
  +
以下で解決できます: [https://bbs.archlinux.org/viewtopic.php?id=253966 BBS#253966]
{{hc|1=docker-compose up|2= ERRO[0000] failed to move the rootless netns slirp4netns process to the systemd user.slice: Process org.freedesktop.systemd1 exited with status 1}}
 
   
  +
$ env DBUS_SESSION_BUS_ADDRESS= podman ...
Can be solved by [[starting/enabling]] {{ic|podman.service}}.
 
  +
$ env DBUS_SESSION_BUS_ADDRESS= podman-compose ...
   
=== Permission denied: OCI permission denied ===
+
=== Pushing images to Docker Hub: access denied/authentication required ===
   
  +
{{ic|podman push}} を使用してコンテナイメージを Docker Hub に push する際に、次のエラーが発生することがあります: {{ic|Requested access to the resource is denied}} または {{ic|Authentication required}}。以下のヒントが問題を修正する助けになるかもしれません:
{{hc|1=podman exec openvas_openvas_1 bash|2=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}}
 
   
  +
* ローカルイメージにタグをつける: {{bc|# podman tag <localImage> docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>}}
Can be solved: https://bbs.archlinux.org/viewtopic.php?id=253966
 
  +
* タグ付きイメージを push する: {{bc|# podman push docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag> docker://docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>}}
  +
* docker.io、Docker Hub リポジトリ、Docker Hub Registry サーバにログインする:
  +
: {{bc|<nowiki>
  +
# 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
  +
</nowiki>}}
  +
* ログイン前に全レジストリからログアウトする。例: {{bc|# podman logout --all}}
  +
* リポジトリの Docker Hub Collaborators タブで {{ic|<dockerHubUsername>}} を協力者 (collaborator) として追加する。
   
  +
=== WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers ===
env DBUS_SESSION_BUS_ADDRESS= podman ...
 
env DBUS_SESSION_BUS_ADDRESS= podman-compose ...
 
   
  +
ルートレスで実行中の Buildah/Podman は、バインドマウントが共有されていることを期待します。バインドマウントが private に設定されていないか確認してください:
=== Add pause to process ===
 
   
  +
{{hc|$ findmnt -o PROPAGATION /|
WARN[0000] Failed to add pause process to systemd sandbox cgroup: Process org.freedesktop.systemd1 exited with status 1
 
  +
PROPAGATION
  +
private
  +
}}
   
  +
その場合、{{man|8|mount|Shared_subtree_operations}} を参照し、以下を実行して'''一時的に'''マウントを共有させることができます:
Can be solved using: https://github.com/containers/crun/issues/704
 
   
  +
# mount --make-shared /
# echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control
 
  +
  +
'''恒久的に'''共有させたい場合は、[[Fstab#使用法|/etc/fstab]] を編集して、対象のマウントに ''shared'' オプションを追加し、再起動してください。以下のようなエントリになります:
  +
  +
{{hc|/etc/fstab|2=
  +
# <device> <dir> <type> <options> <dump> <fsck>
  +
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 / ext4 defaults,shared 0 1
  +
}}
   
 
== 参照 ==
 
== 参照 ==
   
 
* [https://podman.io/ 公式ウェブサイト]
 
* [https://podman.io/ 公式ウェブサイト]
  +
  +
{{TranslationStatus|Podman|2023-04-10|775105}}

2023年4月10日 (月) 19:25時点における最新版

関連記事

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: overlayNative 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-staticqemu-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-toolkitAUR パッケージをインストールしてください。

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

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

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

イメージ

ノート: イメージのレジストリプレフィックスは省略できます。Podman は /etc/containers/registries.confunqualified-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 のデフォルト設定と等価です。

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

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 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。