「Podman」の版間の差分
(→インストール: 同期) |
(→ルートレス Podman: 同期) |
||
27行目: | 27行目: | ||
コンテナの挙動を設定する設定ファイルは {{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-bridge.conflist}} を見てください。 |
||
+ | |||
=== ルートレス Podman === |
=== ルートレス Podman === |
||
46行目: | 47行目: | ||
現在、{{ic|0}} に設定されている場合は、[[sysctl]] または[[カーネルパラメータ]]で {{ic|1}} を設定して有効にします。 |
現在、{{ic|0}} に設定されている場合は、[[sysctl]] または[[カーネルパラメータ]]で {{ic|1}} を設定して有効にします。 |
||
− | {{Note|{{ |
+ | {{Note|{{Pkg|linux-hardened}} では {{ic|kernel.unprivileged_userns_clone}} がデフォルトで {{ic|0}} に設定されています。}} |
==== subuid と subgid を設定する ==== |
==== subuid と subgid を設定する ==== |
||
53行目: | 54行目: | ||
{{Note| |
{{Note| |
||
− | {{ |
+ | * {{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''}} というユーザとグループが Podman コンテナ (あるいは他の種のコンテナ) を実行できるようにします。このコマンドは、指定された範囲の UID と GID を、指定されたユーザとグループに割り当てます。 |
||
+ | :{{ic|''username''}} に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず {{ic|/etc/subuid}} と {{ic|/etc/subgid}} を調べて、すでに予約されている範囲を見つけてください。 |
||
− | |||
− | # usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ''username'' |
||
− | |||
− | 注意点として、{{ic|''username''}} に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず {{ic|/etc/subuid}} と {{ic|/etc/subgid}} を調べて、すでに予約されている範囲を見つけてください。 |
||
− | }} |
||
− | |||
− | {{Note| |
||
* 多くのイメージはマッピングのために65536個の UID と GID を必要とします (特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の UID と GID を割り当てることをお勧めします。 |
* 多くのイメージはマッピングのために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/] |
* [[systemd-homed]] を使用している場合、コンテナ用の UID と GID の最小値は 524288 以上でなければなりません ({{ic|userdbctl}} の出力で "begin container users" を確認してください)。[https://www.reddit.com/r/podman/comments/uwgkb1/tip_systemdhomed_with_rootless_subuidsubgid/] |
||
74行目: | 69行目: | ||
この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。 |
この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。 |
||
+ | |||
+ | ==== SYS_CHROOT ケイパビリティを追加する (任意) ==== |
||
+ | |||
+ | 4.4 リリースから、以前はデフォルトであった一部のケイパビリティが ({{ic|SYS_CHROOT}} を含めて) 無くなりました ([https://blog.podman.io/2022/12/dropping-capabilities-making-containers-more-secure/ 公式のブログ投稿]で説明されています)。これは、chroot を使用するコンテナ (''archlinux:base'' など) に影響を与え、コンテナ内での pacman の操作 (すなわち、インストール後のスクリプトを実行するパッケージのインストール) が失敗してしまいます。このような問題は、podman でビルドする際にビルド中に以下のようなエラーが発生する場合、特定できます: |
||
+ | |||
+ | ... |
||
+ | could not change the root directory (Operation not permitted) |
||
+ | error: command failed to execute correctly |
||
+ | ... |
||
+ | |||
+ | これを解決するには、{{ic|/etc/containers/contrainers.conf}} を編集してリストに {{ic|SYS_CHROOT}} を追加してください: |
||
+ | |||
+ | {{hc|/etc/containers/contrainers.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 ケイパビリティを付与することができます。 |
||
=== ストレージ === |
=== ストレージ === |
2023年3月16日 (木) 14:51時点における版
Podman は Docker の代わりになるプログラムで、同じようなインターフェイスを提供します。ルートレスコンテナと docker-compose の shim サービスをサポートします。
目次
- 1 インストール
- 2 設定
- 3 イメージ
- 4 トラブルシューティング
- 4.1 イメージが見つからない
- 4.2 コンテナがシェルログアウトで終了する
- 4.3 ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー
- 4.4 ルートレスモードでのコミット時にエラー
- 4.5 Error building pause image after Podman upgrade 3.x to 4.0
- 4.6 Container dns will not be enabled
- 4.7 failed to move rootless netns
- 4.8 Permission denied: OCI permission denied
- 4.9 プロセスをポーズに追加
- 5 参照
インストール
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-bridge.conflist
を見てください。
ルートレス Podman
デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは root
だけです。ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。podman(1) § Rootless mode も参照してください。
追加の依存関係
Podman をルートレス環境で動作させるために fuse-overlayfs パッケージが必要です。
kernel.unprivileged_userns_clone を有効にする
まず、次のコマンドを実行して kernel.unprivileged_userns_clone
の値を確認します:
$ sysctl kernel.unprivileged_userns_clone
現在、0
に設定されている場合は、sysctl またはカーネルパラメータで 1
を設定して有効にします。
subuid と subgid を設定する
ルートレスで Podman を動かすには、Podman を使用するユーザー毎に subuid(5) と subgid(5) の設定エントリが存在していなければなりません。useradd(8) を使って作成された新しいユーザーには、これらのエントリがデフォルトで存在します。
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/contrainers.conf
を編集してリストに SYS_CHROOT
を追加してください:
/etc/containers/contrainers.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
にあります。
ストレージに使用しているファイルシステムに応じて driver
を設定します (containers-storage.conf(5) § STORAGE_TABLE を参照)。
Foreign architectures
Podman is able to run images built for different CPU architecture than host using Wikipedia:binfmt_misc system.
To enable it install qemu-user-staticAUR and binfmt-qemu-staticAUR packages.
systemd comes with systemd-binfmt.service
service which should enable new rules.
Verify that binfmt rules have been added:
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 should now be able to run foreign architecture images. Most commands use the foreign architecture when --arch
option is passed.
Example:
podman run --arch arm64 'docker.io/alpine:latest' arch
aarch64
Docker Compose
Podman 3.0.0 introduces docker-compose support. This requires enabling a Podman socket which pretends to be docker; start the podman.service
unit. For rootless containers, this requires you to start the podman.service
user unit instead and set the DOCKER_HOST
variable:
$ export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"
To get hostname resolution between containers running install podman-dnsname.
イメージ
Arch Linux
以下のコマンドで Arch Linux x86_64 イメージが Docker Hub から取得されます。ネットワークなどを除外した縮小版の Arch となっています。
# podman pull docker.io/archlinux
README.md も参照してください。
完全な Arch イメージを使いたい場合、リポジトリを複製して自分自身のイメージを作成してください。
$ git clone https://github.com/archlinux/archlinux-docker.git
devtools パッケージをインストールしてください。
packages
ファイルを編集して 'base' とだけ記述し、以下のコマンドを実行:
# make rootfs # podman build -t archlinux .
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 コンテナにはパフォーマンスからソフトウェアの正確性まで様々な影響がある違いが存在します。C ライブラリの差異については こちら に記述されています。
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 バージョンが存在します。
トラブルシューティング
イメージが見つからない
デフォルトでは、パッケージ内のファイルはアップストリームからのものであるため、レジストリリストは作成されません。つまり、デフォルトではレジストリを指定せずに任意のイメージを引っ張ってこようとすると、以下のようなエラーが発生します。
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 設定と同等です。
コンテナがシェルログアウトで終了する
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:
$ loginctl enable-linger
You can also create user systemd unit as described: https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html#examples
ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー
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
ルートレスモードでのコミット時にエラー
Error committing the finished image: error adding layer with blob "sha256:02823fca9b5444c196f1f406aa235213254af9909fca270f462e32793e2260d8": Error processing tar file(exit status 1) permitted operation
ストレージドライバが#ストレージ設定でオーバーレイされていることを確認します。
Error building pause image after Podman upgrade 3.x to 4.0
Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH
Install the catatonit package to fix the error.
For details on upgrading from 3.x to 4.0, see the official blog article
Container dns will not be enabled
WARN[0000] binary not found, container dns will not be enabled
If you installed netavark as podman network backend you need to install aardvark-dns
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
を 起動/有効化することで解決します。
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
Can be solved: https://bbs.archlinux.org/viewtopic.php?id=253966
env DBUS_SESSION_BUS_ADDRESS= podman ... env DBUS_SESSION_BUS_ADDRESS= podman-compose ...
プロセスをポーズに追加
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