「インストール - Podman」の版間の差分

2024年11月28日 (木) 14:19時点における最新版

概要

コンテナとは、Linuxシステム上で実行される、互いに隔離されたプロセス群のことである。
また、ソフトウェアプロセスやマイクロサービスをパッケージ化して、あらゆるコンピューティング環境で実行可能にするソフトウェアソリューションである。

コンテナは、1つのプロセス・グループがシステム上の他のプロセスに干渉しないようにする。

コンテナに含まれるファイルには、アプリケーションコード、環境変数、設定コード、バイナリプログラム、ソフトウェアの依存関係、ライブラリ等がある。
これらのコンポーネントをバンドルするプロセスはコンテナ化と呼ばれ、最終的な製品はコンテナイメージとして知られている。

このイメージは、クラウド、オンプレミスのデータシステム、ローカルシステム等、あらゆるプラットフォームにデプロイされる。

また、不正なプロセスがシステム・リソースを独占することはできず、他のプロセスがタスクを実行するのを妨げることもできる。
悪意のあるコンテナであったとしても、他のコンテナを攻撃したり、データを盗んだり、サービス拒否攻撃を引き起こしたりすることもできない。

コンテナの最終的な目標は、同じライブラリの異なるバージョンを必要とするアプリケーションと競合しないように、
共有ライブラリの独自のバージョンでアプリケーションをインストールできるようにすることある。
その代わり、コンテナによってアプリケーションは仮想化された環境に住むことができ、あたかもシステム全体を所有しているかのような印象を与えることができる。

Podman (Pod Manager) は、Open Container Initiatives （OCI）のコンテナイメージを開発、管理、本番環境で実行する時に使用するコンテナエンジンである。
Podmanプロジェクトは、PodmanをLinuxシステム上でOCIコンテナを開発、管理、実行するためのデーモンレス・コンテナ・エンジンと説明している。

OCIは、コンテナフォーマットとランタイムに関するOSレベルの仮想化ソフトウェアコンテナのオープンなガバナンス構造を実装するために設計された。

Podmanコンテナは、スーパユーザ / 非スーパーユーザのいずれでも実行可能である。

PodmanはDockerと同じコマンドラインでDockerができることのほとんど全てを行うことができるため、Docker = Podmanという単純な行のエイリアスで要約されることが多い。
しかし、Podmanはそれ以上のことができる。

Dockerを理解することはPodmanを理解する上で重要ではないが役立つこともある。

コンテナ・オーケストレータ / コンテナ・エンジン / コンテナ・ランタイム

コンテナの世界では、コンテナ・オーケストレータ、コンテナ・エンジン、コンテナ・ランタイムといった用語が同じ意味で用いられることがよくある。

コンテナ・オーケストレータ

コンテナを複数の異なるマシンやノードにオーケストレートするソフトウェアプロジェクトや製品のことである。
これらのオーケストレータは、コンテナを実行するためにコンテナエンジンと通信する。

主要なコンテナ・オーケストレータはKubernetesで、元々はDockerデーモンのコンテナ・エンジンと通信するように設計されていたが、
Kubernetesはコンテナ・エンジンとして主にCRI-Oまたはcontainerdを使用しているため、Dockerを使用することは時代遅れになりつつある。

CRI-Oとcontainerdは、オーケストレーションされたKubernetesコンテナを実行するために構築されている。

Docker SwarmおよびApache Mesosも、コンテナ・オーケストレータである。

コンテナ・エンジン

主に、コンテナ化されたアプリケーションを単一のローカル・ノードで実行するように構成するために使用される。
ユーザ、管理者、開発者が直接起動できる。

また、ブート時にSystemdユニットファイルから起動したり、Kubernetesのようなコンテナ・オーケストレータから起動することもできる。

前述したように、CRI-Oとcontainerdは、Kubernetesがコンテナをローカルで管理するために使用するコンテナエンジンである。
一般的に、ユーザが直接使用することは想定されていない。

DockerとPodmanは、コンテナ化されたアプリケーションを1台のマシンで開発、管理、実行するためにユーザが使用する主要なコンテナエンジンである。

PodmanがKubernetesのコンテナ起動に使われることはほとんどない。

Buildahもコンテナエンジンの1つであるが、コンテナイメージの構築にしか使用されない。

Open Container Initiative (OCI) コンテナ・ランタイム

Linuxカーネルの様々な部分を設定して、最後にコンテナ化されたアプリケーションを起動する。
最も一般的に使用される2つのコンテナ・ランタイムは、runcとcrunである。

KataとgVisorも、コンテナ・ランタイムである。

※注意
Open Container Initiative (OCI) は、コンテナフォーマットとランタイムに関するオープンな業界標準を作成することを主な目的とした標準化団体である。
詳細を知りたい場合は、https://opencontainers.org を参照すること。

下図は、オープンソース・コンテナ・プロジェクトがどのカテゴリーに当てはまるかを示している。

Podmanのソケットアクティベーション

ソケットアクティベーションは、systemdがソケット（TCP、UDP、Unixソケット等）を作成することで機能する。

クライアントがソケットに接続する時、systemdはソケット用に設定されたsystemdサービスを起動する。
新しく起動されたプログラムは、ソケットのファイルディスクリプタを継承して、着信した接続を受け付けることができる。（システムコールのaccept()を実行する）

これにより、デフォルトのsystemdソケット設定であるAccept=noに対応し、サービスがソケットを受け付けるようになる。

Podmanは、2種類のソケットアクティベーションをサポートしている。

APIサービスのソケットアクティベーション
コンテナのソケット起動

Podmanのインストール

パッケージ管理システムからインストール

# RHEL
sudo yum install epel-release
sudo dnf install podman

# SUSE
sudo zypper install podman

スタティックビルド済みのPodmanの使用

Podmanのダウンロード

※注意
スタティックビルド済みのPodmanを使用する場合は、Podman Desktopが使用できないことに注意する。

PodmanのGithubにアクセスして、スタティックビルド済みのPodmanをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf podman-remote-static-linux_<アーキテクチャ名>.tar.gz
cd bin
mv podman-remote-static-linux_<アーキテクチャ名> podman

必要ならば、Podmanを任意のインストールディレクトリに配置する。

mkdir -p <任意のインストールディレクトリ>
mv podman <任意のインストールディレクトリ>

~/.profileファイル等に、環境変数PATHおよびソケットの設定を記述する。

vi ~/.profile

 # ~/.profileファイル
 
 export PATH="<Podmanのインストールディレクトリ>:$PATH"
 
 export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock

gvproxyのダウンロード

SUSEにおいて、パッケージ管理システムにgvproxyパッケージが存在しないため、手動でgvproxyをインストールする必要がある。

まず、gvproxyのGithubにアクセスして、gvproxyをダウンロードする。
ダウンロードしたgvproxyのファイル名を変更して、/usr/libexec/podmanディレクトリまたは/usr/local/libexec/podmanディレクトリにコピーする。

# ファイル名を変更
mv gvproxy-linux-<アーキテクチャ名> gvproxy

# 実行権限を付加 (非スーパーユーザでも実行できるようにする)
chmod +x gvproxy

# gvproxyを配置するディレクトリを作成
sudo mkdir -p /usr/libexec/podman
## または
sudo mkdir -p /usr/local/libexec/podman
## または
sudo mkdir -p /usr/local/lib/podman
## または
sudo mkdir -p /usr/lib/podman

# gvproxyを配置する
sudo mv gvproxy /usr/local/libexec/podman

ソースコードからインストール

Goのバージョンが1.16未満の場合

もし、パッケージ管理システムのGoのバージョンが1.16未満の場合は、Goの公式Webサイトにアクセスして、Goをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf go<バージョン>.linux-<アーキテクチャ名>.tar.gz
mv go<バージョン>.linux-<アーキテクチャ名> Go

必要ならば、Goを任意のインストールディクトリに配置する。

mv Go <任意のインストールディレクトリ>

~/.profileファイル等に、環境変数PATHを追記する。

 export GOPATH=<Goのインストールディレクトリ>
 export PATH=/<Goのインストールディレクトリ>/bin:$PATH

slirp4netnsのインストール

slirp4netnsは、コンテナのネットワーク機能を提供するために使用されるライブラリである。

Podmanがルートレス環境でコンテナのネットワーク機能を提供するために重要な役割を果たしている。
これにより、ユーザはroot権限を必要とせずにコンテナを実行して、ネットワークを利用できるようになる。
また、各コンテナが独立したネットワーク環境を持つことにより、セキュリティと分離性が向上する。

主な役割を以下に示す。

ユーザ空間ネットワーキング
slirp4netnsは、カーネル空間ではなくユーザ空間でネットワーキングを実現する。

これにより、ルートレス環境でもコンテナがネットワーク機能を利用できるようになる。
ネットワーク名前空間の分離
各コンテナに独立したネットワーク名前空間を提供して、ホストから分離されたネットワーク環境を実現する。
ネットワークアドレス変換 (NAT)
コンテナ内部のIPアドレスをホストのIPアドレスに変換することで、外部ネットワークとの通信を可能にする。
ポートフォワーディング
コンテナ内部のポートをホストのポートに転送して、外部からコンテナが公開するサービスにアクセスできるようにする。
DNS解決
コンテナ内部からDNSを利用してホスト名の解決ができるようにする。

slirp4netnsのビルドに必要なライブラリをインストールする。

# RHEL
sudo dnf install glib2-devel libslirp-devel libcap-devel libseccomp-devel

# SUSE
sudo zypper install glib2-devel libslirp-devel libcap-devel libseccomp-devel

slirp4netnsのGithubにアクセスして、ソースコードをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf slirp4netns-<バージョン>.tar.gz
cd slirp4netns-<バージョン>

slirp4netnsをビルドおよびインストールする。

./autogen.sh

mkdir build && cd build

../configure --prefix=<Podmanのインストールディレクトリ>
make -j $(nproc)
make install

CNIネットワークの設定

※注意
CNIバックエンドは非推奨であり、Podman 5.0以降ではNetavarkが優先されるため、CNIネットワークは削除される予定である。

CNIネットワーキングの基本的な設定は、Podmanのビルド時で行われており、Podmanを使用するために他の設定は必要ない。

追加の設定を行う場合は、CNIネットワークの設定ファイルをダウンロードして、/etc/containersディレクトリに配置する。

sudo mkdir -p /etc/containers

sudo curl -L -o /etc/containers/registries.conf https://src.fedoraproject.org/rpms/containers-common/raw/main/f/registries.conf
sudo curl -L -o /etc/containers/policy.json https://src.fedoraproject.org/rpms/containers-common/raw/main/f/default-policy.json

CNIネットワークの設定の詳細は、PodmanのGithubに記載されている。

ユーザネームスペースの有効化

Linuxカーネルがユーザネームスペースをサポートしているかどうかを確認する。

zgrep CONFIG_USER_NS /proc/config.gz

# 出力例: ユーザネームスペースをサポートしている場合
CONFIG_USER_NS=y

もし、ユーザネームスペースが無効の場合は有効にする。

# ユーザネームスペースを一時的に有効にする
sudo sysctl kernel.unprivileged_userns_clone=1

# ユーザネームスペースを恒久的に有効にする
echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/userns.conf

Podmanのビルド

Podmanのビルドに必要なライブラリをインストールする。

# RHEL
sudo dnf install 'dnf-command(builddep)'
sudo dnf builddep rpm/podman.spec --enablerepo=codeready-builder-for-rhel-$(rpm --eval %{?rhel})-$(uname -m)-rpms

sudo dnf install conmon containers-common crun iptables netavark nftables slirp4netns

# SUSE
sudo zypper install pkg-config libseccomp-devel libgpgme-devel libbtrfs-devel device-mapper-devel systemd-devel libapparmor-devel protobuf-devel

# Raspberry Pi / Mobian
sudo apt install btrfs-progs git uidmap pkg-config crun golang-go go-md2man iptables libassuan-dev libbtrfs-dev libc6-dev libdevmapper-dev libglib2.0-dev \
                 libgpgme-dev libgpg-error-dev libprotobuf-dev libprotobuf-c-dev libseccomp-dev libselinux1-dev libsystemd-dev libapparmor-dev \
                 netavark  # 古いバージョンのRaspbian OSの場合、netavarkパッケージが利用できない場合がある
                           # その場合、containernetworking-pluginsパッケージをインストールする

PodmanのGithubにアクセスして、ソースコードをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf podman-<バージョン>.tar.gz
cd podman-<バージョン>

または、git cloneコマンドを実行して、Podmanのソースコードをダウンロードすることもできる。

git clone https://github.com/containers/podman/
cd podman

Podmanをビルドおよびインストールする。

# SELinux, SECcomp (syscall filtering) を有効にする場合
make BUILDTAGS="selinux seccomp" PREFIX=<Podmanのインストールディレクトリ> -j $(nproc)

# AppArmor, SECcomp (syscall filtering) を有効にする場合
make BUILDTAGS="apparmor seccomp" PREFIX=<Podmanのインストールディレクトリ> -j $(nproc)

# SELinux, SECcomp (syscall filtering) を無効にする場合
make BUILDTAGS="" PREFIX=<Podmanのインストールディレクトリ> -j $(nproc)

make install PREFIX=<Podmanのインストールディレクトリ>

~/.profileファイル等に、環境変数PATHおよびPodmanソケットの設定を記述する。

vi ~/.profile

 # ~/.profileファイル
 
 export PATH="/<Podmanのインストールディレクトリ>/bin:$PATH"
 
 export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock

catatonitのインストール

catatonitは、PodmanやDocker等のコンテナランタイムが、コンテナ内のプロセスを正しく管理するために使う補助的なツールである。
ポッドは、Kubernetes等のオーケストレーションツールで使用される複数のコンテナを1つにまとめた単位であるが、ポッド自体の作成や管理はKubernetesの制御プレーンやAPIサーバが行う。

catatonitは、コンテナのinitプロセスとして使用される小さなプログラムである。
Podmanや他のコンテナランタイムでは、コンテナ内でプロセスが正しく動作および終了するためにinitプロセスを使用することが一般的である。
catatonitはそのための軽量な選択肢の1つであり、特にリソースの少ない環境やシンプルなコンテナイメージでの使用に適している。

コンテナのinitプロセスは、コンテナ内で最初に実行されるプロセスであり、次のような役割を果たす。

孤児プロセスの回収
コンテナ内で起動されたプロセスが終了した時、その親プロセスが終了している場合、プロセスが孤児化される。

initプロセスはこれらの孤児プロセスを回収して、適切に終了させる。
シグナルの管理
catatonitは、コンテナに送信されるシグナルをキャッチして、適切にハンドリングする。

これにより、コンテナ内で実行中のプロセスがシグナルを受信できるようにする。
リソースのクリーンアップ
コンテナが終了する時、catatonitはシステムリソースを適切にクリーンアップする。

catatonitのGithubにアクセスして、ソースコードをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf catatonit.tar.xz
cd catatonit

または、git cloneコマンドを実行してソースコードをダウンロードすることもできる。

git clone https://github.com/openSUSE/catatonit.git
cd catatonit

catatonitをビルドおよびインストールする。

./autogen.sh

mkdir build && cd build

../configure --prefix=<Podmanのインストールディレクトリ>
make -J $(nproc)
make install

エラー関連

Seccompエラー

Podmanイメージのビルド時において、以下に示すようなエラーが出力される場合がある。

Error: loading seccomp profile () failed: seccomp not enabled in this build

Podmanイメージでは、Seccompを無効にしている場合はコンテナを作成できないイメージが存在する。
この時、runc / crunおよびPodmanのビルド時において、BUILDTAGSオプションにseccompを指定する必要がある。

gvproxy

gvproxyとは

gvproxyは、libslirpおよびVPNKitを置き換えるものであり、Golangで記述されている。
gVisorのネットワークスタックをベースにしている。

libslirpと比較して、gvisor-tap-vsockは設定可能なDNSサーバと動的なポート転送を提供する。

また、QEMU、Hyperkit、Hyper-V、User Mode Linuxで使用することができる。

※注意 1
SUSEにおいて、パッケージ管理システムにgvproxyパッケージが存在しないため、手動でgvproxyをインストールする必要がある。

※注意 2
podman machine startコマンドを実行して仮想マシンを起動する時、gvproxyが無いためホストネットワークを起動できない場合がある。
この時、以下に示すセクションを参照して、gvproxyをインストールする必要がある。

Staticビルド済みのバイナリをインストール

まず、gvproxyのGithubにアクセスして、gvproxyをダウンロードする。
ダウンロードしたgvproxyのファイル名を変更して、/usr/libexec/podmanディレクトリまたは/usr/local/libexec/podmanディレクトリにコピーする。

# ファイル名を変更
mv gvproxy-linux-<アーキテクチャ名> gvproxy

# 実行権限を付加 (非スーパーユーザでも実行できるようにする)
chmod +x gvproxy

# gvproxyを配置するディレクトリを作成
sudo mkdir -p /usr/libexec/podman
## または
sudo mkdir -p /usr/local/libexec/podman
## または
sudo mkdir -p /usr/local/lib/podman
## または
sudo mkdir -p /usr/lib/podman

# gvproxyを配置する
sudo mv gvproxy /usr/local/libexec/podman

ソースコードからインストール

gvproxyのビルドに必要なライブラリをインストールする。

# SUSE
sudo zypper install rust cargo protobuf-devel go-md2man

gvproxyのGithubにアクセスして、ソースコードをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf gvisor-tap-vsock-<バージョン>.tar.gz
cd gvisor-tap-vsock-<バージョン>

gvproxyをビルドする。

make -j $(nproc)

binディレクトリに実行バイナリ群が生成される。
そのため、それらの実行バイナリ群をPodmanのインストールディレクトリに配置する。

cd bin
mv ./*  /<Podmanのインストールディレクトリ>/bin

Podmanに関連するディレクトリ

Podmanに関連するディレクトリを以下に示す。
これらのディレクトリは、Podmanとその関連ツール (Podman Desktop) によって使用されており、rootlessモードで実行する時にユーザのホームディレクトリ配下に作成される。

~/.local/share/containers/storage
Podmanが使用するメインのストレージディレクトリである。

コンテナイメージ、コンテナ、ボリューム等のデータが格納される。
~/.local/share/containers/podman-desktop
Podman Desktopアプリケーションが使用するディレクトリである。

GUIベースのPodman管理ツールの設定やデータが保存される。
~/.local/share/containers/cache
Podmanのキャッシュディレクトリである。

イメージレイヤーのキャッシュやその他の一時的なデータが保存される。

キャッシュを使用することにより、同じイメージの再ダウンロードを避け、操作を高速化する。

Podmanの設定

Dockerから移行する場合

DockerからPodman Desktopに透過的に移行するため、環境変数DOCKER_HOSTを使用することができる。

使い慣れたDockerコマンドを使い続けることが可能である。
Podmanの利点を活用できる。
GradleやTestcontainers等のツールは、再設定なしでPodmanと通信することができる。

Podmanソケットファイルの場所を確認する。

podman info --format '{{.Host.RemoteSocket.Path}}'

Podmanソケットの場所を設定するため、~/.profileファイル等に環境変数DOCKER_HOSTに記述する。

vi ~/.profile

 # ~/.profileファイル
 
 export DOCKER_HOST="unix://<Podmanソケットファイルのパス>"

cgroup v1に関する警告

podmanコマンドを実行した時、以下に示すような警告が出力される時がある。

Using cgroups-v1 which is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version.
Set environment variable `PODMAN_IGNORE_CGROUPSV1_WARNING` to hide this warning.

この警告は、Podman 5.0以降はcgroups v1の使用が非推奨となり、将来のバージョンでは削除される予定であることを示している。
これは、以下に示すような原因がある。

システムがcgroups-v1を使用している場合。
現在のシステムがcgroups-v1を使用しており、Podmanもそれを検出して使用している。

しかし、Podman v5以降ではcgroups-v2の使用が推奨されている。
Podmanのバージョン
使用しているPodmanのバージョンが5.0以降であるため、この警告メッセージが表示されている。

この警告は、将来的にcgroups v1のサポートが終了することを事前に知らせるためのものである。
現時点ではcgroups v1を使用していても問題ないが、将来のバージョンではcgroups v2に移行する必要がある。

警告を非表示にするには、~/.profileファイル等に環境変数PODMAN_IGNORE_CGROUPSV1_WARNINGを1、または、true、または、yesに設定する。
ただし、これは警告を非表示にするだけで、根本的な問題は解決しない。

vi ~/.profile

 # ~/.profileファイル
 
 # 上記の警告を非表示にする
 export PODMAN_IGNORE_CGROUPSV1_WARNING=1
 
 # Podmanの設定ファイルのパスを指定
 export CONTAINERS_CONF="$HOME/.config/containers/containers.conf"

長期的には、システムをcgroups v2に移行することを検討する。
cgroups v2は、より効率的でシンプルなリソース管理機能を提供している。
移行には、カーネルのアップグレード、または、関連するツールやライブラリの対応が必要となる場合がある。

SUSEのcgroupのデフォルトモードはハイブリッドモードである。
ハイブリッドモードは、それを必要とするアプリケーションに後方互換性を提供する。

以下に示す機能はunified v2階層でのみ使用可能である。

メモリコントローラ
再生保護（別名 memory.low）、memory.high、PSI（圧力ストール情報）
I/Oコントローラ
ライトバック制御、新しい制御ポリシー
非特権ユーザへのコントローラ委譲 (ルートレスコンテナ)
systemd のフリーザサポート
単一階層の取り扱いがよりシンプルになる。

cgroupは、1つのモードしか設定できない。

現在のPCにおいて、cgroups v2が有効になっているかどうかを確認する。

sudo mount | grep cgroup2

# cgroups v2が有効になっている場合
# 出力にcgroup v2のエントリが含まれている場合は、cgroups v2が有効になっている
# 出力例: cgroups v2が有効になっている場合
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)

vi ~/.config/containers/containers.conf
# または
sudo vi /etc/containers/containers.conf

 [engine]
 cgroup_manager = "systemd"
 cgroups = "v2"

もし、上記の手順で解決しない場合は、GRUB2のブートオプションに設定を追加する。
統一制御グループ階層を有効にする場合は、GRUB2ブートローダのカーネルコマンドラインパラメータとして追加する。

sudo vi /etc/default/grub

# /etc/default/grubファイル

GRUB_CMDLINE_LINUX_DEFAULT="〜 systemd.unified_cgroup_hierarchy=1 〜"

GRUB2を更新する。

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Linuxを再起動する。

sudo shutdown -r now

Linux仮想マシンの作成と開始

Linux仮想マシン (Podman Machine) とは

Podman Machineを理解するには、まず、Podmanのアーキテクチャについて知る必要がある。

Linuxでは、Podmanはデフォルトでrootless (非特権) モードで動作できるため、直接コンテナが実行できる。
Linuxでは、以下に示すようなLinuxカーネルの機能 (コンテナ実行に必要な機能が最初から利用可能) を直接利用できるできるため、
Podman Machineは不要であり、podman run等のコマンドが直接実行できる。

namespaces
cgroups
SELinux / AppArmor等

Windows / MacOSでは、Linuxコンテナをネイティブに実行できないため、仮想マシンを介してLinux環境を用意する必要があるため、仮想マシン (VM) が必要になる。
この仮想マシンをPodman Machineと呼ぶ。

podman machineコマンドの役割を以下に示す。

Windows / MacOS環境で必要な仮想マシンを起動すること。
仮想マシン内でPodmanデーモンを開始すること。
ホストOSからコンテナを操作できるような環境を準備すること。

podman machineコマンドを実行せずにpodman runコマンド等が使用できる環境は、以下の通りである。

ホストOSがLinux
Podman Machineが自動的に設定・起動されている状態

Linux仮想マシンの初期化

コンテナが実行される新しいLinux仮想マシンを初期化する。
VMにアクセスするためのSSHキーが自動的に生成されて、VM内のスーパーユーザアカウントとユーザアカウントへのシステム接続が追加される。

podman machine init

デフォルトでは、VMのディストリビューションはカスタムFedoraイメージに基づくWSLを除き、Fedora CoreOSである。
一般的なFedora CoreOSのアップグレードは14日ごとに行われるが、自動アップデートのZincataはPodmanマシンでは無効になっている。

もし、LinuxホストでPodman Machineを作成した場合は、~/.local/share/containers/podman/machineディレクトリに初期ファイルが生成される。
これは、2[GB]程度の容量が必要なため、Linux上ではPodman Machineは不要であることから削除することを推奨する。

Linux仮想マシンの編集

Podmanをソースコードから任意のディレクトリにインストールした場合、
~/.config/containers/containers.confファイル内の[engine]セクションの直下にhelper_binaries_dirキーを追加して、ヘルパーバイナリのあるディレクトリを設定する。

vi ~/.config/containers/containers.conf

 # ~/.config/containers/containers.confファイル
 
 [engine]
 helper_binaries_dir = ["/<Podmanのインストールディレクトリ>/bin", "/<Podmanのインストールディレクトリ>/libexec/podman", "/usr/local/libexec/podman", "/usr/local/lib/podman", "/usr/libexec/podman", "/usr/lib/podman"]

Linux仮想マシンの開始

Linux仮想マシンを開始する。

podman machine start

開始後、Docker APIに関するメッセージが表示される。
これは、Docker APIフォワーディングがリッスンしているため、環境変数DOCKER_HOSTを設定することにより、Docker APIクライアントに接続することができることを表す。

API forwarding listening on: /home/user-name/.local/share/containers/podman/machine/qemu/podman.sock
You can connect Docker API clients by setting DOCKER_HOST using the following command in your terminal session:

export DOCKER_HOST='unix:///home/user-name/.local/share/containers/podman/machine/qemu/podman.sock'

Podmanマシンの接続の設定

各Podmanマシンは2つのデフォルト接続を公開する。
Podmanのデフォルト接続は1つのみ選択することができる。

ルートレス
ルートフル

Podman DesktopやKind等の他のツールはデフォルト接続に接続する。
もし、別のPodmanマシンの作成等により、デフォルトのPodmanマシン接続が変更された可能性があるイベントが発生した場合、デフォルト接続の確認と設定を検討すること。

まず、Podmanマシンの接続を確認する。

podman system connection ls

次に、Podmanマシンのデフォルト接続を任意の接続に設定する。

podman system connection default podman-machine-default
# または
podman system connection default podman-machine-default-root

Podmanマシンのデフォルト接続が変更されているかどうかを確認する。

podman system connection ls

デフォルト接続を持つPodmanマシンを再起動する。

podman machine stop
podman machine start

Podman DesktopとPodmanの接続を更新する。

Podman Desktopのメイン画面右下にある[電球]アイコンを選択して[トラブルシューティング]ページを開き、[プロバイダーを再接続]ボタンを押下する。

Podmanの動作確認

Podmanの動作を確認するため、テストイメージをダウンロードして実行する。

 podman run hello-world

Podman Desktop

Podman Desktopのインストール

Podman Desktopの公式Webサイト、または、Githubにアクセスして、Podman Desktopをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf podman-desktop-<バージョン>.tar.gz
mv podman-desktop-<バージョン> Podman-Desktop

必要ならば、任意のインストールディレクトリに配置する。

mv Podman-Desktop <任意のインストールディレクトリ>

Podman Desktopのデスクトップエントリファイルを作成する。

vi ~/.local/share/applications/Podman-Desktop.desktop

 # ~/.local/share/applications/Podman-Desktop.desktopファイル
 
 [Desktop Entry]
 Type=Application
 Name=Podman Desktop
 Exec=/<Podman Desktopのインストールディレクトリ>/podman-desktop %F
 Icon=io.podman_desktop.PodmanDesktop
 Categories=Development;
 StartupWMClass=Podman Desktop
 Terminal=false

Docker Hubの使用

Docker Hubにログインする。

podman login -u <Docker Hubのユーザ名> -v https://docker.io
podman login -u <Docker Hubのユーザ名> -v https://index.docker.io/v2/

Podman Desktopを再起動する。

認証情報は、/run/user/$UID/containers/auth.jsonファイルに保存される。

ルートレスモード

ルートレスモードとは

Podmanはsetuidパッケージが不要であり、一般ユーザとしてコンテナを実行することができる。
ルートレスモードで実行する場合、Podmanコンテナはユーザネームスペースを使用して、コンテナ内のrootをPodmanを実行しているユーザに設定する。

ルートレスモードのPodmanは、コンテナを実行しているユーザには無い特権は持たず、ロックダウンされたコンテナを実行する。

これらの制限の一部は (例えば、--privilegedオプションを付加して) 解除できるが、ルートレスコンテナが起動したユーザ以上の権限を持つことはない。
一般ユーザとしてPodmanを実行する時、ホストから/etc/passwdにマウントした場合でも、一般ユーザには権限が無いため変更することはできない。

PodmanとDockerの違い

DockerとPodmanの違いの1つは、コンテナの扱い方である。
Dockerは、コンテナを実行するためにスーパーユーザ権限を必要とする。
Podmanは、スーパーユーザ権限無しでコンテナを実行することができる。

例えば、ルートレスモードのPodmanでは、ポート番号が1024番未満のポートでコンテナを起動することはできないため、1024番以上のポートを使用する必要がある。

もし、1024番未満のポートでコンテナを作成する必要がある場合は、ルートレスモードを解除してスーパーユーザ権限で実行する。

podman machine set --rootful

ルートレスモードに戻す場合は、以下に示すコマンドを実行する。

podman machine set --rootful=false

しかし、Dockerには、コンテナを作成および管理するためDocker Composeが存在する。
幸運なことに、PodmanはDocker CLIをエミュレートできるため、Docker Composeと連携することができる。

ルートレスコンテナの保存先

ルートレスコンテナのイメージは、~/.local/share/containers/storageディレクトリに保存される。
ルートレスコンテナの設定ファイルは、~/.config/containersディレクトリに保存される。

firewalldの設定 (ポートフォワード)

ルートレスコンテナにおいて、一般ユーザは、ルートレスコンテナのWebサーバをホスト側の80番ポートで公開することができない。
(1024番未満のポートを公開することができない)

そのため、1024番未満のポートでサービスを公開する場合は、firewalldでポートフォワードを設定して、ポートをマッピングする必要がある。

sudo firewall-cmd --permanent --add-forward-port=port=<ホスト側のフォワード先のポート番号>:proto=tcp:toport=<Podmanのコンテナで設定したフォワード先のポート番号>
sudo firewall-cmd --permanent --add-port=<ホスト側のフォワード先のポート番号>/tcp
sudo firewall-cmd --reload

k8sマニフェストとの連携

Podmanは、k8sマニフェストを作成および実行することも可能である。
これは、k8s Podの開発に有効である。

k8sマニフェストの作成

k8sマニフェストを作成元となるPodmanのコンテナを実行する。

podman container start <コンテナ名 または コンテナID>

k8sマニフェストを生成する。

podman generate kube <コンテナ名 または コンテナID> > <k8sマニフェストのファイル名>.yml

k8s Podの作成

k8sマニフェストを使用して、k8s Podを作成する。

kubectl create -f <k8sマニフェストのファイル名>.yml

k8sマニフェストの実行

k8sマニフェストの作成元のコンテナを削除する。

podman container stop <コンテナ名 または コンテナID>
podman container rm <コンテナ名 または コンテナID>

k8sマニフェストを実行して、コンテナを実行する。

podman play kube <k8sマニフェストのファイル名>.yml

k8sマニフェストを作成したコンテナが実行されているかどうかを確認する。

podman ps

エラー関連

実行権限エラー

containerfileファイルまたはcontainer-compose.ymlファイルを使用する時、以下に示すようなエラーが出力される場合がある。

error checking context: 'no permission 〜'

この時、Containerfileファイルまたはcontainer-compose.ymlファイルに実行権限を付加する。

chmod 755 containerfile
# または
container-compose.yml

Systemdエラー

openSUSEコンテナをPodmanコンテナとして動作する時、以下のようなエラーが出力されてSystemdサービスが起動できない。

Failed to connect to bus: No such file or directory.

これは、Podmanコンテナを実行する時、initシステムを実行していないからである。

systemctlコマンドは、dbusを介してsystemdと通信するプロセスである。
openSUSEコンテナでは、dbusとsysvinitがインストールされていないため(dbusやsystemdが動作していない)、systemctlコマンドは失敗する。

Podmanコンテナでsystemctlを実行するには、その依存関係をインストールして、特殊なコマンドを実行する必要がある。

containerfileを作成および使用して解決する手順を、以下に記載する。
まず、以下のようなdockerfileを作成する。

FROM opensuse/leap:15.3
MAINTAINER Annonymas

RUN zypper update -y
RUN zypper install -y dbus-1 systemd-sysvinit
RUN cp /usr/lib/systemd/system/dbus.service /etc/systemd/system/; \
    sed -i 's/OOMScoreAdjust=-900//' /etc/systemd/system/dbus.service

VOLUME ["/sys/fs/cgroup", "/run"]

CMD ["/sbin/init"]

EXPOSE 22
EXPOSE 80

次に、作成したcontainerfileからPodmanイメージを作成する。

podman build -t <イメージ名>:<タグ名> -f <containerfile名> .  # イメージ名:タグ名およびDockerfile名(Dockerfile名がdockerfileの場合のみ)は省略できる
例. podman build -t suse153i .

Podmanコンテナを実行する。

podman run -d --name=<コンテナ名> --hostname <コンテナのホスト名> <ポートマッピングする場合: -p <ホストのポート番号>:<コンテナのポート番号>> --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro <イメージ名>
例. podman run -d --name=suse153c --hostname suse153 -p 50080:80 --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro suse153i

# 開始しているコンテナ内にアクセスする場合
podman exec -it <コンテナ名> /bin/bash
例. podman exec -it suse153c /bin/bash

# 停止したコンテナを開始する場合
podman container start <コンテナ名>
例. podman container start suse153c

openSUSEコンテナにおいて、systemctlコマンドが実行できるかどうかを確認する。

# Podmanコンテナ内に入る
podman exec -it <コンテナIDまたはコンテナ名> /bin/bash

# systemctlコマンドが実行できるかどうかを確認
systemctl list-units

Systemdサービスのサポート

openSUSEコンテナリポジトリで公開されているコンテナイメージは、containers-systemdパッケージがインストールされている。
例えば、Systemdサービスを使用してNginXコンテナを設定して、自動的に起動するためのSystemdサービスファイルとSysconfigファイルが含まれている。

「インストール - Podman」の版間の差分

2024年11月28日 (木) 14:19時点における最新版

概要

コンテナ・オーケストレータ / コンテナ・エンジン / コンテナ・ランタイム

コンテナ・オーケストレータ

コンテナ・エンジン

Open Container Initiative (OCI) コンテナ・ランタイム

Podmanのソケットアクティベーション

Podmanのインストール

パッケージ管理システムからインストール

スタティックビルド済みのPodmanの使用

Podmanのダウンロード

gvproxyのダウンロード

ソースコードからインストール

Goのバージョンが1.16未満の場合

最新のconmonが必要な場合

最新のcrun /runcが必要な場合

slirp4netnsのインストール

CNIネットワークの設定

ユーザネームスペースの有効化

Podmanのビルド

catatonitのインストール

最新のnetavarkが必要な場合

エラー関連

Seccompエラー

gvproxy

gvproxyとは

Staticビルド済みのバイナリをインストール

ソースコードからインストール

Podmanに関連するディレクトリ

Podmanの設定

Dockerから移行する場合

cgroup v1に関する警告

Linux仮想マシンの作成と開始

Linux仮想マシン (Podman Machine) とは

Linux仮想マシンの初期化

Linux仮想マシンの編集

Linux仮想マシンの開始

Podmanマシンの接続の設定

Podmanの動作確認

Podman Desktop

Podman Desktopのインストール

Docker Hubの使用

ルートレスモード

ルートレスモードとは

PodmanとDockerの違い

ルートレスコンテナの保存先

firewalldの設定 (ポートフォワード)

k8sマニフェストとの連携

k8sマニフェストの作成

k8s Podの作成

k8sマニフェストの実行

エラー関連

実行権限エラー

Systemdエラー

Systemdサービスのサポート

案内メニュー

検索