Red Hat Training
A Red Hat training course is available for RHEL 8
コンテナーの構築、実行、および管理
Red Hat Enterprise Linux 8 での Podman、Buildah、および Skopeo の使用
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
当社のドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
特定の文章に関するコメントの送信
- Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
- カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
- 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
- フィードバックを追加し、Submit をクリックします。
Bugzilla からのフィードバック送信 (アカウントが必要)
- Bugzilla の Web サイトにログインします。
- Version メニューから正しいバージョンを選択します。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
第1章 コンテナーの使用
Linux コンテナーは、イメージベースのデプロイメント方法の柔軟性と、軽量アプリケーションの分離を組み合わせた、主要なオープンソースアプリケーションをパッケージ化して、配信するテクノロジーとして登場しました。Red Hat Enterprise Linux は、以下のようなコア技術を使用して Linux コンテナーを実装します。
- リソース管理用のコントロールグループ (cgroup)
- プロセス分離用の namespace
- SELinux (セキュリティー用)
- セキュアなマルチテナンシー
このような技術は、セキュリティーエクスプロイトの可能性を軽減し、エンタープライズ品質のコンテナーを生成および実行する環境を提供します。
Red Hat OpenShift は、強力なコマンドラインと Web UI ツールを提供し、Pod と呼ばれる単位でコンテナーを構築、管理、および実行します。Red Hat では、OpenShift 外で個々のコンテナーおよびコンテナーイメージをビルドして管理できます。本書では、RHEL システムで直接実行されるタスクを実行するためのツールについて説明します。
他のコンテナーツールの実装とは異なり、ここで説明するツールはモノリシック Docker のコンテナーエンジンと、docker
コマンドを中心としたものではありません。代わりに、Red Hat はコンテナーエンジンがなくても動作できる一連のコマンドラインツールを提供します。これには、以下が含まれます。
-
Podman - Pod およびコンテナーイメージの直接管理 (
run
、stop
、start
、ps
、attach
、exec
など) - buildah - コンテナーイメージの構築、プッシュ、および署名
- skopeo - イメージのコピー、検証、削除、および署名
- runc - podman および buildah へのコンテナーの実行機能と構築機能の提供
- crun - ルートレスコンテナーの柔軟性、制御、セキュリティーを向上するために設定可能なオプションのランタイム。
これは、このツールが、Docker が生成して管理するのと同じ Linux コンテナーや、その他の OCI 互換コンテナーエンジンの管理に使用する Open Container Initiative (OCI) と互換性があるためです。ただし、シングルノードのユースケースでは、Red Hat Enterprise Linux で直接実行することが特に適しています。
マルチノードコンテナープラットフォームの場合は、OpenShift および CRI-O Container Engine の使用 を参照してください。
1.1. Podman、Buildah、および Skopeo の特徴
Docker コマンド機能に代わる、Podman、Skopeo、Buildah ツールが開発されました。このシナリオの各ツールはより軽量になり、機能のサブセットに焦点を当てています。
Podman、Skopeo、Buildah ツールの主な利点は次のとおりです。
- ルートレスモードでの実行 - ルートレスコンテナーは、特権を追加しなくても実行されるため、はるかに安全です。
- デーモンの必要なし - コンテナーが実行されていない場合、Podman は実行されないので、これらのツールではアイドル時のリソース要件がはるかに少なくなります。Docker は逆に、デーモンが常に実行しています。
- ネイティブ systemd 統合 - Podman では systemd ユニットファイルを作成し、コンテナーをシステムサービスとして実行できます。
Podman、Skopeo、および Buildah の特徴は次のとおりです。
-
Podman、Buildah、および CRI-O のコンテナーエンジンはすべて、Docker の保存場所
/var/lib/docker
をデフォルトで使用する代わりに、同じバックエンドストアディレクトリー/var/lib/containers
を使用します。 - Podman、Buildah、および CRI-O は、同じストレージディレクトリーを共有しているため、互いのコンテナーと対話することはできません。このツールはイメージを共有できます。
- プログラムで Podman と対話するには、ルートおよびルートレス環境の両方で動作する Podman v2.0 RESTful API を使用してください。詳細は、コンテナーツール API の使用 の章を参照してください。
1.2. Podman コマンドの概要
表 1.1 は、podman
コマンドで使用できるコマンドの一覧です。podman -h
を使用して、すべての Podman コマンドの一覧を表示します。
表1.1 podman が対応するコマンド
podman コマンド | 説明 | podman コマンド | 説明 |
attach | 実行中のコンテナーに割り当てる | commit | 変更したコンテナーから新規イメージを作成する |
build | Containerfile 命令を使用してイメージをビルドする | create | コンテナーを作成するが、起動はしない |
diff | コンテナーのファイルシステムの変更を検証する | exec | 実行中のコンテナーでプロセスを実行する |
export | コンテナーのファイルシステムの内容を tar アーカイブとしてエクスポートする | help, h | コマンド一覧、または特定のコマンドのヘルプを表示する |
history | 指定したイメージの履歴を表示する | images | ローカルストレージ内のイメージを一覧表示する |
import | tarball をインポートして、ファイルシステムイメージを作成する | info | システム情報を表示する |
inspect | コンテナーまたはイメージの設定を表示する | kill | 1 つ以上の実行中のコンテナーに特定のシグナルを送信する |
load | アーカイブからイメージを読み込む | login | コンテナーレジストリーにログインする |
logout | コンテナーレジストリーからログアウトする | logs | コンテナーのログを取得する |
mount | 作業中のコンテナーの root ファイルシステムをマウントする | pause | 1 つ以上のコンテナー内の全プロセスを一時停止する |
ps | コンテナーの一覧を表示する | port | コンテナーのポートマッピングまたは特定のマッピングを一覧表示する |
pull | レジストリーからイメージを取得する | push | 指定した宛先にイメージをプッシュする |
restart | 1 つ以上のコンテナーを再起動する | rm |
ホストから 1 つ以上のコンテナーを削除する。実行している場合は、 |
rmi | ローカルストレージから 1 つ以上のイメージを削除する | run | 新しいコンテナーでコマンドを実行する |
save | イメージをアーカイブに保存する | search | イメージのレジストリーを検索する |
start | 1 つ以上のコンテナーを起動する | stats | 1 つ以上のコンテナーの CPU、メモリー、ネットワーク I/O、ブロック I/O、および PID の割合を表示する |
stop | 1 つ以上のコンテナーを停止する | tag | ローカルイメージに名前を追加する |
top | コンテナーの実行中のプロセスを表示する | umount, unmount | 作業コンテナーのルートファイルシステムをアンマウントする |
unpause | 1 つ以上のコンテナーでプロセスの一時停止を解除する | version | podman のバージョン情報を表示する |
wait | 1 つ以上のコンテナーをブロックする |
1.3. Docker を使用せずにコンテナーを実行
Red Hat では、RHEL 8 から Docker コンテナーエンジンと、docker コマンドが削除されました。
RHEL で Docker を使用する場合は、異なるアップストリームプロジェクトから Docker を取得できますが、RHEL 8 では対応していません。
-
podman-docker
パッケージをインストールできます。docker
コマンドを実行するたびに、実際にはpodman
コマンドが実行されます。 -
Podman は Docker Socket API にも対応しているため、
podman-docker
パッケージは/var/run/docker.sock
と/var/run/podman/podman.sock
の間でリンクを設定します。そのため、Docker デーモンを必要とせずに、docker-py
とdocker-compose
ツールを使用して Docker API コマンドをそのまま実行できます。Podman はこのような要求を処理します。 -
docker
コマンドなどのpodman
コマンドは、Containerfile
またはDockerfile
からコンテナーイメージを構築できます。Containerfile
およびDockerfile
内で使用できる利用可能なコマンドは同じです。 -
podman
が対応していないdocker
コマンドのオプションには、network、node、plugin (podman
はプラグインをサポートしません)、rename (rm および create を使用してpodman
でコンテナーの名前を変更します)、secret、service、stack、swarm (podman
は Docker Swarm をサポートしません) が含まれます。container および image オプションは、podman
で直接使用されるサブコマンドを実行するのに使用します。
1.4. コンテナーの RHEL アーキテクチャーの選択
Red Hat は、以下のコンピューターアーキテクチャーに、コンテナーイメージとコンテナー関連のソフトウェアを提供します。
- AMD64 および Intel 64 (ベースイメージおよびレイヤー構造イメージ。32 ビットアーキテクチャーはサポートされません)
- PowerPC 8 および 9 の 64 ビット (ベースイメージおよび大概のレイヤー構造イメージ)
- 64 ビット IBM Z (ベースイメージと、大概の階層構造イメージ)
- ARM 64 ビット (ベースイメージのみ)
初めは、すべてのアーキテクチャーですべての Red Hat イメージがサポートされたわけではありませんが、一覧に挙げられているすべてのアーキテクチャーでほぼすべてが利用可能になりました。
1.5. コンテナーツールの取得
この手順では、Podman、Buildah、Skopeo、CRIU、Udica、および必要なすべてのライブラリーを含む container-tools
モジュールをインストールする方法を説明します。
手順
- RHEL をインストールします。
RHEL の登録: ユーザー名とパスワードを入力します。ユーザー名とパスワードは、Red Hat カスタマーポータルのログイン認証情報と同じです。
# subscription-manager register Registering to: subscription.rhsm.redhat.com:443/subscription Username: <username> Password: <password>
RHEL にサブスクライブします。
RHEL に自動的にサブスクライブするには、以下を実行します。
# subscription-manager attach --auto
プール ID で RHEL をサブスクライブするには、次のコマンドを実行します。
# subscription-manager attach --pool PoolID
container-tools
モジュールをインストールします。# yum module install -y container-tools
container-tools モジュールには
podman-docker
パッケージが含まれています。podman-docker
パッケージは、Docker コマンドラインインターフェイスとdocker-api
を、同等の Podman コマンドに置き換えます。
1.6. ルートレスコンテナーの設定
システムで利用可能な機能をコンテナーで完全利用できるように、Podman、Skopeo、Buildah などのコンテナーツールをスーパーユーザー特権 (root ユーザー) が割り当てられたユーザーで実行するのが最善の方法です。ただし、Red Hat Enterprise Linux 8.1 以降で一般的に利用可能なルートレスコンテナーと呼ばれる機能を使用すると、コンテナーを一般ユーザーとして使用できます。
Docker などのコンテナーエンジンでは、通常の (root 以外の) ユーザーとして Docker コマンドを実行できますが、これらの要求を実行する Docker デーモンは root として実行されます。これにより、一般ユーザーがコンテナー経由で要求を送信でき、システムに影響を与える可能性があります。システム管理者は、ルートレスコンテナーユーザーを設定して、一般ユーザーがコンテナーアクティビティーに損害を与える可能性を回避しつつ、一般ユーザーが自分のアカウントで大半のコンテナー機能を安全に実行できるようにします。
この手順では、Podman、Skopeo、および Buildah ツールを使用して、root 以外のユーザー (ルートレス) としてコンテナーを操作するようにシステムを設定する方法を説明します。また、一般ユーザーのアカウントは、コンテナーの実行に必要なすべてのオペレーティングシステム機能に完全にアクセスできないために発生する可能性のある制限についても説明します。
前提条件
- root 以外のユーザーでコンテナーツールを使用できるように、RHEL システムを設定する必要があります。
手順
- RHEL をインストールします。
podman
パッケージをインストールします。# yum install podman -y
ユーザーアカウントを新規作成します。
# useradd -c "Joe Jones" joe # passwd joe
- ユーザーは、ルートレス Podman を使用できるように自動的に設定されます。
-
useradd
コマンドは、/etc/subuid
と/etc/subgid
ファイルに、アクセス可能なユーザー ID とグループ ID の範囲を自動的に設定します。 -
etc/subuid
や/etc/subgid
を手動で変更した場合、新しい変更を適用させるためにpodman system migrate
コマンドを実行する必要があります。
ユーザーに接続します。
$ ssh joe@server.example.com
注記これらのコマンドでは正しい環境変数が設定されないため、
su
またはsu -
コマンドは使用しないでください。registry.access.redhat.com/ubi8/ubi
コンテナーイメージをプルします。$ podman pull registry.access.redhat.com/ubi8/ubi
myubi
という名前のコンテナーを実行し、OS バージョンを表示します。$ podman run --rm --name=myubi registry.access.redhat.com/ubi8/ubi \ cat /etc/os-release NAME="Red Hat Enterprise Linux" VERSION="8 (Plow)"
関連情報
- Podman を使用したルートレスコンテナー: 基本的なコンテナー
-
podman-system-migrate
の man ページ
1.7. ルートレスコンテナーへのアップグレード
Red Hat Enterprise Linux 7 からルートレスコンテナーにアップグレードするには、ユーザーおよびグループ ID を手動で設定する必要があります。
以下は、Red Hat Enterprise Linux 7 からルートレスコンテナーにアップグレードするお t 機に考慮すべき事項です。
- 複数のルートレスコンテナーユーザーを設定する場合は、ユーザーごとに一意の範囲を使用します。
- 既存のコンテナーイメージとの互換性を最大限にするために、UID および GID に 65536 を使用します。ただし、この数は減らすことができます
- 1000 未満の UID または GID を使用したり、既存のユーザーアカウントから UID または GID を再利用したりしないでください (デフォルトでは 1000 から開始します)。
前提条件
- ユーザーアカウントが作成されている。
手順
usermod
コマンドを実行して、UID と GID をユーザーに割り当てます。# usermod --add-subuids 200000-201000 --add-subgids 200000-201000 username
-
usermod --add-subuid
コマンドは、アクセス可能なユーザー ID の範囲をユーザーのアカウントに追加します。 -
usermod --add-subgids
コマンドは、アクセス可能なユーザー GID およびグループ ID の範囲をユーザーのアカウントに手動で追加します。
-
検証手順
UID および GID が正しく設定されていることを確認します。
# grep username /etc/subuid /etc/subgid #/etc/subuid:username:200000:1001 #/etc/subgid:username:200000:1001
1.8. ルートレスコンテナーに関する特別な考慮事項
root 以外のユーザーでコンテナーを実行する場合は、考慮事項が複数あります。
-
ホストコンテナーストレージへのパスは、root ユーザー (
/var/lib/containers/storage
) と root 以外のユーザー ($HOME/.local/share/containers/storage
) との間では異なります。 - ルートレスコンテナーを実行するユーザーには、ホストシステムでユーザー ID およびグループ ID の範囲として実行する特別な権限が付与されます。ただし、ホストのオペレーティングシステムに対する root 権限はありません。
-
etc/subuid
や/etc/subgid
を手動で変更した場合、新しい変更を適用させるためにpodman system migrate
コマンドを実行する必要があります。 -
ルートレスコンテナー環境を設定する必要がある場合は、ホームディレクトリーに設定ファイルを作成します (
$HOME/.config/containers
)。設定ファイルには、storage.conf
(ストレージ設定用) およびcontainers.conf
(さまざまなコンテナー設定用) が含まれます。また、registries.conf
ファイルを作成し、Podman を使用してイメージをプル、検索、または実行する時に利用可能なコンテナーレジストリーを識別することもできます。
root 権限なしで変更できないシステム機能もいくつかあります。たとえば、コンテナー内で
SYS_TIME
機能を設定し、ネットワークタイムサービス (ntpd
) を実行してシステムクロックを変更できません。root としてコンテナーを実行し、ルートレスコンテナー環境を省略して root ユーザーの環境を使用する必要があります。以下に例を示します。# podman run -d --cap-add SYS_TIME ntpd
この例では、
ntpd
がコンテナー内だけでなく、システム全体の時間を調整できることに注意してください。ルートレスコンテナーは、1024 未満のポート番号にアクセスできません。たとえば、ルートレスコンテナーの namespace 内では、コンテナーの httpd サービスからポート 80 を公開するサービスを開始しますが、この namespace の外部からはアクセスできません。
$ podman run -d httpd
ただし、そのポートをホストシステムに公開するには、コンテナーには root ユーザーのコンテナー環境を使用するルート権限が必要です。
# podman run -d -p 80:80 httpd
ワークステーションの管理者は、ユーザーが 1024 未満のポートでサービスを公開できるようにしますが、セキュリティーへの影響を理解する必要があります。たとえば、一般ユーザーは、公式のポート 80 で Web サーバーを実行し、外部ユーザーに対して、管理者が設定したと見せかけることができます。これは、テスト用のワークステーションで問題ありませんが、ネットワークにアクセス可能な開発サーバーでは適切ではなく、実稼働サーバーでは実行しないでください。ユーザーがポート 80 にバインドできるようにするには、次のコマンドを実行します。
# echo 80 > /proc/sys/net/ipv4/ip_unprivileged_port_start
関連情報
1.9. 関連情報
第2章 コンテナーイメージの種類
コンテナーイメージは、単一コンテナー実行の全要件、およびそのニーズおよび機能を記述するメタデータを含むバイナリーです。
コンテナーイメージには、以下の 2 つのタイプがあります。
- Red Hat Enterprise Linux Base Images (RHEL ベースイメージ)
- Red Hat Universal Base Images (UBI イメージ)
どちらのタイプのコンテナーイメージも Red Hat Enterprise Linux の一部から構築されます。これらのコンテナーを使用することで、ユーザーは、信頼性、セキュリティー、パフォーマンス、ライフサイクルを最大限に活用できます。
2 種類のコンテナーイメージの主な違いは、UBI イメージではコンテナーイメージを他のタイプと共有できる点です。UBI を使用してコンテナー化アプリケーションをビルドして、任意のレジストリーサーバーにプッシュし、他のサーバーと簡単に共有し、Red Hat 以外のプラットフォームにもデプロイできます。UBI イメージは、コンテナーで開発されるクラウドネイティブおよび Web アプリケーションユースケースの基礎として設計されています。
2.1. RHEL コンテナーイメージの一般的な特徴
以下の特徴は、RHEL ベースイメージと UBI イメージの両方に当てはまります。
一般的には、RHEL コンテナーイメージの特徴は以下のとおりです。
- サポート対象: コンテナー化されたアプリケーションでの使用は、Red Hat によりサポートされています。Red Hat Enterprise Linux で、安全で、テストされ、認定されたものと同じソフトウェアパッケージが含まれています。
- カタログ化される - Red Hat Container Catalog の一覧に追加されます。ここでは、各イメージの説明、技術詳細、および正常指数を確認できます。
- 更新される - 明確に定義された更新スケジュールで提供されます。最新のソフトウェアを取得するには、Red Hat Container Image の更新記事 を参照してください。
- 追跡される - Red Hat 製品エラータにより追跡され、各更新に追加された変更を理解するのに役立ちます。
- 再利用できる: コンテナーイメージは、一度実稼働環境にダウンロードしてキャッシュする必要があります。各コンテナーイメージは、基盤として含まれるすべてのコンテナーで再利用できます。
2.2. UBI イメージの特徴
UBI イメージを使用すると、コンテナーイメージを他と共有できます。4 つの UBI イメージ (Micro、Minimal、Standard、および init) が提供されます。アプリケーションのビルド用に、事前にビルドされた言語のランタイムイメージと YUM リポジトリーが提供されます。
UBI イメージの特徴は以下のとおりです。
- RHEL コンテンツのサブセットから構築 - Red Hat Universal Base イメージは、通常の Red Hat Enterprise Linux コンテンツのサブセットから構築されます。
- 再配布可能: UBI イメージは、Red Hat のお客様、パートナー、ISV など向けに標準化できます。UBI イメージを使用すると、自由に共有およびデプロイが可能な公式の Red Hat ソフトウェアにコンテナーイメージを構築できます。
- 4 つのベースイメージをセットで提供する: Micro、Minimal、Standard、init
- 事前にビルドされた言語ランタイムコンテナーイメージセット を提供する: Application Streams をベースとするランタイムイメージは、アプリケーションの基盤を提供し、python、perl、php、dotnet、nodejs、ruby などの標準かつサポート対象のランタイムから利点を受けることができます。
関連のある YUM リポジトリーを提供する: Yum リポジトリーには、RPM パッケージと更新が含まれており、アプリケーションの依存関係を追加して、UBI コンテナーイメージを再ビルドできます。
-
ubi-8-baseos
リポジトリーは、コンテナーに追加できる RHEL パッケージの再配布可能なサブセットを保持します。 -
ubi-8-appstream
リポジトリーは、特定のランタイムを必要とするアプリケーションで使用する環境を標準化するために、UBI イメージに追加できるアプリケーションストリームパッケージを保持しています。 - UBI RPM の追加 - 事前設定された UBI リポジトリーから UBI イメージに RPM パッケージを追加できます。切断した環境でこのような機能を使用するには、その機能を使用する UBI コンテンツ配信ネットワーク (https://cdn-ubi.redhat.com) をホワイトリストに追加する必要があります。詳細は Red Hat Container Images are trying to connect to https://cdn-ubi.redhat.com を参照してください。
-
- ライセンス - Red Hat Universal Base Image End User License Agreement に従い、UBI イメージを自由に使用および再配布できます。
レイヤー化されたイメージはすべて UBI イメージに基づいています。どの UBI イメージがイメージベースであるかを確認するには、Red Hat Container Catalog で Containerfile を表示し、UBI イメージに必要なすべてのコンテンツが含まれていることを確認します。
2.3. UBI 標準イメージの概要
標準イメージ (名称 ubi
) は、RHEL で実行されるアプリケーション用に設計されています。UBI 標準イメージの主な機能には、以下が含まれます。
-
init system - systemd サービスの管理に必要な systemd 初期化システムのすべての機能は、標準のベースイメージで利用できます。この init システムを使用すると、Web サーバー (
httpd
) や FTP サーバー (vsftpd
) などのサービスを自動的に起動するように事前設定された RPM パッケージをインストールできます。 -
yum: ソフトウェアの追加や更新が可能な、無料の yum リポジトリーにアクセスできます。
yum
コマンドの標準のセットを使用できます (yum
、yum-config-manager
、yumdownloader
など)。 -
utilities: ユーティリティーには
tar
、dmidecode
、gzip
、getfacl
や他の ACL コマンド、dmsetup
、ここに記載されていない他のユーティリティーとのデバイスマッパーコマンドが含まれます。
2.4. UBI init イメージの概要
UBI init イメージ (名称 ubi8-init
) には、systemd 初期化システムが含まれているため、Web サーバーやファイルサーバーなどの systemd サービスを実行するイメージを構築するのに役立ちます。Init イメージの内容は、標準イメージで得られるものよりも少なくなりますが、最小イメージよりも多くなります。
ubi8-init
イメージは ubi8
イメージの上に構築されるため、その内容はほとんど同じです。ただし、重要な相違点がいくつかあります。
ubi8-init
:-
CMD は
/sbin/init
に設定され、デフォルトで systemd Init サービスを開始します。 -
ps
およびプロセス関連のコマンド (procps-ng
パッケージ) が含まれます。 -
また、
SIGRTMIN+3
をStopSignal
として設定しています。これは、ubi8-init
の systemd が通常の終了信号 (SIGTERM
およびSIGKILL
) を無視しているためですが、SIGRTMIN+3
を受け取った場合は無効になります。
-
CMD は
ubi8
:-
CMD は
/bin/bash
に設定されます。 -
ps
およびプロセス関連のコマンド (procps-ng
パッケージ) は含まれません。 -
通常の終了シグナルを無視しません (
SIGTERM
およびSIGKILL
)。
-
CMD は
2.5. UBI の最小イメージの理解
ubi-minimal
という名前の UBI の最小イメージは、事前にインストールされたコンテンツセットおよびパッケージマネージャー (microdnf`
) の最小イメージを提供します。これにより、Containerfile
を使用し、イメージに含まれる依存関係を最小化できます。
UBI 最小イメージの主な機能には、以下が含まれます。
- サイズが小さい - 最小イメージは、ディスク上では約 92M、圧縮時は 32M です。これにより、サイズが、標準イメージの半分に満たなくなります。
-
ソフトウェアインストール (
microdnf
) - ソフトウェアリポジトリーおよび RPM ソフトウェアパッケージを使用する完全に開発されたyum
機能を追加する代わりに、最小イメージにはmicrodnf
ユーティリティーが含まれます。microdnf
はdnf
の縮小バージョンであるため、リポジトリーの有効化/無効化、パッケージの削除と更新、パッケージのインストール後にキャッシュを削除できます。 - RHEL パッケージをベースとする - 最小イメージには、通常の RHEL ソフトウェアの RPM パッケージから機能がいくつか削除されたものです。最小イメージには、systemd や System V init、Python ランタイム環境、および一部のシェルユーティリティーなど、初期化およびサービス管理システムが含まれません。RHEL リポジトリーを使用してイメージを構築することができますが、オーバーヘッドの量は最小限に抑えられます。
microdnf
のモジュールはサポート対象 -microdnf
コマンドで使用されるモジュールにより、利用可能な場合は、同じソフトウェアの複数のバージョンをインストールできます。microdnf module enable
、microdnf module disable
、およびmicrodnf module reset
を使用して、モジュールストリームをそれぞれ有効化、無効化、およびリセットできます。たとえば、UBI 最小コンテナー内で
nodejs:14
モジュールストリームを有効にするには、次のコマンドを実行します。# microdnf module enable nodejs:14 Downloading metadata... ... Enabling module streams: nodejs:14 Running transaction test...
Red Hat は UBI の最新バージョンのみをサポートし、ドットリリースの過去バージョンはサポートしません。特定のドットリリースを使用し続ける必要がある場合は、延長更新サポート を参照してください。
2.6. UBI マイクロイメージの概要
ubi-micro
は、取得可能な最小 UBI イメージで、パッケージマネージャーと、通常はコンテナーイメージに含まれるすべての依存関係を除外しています。これにより、他のアプリケーションに UBI Standard、Minimal、または Init を使用する場合でも、ubi-micro
イメージがベースのコンテナーイメージに対する攻撃の可能性を最小限に抑えられ、最小アプリケーションに適しています。Linux ディストリビューションパッケージのないコンテナーイメージは Distroless コンテナーイメージと呼ばれます。
第3章 コンテナーイメージの使用
Podman ツールは、コンテナーイメージと連携するように設計されています。このツールを使用して、イメージのプル、イメージ署名の検査、タグ付け、保存、読み込み、再配布、および定義を行うことができます。
3.1. コンテナーレジストリー
コンテナーレジストリーは、コンテナーイメージとコンテナーベースのアプリケーションアーティファクトを保存するためのリポジトリーまたはリポジトリーのコレクションです。Red Hat が提供するレジストリーは以下のとおりです。
- registry.redhat.io (認証が必要)
- registry.access.redhat.com (認証なし)
- registry.connect.redhat.com (Red Hat Partner Connect プログラムイメージ)
リモートレジストリー (Red Hat の独自のコンテナーレジストリーなど) からコンテナーイメージを取得して、ローカルシステムに追加するには、podman pull
コマンドを使用します。
# podman pull <registry>[:<port>]/[<namespace>/]<name>:<tag>
ここで、<registry>[:<port>]/[<namespace>/]<name>:<tag>
はコンテナーイメージの名前です。
たとえば、registry.redhat.io/ubi8/ubi
コンテナーイメージは以下によって識別されます。
-
レジストリーサーバー (
registry.redhat.io
) -
namespace (
ubi8
) -
イメージ名 (
ubi
)
同じイメージにバージョンが複数ある場合は、イメージ名を明示的に指定するタグを追加します。デフォルトでは、Podman は :latest
タグを使用します (例: ubi8/ubi:latest
)。
一部のレジストリーでは、<namespace> も使用して、異なるユーザーまたは組織によって所有される同じ <name> のイメージを区別します。以下に例を示します。
名前空間 | (<namespace>/<name>) の例 |
---|---|
organization |
|
login (ユーザー名) |
|
role |
|
registry.redhat.io への移行の詳細は、Red Hat Container Registry Authentication を参照してください。registry.redhat.io からコンテナーを取得する前に、RHEL サブスクリプション認証情報を使用して認証する必要があります。
3.2. コンテナーレジストリーの設定
registries.conf
の設定ファイルで、コンテナーレジストリーの一覧を確認できます。root ユーザーとして、/etc/containers/registries.conf
ファイルを編集し、デフォルトのシステム全体の検索設定を変更します。
ユーザーとして、$HOME/.config/containers/registries.conf
ファイルを作成し、システム全体の設定を上書きします。
unqualified-search-registries = ["registry.fedoraproject.org", "registry.access.redhat.com", "docker.io"]
デフォルトでは、podman pull
および podman search
コマンドは、unqualified-search-registries
のリストに記載のレジストリーから、その順序でコンテナーイメージを検索します。
- ローカルコンテナーレジストリーの設定
TLS 検証なしでローカルコンテナーレジストリーを設定できます。TLS 検証を無効にする方法は 2 つあります。まず、Podman で
--tls-verify=false
オプションを使用できます。次に、registries.conf
ファイルにinsecure=true
を設定できます。[[registry]] location="localhost:5000" insecure=true
- レジストリー、名前空間、またはイメージのブロック
ローカルシステムがアクセスできないレジストリーを定義できます。
blocked=true
を設定して、特定のレジストリーをブロックできます。[[registry]] location = "registry.example.org" blocked = true
接頭辞を
prefix="registry.example.org/namespace"
に設定して、名前空間をブロックすることもできます。たとえば、podman pull registry.example.org/example/image:latest
コマンドを使用するイメージのプルは、指定した接頭辞が一致するためブロックされます。[[registry]] location = "registry.example.org" prefix="registry.example.org/namespace" blocked = true
注記prefix
はオプションで、デフォルト値はlocation
の値と同じです。prefix="registry.example.org/namespace/image"
を設定して、特定のイメージをブロックできます。[[registry]] location = "registry.example.org" prefix="registry.example.org/namespace/image" blocked = true
- レジストリーのミラーリング
元のレジストリーにアクセスできない場合は、レジストリーミラーを設定できます。たとえば、機密レベルの高い環境で作業するため、インターネットに接続することはできません。指定された順序でアクセスされる複数のミラーを指定できます。たとえば、
podman pull registry.example.com/myimage:latest
コマンドを実行すると、まずmirror-1.com
が試行され、次にmirror-2.com
が試行されます。[[registry]] location="registry.example.com" [[registry.mirror]] location="mirror-1.com" [[registry.mirror]] location="mirror-2.com"
3.3. コンテナーイメージの検索
podman search
コマンドを使用すると、イメージ用に選択したコンテナーレジストリーを検索できます。また、Red Hat Container Catalog でイメージを検索することもできます。Red Hat コンテナーレジストリーには、イメージの説明、コンテンツ、ヘルスインデックスなど情報が含まれます。
podman search
コマンドは、イメージの存在を判断する信頼できる方法ではありません。v1 および v2 Docker ディストリビューション API の podman search
動作は、各レジストリーの実装に固有のものです。一部のレジストリーは、検索をまったくサポートしない場合があります。検索用語を使用しない検索は、v2 API を実装するレジストリーでのみ機能します。docker search
コマンドにも、同じことが言えます。
quay.io レジストリーで postgresql-10
イメージを検索するには、手順に従います。
前提条件
- レジストリーが設定されている。
手順
レジストリーに対して認証します。
# podman login quay.io
イメージを検索します。
特定のレジストリーで特定のイメージを検索するには、以下を入力します。
# podman search quay.io/postgresql-10 INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED redhat.io registry.redhat.io/rhel8/postgresql-10 This container image ... 0 redhat.io registry.redhat.io/rhscl/postgresql-10-rhel7 PostgreSQL is an ... 0
または、特定のレジストリーで提供されるすべてのイメージを表示するには、以下を入力します。
# podman search quay.io/
すべてのレジストリー全体でイメージ名を検索するには、以下を入力します。
# podman search postgresql-10
完全な説明を表示するには、
--no-trunc
オプションをコマンドに渡します。
関連情報
-
podman-search
の man ページ
3.4. レジストリーからのイメージの取得 (プル)
podman pull
コマンドを使用して、ローカルシステムにイメージを取得します。
手順
registry.redhat.io レジストリーにログインします。
$ podman login registry.redhat.io Username: <username> Password: <password> Login Succeeded!
registry.redhat.io/ubi8/ubi コンテナーイメージをプルします。
$ podman pull registry.redhat.io/ubi8/ubi
検証手順
ローカルシステムにプルしたすべてのイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/ubi8/ubi latest 3269c37eae33 7 weeks ago 208 MB
関連情報
-
podman-pull
の man ページ
3.5. 短縮名のエイリアスの設定
Red Hat は、常に完全修飾名でイメージをプルすることを推奨します。ただし、短縮名でイメージをプルすることが一般的です。たとえば、registry.access.redhat.com/ubi8:latest
の代わりに ubi8
を使用できます。
registries.conf
ファイルにより、短縮名のエイリアスを指定でき、管理者はイメージをプルする場所を完全に制御できます。エイリアスは、"name" = "value"
の形式で [aliases]
テーブルで指定されます。エイリアスの一覧は、/etc/containers/registries.conf.d
ディレクトリーで確認できます。Red Hat は、このディレクトリーでエイリアスのセットを提供します。たとえば、podman pull ubi8
は、registry.access.redhat.com/ubi8:latest
である適切なイメージに直接解決します。
以下に例を示します。
unqualified-search-registries=["registry.fedoraproject.org", “quay.io"] [aliases] "fedora"="registry.fedoraproject.org/fedora"
short-names モードは以下のようになります。
-
enforcing: イメージのプル中に一致するエイリアスが見つからない場合、Podman はユーザーが非修飾レジストリーのいずれかを選択するよう求めます。選択したイメージを正常に取得すると、Podman は、
$HOME/.cache/containers/short-name-aliases.conf
ファイル (ルートレスユーザー) または/var/cache/containers/short-name-aliases.conf
(root ユーザー) に新しい短縮名のエイリアスを自動的に記録します。ユーザーを要求できない場合 (stdin や stdout など) が TTY ではない場合は、Podman は失敗します。short-name-aliases.conf
ファイルは、両方が同じエイリアスを指定する場合、registries.conf
ファイルよりも優先されることに注意してください。 - permissive: enforcing モードと似ていますが、ユーザーにプロンプトが表示されないと Podman は失敗しません。代わりに、Podman は指定された順序で修飾されていないすべてのレジストリーを検索します。エイリアスは記録されないことに注意してください。
- disabled: すべての非修飾検索レジストリーが指定の順序で試行され、エイリアスは記録されません。
Red Hat では、レジストリー、名前空間、イメージ名、およびタグが含まれる完全修飾イメージ名を使用することを推奨しますします。短縮名を使用する場合は、なりすましの固有リスクが常にあります。不明なユーザーや匿名ユーザーが任意の名前でアカウントを作成できないように、信頼できるレジストリー (つまりレジストリー) を追加します。たとえば、ユーザーは example.registry.com registry
レジストリーから example コンテナーイメージをプルします。example.registry.com
が検索リストの最初にない場合には、攻撃者は検索リストの前のほうに別の example イメージを配置することができてしまいます。目的のコンテンツではなく、攻撃者が配置したイメージを間違ってプルして実行する可能性があります。
3.6. 短縮名のエイリアスを使用したコンテナーイメージのプル
セキュアな短縮名を使用して、ローカルシステムにイメージを取得できます。以下の手順では、fedora
または nginx
のコンテナーイメージをプルする方法を説明します。
手順
コンテナーイメージをプルします。
fedora
イメージをプルします。$ podman pull fedora Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf) Trying to pull registry.fedoraproject.org/fedora:latest… ... Storing signatures ...
エイリアスが検出され、
registry.fedoraproject.org/fedora
イメージが安全にプルされます。unqualified-search-registries
の一覧は、fedora
イメージ名を解決するためには使用されません。nginx
イメージをプルします。$ podman pull nginx ? Please select an image: registry.access.redhat.com/nginx:latest registry.redhat.io/nginx:latest ▸ docker.io/library/nginx:latest ✔ docker.io/library/nginx:latest Trying to pull docker.io/library/nginx:latest… ... Storing signatures ...
一致するエイリアスが見つからない場合は、
unqualified-search-registries
一覧のいずれかを選択するように求められます。選択したイメージが正常にプルされると、新しい短縮名のエイリアスがローカルに記録されます。そうでない場合はエラーが生じます。
検証
ローカルシステムにプルしたすべてのイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.fedoraproject.org/fedora latest 28317703decd 12 days ago 184 MB docker.io/library/nginx latest 08b152afcfae 13 days ago 137 MB
3.7. イメージの一覧表示
podman images
コマンドを使用して、ローカルストレージのイメージを一覧表示します。
前提条件
- プルしたイメージがローカルシステムで利用できる。
手順
ローカルストレージ内のイメージをすべて一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi8/ubi latest 3269c37eae33 6 weeks ago 208 MB
関連情報
-
podman-images
の man ページ
3.8. ローカルイメージの検証
ローカルシステムにイメージをプルして実行したら、podman inspect
コマンドを使用してイメージを調査できます。たとえば、イメージの内容を理解して、イメージ内のソフトウェアを確認します。podman inspect
コマンドは、名前または ID で識別されるコンテナーおよびイメージに関する情報を表示します。
前提条件
- プルしたイメージがローカルシステムで利用できる。
手順
registry.redhat.io/ubi8/ubi
イメージを確認します。$ podman inspect registry.redhat.io/ubi8/ubi … "Cmd": [ "/bin/bash" ], "Labels": { "architecture": "x86_64", "build-date": "2020-12-10T01:59:40.343735", "com.redhat.build-host": "cpt-1002.osbs.prod.upshift.rdu2.redhat.com", "com.redhat.component": "ubi8-container", "com.redhat.license_terms": "https://www.redhat.com/..., "description": "The Universal Base Image is ... } ...
"Cmd"
キーは、コンテナー内で実行するデフォルトのコマンドを指定します。このコマンドは、podman run
コマンドに引数として指定すると、上書きできます。この ubi8/ubi コンテナーは、podman run
で起動時に他の引数を指定していない場合には、bash シェルを実行します。"Entrypoint"
キーが設定された場合は、"Cmd"
値の代わりにその値が使用されます (また、Entriespoint コマンドの引数として"Cmd"
の値が使用されます)。
関連情報
-
podman-inspect
の man ページ
3.9. リモートイメージの検証
skopeo inspect
コマンドを使用して、システムにイメージをプルする前に、リモートコンテナーレジストリーからイメージに関する情報を表示します。
手順
registry.redhat.io/ubi8/ubi-init
イメージを確認します。# skopeo inspect docker://registry.redhat.io/ubi8/ubi-init { "Name": "registry.redhat.io/ubi8/ubi8-init", "Digest": "sha256:c6d1e50ab...", "RepoTags": [ ... "latest" ], "Created": "2020-12-10T07:16:37.250312Z", "DockerVersion": "1.13.1", "Labels": { "architecture": "x86_64", "build-date": "2020-12-10T07:16:11.378348", "com.redhat.build-host": "cpt-1007.osbs.prod.upshift.rdu2.redhat.com", "com.redhat.component": "ubi8-init-container", "com.redhat.license_terms": "https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI", "description": "The Universal Base Image Init is designed to run an init system as PID 1 for running multi-services inside a container ... } }
関連情報
-
skopeo-inspect
の man ページ
3.10. コンテナーイメージのコピー
skopeo copy
コマンドを使用して、コンテナーイメージをあるレジストリーから別のレジストリーにコピーできます。たとえば、外部レジストリーのイメージを使用して内部リポジトリーに反映させたり、2 つの異なる場所のイメージレジストリーを同期したりできます。
手順
skopeo
コンテナーイメージをdocker://quay.io
からdocker://registry.example.com
にコピーします。$ skopeo copy docker://quay.io/skopeo/stable:latest docker://registry.example.com/skopeo:latest
関連情報
-
skopeo-copy
の man ページ
3.11. ローカルディレクトリーへのイメージレイヤーのコピー
skopeo copy
コマンドを使用して、コンテナーイメージのレイヤーをローカルディレクトリーにコピーできます。
手順
/var/lib/images/nginx
ディレクトリーを作成します。$ mkdir -p /var/lib/images/nginx
docker://docker.io/nginx:latest
イメージのレイヤーを、新たに作成したディレクトリーにコピーします。$ skopeo copy docker://docker.io/nginx:latest dir:/var/lib/images/nginx
検証
/var/lib/images/nginx
ディレクトリーの内容を表示します。$ ls /var/lib/images/nginx 08b11a3d692c1a2e15ae840f2c15c18308dcb079aa5320e15d46b62015c0f6f3 ... 4fcb23e29ba19bf305d0d4b35412625fea51e82292ec7312f9be724cb6e31ffd manifest.json version
関連情報
-
skopeo-copy
の man ページ
3.12. タグ付けイメージ
podman tag
コマンドを使用して、ローカルイメージに名前を追加します。この追加した名前は、registryhost/username/NAME:tag のように複数の部分で設定されます。
前提条件
- プルしたイメージがローカルシステムで利用できる。
手順
すべてのイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/ubi8/ubi latest 3269c37eae33 7 weeks ago 208 MB
以下のいずれかを使用して、
myubi
名をregistry.redhat.io/ubi8/ubi
イメージに割り当てます。イメージ名:
$ podman tag registry.redhat.io/ubi8/ubi myubi
イメージ ID:
$ podman tag 3269c37eae33 myubi
どちらのコマンドも、同じ結果になります。
すべてのイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/ubi8/ubi latest 3269c37eae33 2 months ago 208 MB localhost/myubi latest 3269c37eae33 2 months ago 208 MB
デフォルトのタグがいずれのイメージでも
latest
であることに注意してください。すべてのイメージ名が単一のイメージ ID 3269c37eae33 に割り当てられていることを確認できます。以下のいずれかを使用して、
8
タグをregistry.redhat.io/ubi8/ubi
イメージに追加します。イメージ名:
$ podman tag registry.redhat.io/ubi8/ubi myubi:8
イメージ ID:
$ podman tag 3269c37eae33 myubi:8
どちらのコマンドも、同じ結果になります。
すべてのイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/ubi8/ubi latest 3269c37eae33 2 months ago 208 MB localhost/myubi latest 3269c37eae33 2 months ago 208 MB localhost/myubi 8 3269c37eae33 2 months ago 208 MB
デフォルトのタグがいずれのイメージでも
latest
であることに注意してください。すべてのイメージ名が単一のイメージ ID 3269c37eae33 に割り当てられていることを確認できます。
registry.redhat.io/ubi8/ubi
イメージにタグ付けした後に、コンテナーを実行するオプションが 3 つあります。
-
ID (
3269c37eae33
) -
名前 (
localhost/myubi:latest
) -
名前 (
localhost/myubi:8
)
関連情報
-
podman-tag
の man ページ
3.13. イメージの保存および読み込み
podman save
コマンドを使用して、イメージをコンテナーアーカイブに保存します。別のコンテナー環境に後で復元したり、別のユーザーに送信することもできます。--format
オプションを使用して、アーカイブ形式を指定できます。サポート対象の形式は以下のとおりです。
-
docker-archive
-
oci-archive
-
oci-dir
(oci マニフェストタイプのあるディレクトリー) -
docker-dir
(v2s2 マニフェストタイプを含むディレクトリー)
デフォルトの形式は docker-dir
です。
podman load
コマンドを使用して、コンテナーイメージアーカイブからコンテナーストレージにイメージを読み込みます。
前提条件
- プルしたイメージがローカルシステムで利用できる。
手順
registry.redhat.io/rhel8/rsyslog
イメージを tarball として保存します。デフォルトの
docker-dir
形式で以下を行います。$ podman save -o myrsyslog.tar registry.redhat.io/rhel8/rsyslog:latest
oci-archive
形式で、--format
オプションを使用します。$ podman save -o myrsyslog-oci.tar --format=oci-archive registry.redhat.io/rhel8/rsyslog
myrsyslog.tar
およびmyrsyslog-oci.tar
アーカイブは現在のディレクトリーに保存されます。次の手順では、myrsyslog.tar
tarball で実行されます。
myrsyslog.tar
のファイルタイプを確認します。$ file myrsyslog.tar myrsyslog.tar: POSIX tar archive
myrsyslog.tar
からregistry.redhat.io/rhel8/rsyslog:latest
イメージを読み込むには、以下を実行します。$ podman load -i myrsyslog.tar ... Loaded image(s): registry.redhat.io/rhel8/rsyslog:latest
関連情報
-
podman-save
の man ページ
3.14. UBI イメージの再配布
podman push
コマンドを使用して、UBI イメージを独自のレジストリーやサードパーティーのレジストリーにプッシュするか、他のと共有します。UBI yum リポジトリーから、必要に応じてイメージをアップグレードまたは追加できます。
前提条件
- プルしたイメージがローカルシステムで利用できる。
手順
必要に応じて、
ubi
イメージに別の名前を追加します。# podman tag registry.redhat.io/ubi8/ubi registry.example.com:5000/ubi8/ubi
registry.example.com:5000/ubi8/ubi
イメージをローカルストレージからレジストリーにプッシュします。# podman push registry.example.com:5000/ubi8/ubi
- 重要
- このイメージを使用する方法には制限がいくつかありますが、その方法を参照する方法にもいくつかの制限があります。たとえば、Red Hat Container Certification または Red Hat OpenShift Operator Certification の Red Hat Partner Connect Program で認定されていなければ、Red Hat の認定イメージまたは Red Hat のサポートイメージとはみなされません。
3.15. イメージの削除
podman rmi
コマンドを使用して、ローカルに保存されたコンテナーイメージを削除します。ID または名前を使用して、イメージを削除できます。
手順
ローカルシステムにある全イメージの一覧を表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/rhel8/rsyslog latest 4b32d14201de 7 weeks ago 228 MB registry.redhat.io/ubi8/ubi latest 3269c37eae33 7 weeks ago 208 MB localhost/myubi X.Y 3269c37eae33 7 weeks ago 208 MB
すべてのコンテナーを一覧表示します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7ccd6001166e registry.redhat.io/rhel8/rsyslog:latest /bin/rsyslog.sh 6 seconds ago Up 5 seconds ago mysyslog
registry.redhat.io/rhel8/rsyslog
イメージを削除するには、podman stop
コマンドを使用して、このイメージから実行中のコンテナーをすべて停止する必要があります。コンテナーを ID または名前を使用して停止できます。mysyslog
コンテナーを停止します。$ podman stop mysyslog 7ccd6001166e9720c47fbeb077e0afd0bb635e74a1b0ede3fd34d09eaf5a52e9
registry.redhat.io/rhel8/rsyslog
イメージを削除します。$ podman rmi registry.redhat.io/rhel8/rsyslog
複数のイメージを削除するには、以下のコマンドを実行します。
$ podman rmi registry.redhat.io/rhel8/rsyslog registry.redhat.io/ubi8/ubi
システムからすべてのイメージを削除するには、以下のコマンドを実行します。
$ podman rmi -a
複数の名前 (タグ) が関連付けられているイメージを削除するには、
-f
オプションを追加して削除します。$ podman rmi -f 1de7d7b3f531 1de7d7b3f531...
関連情報
-
podman-rmi
の man ページ
第4章 コンテナーイメージへの署名
GNU Privacy Guard (GPG) 署名または sigstore 署名を使用して、コンテナーイメージに署名できます。両方の署名手法は、通常、OCI 準拠のコンテナーレジストリーと互換性があります。Podman を使用して、リモートレジストリーにプッシュする前にイメージに署名し、署名されていないイメージが拒否されるようにコンシューマーを設定できます。コンテナーイメージに署名すると、サプライチェーンへの攻撃を防ぐことができます。
GPG キーを使用して署名するには、署名を配布するために別のルックアサイドサーバーをデプロイメントする必要があります。ルックアサイドサーバーは、任意の HTTP サーバーにすることができます。Podman バージョン 4.2 以降では、コンテナー署名の sigstore 形式を使用できます。GPG キーと比較して、sigstore 署名はコンテナーレジストリーに格納されるため、個別のルックアサイドサーバーは必要ありません。
4.1. GPG 署名を使用したコンテナーイメージへの署名
GNU Privacy Guard (GPG) キーを使用してイメージに署名できます。
前提条件
- GPG ツールがインストールされます。
ルックアサイド Web サーバーがセットアップされ、その上でファイルを公開できます。
システム全体のレジストリー設定は、
/etc/containers/registries.d/default.yaml
ファイルで確認できます。lookaside-staging
オプションは、署名を書き込むためのファイルパスを参照し、通常、署名を発行するホストで設定されます。# cat /etc/containers/registries.d/default.yaml docker: <registry>: lookaside: https://registry-lookaside.example.com lookaside-staging: file:///var/lib/containers/sigstore ...
手順
GPG キーを生成します。
# gpg --full-gen-key
公開鍵をエクスポートします。
# gpg --output <path>/key.gpg --armor --export <username>@redhat.com
現在のディレクトリーで
Containerfile
を使用してコンテナーイメージをビルドします。$ podman build -t <registry>/<namespace>/<image>
<registry>
、<namespace>
、および<image>
をコンテナーイメージ識別子に置き換えます。詳細については、コンテナーレジストリー を参照してください。イメージに署名し、レジストリーにプッシュします。
$ podman push \ --sign-by <username>@redhat.com \ <registry>/<namespace>/<image>
注記既存のイメージをコンテナーレジストリー間で移動するときに署名する必要がある場合は、
skopeo copy
コマンドを使用できます。オプション:新しいイメージシグネチャーを表示します。
# (cd /var/lib/containers/sigstore/; find . -type f) ./<image>@sha256=<digest>/signature-1
ローカル署名をルックアサイド Web サーバーにコピーします。
# rsync -a /var/lib/containers/sigstore user@registry-lookaside.example.com:/registry-lookaside/webroot/sigstore
署名は、lookaside-staging
オプションによって決定される場所 (この場合は /var/lib/containers/sigstore
ディレクトリー) に保存されます。
検証
- 詳細については、GPG イメージ署名の検証 を参照してください。
関連情報
-
podman-image-trust
の man ページ -
podman-push
の man ページ -
podman-build
の man ページ - GPG キーペアの生成方法
4.2. GPG イメージ署名の検証
次の手順を使用して、コンテナーイメージが GPG キーで正しく署名されていることを確認できます。
前提条件
署名読み取り用の Web サーバーがセットアップされ、その上でファイルを公開できます。
システム全体のレジストリー設定は、
/etc/containers/registries.d/default.yaml
ファイルで確認できます。lookaside
オプションは、署名読み取り用の Web サーバーを参照します。署名を検証するには、lookaside
オプションを設定する必要があります。# cat /etc/containers/registries.d/default.yaml docker: <registry>: lookaside: https://registry-lookaside.example.com lookaside-staging: file:///var/lib/containers/sigstore ...
手順
<registry>
の信頼範囲を更新します。$ podman image trust set -f <path>/key.gpg <registry>/<namespace>
オプション:
/etc/containers/policy.json
ファイルを表示して、信頼ポリシーの設定を確認します。$ cat /etc/containers/policy.json { ... "transports": { "docker": { "<registry>/<namespace>": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "<path>/key.gpg" } ] } } }
注記通常、
/etc/containers.policy.json
ファイルは、同じキーが使用される組織のレベルで設定されます。たとえば、公開レジストリーの場合は<registry>/<namespace>
、単一企業専用レジストリーの場合は単に<registry>
です。イメージをプルします:
# podman pull <registry>/<namespace>/<image> ... Storing signatures e7d92cdc71feacf90708cb59182d0df1b911f8ae022d29e8e95d75ca6a99776a
podman pull
コマンドは、設定どおりに署名の存在を強制します。追加のオプションは必要ありません。
/etc/containers/registries.d/default.yaml
ファイルで、システム全体のレジストリー設定を編集できます。/etc/containers/registries.d
ディレクトリーにある任意の YAML ファイルのレジストリーまたはリポジトリー設定セクションを編集することもできます。すべての YAML ファイルが読み取られ、ファイル名は任意です。単一のスコープ (default-docker、レジストリー、または名前空間) は、/etc/containers/registries.d
ディレクトリー内の 1 つのファイルにのみ存在できます。
/etc/containers/registries.d/default.yaml
ファイルのシステム全体のレジストリー設定により、公開された署名にアクセスできます。sigstore
および sigstore-staging
オプションは非推奨になりました。これらのオプションは署名ストレージを参照しており、sigstore 署名形式には関連付けられていません。代わりに、新しい同等の lookaside
および lookaside-staging
オプションを使用してください。
関連情報
-
podman-image-trust
の man ページ -
podman-pull
の man ページ
4.3. sigstore 署名を使用したコンテナーイメージの署名
Podman バージョン 4.2 以降では、コンテナー署名の sigstore 形式を使用できます。
前提条件
- 公開鍵と秘密鍵のペアが存在します。
公開鍵と秘密鍵の生成は実装されていません。アップストリームの Cosign プロジェクトを使用して、公開鍵と秘密鍵のペアを生成する必要があります。
cosign ツールをインストールします。
$ git clone https://github.com/sigstore/cosign $ cd cosign $ make ./cosign
公開鍵と秘密鍵を生成:
$ ./cosign generate-key-pair ... Private key written to cosign.key Public key written to cosign.pub
手順
次の内容を
/etc/containers/registries.d/default.yaml
ファイルに追加します。docker: <registry>: use-sigstore-attachments: true
use-sigstore-attachments
オプションを設定することで、Podman と Skopeo はコンテナーの sigstore 署名をイメージと共に読み書きし、署名されたイメージと同じリポジトリーに保存できます。注記/etc/containers/registries.d/default.yaml
ファイルで、システム全体のレジストリー設定を編集できます。/etc/containers/registries.d
ディレクトリーにある任意の YAML ファイルのレジストリーまたはリポジトリー設定セクションを編集することもできます。すべての YAML ファイルが読み取られ、ファイル名は任意です。単一のスコープ (default-docker、レジストリー、または名前空間) は、/etc/containers/registries.d
ディレクトリー内の 1 つのファイルにのみ存在できます。現在のディレクトリーで
Containerfile
を使用してコンテナーイメージをビルドします。$ podman build -t <registry>/<namespace>/<image>
イメージに署名し、レジストリーにプッシュします。
$ podman push --sign-by-sigstore-private-key ./cosign.key <registry>/<namespace>/image>
podman push
コマンドは、<registry>/<namespace>/<image>
ローカルイメージを<registry>/<namespace>/<image>
としてリモートレジストリーにプッシュします。--sign-by-sigstore-private-key
オプションは、cosign.key
秘密鍵を使用して sigstore 署名を<registry>/<namespace>/<image>
イメージに追加します。イメージと sigstore 署名がリモートレジストリーにアップロードされます。
既存のイメージをコンテナーレジストリー間で移動するときに署名する必要がある場合は、skopeo copy
コマンドを使用できます。
検証
- 詳細については、sigstore イメージ署名の検証 を参照してください。
関連情報
-
podman-push
の man ページ -
podman-build
の man ページ - Sigstore: ソフトウェアサプライチェーンの信頼とセキュリティーに対するオープンな答え
4.4. sigstore イメージ署名の検証
次の手順を使用して、コンテナーイメージが正しく署名されていることを確認できます。
手順
次の内容を
/etc/containers/registries.d/default.yaml
ファイルに追加します。docker: <registry>: use-sigstore-attachments: true
use-sigstore-attachments
オプションを設定することで、Podman と Skopeo はコンテナーの sigstore 署名をイメージと共に読み書きし、署名されたイメージと同じリポジトリーに保存できます。注記/etc/containers/registries.d/default.yaml
ファイルで、システム全体のレジストリー設定を編集できます。/etc/containers/registries.d
ディレクトリーにある任意の YAML ファイルのレジストリーまたはリポジトリー設定セクションを編集することもできます。すべての YAML ファイルが読み取られ、ファイル名は任意です。単一のスコープ (default-docker、レジストリー、または名前空間) は、/etc/containers/registries.d
ディレクトリー内の 1 つのファイルにのみ存在できます。/etc/containers/policy.json ファイルを編集して、
sigstore
署名の存在を強制します。... "transports": { "docker": { "<registry>/<namespace>": [ { "type": "sigstoreSigned", "keyPath": "/some/path/to/cosign.pub" } ] } } ...
/etc/containers/policy.json
設定ファイルを変更することにより、信頼ポリシーの設定を変更します。Podman、Buildah、および Skopeo は、コンテナーイメージの署名の存在を強制します。イメージをプルします:
$ podman pull <registry>/<namespace>/<image>
podman pull
コマンドは、設定どおりに署名の存在を強制します。追加のオプションは必要ありません。
第5章 コンテナーの使用
コンテナーは、展開されたコンテナーイメージにあるファイルから作成された、実行中プロセスまたは停止プロセスを表します。Podman ツールを使用してコンテナーと連携できます。
5.1. podman run コマンド
podman run
コマンドは、コンテナーイメージをもとに新しいコンテナーでプロセスを実行します。コンテナーイメージがすでにロードされていない場合は、podman run
は、そのイメージからコンテナーを起動する前に、podman pull image
を実行するのと同じ方法で、リポジトリーからイメージおよびイメージの全依存関係を取得します。コンテナープロセスには、独自のファイルシステム、独自のネットワーク、独自のプロセスツリーがあります。
podman run
コマンドの形式は次のとおりです。
podman run [options] image [command [arg ...]]
基本オプションは次のとおりです。
-
--detach(-d)
: コンテナーをバックグラウンドで実行し、新しいコンテナー ID を出力します。 -
--attach(-a)
: フォアグラウンドモードでコンテナーを実行します。 -
--name(-n)
: 名前をコンテナーに割り当てます。--name
で名前がコンテナーに割り当てられていない場合には、ランダムな文字列で名前が生成されます。これはバックグラウンドコンテナーとフォアグラウンドコンテナーの両方で機能します。 -
--rm
: 終了時にコンテナーを自動的に削除します。コンテナーが正常に作成または起動できない場合には、削除されない点に注意してください。 -
--tty(-t)
: コンテナーの標準入力に、疑似端末を割り当て、接続します。 -
--interactive(-i)
: 対話式プロセスの場合には、-i
と-t
を佩用してコンテナープロセスに端末を割り当てます。-i -t
は頻繁に-it
と記述されます。
5.2. ホストからのコンテナーでのコマンド実行
この手順では、podman run
コマンドを使用して、コンテナーのオペレーティングシステムタイプを表示する方法を説明します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
cat /etc/os-release
コマンドを使用して、registry.access.redhat.com/ubi8/ubi
コンテナーイメージをベースとするコンテナーのオペレーティングシステムの種類を表示します。$ podman run --rm registry.access.redhat.com/ubi8/ubi cat /etc/os-release NAME="Red Hat Enterprise Linux" ... ID="rhel" ... HOME_URL="https://www.redhat.com/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT=" Red Hat Enterprise Linux 8" ...
オプション: すべてのコンテナーを一覧表示します。
$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
--rm
オプションがあるのでコンテナーは表示されません。コンテナーが削除されました。
関連情報
-
podman-run
の man ページ
5.3. コンテナー内でのコマンドの実行
この手順では、podman run
コマンドを使用して、コンテナーを対話的に実行する方法を説明します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
registry.redhat.io/ubi8/ubi
イメージに基づいて、myubi
という名前のコンテナーを実行します。$ podman run --name=myubi -it registry.access.redhat.com/ubi8/ubi /bin/bash [root@6ccffd0f6421 /]#
-
-i
オプションは対話式のセッションを作成します。-t
オプションを指定しないと、シェルは開いたままにも拘らず、シェルには何も入力できません。 -
-t
オプションは、端末セッションを開きます。-i
オプションを指定しないと、シェルが開き、終了します。
-
システムユーティリティーのセットが含まれる
procps-ng
パッケージをインストールします (例:ps
、top
、uptime
など)。[root@6ccffd0f6421 /]# yum install procps-ng
ps -ef
コマンドを使用して、現在のプロセスを一覧表示します。# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 12:55 pts/0 00:00:00 /bin/bash root 31 1 0 13:07 pts/0 00:00:00 ps -ef
exit
を実行してコンテナーを終了し、ホストに戻ります。# exit
必要に応じて、すべてのコンテナーを一覧表示します。
$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1984555a2c27 registry.redhat.io/ubi8/ubi:latest /bin/bash 21 minutes ago Exited (0) 21 minutes ago myubi
コンテナーが終了ステータスであることを確認できます。
関連情報
-
podman-run
の man ページ
5.4. コンテナーの一覧表示
podman ps
コマンドを使用して、システムで実行中のコンテナーの一覧を表示します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
registry.redhat.io/rhel8/rsyslog
イメージをベースとするコンテナーを実行します。$ podman run -d registry.redhat.io/rhel8/rsyslog
すべてのコンテナーを一覧表示します。
実行中のコンテナーの一覧を表示するには、以下のコマンドを実行します。
$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 74b1da000a11 rhel8/rsyslog /bin/rsyslog.sh 2 minutes ago Up About a minute musing_brown
全コンテナー (実行中または停止) を一覧表示するには以下を実行します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES IS INFRA d65aecc325a4 ubi8/ubi /bin/bash 3 secs ago Exited (0) 5 secs ago peaceful_hopper false 74b1da000a11 rhel8/rsyslog rsyslog.sh 2 mins ago Up About a minute musing_brown false
実行されていないものの削除されていない (--rm
オプション) コンテナーが存在する場合には、コンテナーがあるので、再起動できます。
関連情報
-
podman-ps
の man ページ
5.5. コンテナーの起動
コンテナーを実行してから停止し、削除しない場合には、ローカルシステムに保存されて再び実行する準備ができます。podman start
コマンドを使用して、コンテナーを再実行できます。コンテナー ID または名前を使用して、コンテナーを指定できます。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
- 1 つ以上のコンテナーが停止されている。
手順
myubi
コンテナーを起動します。非対話モードで以下を行います。
$ podman start myubi
または、
podman start 1984555a2c27
を使用することもできます。対話モードで、
-a
(--attach
) および-t
(--interactive
) を使用して、コンテナーの bash シェルと連携します。$ podman start -a -i myubi
または、
podman start -a -i 1984555a2c27
を使用することができます。
exit
を実行してコンテナーを終了し、ホストに戻ります。[root@6ccffd0f6421 /]# exit
関連情報
-
podman-start
の man ページ
5.6. ホストからのコンテナーの検証
podman inspect
コマンドを使用して、既存のコンテナーのメタデータを JSON 形式で検証します。コンテナー ID または名前を使用して、コンテナーを指定できます。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
ID 64ad95327c74 で定義されるコンテナーを検査します。
すべてのメタデータを取得するには、以下のコマンドを実行します。
$ podman inspect 64ad95327c74 [ { "Id": "64ad95327c740ad9de468d551c50b6d906344027a0e645927256cd061049f681", "Created": "2021-03-02T11:23:54.591685515+01:00", "Path": "/bin/rsyslog.sh", "Args": [ "/bin/rsyslog.sh" ], "State": { "OciVersion": "1.0.2-dev", "Status": "running", ...
JSON ファイルから特定の項目 (例:
StartedAt
タイムスタンプ) を取得するには、以下を実行します。$ podman inspect --format='{{.State.StartedAt}}' 64ad95327c74 2021-03-02 11:23:54.945071961 +0100 CET
その情報は階層構造で保存されます。コンテナーの
StartedAt
タイムスタンプ (StartedAt
はState
の配下にある) を確認するには、--format
オプションとコンテナー ID または名前を使用します。
検証する他の項目の例には、以下が含まれます。
-
.path
: コンテナーとともに実行するコマンドを表示します。 -
.Args
: コマンドに指定する引数 -
.Config.ExposedPorts
: コンテナーから公開する TCP または UDP ポート -
.state.Pid
: コンテナーのプロセス ID を表示します。 -
.HostConfig.PortBindings
: コンテナーからホストへのポートマッピング
関連情報
-
podman-inspect
の man ページ
5.7. localhost のディレクトリーのコンテナーへのマウント
以下の手順では、コンテナーでホストの /dev/log
デバイスをマウントして、コンテナー内のログメッセージをホストシステムに公開する方法を説明します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
log_test
という名前のコンテナーを実行し、コンテナーにホストの/dev/log
デバイスをマウントします。# podman run --name="log_test" -v /dev/log:/dev/log --rm \ registry.redhat.io/ubi8/ubi logger "Testing logging to the host"
journalctl
ユーティリティーを使用してログを表示します。# journalctl -b | grep Testing Dec 09 16:55:00 localhost.localdomain root[14634]: Testing logging to the host
--rm
オプションは、終了時にコンテナーを削除します。
関連情報
-
podman-run
の man ページ
5.8. コンテナーのファイルシステムのマウント
podman mount
コマンドを使用して、ホストからアクセス可能な場所に、作業コンテナーの root ファイルシステムをマウントします。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
mysyslog
という名前のコンテナーを実行します。# podman run -d --name=mysyslog registry.redhat.io/rhel8/rsyslog
必要に応じて、すべてのコンテナーを一覧表示します。
# podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c56ef6a256f8 registry.redhat.io/rhel8/rsyslog:latest /bin/rsyslog.sh 20 minutes ago Up 20 minutes ago mysyslog
mysyslog
コンテナーをマウントします。# podman mount mysyslog /var/lib/containers/storage/overlay/990b5c6ddcdeed4bde7b245885ce4544c553d108310e2b797d7be46750894719/merged
ls
コマンドを使用して、マウントポイントのコンテンツを表示します。# ls /var/lib/containers/storage/overlay/990b5c6ddcdeed4bde7b245885ce4544c553d108310e2b797d7be46750894719/merged bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
OS バージョンを表示します。
# cat /var/lib/containers/storage/overlay/990b5c6ddcdeed4bde7b245885ce4544c553d108310e2b797d7be46750894719/merged/etc/os-release NAME="Red Hat Enterprise Linux" VERSION="8 (Ootpa)" ID="rhel" ID_LIKE="fedora" ...
関連情報
-
podman-mount
の man ページ
5.9. 静的 IP を使用したデーモンとしてのサービスの実行
以下の例は、rsyslog
サービスをバックグラウンドでデーモンプロセスとして実行します。--ip
オプションは、コンテナーのネットワークインターフェイスを特定の IP アドレスに設定します (例: 10.88.0.44)。その後、podman inspect
コマンドを実行して、IP アドレスを適切に設定できます。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
コンテナーのネットワークインターフェイスを IP アドレス 10.88.0.44 に設定します。
# podman run -d --ip=10.88.0.44 registry.access.redhat.com/rhel8/rsyslog efde5f0a8c723f70dd5cb5dc3d5039df3b962fae65575b08662e0d5b5f9fbe85
IP アドレスが正しく設定されていることを確認します。
# podman inspect efde5f0a8c723 | grep 10.88.0.44 "IPAddress": "10.88.0.44",
関連情報
-
podman-inspect
の man ページ -
podman-run
の man ページ
5.10. 実行中のコンテナー内でのコマンドの実行
podman exec
コマンドを使用して、実行中のコンテナーでコマンドを実行し、そのコンテナーを調べます。コンテナーアクティビティーを中断せずに実行中のコンテナーを調査できるので、podman run
コマンドの代わりに podman exec
コマンドを使用します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
- コンテナーが実行されている。
手順
myrsyslog
コンテナー内でrpm -qa
コマンドを実行し、インストールされているパッケージの一覧を表示します。$ podman exec -it myrsyslog rpm -qa tzdata-2020d-1.el8.noarch python3-pip-wheel-9.0.3-18.el8.noarch redhat-release-8.3-1.0.el8.x86_64 filesystem-3.8-3.el8.x86_64 ...
myrsyslog
コンテナーで/bin/bash
コマンドを実行します。$ podman exec -it myrsyslog /bin/bash
システムユーティリティーのセットが含まれる
procps-ng
パッケージをインストールします (例:ps
、top
、uptime
など)。# yum install procps-ng
コンテナーを検査します。
システムにある全プロセスを一覧表示するには、以下のコマンドを実行します。
# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 10:23 ? 00:00:01 /usr/sbin/rsyslogd -n root 8 0 0 11:07 pts/0 00:00:00 /bin/bash root 47 8 0 11:13 pts/0 00:00:00 ps -ef
ファイルシステムのディスク領域の使用量を表示するには、次のコマンドを実行します。
# df -h Filesystem Size Used Avail Use% Mounted on fuse-overlayfs 27G 7.1G 20G 27% / tmpfs 64M 0 64M 0% /dev tmpfs 269M 936K 268M 1% /etc/hosts shm 63M 0 63M 0% /dev/shm ...
システム情報を表示するには、以下のコマンドを実行します。
# uname -r 4.18.0-240.10.1.el8_3.x86_64
MB 単位でメモリーの空き容量を表示するには、次のコマンドを実行します。
# free --mega total used free shared buff/cache available Mem: 2818 615 1183 12 1020 1957 Swap: 3124 0 3124
関連情報
-
podman-exec
の man ページ
5.11. 2 つのコンテナー間でのファイルの共有
コンテナーが削除されても、ボリュームを使用してコンテナー内のデータを永続化できます。ボリュームは、複数のコンテナー間でのデータ共有に使用できます。ボリュームとは、ホストマシンに保存されているフォルダーです。ボリュームはコンテナーとホスト間で共有できます。
主な利点は以下のとおりです。
- ボリュームはコンテナー間で共有できます。
- ボリュームは、他と比べるとバックアップまたは移行が簡単です。
- ボリュームを使用するとコンテナーのサイズが増えません。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
ボリュームを作成します。
$ podman volume create hostvolume
ボリュームに関する情報を表示します。
$ podman volume inspect hostvolume [ { "name": "hostvolume", "labels": {}, "mountpoint": "/home/username/.local/share/containers/storage/volumes/hostvolume/_data", "driver": "local", "options": {}, "scope": "local" } ]
volumes ディレクトリーにボリュームが作成されることに注意してください。
$ mntPoint=$(podman volume inspect hostvolume --format {{.Mountpoint}})
で、変数へのマウントポイントパスを保存して操作を簡素化できます。sudo podman volume create hostvolume
を実行すると、マウントポイントが/var/lib/containers/storage/volumes/hostvolume/_data
に変わります。mntPoint
変数に保管されたパスを使用して、ディレクトリー内にテキストファイルを作成します。$ echo "Hello from host" >> $mntPoint/host.txt
mntPoint
変数で定義されたディレクトリー内の全ファイルを一覧表示します。$ ls $mntPoint/ host.txt
myubi1
という名前のコンテナーを実行し、ホストのボリューム名hostvolume
で定義したディレクトリーをコンテナーの/containervolume1
ディレクトリーにマッピングします。$ podman run -it --name myubi1 -v hostvolume:/containervolume1 registry.access.redhat.com/ubi8/ubi /bin/bash
mntPoint
変数 (-v $mntPoint:/containervolume1
) で定義したボリュームパスを使用する場合には、podman volume prune
コマンドを実行すると未使用のボリュームが削除され、データが失われる場合がある点に注意してください。常に-v hostvolume_name:/containervolume_name
を使用します。コンテナー上にある共有ボリューム内のファイルを一覧表示します。
# ls /containervolume1 host.txt
ホスト上で作成した
host.txt
ファイルが表示されます。/containervolume1
ディレクトリーにテキストファイルを作成します。# echo "Hello from container 1" >> /containervolume1/container1.txt
-
CTRL+p
およびCTRL+q
を使用してコンテナーからデタッチします。 ホスト上にある共有ボリューム内のファイルを一覧表示します。以下の 2 つのファイルが表示されるはずです。
$ ls $mntPoint container1.rxt host.txt
この時点で、コンテナーとホスト間でファイルを共有しています。2 つのコンテナー間でファイルを共有するには、
myubi2
という名前の別のコンテナーを実行します。myubi2
という名前のコンテナーを実行し、ホストのボリューム名hostvolume
で定義したディレクトリーをコンテナーの/containervolume2
ディレクトリーにマッピングします。$ podman run -it --name myubi2 -v hostvolume:/containervolume2 registry.access.redhat.com/ubi8/ubi /bin/bash
コンテナー上にある共有ボリューム内のファイルを一覧表示します。
# ls /containervolume2 container1.txt host.txt
ホストで作成した
host.txt
ファイルと、myubi1
コンテナー内に作成したcontainer1.txt
ファイルが表示されます。/containervolume2
ディレクトリーにテキストファイルを作成します。# echo "Hello from container 2" >> /containervolume2/container2.txt
-
CTRL+p
およびCTRL+q
を使用してコンテナーからデタッチします。 ホスト上にある共有ボリューム内のファイルを一覧表示します。以下の 3 つのファイルが表示されるはずです。
$ ls $mntPoint container1.rxt container2.txt host.txt
関連情報
-
podman-volume
の man ページ
5.12. コンテナーのエクスポートおよびインポート
podman export
コマンドを使用して、実行中のコンテナーのファイルシステムをローカルマシンの tarball にエクスポートできます。たとえば、頻繁に使用しない大規模なコンテナーがある場合、スナップショットを保存して後で復元できるようにする場合には、podman export
コマンドを使用して、実行中のコンテナーの現在のスナップショットを tarball にエクスポートできます。
podman import
コマンドを使用して tarball をインポートし、ファイルシステムイメージとして保存できます。これにより、このファイルシステムイメージを実行するか、他のイメージのレイヤーとして使用できます。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
registry.access.redhat.com/ubi8/ubi
イメージに基づいて、myubi
コンテナーを実行します。$ podman run -dt --name=myubi registry.access.redhat.com/8/ubi
必要に応じて、すべてのコンテナーを一覧表示します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a6a6d4896142 registry.access.redhat.com/8:latest /bin/bash 7 seconds ago Up 7 seconds ago myubi
myubi
コンテナーに割り当てます。$ podman attach myubi
testfile
という名前のファイルを作成します。[root@a6a6d4896142 /]# echo "hello" > testfile
-
CTRL+p
およびCTRL+q
を使用してコンテナーからデタッチします。 ローカルマシンで、
myubi
のファイルシステムをmyubi-container.tar
としてエクスポートします。$ podman export -o myubi.tar a6a6d4896142
必要に応じて、現在のディレクトリーの内容を一覧表示します。
$ ls -l -rw-r--r--. 1 user user 210885120 Apr 6 10:50 myubi-container.tar ...
必要に応じて、
myubi-container
ディレクトリーを作成し、myubi-container.tar
アーカイブからすべてのファイルを展開します。ツリー形式でmyubi-directory
の内容を一覧表示します。$ mkdir myubi-container $ tar -xf myubi-container.tar -C myubi-container $ tree -L 1 myubi-container ├── bin -> usr/bin ├── boot ├── dev ├── etc ├── home ├── lib -> usr/lib ├── lib64 -> usr/lib64 ├── lost+found ├── media ├── mnt ├── opt ├── proc ├── root ├── run ├── sbin -> usr/sbin ├── srv ├── sys ├── testfile ├── tmp ├── usr └── var 20 directories, 1 file
myubi-container.tar
にコンテナーのファイルシステムが含まれていることを確認できます。myubi.tar
をインポートして、ファイルシステムイメージとして保存します。$ podman import myubi.tar myubi-imported Getting image source signatures Copying blob 277cab30fe96 done Copying config c296689a17 done Writing manifest to image destination Storing signatures c296689a17da2f33bf9d16071911636d7ce4d63f329741db679c3f41537e7cbf
すべてのイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/myubi-imported latest c296689a17da 51 seconds ago 211 MB
testfile
ファイルの内容を表示します。$ podman run -it --name=myubi-imported docker.io/library/myubi-imported cat testfile hello
関連情報
-
podman-export
man ページ -
podman-import
man ページ
5.13. コンテナーの停止
実行中のコンテナーを停止するには、podman stop
コマンドを使用します。コンテナー ID または名前を使用して、コンテナーを指定できます。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
- 1 つ以上のコンテナーが実行中である。
手順
myubi
コンテナーを停止します。コンテナー名を使用する場合
$ podman stop myubi
コンテナー ID を使用する場合
$ podman stop 1984555a2c27
端末セッションに接続されている、実行中のコンテナーを停止するには、コンテナーで exit
コマンドを入力してください。
podman stop
コマンドは、SIGTERM シグナルを送信し、実行中のコンテナーを終了します。定義された期間 (デフォルトでは 10 秒) 後にコンテナーが停止しない場合は、Podman は SIGKILL シグナルを送信します。
また、podman kill
コマンドを使用して、コンテナーを強制終了 (SIGKILL) するか、別のシグナルをコンテナーに送信することもできます。以下は、SIGHUP シグナルをコンテナーに送信する例です (アプリケーションでサポートされていると、SIGHUP により、アプリケーションが設定ファイルを再読み取りします)。
# *podman kill --signal="SIGHUP" 74b1da000a11* 74b1da000a114015886c557deec8bed9dfb80c888097aa83f30ca4074ff55fb2
関連情報
-
podman-stop
の man ページ -
podman-kill
の man ページ
5.14. コンテナーの削除
podman rm
コマンドを使用して、コンテナーを削除します。コンテナー ID または名前でコンテナーを指定できます。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
- 1 つ以上のコンテナーが停止されている。
手順
全コンテナー (実行中または停止) を一覧表示するには以下を実行します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES IS INFRA d65aecc325a4 ubi8/ubi /bin/bash 3 secs ago Exited (0) 5 secs ago peaceful_hopper false 74b1da000a11 rhel8/rsyslog rsyslog.sh 2 mins ago Up About a minute musing_brown false
コンテナーを削除します。
peaceful_hopper
を削除するには以下を実行します。$ podman rm peaceful_hopper
peaceful_hopper
コンテナーが終了ステータスであったことに注意してください。コンテナーが停止されているので、即座に削除できます。musing_brown
コンテナーを削除するには、まずコンテナーを停止してから削除します。$ podman stop musing_brown $ podman rm musing_brown
- 注記
複数のコンテナーを削除するには、以下を実行します。
$ podman rm clever_yonath furious_shockley
ローカルシステムからすべてのコンテナーを削除するには、以下のコマンドを実行します。
$ podman rm -a
関連情報
-
podman-rm
の man ページ
5.15. runc コンテナーランタイム
runc コンテナーランタイムは、Open Container Initiative (OCI) コンテナーランタイム仕様の軽量で移植可能な実装です。runc ランタイムは多くの低レベルコードを Docker と共有しますが、Docker プラットフォームのコンポーネントには依存しません。runc は Linux 名前空間とライブ移行をサポートしており、移植可能なパフォーマンスプロファイルがあります。
また、SELinux、コントロールグループ (cgroups)、seccomp などの Linux セキュリティー機能に完全に対応します。runc でイメージをビルドして実行したり、runc で OCI 互換イメージを実行したりできます。
5.16. crun コンテナーランタイム
crun は、C 言語で書かれた高速および低メモリーフットプリントの OCI コンテナーランタイムで、crun バイナリーは runc バイナリーの最大 1/50 のサイズで、2 倍の速度です。crun を使用して、コンテナーの実行時に最小限のプロセス数を設定することもできます。crun ランタイムは OCI フックもサポートしています。
crun の追加機能には、以下が含まれます。
- ルートレスコンテナーのグループによるファイルの共有
- OCI フックの標準出力および標準エラーの制御
- cgroup v2 での古いバージョンの systemd の実行
- 他のプログラムによって使用される C ライブラリー
- 拡張性
- 移植性
5.17. runc および crun でのコンテナーの実行
runc または crun では、コンテナーはバンドルを使用して設定されます。コンテナーのバンドルは、config.json
という名前の仕様ファイルと、root ファイルシステムを含むディレクトリーです。root ファイルシステムには、コンテナーの内容が含まれます。
<runtime>
は crun または runc です。
手順
registry.access.redhat.com/ubi8/ubi
コンテナーイメージをプルします。# podman pull registry.access.redhat.com/ubi8/ubi
registry.access.redhat.com/ubi8/ubi
イメージをrhel.tar
アーカイブにエクスポートします。# podman export $(podman create registry.access.redhat.com/ubi8/ubi) > rhel.tar
bundle/rootfs
ディレクトリーを作成します。# mkdir -p bundle/rootfs
rhel.tar
アーカイブをbundle/rootfs
ディレクトリーに展開します。# tar -C bundle/rootfs -xf rhel.tar
バンドル用に
config.json
という名前の新規仕様ファイルを作成します。# <runtime> spec -b bundle
-
-b
オプションは、バンドルのディレクトリーを指定します。デフォルト値は現在のディレクトリーです。
-
オプション:設定を変更します。
# vi bundle/config.json
バンドル用に
myubi
という名前のコンテナーのインスタンスを作成します。# <runtime> create -b bundle/ myubi
myubi
コンテナーを起動します。# <runtime> start myubi
コンテナーインスタンスの名前は、ホストで一意のものである必要があります。コンテナーの新規インスタンスを起動するには、# <runtime> start <container_name>
を実行します。
検証
<runtime>
によって起動したコンテナーを一覧表示します。# <runtime> list ID PID STATUS BUNDLE CREATED OWNER myubi 0 stopped /root/bundle 2021-09-14T09:52:26.659714605Z root
関連情報
-
crun
の man ページ -
runc
の man ページ - An introduction to crun, a fast and low-memory footprint container runtime
5.18. コンテナーランタイムの一時的な変更
podman run
コマンドに --runtime
オプションを指定して使用して、コンテナーのランタイムを変更できます。
<runtime>
は crun または runc です。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
registry.access.redhat.com/ubi8/ubi
コンテナーイメージをプルします。$ podman pull registry.access.redhat.com/ubi8/ubi
--runtime
オプションを使用してコンテナーランタイムを変更します。$ podman run --name=myubi -dt --runtime=<runtime> ubi8 bashe4654eb4df12ac031f1d0f2657dc4ae6ff8eb0085bf114623b66cc664072e69b
オプション:すべてのイメージを一覧表示します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e4654eb4df12 registry.access.redhat.com/ubi8:latest bash 4 seconds ago Up 4 seconds ago myubi
検証
OCI ランタイムが myubi コンテナーで
<runtime>
に設定されていることを確認します。$ podman inspect myubi --format "{{.OCIRuntime}}" <runtime>
5.19. コンテナーランタイムの永続的な変更
コンテナーランタイムおよびそのオプションを、/etc/containers/containers.conf
設定ファイル (root ユーザーとして) または $HOME/.config/containers/containers.conf
設定ファイル (非 root ユーザーとして) で設定できます。
<runtime>
は crun または runc ランタイムです。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
/etc/containers/containers.conf
ファイルでランタイムを変更します。# vim /etc/containers/containers.conf [engine] runtime = "<runtime>"
myubi という名前のコンテナーを実行します。
# podman run --name=myubi -dt ubi8 bash Resolved "ubi8" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf) Trying to pull registry.access.redhat.com/ubi8:latest… ... Storing signatures
検証
OCI ランタイムが
myubi
コンテナーで<runtime>
に設定されていることを確認します。# podman inspect myubi --format "{{.OCIRuntime}}" <runtime>
関連情報
- An introduction to crun, a fast and low-memory footprint container runtime
-
containers.conf
の man ページ
5.20. コンテナーの SELinux ポリシーの作成
コンテナーの SELinux ポリシーを生成するには、UDICA ツールを使用します。詳細は udica の SELinux ポリシージェネレーターの概要 を参照してください。
第6章 UBI コンテナーへのソフトウェアの追加
UBI (Red Hat Universal Base Images) は、RHEL コンテンツのサブセットから構築されます。UBI は、UBI でインストールするために自由に利用可能な RHEL パッケージのサブセットも提供します。実行中のコンテナーにソフトウェアを追加または更新するには、RPM パッケージおよび更新を含む yum リポジトリーを使用します。UBI は、Python、Perl、Node.js、Ruby などの事前にビルドされた言語ランタイムコンテナーイメージを提供します。
UBI コンテナーを実行するパッケージを UBI リポジトリーから追加するには、以下を行います。
-
UBI init および UBI 標準イメージでは、
yum
コマンドを使用します。 -
UBI の最小イメージでは、
microdnf
コマンドを使用します。
実行中のコンテナーでソフトウェアパッケージを直接インストールして作業すると、パッケージを一時的に追加します。この変更はコンテナーイメージに保存されません。パッケージの変更を永続化するには、Buildah を使用した Containerfile からのイメージのビルド セクションを参照してください。
UBI コンテナーにソフトウェアを追加する場合は、サブスクライブしている RHEL ホスト、またはサブスクライブしていない (または非 RHEL) システムで UBI を更新する手順が異なります。
6.1. UBI init イメージの使用
この手順では、Containerfile
を使用してコンテナーを構築する方法を紹介します。この Containerfile は、コンテナーがホストシステムで実行されている場合に Web サーバー (httpd
) をインストールして、systemd サービス (/sbin/init
) により Web サーバーが自動的に起動されるように設定します。podman build
コマンドは、1 つ以上の Containerfiles
および指定されたビルドコンテキストディレクトリー内の命令を使用してイメージをビルドします。コンテキストディレクトリーは、アーカイブ、Git リポジトリー、または Containerfile
の URL として指定できます。コンテキストディレクトリーが指定されていない場合、現在の作業ディレクトリーはビルドコンテキストと見なされ、Containerfile
が含まれている必要があります。--file
オプションで Containerfile
を指定することもできます。
手順
新しいディレクトリーに以下の内容を含む
Containerfile
を作成します。FROM registry.access.redhat.com/ubi8/ubi-init RUN yum -y install httpd; yum clean all; systemctl enable httpd; RUN echo "Successful Web Server Test" > /var/www/html/index.html RUN mkdir /etc/systemd/system/httpd.service.d/; echo -e '[Service]\nRestart=always' > /etc/systemd/system/httpd.service.d/httpd.conf EXPOSE 80 CMD [ "/sbin/init" ]
Containerfile
は、httpd
パッケージをインストールし、システムの起動時 (つまりコンテナーが起動した時) にhttpd
サービスが開始するようにし、テストファイル (index.html
) を作成し、Web サーバーをホスト (ポート 80) に公開し、コンテナーが起動すると systemd init サービス (/sbin/init
) を開始します。コンテナーをビルドします。
# podman build --format=docker -t mysysd .
オプション:お使いのシステムで systemd を使用してコンテナーを実行し、SELinux を有効にする場合は、
container_manage_cgroup
ブール値変数を設定する必要があります。# setsebool -P container_manage_cgroup 1
mysysd_run
という名前のコンテナーを実行します。# podman run -d --name=mysysd_run -p 80:80 mysysd
mysysd
イメージがmysysd_run
コンテナーをデーモンプロセスとして実行し、コンテナーのポート 80 がホストシステムのポート 80 に公開されます。- 注記
ルートレスモードでは、1024 以上のホストのポート番号を選択する必要があります。以下に例を示します。
$ podman run -d --name=mysysd -p 8081:80 mysysd
1024 未満のポート番号を使用するには、
net.ipv4.ip_unprivileged_port_start
変数を変更する必要があります。# sysctl net.ipv4.ip_unprivileged_port_start=80
コンテナーが実行していることを確認します。
# podman ps a282b0c2ad3d localhost/mysysd:latest /sbin/init 15 seconds ago Up 14 seconds ago 0.0.0.0:80->80/tcp mysysd_run
Web サーバーをテストします。
# curl localhost/index.html Successful Web Server Test
関連情報
6.2. UBI マイクロイメージの使用
この手順では、Buildah ツールを使用して ubi-micro
コンテナーイメージを構築する方法を説明します。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
registry.access.redhat.com/ubi8/ubi-micro
イメージをプルしてビルドします。# microcontainer=$(buildah from registry.access.redhat.com/ubi8/ubi-micro)
作業中のコンテナーの root ファイルシステムをマウントします。
# micromount=$(buildah mount $microcontainer)
httpd
サービスをmicromount
ディレクトリーにインストールします。# yum install \ --installroot $micromount \ --releasever 8 \ --setopt install_weak_deps=false \ --nodocs -y \ httpd # yum clean all \ --installroot $micromount
作業コンテナーで root ファイルシステムをアンマウントします。
# buildah umount $microcontainer
作業コンテナーから
ubi-micro-httpd
イメージを作成します。# buildah commit $microcontainer ubi-micro-httpd
検証手順
ubi-micro-httpd
イメージの詳細を表示します。# podman images ubi-micro-httpd localhost/ubi-micro-httpd latest 7c557e7fbe9f 22 minutes ago 151 MB
6.3. UBI コンテナーへのソフトウェアの追加 (サブスクライブされたホスト)
登録およびサブスクライブされた RHEL ホストで UBI コンテナーを実行している場合は、RHEL Base リポジトリーおよび AppStream リポジトリーが、標準の UBI コンテナーとすべての UBI リポジトリーで有効になります。
6.4. 標準の UBI コンテナーへのソフトウェアの追加
標準の UBI コンテナー内にソフトウェアを追加するには、UBI 以外の yum リポジトリーを無効にして、ビルドするコンテナーが再配布されるようにします。
手順
registry.access.redhat.com/ubi8/ubi
イメージをプルして実行します。$ podman run -it --name myubi registry.access.redhat.com/ubi8/ubi
myubi
コンテナーにパッケージを追加します。UBI リポジトリーにあるパッケージを追加するには、UBI リポジトリー以外の yum リポジトリーをすべて無効にします。たとえば、
bzip2
パッケージを追加するには、次のコマンドを実行します。# yum install --disablerepo= --enablerepo=ubi-8-appstream-rpms --enablerepo=ubi-8-baseos-rpms bzip2*
UBI リポジトリーにないパッケージを追加するには、リポジトリーを無効にしないでください。たとえば、
zsh
パッケージを追加するには、次のコマンドを実行します。# yum install zsh
別のホストリポジトリーにあるパッケージを追加するには、必要なリポジトリーを明示的に有効にします。たとえば、
codeready-builder-for-rhel-8-x86_64-rpms
リポジトリーからpython38-devel
パッケージをインストールするには、以下のコマンドを実行します。# yum install --enablerepo=codeready-builder-for-rhel-8-x86_64-rpms python38-devel
検証手順
コンテナー内で有効なリポジトリーの一覧を表示します。
# yum repolist
- 必要なリポジトリーが一覧表示されていることを確認します。
インストール済みパッケージの一覧を表示します。
# rpm -qa
- 必要なパッケージが一覧表示されていることを確認します。
Red Hat UBI リポジトリーに含まれていない Red Hat パッケージをインストールすると、サブスクライブしている RHEL システム以外でコンテナーを配布する機能が限定される可能性があります。
6.5. 最小 UBI コンテナーへのソフトウェアの追加
UBI yum リポジトリーは、デフォルトで UBI 最小イメージで有効になります。
手順
registry.access.redhat.com/ubi8/ubi-minimal
イメージをプルして実行します。$ podman run -it --name myubimin registry.access.redhat.com/ubi8/ubi-minimal
myubimin
コンテナーにパッケージを追加します。UBI リポジトリーにあるパッケージを追加するには、リポジトリーを無効にしないでください。たとえば、
bzip2
パッケージを追加するには、次のコマンドを実行します。# microdnf install bzip2
別のホストリポジトリーにあるパッケージを追加するには、必要なリポジトリーを明示的に有効にします。たとえば、
codeready-builder-for-rhel-8-x86_64-rpms
リポジトリーからpython38-devel
パッケージをインストールするには、以下のコマンドを実行します。# microdnf install --enablerepo=codeready-builder-for-rhel-8-x86_64-rpms python38-devel
検証手順
コンテナー内で有効なリポジトリーの一覧を表示します。
# microdnf repolist
- 必要なリポジトリーが一覧表示されていることを確認します。
インストール済みパッケージの一覧を表示します。
# rpm -qa
- 必要なパッケージが一覧表示されていることを確認します。
Red Hat UBI リポジトリーに含まれていない Red Hat パッケージをインストールすると、サブスクライブしている RHEL システム以外でコンテナーを配布する機能が限定される可能性があります。
6.6. UBI コンテナーへのソフトウェアの追加 (サブスクライブしていないホスト)
サブスクライブしていない RHEL システムにソフトウェアパッケージを追加するときに、リポジトリーを無効にする必要はありません。
手順
UBI 標準または UBI init イメージに基づいて、実行中のコンテナーにパッケージを追加します。リポジトリーを無効にしないでください。
podman run
コマンドを使用してコンテナーを実行し、コンテナー内でyum install
コマンドを使用します。たとえば、
bzip2
パッケージを UBI 標準ベースのコンテナーに追加するには、次のコマンドを実行します。$ podman run -it --name myubi registry.access.redhat.com/ubi8/ubi # yum install bzip2
たとえば、
bzip2
パッケージを UBI init ベースのコンテナーに追加するには、次のコマンドを実行します。$ podman run -it --name myubimin registry.access.redhat.com/ubi8/ubi-minimal # microdnf install bzip2
検証手順
有効なリポジトリーを一覧表示します。
UBI 標準イメージまたは UBI init イメージに基づいて、コンテナー内で有効なリポジトリーをすべて一覧表示するには、次のコマンドを実行します。
# yum repolist
UBI の最小コンテナーに基づいて、コンテナー内で有効なリポジトリーを一覧表示するには、以下を実行します。
# microdnf repolist
- 必要なリポジトリーが一覧表示されていることを確認します。
インストール済みパッケージの一覧を表示します。
# rpm -qa
- 必要なパッケージが一覧表示されていることを確認します。
6.7. UBI ベースのイメージの構築
Buildah ユーティリティーを使用して、Containerfile
から UBI ベースの Web サーバーコンテナーを作成できます。UBI 以外の yum リポジトリーをすべて無効にして、イメージに再配布できる Red Hat ソフトウェアのみが含まれていることを確認する必要があります。
For UBI minimal images, use `microdnf` instead of `{PackageManagerCommand}`: [literal,subs="+quotes,attributes",options="nowrap",role=white-space-pre]
`RUN microdnf update -y && rm -rf /var/cache/yum` and `RUN microdnf install httpd -y && microdnf clean all` commands.
手順
Containerfile
を作成します。FROM registry.access.redhat.com/ubi8/ubi USER root LABEL maintainer="John Doe" # Update image RUN yum update --disablerepo=* --enablerepo=ubi-8-appstream-rpms --enablerepo=ubi-8-baseos-rpms -y && rm -rf /var/cache/yum RUN yum install --disablerepo=* --enablerepo=ubi-8-appstream-rpms --enablerepo=ubi-8-baseos-rpms httpd -y && rm -rf /var/cache/yum # Add default Web page and expose port RUN echo "The Web Server is Running" > /var/www/html/index.html EXPOSE 80 # Start the service CMD ["-D", "FOREGROUND"] ENTRYPOINT ["/usr/sbin/httpd"]
コンテナーイメージをビルドします。
# buildah bud -t johndoe/webserver . STEP 1: FROM registry.access.redhat.com/ubi8/ubi:latest STEP 2: USER root STEP 3: LABEL maintainer="John Doe" STEP 4: RUN yum update --disablerepo=* --enablerepo=ubi-8-appstream-rpms --enablerepo=ubi-8-baseos-rpms -y ... Writing manifest to image destination Storing signatures --> f9874f27050 f9874f270500c255b950e751e53d37c6f8f6dba13425d42f30c2a8ef26b769f2
検証手順
Web サーバーを実行します。
# podman run -d --name=myweb -p 80:80 johndoe/webserver bbe98c71d18720d966e4567949888dc4fb86eec7d304e785d5177168a5965f64
Web サーバーをテストします。
# curl http://localhost/index.html The Web Server is Running
6.8. Application Stream ランタイムイメージの使用
Application Streams に基づくランタイムイメージは、コンテナービルドのベースとして使用できる一連のコンテナーイメージを提供します。
サポートされるランタイムイメージは Python、Ruby、s2-core、s2i-base、.NET Core、PHP です。ランタイムイメージは Red Hat Container Catalog で利用できます。
- 注記
- このような UBI イメージコンテナーには、従来のイメージと同じ基本ソフトウェアが含まれているため、詳細は Using Red Hat Software Collections Container Images を参照してください。
6.9. UBI コンテナーイメージソースコードの取得
すべての Red Hat UBI ベースのイメージのソースコードは、ダウンロード可能なコンテナーイメージの形で入手できます。コンテナーとしてパッケージ化されているにもかかわらず、ソースコンテナーイメージを実行できません。システムに Red Hat ソースコンテナーイメージをインストールするには、podman pull
コマンドではなく、skopeo
コマンドを使用します。
ソースコンテナーイメージは、それらが表すバイナリーコンテナーに基づいて名前が付けられます。たとえば、ある標準的な RHEL UBI 8 コンテナーでは、registry.access.redhat.com/ubi8:8.1-397
に -source
を追加してソースコンテナーイメージを取得します (registry.access.redhat.com/ubi8:8.1-397-source
)。
手順
skopeo copy
コマンドを使用して、ソースコンテナーイメージをローカルディレクトリーにコピーします。$ skopeo copy \ docker://registry.access.redhat.com/ubi8:8.1-397-source \ dir:$HOME/TEST ... Copying blob 477bc8106765 done Copying blob c438818481d3 done ... Writing manifest to image destination Storing signatures
skopeo inspect
コマンドを使用して、ソースコンテナーイメージを検査します。$ skopeo inspect dir:$HOME/TEST { "Digest": "sha256:7ab721ef3305271bbb629a6db065c59bbeb87bc53e7cbf88e2953a1217ba7322", "RepoTags": [], "Created": "2020-02-11T12:14:18.612461174Z", "DockerVersion": "", "Labels": null, "Architecture": "amd64", "Os": "linux", "Layers": [ "sha256:1ae73d938ab9f11718d0f6a4148eb07d38ac1c0a70b1d03e751de8bf3c2c87fa", "sha256:9fe966885cb8712c47efe5ecc2eaa0797a0d5ffb8b119c4bd4b400cc9e255421", "sha256:61b2527a4b836a4efbb82dfd449c0556c0f769570a6c02e112f88f8bbcd90166", ... "sha256:cc56c782b513e2bdd2cc2af77b69e13df4ab624ddb856c4d086206b46b9b9e5f", "sha256:dcf9396fdada4e6c1ce667b306b7f08a83c9e6b39d0955c481b8ea5b2a465b32", "sha256:feb6d2ae252402ea6a6fca8a158a7d32c7e4572db0e6e5a5eab15d4e0777951e" ], "Env": null }
すべてのコンテンツを展開します。
$ cd $HOME/TEST $ for f in $(ls); do tar xvf $f; done
結果を確認します。
$ find blobs/ rpm_dir/ blobs/ blobs/sha256 blobs/sha256/10914f1fff060ce31388f5ab963871870535aaaa551629f5ad182384d60fdf82 rpm_dir/ rpm_dir/gzip-1.9-4.el8.src.rpm
結果が正しい場合は、イメージを使用できる状態になります。
コンテナーイメージがリリースされてから、関連するソースコンテナーが利用可能になるまでに数時間かかる場合があります。
関連情報
-
skopeo-copy
の man ページ -
skopeo-inspect
の man ページ
第7章 Pod の使用
コンテナーは、Podman、Skopeo、および Buildah のコンテナーツールで管理できる最小単位です。Podman Pod は、1 つ以上のコンテナーのグループです。Pod の概念は Kubernetes により導入されました。Podman Pod は Kubernetes 定義に似ています。Pod は、OpenShift または Kubernetes 環境で作成、デプロイ、管理できる最小のコンピュート単位です。すべての Podman Pod には infra コンテナーが含まれます。このコンテナーは Pod に関連付けられた namespace を保持し、Podman が他のコンテナーを Pod に接続できるようにします。これにより、Pod を稼働したまま、Pod 内のコンテナーの起動や停止が可能になります。デフォルトの infra コンテナーは、registry.access.redhat.com/ubi8/pause
イメージ上にあります。
7.1. Pod の作成
以下の手順では、コンテナーが 1 つ含まれる Pod を作成する方法を説明します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
手順
空の Pod を作成します。
$ podman pod create --name mypod 223df6b390b4ea87a090a4b5207f7b9b003187a6960bd37631ae9bc12c433aff The pod is in the initial state Created.
Pod の初期状態は Created です。
必要に応じて、すべての Pod を一覧表示します。
$ podman pod ps POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID 223df6b390b4 mypod Created Less than a second ago 1 3afdcd93de3e
Pod にはコンテナーが 1 つあることに注意してください。
必要に応じて、関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD 3afdcd93de3e registry.access.redhat.com/ubi8/pause Less than a second ago Created 223df6b390b4-infra 223df6b390b4
podman ps
コマンドからの Pod ID とpodman pod ps
コマンドの Pod ID が一致することが確認できます。デフォルトの infra コンテナーはregistry.access.redhat.com/ubi8/pause
イメージをベースとしています。mypod
という名前の既存 Pod 内で、名前がmyubi
のコンテナーを実行します。$ podman run -dt --name myubi --pod mypod registry.access.redhat.com/ubi8/ubi /bin/bash 5df5c48fea87860cf75822ceab8370548b04c78be9fc156570949013863ccf71
必要に応じて、すべての Pod を一覧表示します。
$ podman pod ps POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID 223df6b390b4 mypod Running Less than a second ago 2 3afdcd93de3e
Pod にはコンテナーが 2 つあることが分かります。
必要に応じて、関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD 5df5c48fea87 registry.access.redhat.com/ubi8/ubi:latest /bin/bash Less than a second ago Up Less than a second ago myubi 223df6b390b4 3afdcd93de3e registry.access.redhat.com/ubi8/pause Less than a second ago Up Less than a second ago 223df6b390b4-infra 223df6b390b4
関連情報
-
podman-pod-create
man ページ - Podman: Managing pods and containers in a local container runtime
7.2. Pod 情報の表示
この手順では、Pod 情報を表示する方法を説明します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
- Pod が作成されている。詳細は、Pod の作成 を参照してください。
手順
Pod で実行されているアクティブなプロセスを表示します。
Pod 内のコンテナーで実行中のプロセスを表示するには、以下を入力します。
$ podman pod top mypod USER PID PPID %CPU ELAPSED TTY TIME COMMAND 0 1 0 0.000 24.077433518s ? 0s /pause root 1 0 0.000 24.078146025s pts/0 0s /bin/bash
1 つ以上の Pod のコンテナーにおけるリソース使用状況の統計をライブストリームで表示するには、以下を入力します。
$ podman pod stats -a --no-stream ID NAME CPU % MEM USAGE / LIMIT MEM % NET IO BLOCK IO PIDS a9f807ffaacd frosty_hodgkin -- 3.092MB / 16.7GB 0.02% -- / -- -- / -- 2 3b33001239ee sleepy_stallman -- -- / -- -- -- / -- -- / -- --
Pod に関する情報を表示するには、以下を入力します。
$ podman pod inspect mypod { "Id": "db99446fa9c6d10b973d1ce55a42a6850357e0cd447d9bac5627bb2516b5b19a", "Name": "mypod", "Created": "2020-09-08T10:35:07.536541534+02:00", "CreateCommand": [ "podman", "pod", "create", "--name", "mypod" ], "State": "Running", "Hostname": "mypod", "CreateCgroup": false, "CgroupParent": "/libpod_parent", "CgroupPath": "/libpod_parent/db99446fa9c6d10b973d1ce55a42a6850357e0cd447d9bac5627bb2516b5b19a", "CreateInfra": false, "InfraContainerID": "891c54f70783dcad596d888040700d93f3ead01921894bc19c10b0a03c738ff7", "SharedNamespaces": [ "uts", "ipc", "net" ], "NumContainers": 2, "Containers": [ { "Id": "891c54f70783dcad596d888040700d93f3ead01921894bc19c10b0a03c738ff7", "Name": "db99446fa9c6-infra", "State": "running" }, { "Id": "effc5bbcfe505b522e3bf8fbb5705a39f94a455a66fd81e542bcc27d39727d2d", "Name": "myubi", "State": "running" } ] }
Pod 内のコンテナーについての情報を確認できます。
関連情報
-
podman pod top
man ページ -
podman-pod-stats
man ページ -
podman-pod-inspect
man ページ
7.3. Pod の停止
1 つ以上の Pod を停止するには、podman pod stop
コマンドを使用します。
前提条件
Podman ツールがインストールされている。
# yum module install -y container-tools
- Pod が作成されている。詳細は、Pod の作成 を参照してください。
手順
Pod
mypod
を停止します。$ podman pod stop mypod
必要に応じて、関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME 5df5c48fea87 registry.redhat.io/ubi8/ubi:latest /bin/bash About a minute ago Exited (0) 7 seconds ago myubi 223df6b390b4 mypod 3afdcd93de3e registry.access.redhat.com/8/pause About a minute ago Exited (0) 7 seconds ago 8a4e6527ac9d-infra 223df6b390b4 mypod
Pod
mypod
およびコンテナーmyubi
のステータスが Exited であることが分かります。
関連情報
-
podman-pod-stop
man ページ
7.4. Pod の削除
停止されている Pod またはコンテナーを削除するには、podman pod rm
コマンドを使用します。
前提条件
手順
以下を入力して、Pod
mypod
を削除します。$ podman pod rm mypod 223df6b390b4ea87a090a4b5207f7b9b003187a6960bd37631ae9bc12c433aff
Pod を削除すると、その Pod 中の全コンテナーが自動的に削除されることに注意してください。
必要に応じて、すべてのコンテナーおよび Pod が削除されたことを確認します。
$ podman ps $ podman pod ps
関連情報
-
podman-pod-rm
man ページ
第8章 コンテナーネットワークの管理
本章では、コンテナー間の通信方法について説明します。
8.1. コンテナーネットワークのリストアップ
Podman には、ルートレスルートフルという 2 つのネットワークの動作があります。
- ルートレスネットワーク: ネットワークは自動的に設定され、コンテナーには IP アドレスがありません。
- ルートフルネットワーク: コンテナーには IP アドレスがあります。
手順
ルートユーザーで全ネットワークを一覧表示します。
# podman network ls NETWORK ID NAME VERSION PLUGINS 2f259bab93aa podman 0.4.0 bridge,portmap,firewall,tuning
- デフォルトでは、Podman はブリッジネットワークを提供します。
- ルートレスユーザーのネットワーク一覧は、ルートフルユーザーと同じです。
関連情報
-
podman-network-ls
の man ページ
8.2. ネットワークの検査
podman network ls
コマンドでリストアップされた特定のネットワークの IP 範囲、有効なプラグイン、ネットワークのタイプなどを表示します。
手順
デフォルトの
Podman
ネットワークを検査します。$ podman network inspect podman [ { "cniVersion": "0.4.0", "name": "podman", "plugins": [ { "bridge": "cni-podman0", "hairpinMode": true, "ipMasq": true, "ipam": { "ranges": [ [ { "gateway": "10.88.0.1", "subnet": "10.88.0.0/16" } ] ], "routes": [ { "dst": "0.0.0.0/0" } ], "type": "host-local" }, "isGateway": true, "type": "bridge" }, { "capabilities": { "portMappings": true }, "type": "portmap" }, { "type": "firewall" }, { "type": "tuning" } ] } ]
IP 範囲、有効なプラグイン、ネットワークの種類など、ネットワークの設定を確認できます。
関連情報
-
podman-network-inspect
の man ページ
8.3. ネットワークの作成
新しいネットワークを作成するには、Podman network create
コマンドを使用します。
デフォルトでは、Podman は外部ネットワークを作成します。podman network create --internal
コマンドで内部ネットワークを作成することができます。内部ネットワーク内のコンテナーは、ホスト上の他のコンテナーと通信できますが、ホスト外のネットワークに接続したり、ホストから到達したりすることはできません。
手順
mynet
という名前の外部ネットワークを作成します。# podman network create mynet /etc/cni/net.d/mynet.conflist
検証
すべてのネットワークをリストアップします。
# podman network ls NETWORK ID NAME VERSION PLUGINS 2f259bab93aa podman 0.4.0 bridge,portmap,firewall,tuning 11c844f95e28 mynet 0.4.0 bridge,portmap,firewall,tuning,dnsname
作成された
mynet
ネットワークとデフォルトのPodman
ネットワークが表示されます。
Podman 4.0 以降、podman network create
コマンドを使用して新しい外部ネットワークを作成すると、デフォルトで DNS プラグインが有効になります。
関連情報
-
podman-network-create
man ページ
8.4. コンテナーのネットワークへの接続
コンテナーをネットワークに接続するには、Podman network connect
コマンドを使用します。
前提条件
-
podman network create
コマンドでネットワークが作成さている。 - コンテナーが作成されている。
手順
mycontainer
という名前のコンテナーをmynet
という名前のネットワークに接続します。# podman network connect mynet mycontainer
検証
mycontainer
がmynet
ネットワークに接続されていることを確認します。# podman inspect --format='{{.NetworkSettings.Networks}}' mycontainer map[podman:0xc00042ab40 mynet:0xc00042ac60]
mycontainer
がmynet
とpodman
のネットワークに接続されていることがわかります。
関連情報
-
podman-network-connect
の man ページ
8.5. コンテナーのネットワークからの切断
コンテナーをネットワークから切断するには、podman network disconnect
コマンドを使用します。
前提条件
-
podman network create
コマンドでネットワークが作成さている。 - コンテナーがネットワークに接続されている。
手順
mycontainer
というコンテナーをmynet
というネットワークから切り離します。# podman network disconnect mynet mycontainer
検証
mycontainer
がmynet
ネットワークから切断されていることを確認します。# podman inspect --format='{{.NetworkSettings.Networks}}' mycontainer map[podman:0xc000537440]
mycontainer
がmynet
ネットワークから切断され、mycontainer
がデフォルトのPodman
ネットワークにのみ接続されていることがわかります。
関連情報
-
podman-network-disconnect
の man ページ
8.6. ネットワークの削除
指定したネットワークを削除するには、podman network rm
コマンドを使用します。
手順
すべてのネットワークをリストアップします。
# podman network ls NETWORK ID NAME VERSION PLUGINS 2f259bab93aa podman 0.4.0 bridge,portmap,firewall,tuning 11c844f95e28 mynet 0.4.0 bridge,portmap,firewall,tuning,dnsname
mynet
ネットワークを削除します。# podman network rm mynet mynet
削除されたネットワークに関連するコンテナーがある場合は、Podman network rm -f
コマンドを使用してコンテナーと Pod を削除する必要があります。
検証
mynet
ネットワークが削除されたかどうかを確認します。# podman network ls NETWORK ID NAME VERSION PLUGINS 2f259bab93aa podman 0.4.0 bridge,portmap,firewall,tuning
関連情報
-
podman-network-rm
の man ページ
8.7. 未使用の全ネットワークの削除
podman network prune
で、使われていないネットワークをすべて削除してください。未使用のネットワークとは、コンテナーが接続されていないネットワークのことです。podman network prune
コマンドでは、デフォルトの podman
ネットワークは削除されません。
手順
未使用のネットワークをすべて削除します。
# podman network prune WARNING! This will remove all networks not used by at least one container. Are you sure you want to continue? [y/N] y
検証
すべてのネットワークが削除されたことを確認します。
# podman network ls NETWORK ID NAME VERSION PLUGINS 2f259bab93aa podman 0.4.0 bridge,portmap,firewall,tuning
関連情報
-
podman-network-prune
の man ページ
第9章 コンテナー間の通信
この章では、コンテナー間の通信方法について説明します。
9.1. ネットワークモードとレイヤー
Podman には、いくつかの異なるネットワークモードがあります。
-
bridge
- デフォルトのブリッジネットワーク上に別のネットワークを作成します。 -
container:<id>
- id が<id>の
コンテナーと同じネットワークを使用します。 -
host
- ホストネットワークスタックを使用します。 -
network-id
-podman
network create コマンドで作成されたユーザー定義のネットワークを使用します。 -
private
- コンテナーの新しいネットワークを作成します。 -
slirp4nets
- ルートレスコンテナーのデフォルトオプションである slirp4netns を使ってユーザーネットワークスタックを作成します。
ホストモードでは、D-bus (コンテナーはプロセス間通信 (IPC) システム) などのローカルシステムサービスにフルアクセスできるため、安全でないと考えられています。
9.2. コンテナーのネットワーク設定の検査
podman inspect
コマンドに --format
オプションを付けると、podman inspect
の出力から個々の項目を表示できます。
手順
コンテナーの IP アドレスを表示します。
# podman inspect --format='{{.NetworkSettings.IPAddress}}' containerName
コンテナーが接続されている全ネットワークを表示します。
# podman inspect --format='{{.NetworkSettings.Networks}}' containerName
ポートマッピングを表示します。
# podman inspect --format='{{.NetworkSettings.Ports}}' containerName
関連情報
-
podman-inspect
の man ページ
9.3. コンテナーとアプリケーション間の通信
コンテナーとアプリケーションの間で通信を行うことができます。アプリケーションのポートは、リスニング状態かオープン状態のどちらかです。これらのポートは自動的にコンテナーネットワークに公開されるため、このようなネットワークを使用してコンテナーに到達できます。デフォルトでは、Web サーバーはポート 80 でリッスンします。この手順で、myubi
コンテナーは web-container
アプリケーションと通信を行います。
手順
web-container
という名前のコンテナーを起動します。# podman run -dt --name=web-container docker.io/library/httpd
すべてのコンテナーを一覧表示します。
# podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b8c057333513 docker.io/library/httpd:latest httpd-foreground 4 seconds ago Up 5 seconds ago web-container
コンテナーを点検し、IP アドレスを表示します。
# podman inspect --format='{{.NetworkSettings.IPAddress}}' web-container 10.88.0.2
myubi
コンテナーを実行し、Web サーバーが動作していることを確認します。# podman run -it --name=myubi ubi8/ubi curl 10.88.0.2:80 <html><body><h1>It works!</h1></body></html>
9.4. コンテナーとホスト間の通信
デフォルトでは、Podman
ネットワークはブリッジネットワークです。つまり、ネットワークデバイスがコンテナーネットワークとホストネットワークをつなぎます。
前提条件
-
web-container
が動作している。詳細は、コンテナーとアプリケーションの間の通信 のセクションを参照してください。
手順
ブリッジが設定されていることを確認します。
# podman network inspect podman | grep bridge "bridge": "cni-podman0", "type": "bridge"
ホストネットワークの設定を表示します。
# ip addr show cni-podman0 6: cni-podman0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 62:af:a1:0a:ca:2e brd ff:ff:ff:ff:ff:ff inet 10.88.0.1/16 brd 10.88.255.255 scope global cni-podman0 valid_lft forever preferred_lft forever inet6 fe80::60af:a1ff:fe0a:ca2e/64 scope link valid_lft forever preferred_lft forever
web-container
にはcni-podman0
ネットワークの IP が指定されており、そのネットワークがホストにブリッジされていることがわかります。web-containe
をチェックし、その IP アドレスを表示します。# podman inspect --format='{{.NetworkSettings.IPAddress}}' web-container 10.88.0.2
ホストから直接
web-container
にアクセスします。$ curl 10.88.0.2:80 <html><body><h1>It works!</h1></body></html>
関連情報
-
podman-network
の man ページ
9.5. ポートマッピングによるコンテナー間の通信
2 つのコンテナー間で通信する最も便利な方法は、公開ポートを使用することです。ポートの公開は、自動と手動の 2 つの方法で行うことができます。
手順
未公開のコンテナーを実行します。
# podman run -dt --name=web1 ubi8/httpd-24
自動的に公開されたコンテナーを実行します。
# podman run -dt --name=web2 -P ubi8/httpd-24
手動で公開したコンテナーを実行し、コンテナーポート 80 を公開します。
# podman run -dt --name=web3 -p 9090:80 ubi8/httpd-24
すべてのコンテナーを一覧表示します。
# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f12fa79b8b39 registry.access.redhat.com/ubi8/httpd-24:latest /usr/bin/run-http... 23 seconds ago Up 24 seconds ago web1 9024d9e815e2 registry.access.redhat.com/ubi8/httpd-24:latest /usr/bin/run-http... 13 seconds ago Up 13 seconds ago 0.0.0.0:43595->8080/tcp, 0.0.0.0:42423->8443/tcp web2 03bc2a019f1b registry.access.redhat.com/ubi8/httpd-24:latest /usr/bin/run-http... 2 seconds ago Up 2 seconds ago 0.0.0.0:9090->80/tcp web3
以下が確認できます。
-
コンテナー
web1
には公開ポートがなく、コンテナーネットワークまたはブリッジにでのみアクセスできます。 コンテナー
web2
は、ポート 43595 と 42423 を自動的にマッピングして、それぞれアプリケーションポート 8080 と 8443 を公開します。注記registry.access.redhat.com/8/httpd-24
イメージの Containerfile にEXPOSE 8080
とEXPOSE 8443
コマンドがあるため、自動ポートマッピングが可能です。-
コンテナー
web3
は手動でポートを公開しています。ホストポート 9090 は、コンテナーポート 80 にマッピングされます。
-
コンテナー
web1
、web3
コンテナーの IP アドレスを表示します。# podman inspect --format='{{.NetworkSettings.IPAddress}}' web1 # podman inspect --format='{{.NetworkSettings.IPAddress}}' web3
<IP>:<port> 表記を使用して
web1
コンテナーに到達します。# curl 10.88.0.14:8080 ... <title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title> ...
localhost:<port> 表記を使用して
web2
コンテナーに到達します。# curl localhost:43595 ... <title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title> ...
<IP>:<port> 表記を使用して
web3
コンテナーに到達します:# curl 10.88.0.14:9090 ... <title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title> ...
9.6. DNS を利用したコンテナー間の通信
DNS プラグインが有効な場合に、コンテナー名を使用してコンテナーのアドレスを指定します。
前提条件
-
DNS プラグインを有効にしたネットワークが
podman network create
コマンドで作成されている。
手順
mynet
ネットワークに接続されたreceiver
コンテナーを実行します。# podman run -d --net mynet --name receiver ubi8 sleep 3000
sender
コンテナーを実行し、その名前でreceiver
コンテナーにアクセスします。# podman run -it --rm --net mynet --name sender alpine ping receiver PING rcv01 (10.89.0.2): 56 data bytes 64 bytes from 10.89.0.2: seq=0 ttl=42 time=0.041 ms 64 bytes from 10.89.0.2: seq=1 ttl=42 time=0.125 ms 64 bytes from 10.89.0.2: seq=2 ttl=42 time=0.109 ms
CTRL+C
で終了します。
sender
コンテナーは、receiver
コンテナーの名前を使用して ping を送信できることがわかります。
9.7. Pod 内の 2 つのコンテナー間での通信
同じ Pod 内のコンテナーはすべて、IP アドレス、MAC アドレス、およびポートマッピングを共有します。同じ Pod 内のコンテナー間では、localhost:port の表記で通信が可能です。
手順
web-pod
という名前の Pod を作成します。$ podman pod create --name=web-pod
web-container
という名前の Web コンテナーを Pod で実行します。$ podman container run -d --pod web-pod --name=web-container docker.io/library/httpd
関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME 58653cf0cf09 k8s.gcr.io/pause:3.5 4 minutes ago Up 3 minutes ago 4e61a300c194-infra 4e61a300c194 web-pod b3f4255afdb3 docker.io/library/httpd:latest httpd-foreground 3 minutes ago Up 3 minutes ago web-container 4e61a300c194 web-pod
docker.io/library/fedora イメージを元に、
web-pod
でコンテナーを実行します。$ podman container run -it --rm --pod web-pod docker.io/library/fedora curl localhost <html><body><h1>It works!</h1></body></html>
コンテナーが
web-container
に到達できることがわかります。
9.8. Pod での通信
Pod 作成時に、Pod 内のコンテナー用のポートを公開する必要があります。
手順
web-pod
という名前の Pod を作成します。# podman pod create --name=web-pod-publish -p 80:80
すべての Pod を一覧表示します。
# podman pod ls POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS 26fe5de43ab3 publish-pod Created 5 seconds ago 7de09076d2b3 1
web-pod
でweb-container
という名前の Web コンテナーを実行します。# podman container run -d --pod web-pod-publish --name=web-container docker.io/library/httpd
コンテナーの一覧を表示します。
# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7de09076d2b3 k8s.gcr.io/pause:3.5 About a minute ago Up 23 seconds ago 0.0.0.0:80->80/tcp 26fe5de43ab3-infra 088befb90e59 docker.io/library/httpd httpd-foreground 23 seconds ago Up 23 seconds ago 0.0.0.0:80->80/tcp web-container
web-container
に到達できることを確認します。$ curl localhost:80 <html><body><h1>It works!</h1></body></html>
9.9. コンテナーネットワークへの Pod のアタッチ
Pod 作成時に Pod 内のコンテナーをネットワークにアタッチします。
手順
pod-net
という名前のネットワークを作成します。# podman network create pod-net /etc/cni/net.d/pod-net.conflist
Pod
web-pod
を作成します。# podman pod create --net pod-net --name web-pod
web-pod
でweb-container
という名前のコンテナーを実行します。# podman run -d --pod webt-pod --name=web-container docker.io/library/httpd
オプション:コンテナーが関連付けられている Pod を表示します。
# podman ps -p CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME b7d6871d018c registry.access.redhat.com/ubi8/pause:latest 9 minutes ago Up 6 minutes ago a8e7360326ba-infra a8e7360326ba web-pod 645835585e24 docker.io/library/httpd:latest httpd-foreground 6 minutes ago Up 6 minutes ago web-container a8e7360326ba web-pod
検証
コンテナーに接続されているすべてのネットワークを表示します。
# podman ps --format="{{.Networks}}" pod-net
第10章 コンテナーネットワークモードの設定
本章では、さまざまなネットワークモードを設定する方法を説明します。
10.1. 静的 IP でのコンテナー実行
podman run
コマンドで --ip
オプションを指定すると、コンテナーのネットワークインターフェイスが特定の IP アドレスに設定さします (例: 10.88.0.44)。podman inspect
コマンドを実行して、IP アドレスが正しく設定されていることを確認します。
手順
コンテナーのネットワークインターフェイスを IP アドレス 10.88.0.44 に設定します。
# podman run -d --name=myubi --ip=10.88.0.44 registry.access.redhat.com/ubi8/ubi efde5f0a8c723f70dd5cb5dc3d5039df3b962fae65575b08662e0d5b5f9fbe85
検証
IP アドレスが正しく設定されていることを確認します。
# podman inspect --format='{{.NetworkSettings.IPAddress}}' myubi 10.88.0.44
10.2. systemd なしでの DHCP プラグイン実行
ユーザー定義のネットワークに接続するには、Podman run --network
コマンドを使用します。ほとんどのコンテナーイメージには DHCP クライアントがありませんが、dhcp
プラグインは、コンテナーが DHCP サーバーを操作するためのプロキシー DHCP クライアントとして機能します。
この手順は、ルートフルコンテナーにのみ適用されます。ルートレスコンテナーでは、dhcp
プラグインは使用されません。
手順
dhcp
プラグインを手動で実行します。# /usr/libexec/cni/dhcp daemon & [1] 4966
dhcp
プラグインが動作していることを確認します。# ps -a | grep dhcp 4966 pts/1 00:00:00 dhcp
alpine
コンテナーを実行します。# podman run -it --rm --network=example alpine ip addr show enp1s0 Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf) Trying to pull docker.io/library/alpine:latest... ... Storing signatures 2: eth0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether f6:dd:1b:a7:9b:92 brd ff:ff:ff:ff:ff:ff inet 192.168.1.22/24 brd 192.168.1.255 scope global eth0 ...
この例では、以下のように設定されています。
-
network=example
オプションは、接続するネットワークを example という名前で指定します。 -
alpine
コンテナーでip addr show enp1s0
コマンドを実行すると、ネットワークインターフェイスenp1s0
の IP アドレスを確認します。 - ホストネットワークは 192.168.1.0/24 です。
-
eth0
インターフェイスは、alpine コンテナー用に 192.168.1.122 の IP アドレスをリースしています。
-
この設定では、有効期限の短いコンテナーとリースの長い DHCP サーバーが多数ある場合に、利用可能な DHCP アドレスが枯渇する可能性があります。
10.3. systemd を使用した DHCP プラグインの実行
dhcp
プラグインを実行するために systemd ユニットファイルを使用できます。
手順
ソケットユニットファイルを作成します。
# cat /usr/lib/systemd/system/io.podman.dhcp.socket [Unit] Description=DHCP Client for CNI [Socket] ListenStream=%t/cni/dhcp.sock SocketMode=0600 [Install] WantedBy=sockets.target
サービスユニットファイルを作成します。
# cat /usr/lib/systemd/system/io.podman.dhcp.service [Unit] Description=DHCP Client CNI Service Requires=io.podman.dhcp.socket After=io.podman.dhcp.socket [Service] Type=simple ExecStart=/usr/libexec/cni/dhcp daemon TimeoutStopSec=30 KillMode=process [Install] WantedBy=multi-user.target Also=io.podman.dhcp.socket
サービスをすぐに起動します。
# systemctl --now enable io.podman.dhcp.socket
検証
ソケットのステータスを確認します。
# systemctl status io.podman.dhcp.socket io.podman.dhcp.socket - DHCP Client for CNI Loaded: loaded (/usr/lib/systemd/system/io.podman.dhcp.socket; enabled; vendor preset: disabled) Active: active (listening) since Mon 2022-01-03 18:08:10 CET; 39s ago Listen: /run/cni/dhcp.sock (Stream) CGroup: /system.slice/io.podman.dhcp.socket
10.4. macvlan プラグイン
ほとんどのコンテナーイメージには DHCP クライアントがありませんが、dhcp
プラグインは、コンテナーが DHCP サーバーを操作するためのプロキシー DHCP クライアントとして機能します。
ホストシステムには、コンテナーへのネットワークアクセス権がありません。ホスト外部からコンテナーへのネットワーク接続を許可するには、コンテナーには、ホストと同じネットワーク上に IP が必要です。macvlan
プラグインを使用すると、コンテナーをホストと同じネットワークに接続することができます。
この手順は、ルートフルコンテナーにのみ適用されます。ルートレスコンテナーは、macvlan
および dhcp
プラグインを使用することができません。
macvlan ネットワークは、podman network create --macvlan
コマンドで作成することができます。
関連情報
- Leasing routable IP addresses with Podman containers
-
podman-network-create
man ページ
10.5. ネットワークスタックの CNI から Netavark への切り替え
これまで、コンテナーは単一の Container Network Interface (CNI) プラグインに接続されている場合のみ DNS を使用できました。Netavark は、コンテナー用のネットワークスタックです。Netavark は、Podman やその他の OCI(Open Container Initiative) コンテナー管理アプリケーションで使用できます。Podman の高度なネットワークスタックは、Docker の詳細機能にも対応しています。現在、複数のネットワーク上にあるコンテナーは、これらのネットワークにあるコンテナーにアクセスします。
Netavark は以下のことが可能です。
- ブリッジおよび MACVLAN インターフェイスなどのネットワークインターフェイスの作成、管理、削除。
- ネットワークアドレス変換 (NAT) やポートマッピングルールなどのファイアウォールの設定。
- IPv4、IPv6 のサポート。
- 複数のネットワークにおけるコンテナーへの対応改善。
手順
/etc/containers/container.conf
ファイルが存在しない場合は、/usr/share/containers/containers.conf
ファイルを/etc/containers/
ディレクトリーにコピーします。# cp /usr/share/containers/containers.conf /etc/containers/
etc/containers/container.conf
ファイルを編集し、network
セクションに以下の内容を追加します。network_backend="netavark"
コンテナーや Pod がある場合は、ストレージをリセットして初期状態に戻します。
# podman system reset
システムを再起動します。
# reboot
検証
ネットワークスタックが Netavark に変更されていることを確認します。
# cat /etc/containers/container.conf ... [network] network_backend="netavark" ...
Podman 4.0.0 以降をお使いの場合は、podman info
コマンドでネットワークスタックの設定を確認してください。
関連情報
- Podman 4.0's new network stack: What you need to know
-
podman-system-reset
の man ページ
10.6. Netavark から CNI へのネットワークスタックの切り替え
手順
/etc/containers/container.conf
ファイルが存在しない場合は、/usr/share/containers/containers.conf
ファイルを/etc/containers/
ディレクトリーにコピーします。# cp /usr/share/containers/containers.conf /etc/containers/
etc/containers/container.conf
ファイルを編集し、network
セクションに以下の内容を追加します。network_backend="cni"
コンテナーや Pod がある場合は、ストレージをリセットして初期状態に戻します。
# podman system reset
システムを再起動します。
# reboot
検証
ネットワークスタックが Netavark に変更されていることを確認します。
# cat /etc/containers/container.conf ... [network] network_backend="cni" ...
Podman 4.0.0 以降をお使いの場合は、podman info
コマンドでネットワークスタックの設定を確認してください。
関連情報
- Podman 4.0's new network stack: What you need to know
-
podman-system-reset
の man ページ
第11章 Podman を使用した OpenShift へのコンテナーの移植
YAML (YAML Ain't Markup Language) 形式を使用して、コンテナーおよび Pod の移植可能な記述を生成できます。YAML は、設定データの記述に使用されるテキスト形式です。
YAML ファイルは以下のとおりです。
- 読み取り可能
- 生成が簡単
- 環境間の移植性 (RHEL と OpenShift の間など)
- プログラミング言語間で移植が可能
- 使いやすい (全パラメーターをコマンドラインに追加する必要はない)。
YAML ファイルを使用する理由:
- 必要最小限の入力でオーケストレーションされたコンテナーおよび Pod のローカルオーケストレーションセットを再実行でき、反復型開発に役立ちます。
-
同じコンテナーおよび Pod を別のマシンで実行できます。たとえば、OpenShift 環境でアプリケーションを実行し、アプリケーションが正常に機能していることを確認します。
podman generate kube
コマンドを使用して、Kubernetes YAML ファイルを生成できます。次に、podman play
コマンドを使用して、生成された YAML ファイルを Kubernetes または OpenShift 環境に転送する前に、ローカルシステムで Pod およびコンテナーの作成をテストできます。podman play
コマンドを使用して、OpenShift または Kubernetes 環境で作成された Pod およびコンテナーを再作成することもできます。
11.1. Podman を使用した Kubernetes YAML ファイルの生成
この手順では、1 つのコンテナーで Pod を作成し、podman generate kube
コマンドを使用して Kubernetes YAML ファイルを生成する方法を説明します。
前提条件
- Pod が作成されている。詳細は、Pod の作成 を参照してください。
手順
関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD 5df5c48fea87 registry.access.redhat.com/ubi8/ubi:latest /bin/bash Less than a second ago Up Less than a second ago myubi 223df6b390b4 3afdcd93de3e k8s.gcr.io/pause:3.1 Less than a second ago Up Less than a second ago 223df6b390b4-infra 223df6b390b4
Pod 名または ID を使用して Kubernetes YAML ファイルを生成します。
$ podman generate kube mypod > mypod.yaml
podman generate
コマンドは、コンテナーに接続されている論理ボリュームマネージャー (LVM) の論理ボリュームまたは物理ボリュームへは反映されないので注意してください。mypod.yaml
ファイルを表示します。$ cat mypod.yaml # Generation of Kubernetes YAML is still under development! # # Save the output of this file and use kubectl create -f to import # it into Kubernetes. # # Created with podman-1.6.4 apiVersion: v1 kind: Pod metadata: creationTimestamp: "2020-06-09T10:31:56Z" labels: app: mypod name: mypod spec: containers: - command: - /bin/bash env: - name: PATH value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin - name: TERM value: xterm - name: HOSTNAME - name: container value: oci image: registry.access.redhat.com/ubi8/ubi:latest name: myubi resources: {} securityContext: allowPrivilegeEscalation: true capabilities: {} privileged: false readOnlyRootFilesystem: false tty: true workingDir: / status: {}
関連情報
-
podman-generate-kube
の man ページ - Podman: Managing pods and containers in a local container runtime
11.2. OpenShift 環境での Kubernetes YAML ファイルの生成
OpenShift 環境では、oc create
コマンドを使用して、アプリケーションを記述する YAML ファイルを生成します。
手順
myapp
アプリケーションの YAML ファイルを生成します。$ oc create myapp --image=me/myapp:v1 -o yaml --dry-run > myapp.yaml
oc create
コマンドはmyapp
イメージを作成して実行します。オブジェクトは--dry-run
オプションを使用して出力され、myapp.yaml
出力ファイルにリダイレクトされます。
Kubernetes 環境では、同じフラグを指定して kubectl create
コマンドを使用できます。
11.3. Podman でのコンテナーおよび Pod の起動
生成された YAML ファイルを使用すると、任意の環境でコンテナーおよび Pod を自動的に起動できます。YAML ファイルは Podman では生成されないことに注意してください。podman play kube
コマンドを使用すると、YAML 入力ファイルに基づいて Pod およびコンテナーを再作成できます。
手順
mypod.yaml
ファイルから Pod およびコンテナーを作成します。$ podman play kube mypod.yaml Pod: b8c5b99ba846ccff76c3ef257e5761c2d8a5ca4d7ffa3880531aec79c0dacb22 Container: 848179395ebd33dd91d14ffbde7ae273158d9695a081468f487af4e356888ece
すべての Pod を一覧表示します。
$ podman pod ps POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID b8c5b99ba846 mypod Running 19 seconds ago 2 aa4220eaf4bb
関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD 848179395ebd registry.access.redhat.com/ubi8/ubi:latest /bin/bash About a minute ago Up About a minute ago myubi b8c5b99ba846 aa4220eaf4bb k8s.gcr.io/pause:3.1 About a minute ago Up About a minute ago b8c5b99ba846-infra b8c5b99ba846
podman ps
コマンドからの Pod ID と、podman pod ps
コマンドからの Pod ID が一致します。
関連情報
-
podman-play-kube
の man ページ - Podman can now ease the transition to Kubernetes and CRI-O
11.4. OpenShift 環境でのコンテナーおよび Pod の起動
oc create
コマンドを使用して、OpenShift 環境で Pod およびコンテナーを作成できます。
手順
OpenShift 環境で YAML ファイルから Pod を作成します。
$ oc create -f mypod.yaml
Kubernetes 環境では、同じフラグを指定して kubectl create
コマンドを使用できます。
11.5. Podman を使用したコンテナーと Pod の手動実行
以下の手順は、Podman を使用して MariaDB データベースと対になる WordPress コンテンツマネジメントシステムを手動で作成する方法を説明します。
次のようなディレクトリーレイアウトがあるとします。
├── mariadb-conf │ ├── Containerfile │ ├── my.cnf
手順
mariadb-conf/Containerfile
ファイルを表示します。$ cat mariadb-conf/Containerfile FROM docker.io/library/mariadb COPY my.cnf /etc/mysql/my.cnf
mariadb-conf/my.cnf
ファイルを表示します。[client-server] # Port or socket location where to connect port = 3306 socket = /run/mysqld/mysqld.sock # Import all .cnf files from the configuration directory [mariadbd] skip-host-cache skip-name-resolve bind-address = 127.0.0.1 !includedir /etc/mysql/mariadb.conf.d/ !includedir /etc/mysql/conf.d/
mariadb-conf/Containerfile
を使ってdocker.io/library/mariadb
イメージをビルドします。$ cd mariadb-conf $ podman build -t mariadb-conf . $ cd .. STEP 1: FROM docker.io/library/mariadb Trying to pull docker.io/library/mariadb:latest... Getting image source signatures Copying blob 7b1a6ab2e44d done ... Storing signatures STEP 2: COPY my.cnf /etc/mysql/my.cnf STEP 3: COMMIT mariadb-conf --> ffae584aa6e Successfully tagged localhost/mariadb-conf:latest ffae584aa6e733ee1cdf89c053337502e1089d1620ff05680b6818a96eec3c17
オプション:すべてのイメージを一覧表示します。
$ podman images LIST IMAGES REPOSITORY TAG IMAGE ID CREATED SIZE localhost/mariadb-conf latest b66fa0fa0ef2 57 seconds ago 416 MB
wordpresspod
という名前の pod を作成し、コンテナーとホストシステム間のポートマッピングを設定します。$ podman pod create --name wordpresspod -p 8080:80
wordpresspod
pod の中にmydb
コンテナーを作成します。$ podman run --detach --pod wordpresspod \ -e MYSQL_ROOT_PASSWORD=1234 \ -e MYSQL_DATABASE=mywpdb \ -e MYSQL_USER=mywpuser \ -e MYSQL_PASSWORD=1234 \ --name mydb localhost/mariadb-conf
wordpresspod
pod の中にmyweb
コンテナーを作成します。$ podman run --detach --pod wordpresspod \ -e WORDPRESS_DB_HOST=127.0.0.1 \ -e WORDPRESS_DB_NAME=mywpdb \ -e WORDPRESS_DB_USER=mywpuser \ -e WORDPRESS_DB_PASSWORD=1234 \ --name myweb docker.io/wordpress
オプション:関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps --pod -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME 9ea56f771915 k8s.gcr.io/pause:3.5 Less than a second ago Up Less than a second ago 0.0.0.0:8080->80/tcp 4b7f054a6f01-infra 4b7f054a6f01 wordpresspod 60e8dbbabac5 localhost/mariadb-conf:latest mariadbd Less than a second ago Up Less than a second ago 0.0.0.0:8080->80/tcp mydb 4b7f054a6f01 wordpresspod 045d3d506e50 docker.io/library/wordpress:latest apache2-foregroun... Less than a second ago Up Less than a second ago 0.0.0.0:8080->80/tcp myweb 4b7f054a6f01 wordpresspod
検証
Pod が実行されていることを確認します。http://localhost:8080/wp-admin/install.php ページに移動するか、
curl
コマンドを使用します。$ curl http://localhost:8080/wp-admin/install.php <!DOCTYPE html> <html lang="en-US" xml:lang="en-US"> <head> ... </head> <body class="wp-core-ui"> <p id="logo">WordPress</p> <h1>Welcome</h1> ...
関連情報
- Build Kubernetes pods with Podman play kube
-
podman-play-kube
の man ページ
11.6. Podman を使用した YAML ファイルの生成
Kubernetes の YAML ファイルは、podman generate kube
コマンドで生成できます。
前提条件
-
wordpresspod
という名前の Pod が作成されている。詳細は、Pod の作成 を参照してください。
手順
関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps --pod -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME 9ea56f771915 k8s.gcr.io/pause:3.5 Less than a second ago Up Less than a second ago 0.0.0.0:8080->80/tcp 4b7f054a6f01-infra 4b7f054a6f01 wordpresspod 60e8dbbabac5 localhost/mariadb-conf:latest mariadbd Less than a second ago Up Less than a second ago 0.0.0.0:8080->80/tcp mydb 4b7f054a6f01 wordpresspod 045d3d506e50 docker.io/library/wordpress:latest apache2-foregroun... Less than a second ago Up Less than a second ago 0.0.0.0:8080->80/tcp myweb 4b7f054a6f01 wordpresspod
Pod 名または ID を使用して Kubernetes YAML ファイルを生成します。
$ podman generate kube wordpresspod >> wordpresspod.yaml
検証
wordpresspod.yaml
ファイルを表示します。$ cat wordpresspod.yaml ... apiVersion: v1 kind: Pod metadata: creationTimestamp: "2021-12-09T15:09:30Z" labels: app: wordpresspod name: wordpresspod spec: containers: - args: value: podman - name: MYSQL_PASSWORD value: "1234" - name: MYSQL_MAJOR value: "8.0" - name: MYSQL_VERSION value: 8.0.27-1debian10 - name: MYSQL_ROOT_PASSWORD value: "1234" - name: MYSQL_DATABASE value: mywpdb - name: MYSQL_USER value: mywpuser image: mariadb name: mydb ports: - containerPort: 80 hostPort: 8080 protocol: TCP - args: - name: WORDPRESS_DB_NAME value: mywpdb - name: WORDPRESS_DB_PASSWORD value: "1234" - name: WORDPRESS_DB_HOST value: 127.0.0.1 - name: WORDPRESS_DB_USER value: mywpuser image: docker.io/library/wordpress:latest name: myweb
関連情報
- Build Kubernetes pods with Podman play kube
-
podman-play-kube
の man ページ
11.7. Podman を使用したコンテナーと Pod の自動実行
次に、podman play kube
コマンドを使用して、生成された YAML ファイルを Kubernetes または OpenShift 環境に転送する前に、ローカルシステムで Pod およびコンテナーの作成をテストできます。
podman play kube
コマンドは、docker compose コマンドと同様に YAML ファイルを使って、コンテナーが複数ある Pod を自動的に構築して実行することも可能です。以下の条件が該当する場合には、自動的にイメージが構築されます。
- YAML ファイルで使用されているイメージと同じ名前のディレクトリーが存在する
- そのディレクトリーには Containerfile が含まれている
前提条件
-
wordpresspod
という名前の Pod が作成されている。詳細は、Podman を使用したコンテナーと Pod の手動実行 を参照してください。 - YAML ファイルが生成されている。詳細は、Podman を使用した YAML ファイルの生成のセクションをご覧ください。
最初からやり直す場合は、ローカルに保存されているイメージを削除してください。
$ podman rmi localhost/mariadb-conf $ podman rmi docker.io/library/wordpress $ podman rmi docker.io/library/mysql
手順
wordpress.yaml
ファイルを使用して、wordpress Pod を作成します。$ podman play kube wordpress.yaml STEP 1/2: FROM docker.io/library/mariadb STEP 2/2: COPY my.cnf /etc/mysql/my.cnf COMMIT localhost/mariadb-conf:latest --> 428832c45d0 Successfully tagged localhost/mariadb-conf:latest 428832c45d07d78bb9cb34e0296a7dc205026c2fe4d636c54912c3d6bab7f399 Trying to pull docker.io/library/wordpress:latest... Getting image source signatures Copying blob 99c3c1c4d556 done ... Storing signatures Pod: 3e391d091d190756e655219a34de55583eed3ef59470aadd214c1fc48cae92ac Containers: 6c59ebe968467d7fdb961c74a175c88cb5257fed7fb3d375c002899ea855ae1f 29717878452ff56299531f79832723d3a620a403f4a996090ea987233df0bc3d
podman play kube
コマンド:-
docker.io/library/mariadb
イメージを元にlocalhost/mariadb-conf:latest
イメージを自動構築します。 -
docker.io/library/wordpress:latest の
イメージをプルします。 -
wordpresspod-mydb
とwordpresspod-myweb
の 2 つのコンテナーが含まれる、wordpresspod
という名前の Pod を作成します。
-
すべてのコンテナーと Pod を表示します。
$ podman ps --pod -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME a1dbf7b5606c k8s.gcr.io/pause:3.5 3 minutes ago Up 2 minutes ago 0.0.0.0:8080->80/tcp 3e391d091d19-infra 3e391d091d19 wordpresspod 6c59ebe96846 localhost/mariadb-conf:latest mariadbd 2 minutes ago Exited (1) 2 minutes ago 0.0.0.0:8080->80/tcp wordpresspod-mydb 3e391d091d19 wordpresspod 29717878452f docker.io/library/wordpress:latest apache2-foregroun... 2 minutes ago Up 2 minutes ago 0.0.0.0:8080->80/tcp wordpresspod-myweb 3e391d091d19 wordpresspod
検証
Pod が実行されていることを確認します。http://localhost:8080/wp-admin/install.php ページに移動するか、
curl
コマンドを使用します。$ curl http://localhost:8080/wp-admin/install.php <!DOCTYPE html> <html lang="en-US" xml:lang="en-US"> <head> ... </head> <body class="wp-core-ui"> <p id="logo">WordPress</p> <h1>Welcome</h1> ...
関連情報
- Build Kubernetes pods with Podman play kube
-
podman-play-kube
の man ページ
11.8. Podman を使用した Pod の自動停止/削除
podman play kube --down
コマンドは、すべての Pod とそのコンテナーを停止して削除します。
ボリュームが使用中の場合には削除されません。
前提条件
-
wordpresspod
という名前の Pod が作成されている。詳細は、Podman を使用したコンテナーと Pod の手動実行 を参照してください。 - YAML ファイルが生成されている。詳細は、Podman を使用した YAML ファイルの生成のセクションをご覧ください。
- Pod が実行中である。詳細は、Podman を使用したコンテナーや Pod の自動実行 を参照してください。
手順
wordpresspod.yaml
ファイルで作成された全 Pod とコンテナーを削除します。$ podman play kube --down wordpresspod.yaml Pods stopped: 3e391d091d190756e655219a34de55583eed3ef59470aadd214c1fc48cae92ac Pods removed: 3e391d091d190756e655219a34de55583eed3ef59470aadd214c1fc48cae92ac
検証
wordpresspod.yaml
ファイルで作成された全 Pod とコンテナーが削除されたことを確認します。$ podman ps --pod -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME
関連情報
- Build Kubernetes pods with Podman play kube
-
podman-play-kube
の man ページ
第12章 Podman を使用した systemd へのコンテナーの移植
Podman (Pod Manager) は、簡単なデーモンレスツールである、完全に機能するコンテナーエンジンです。Podman は、他のコンテナーエンジンからの移行を容易にし、Pod、コンテナー、およびイメージの管理を可能にする Docker-CLI と同等のコマンドラインを提供します。
Podman は、当初、Linux システム全体の起動や、起動順序、依存関係の確認、失敗したサービスの復元などのサービス管理を行うよう設計されていました。これは、systemd のような、本格的な初期化システムのジョブです。Red Hat は、コンテナーと systemd の統合について先駆者になり、他のサービスと機能が Linux システムで管理されているのと同じように、Podman により構築された OCI 形式および Docker 形式のコンテナーを管理できます。systemd 初期化サービスを使用して、Pod およびコンテナーを操作できます。podman generate systemd
コマンドを使用して、コンテナーおよび Pod の systemd ユニットファイルを生成できます。
systemd ユニットファイルを使用すると、以下が可能になります。
- コンテナーまたは Pod を systemd サービスとして起動するように設定します。
- コンテナー化されたサービスを実行して依存関係を確認する順序を定義します (たとえば、別のサービスが実行されていること、ファイルが利用可能であること、またはリソースがマウントされていることなど)。
-
systemctl
コマンドを使用して、systemd システムの状態を制御します。
systemd ユニットファイルを使用して、コンテナーおよび Pod の移植可能な説明を生成できます。
12.1. systemd サービスの有効化
サービスの有効化には、さまざまなオプションがあります。
手順
サービスの有効化:
システムの起動時にサービスを有効にするには、ユーザーがログインしているかどうかに拘らず、次のコマンドを実行します。
# systemctl enable <service>
systemd ユニットファイルを
/etc/systemd/system
ディレクトリーにコピーする必要があります。ユーザーのログイン時にサービスを起動し、ユーザーのログアウト時に停止するには、次のコマンドを実行します。
$ systemctl --user enable <service>
systemd ユニットファイルを
$HOME/.config/systemd/user
ディレクトリーにコピーする必要があります。システムの起動時にサービスを起動し、ログアウト後もそのまま起動した状態を保つには、次のコマンドを実行します。
# loginctl enable-linger <username>
関連情報
-
systemctl
の man ページ -
loginctl
の man ページ - システム起動時に systemd サービスの開始
12.2. Podman を使用した systemd ユニットファイルの生成
Podman を使用することで、systemd はコンテナープロセスを制御および管理できます。podman generate systemd
コマンドを使用して既存のコンテナーと Pod の systemd ユニットファイルを生成できます。生成されたユニットファイルは頻繁に変更され (Podman に対する更新)、podman generate systemd
で最新のユニットファイルの取得を確認できるので、podman generate systemd
の使用を推奨します。
手順
コンテナー (例:
myubi
) を作成します。$ podman create --name myubi registry.access.redhat.com/ubi8:latest sleep infinity 0280afe98bb75a5c5e713b28de4b7c5cb49f156f1cce4a208f13fee2f75cb453
コンテナー名または ID を使用して systemd ユニットファイルを生成し、それを
~/.config/systemd/user/container-myubi.service
ファイルに送ります。$ podman generate systemd --name myubi > ~/.config/systemd/user/container-myubi.service
検証手順
生成された systemd ユニットファイルの内容を表示します。
$ cat ~/.config/systemd/user/container-myubi.service # container-myubi.service # autogenerated by Podman 3.3.1 # Wed Sep 8 20:34:46 CEST 2021 [Unit] Description=Podman container-myubi.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=/run/user/1000/containers [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure TimeoutStopSec=70 ExecStart=/usr/bin/podman start myubi ExecStop=/usr/bin/podman stop -t 10 myubi ExecStopPost=/usr/bin/podman stop -t 10 myubi PIDFile=/run/user/1000/containers/overlay-containers/9683103f58a32192c84801f0be93446cb33c1ee7d9cdda225b78049d7c5deea4/userdata/conmon.pid Type=forking [Install] WantedBy=multi-user.target default.target
-
Restart=on-failure
行は、再起動ポリシーを設定し、サービスを正常に開始または停止できない場合、またはプロセスがゼロ以外のステータスで終了した場合に、systemd にサービスを再開するように指示します。 -
ExecStart
行は、コンテナーの開始方法を示しています。 -
ExecStop
行は、コンテナーを停止して削除する方法を示しています。
-
12.3. Podman を使用した systemd ユニットファイルの自動生成
デフォルトで、Podman は既存のコンテナーまたは Pod のユニットファイルを生成します。podman generate systemd --new
を使用して、移植可能な別の systemd ユニットファイルを生成できます。--new
フラグでは、コンテナーの作成、起動、削除を行うユニットファイルを生成するように Podman に指示します。
手順
システムで使用するイメージをプルします。たとえば、
httpd-24
イメージをプルするには、以下を実行します。# podman pull registry.access.redhat.com/ubi8/httpd-24
オプション:システムで利用可能なイメージの一覧を表示します。
# podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi8/httpd-24 latest 8594be0a0b57 2 weeks ago 462 MB
httpd
コンテナーを作成します。# podman create --name httpd -p 8080:8080 registry.access.redhat.com/ubi8/httpd-24 cdb9f981cf143021b1679599d860026b13a77187f75e46cc0eac85293710a4b1
オプション:コンテナーが作成されたことを確認します。
# podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES cdb9f981cf14 registry.access.redhat.com/ubi8/httpd-24:latest /usr/bin/run-http... 5 minutes ago Created 0.0.0.0:8080->8080/tcp httpd
httpd
コンテナーの systemd ユニットファイルを生成します。# podman generate systemd --new --files --name httpd /root/container-httpd.service
生成された
container-httpd.service
systemd ユニットファイルの内容を表示します。# cat /root/container-httpd.service # container-httpd.service # autogenerated by Podman 3.3.1 # Wed Sep 8 20:41:44 CEST 2021 [Unit] Description=Podman container-httpd.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=%t/containers [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure TimeoutStopSec=70 ExecStartPre=/bin/rm -f %t/%n.ctr-id ExecStart=/usr/bin/podman run --cidfile=%t/%n.ctr-id --sdnotify=conmon --cgroups=no-conmon --rm -d --replace --name httpd -p 8080:8080 registry.access.redhat.com/ubi8/httpd-24 ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id Type=notify NotifyAccess=all [Install] WantedBy=multi-user.target default.target
- 注記
--new
オプションを使用してユニットファイルを生成した場合には、コンテナーと Pod の存在は想定されていません。したがって、サービスの起動時に (ExecStart
の行を参照)、podman start
コマンドではなく、podman run
コマンドを実行します。たとえば、Generating a systemd unit file using Podmanのセクションを参照してください。podman run
コマンドは、以下のコマンドラインオプションを使用します。-
--conmon-pidfile
オプションは、ホストで実行しているconmon
プロセスのプロセス ID を格納するパスを指します。conmon
プロセスはコンテナーと同じ終了ステータスで終了するので、systemd は正しいサービスステータスを報告して必要に応じてコンテナーを再起動できます。 -
--cidfile
オプションは、コンテナー ID を格納するパスを指します。 -
%t
は、ランタイムディレクトリーのルートへのパスです (例:/run/user/$UserID
)。 -
%n
は、サービスの完全な名前です。
-
/etc/systemd/system
にユニットファイルをコピーして root ユーザーとしてインストールします。# cp -Z container-httpd.service /etc/systemd/system
container-httpd.service
を有効にして起動します。# systemctl daemon-reload # systemctl enable --now container-httpd.service Created symlink /etc/systemd/system/multi-user.target.wants/container-httpd.service → /etc/systemd/system/container-httpd.service. Created symlink /etc/systemd/system/default.target.wants/container-httpd.service → /etc/systemd/system/container-httpd.service.
検証手順
container-httpd.service
のステータスを確認します。# systemctl status container-httpd.service ● container-httpd.service - Podman container-httpd.service Loaded: loaded (/etc/systemd/system/container-httpd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2021-08-24 09:53:40 EDT; 1min 5s ago Docs: man:podman-generate-systemd(1) Process: 493317 ExecStart=/usr/bin/podman run --conmon-pidfile /run/container-httpd.pid --cidfile /run/container-httpd.ctr-id --cgroups=no-conmon -d --repla> Process: 493315 ExecStartPre=/bin/rm -f /run/container-httpd.pid /run/container-httpd.ctr-id (code=exited, status=0/SUCCESS) Main PID: 493435 (conmon) ...
12.4. systemd を使用したコンテナーの自動起動
systemctl
コマンドを使用して、systemd システムおよびサービスマネージャーの状態を制御できます。root 以外のユーザーでサービスを有効化、起動、停止できます。root ユーザーとしてサービスをインストールするには、--user
オプションを省略します。
手順
systemd マネージャーの設定を再読み込みするには、次のコマンドを実行します。
# systemctl --user daemon-reload
サービス
container.service
を有効にし、起動時に開始します。# systemctl --user enable container.service
サービスをすぐに起動します。
# systemctl --user start container.service
サービスの状況を表示するには、次のコマンドを実行します。
$ systemctl --user status container.service ● container.service - Podman container.service Loaded: loaded (/home/user/.config/systemd/user/container.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-09-16 11:56:57 CEST; 8s ago Docs: man:podman-generate-systemd(1) Process: 80602 ExecStart=/usr/bin/podman run --conmon-pidfile //run/user/1000/container.service-pid --cidfile //run/user/1000/container.service-cid -d ubi8-minimal:> Process: 80601 ExecStartPre=/usr/bin/rm -f //run/user/1000/container.service-pid //run/user/1000/container.service-cid (code=exited, status=0/SUCCESS) Main PID: 80617 (conmon) CGroup: /user.slice/user-1000.slice/user@1000.service/container.service ├─ 2870 /usr/bin/podman ├─80612 /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox --enable-seccomp -c -e 3 -r 4 --netns-type=path /run/user/1000/netns/cni-> ├─80614 /usr/bin/fuse-overlayfs -o lowerdir=/home/user/.local/share/containers/storage/overlay/l/YJSPGXM2OCDZPLMLXJOW3NRF6Q:/home/user/.local/share/contain> ├─80617 /usr/bin/conmon --api-version 1 -c cbc75d6031508dfd3d78a74a03e4ace1732b51223e72a2ce4aa3bfe10a78e4fa -u cbc75d6031508dfd3d78a74a03e4ace1732b51223e72> └─cbc75d6031508dfd3d78a74a03e4ace1732b51223e72a2ce4aa3bfe10a78e4fa └─80626 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1d
systemctl is-enabled container.service
コマンドを使用して、サービスが有効であるかどうかを確認できます。
検証手順
実行中または終了したコンテナーを一覧表示します。
# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f20988d59920 registry.access.redhat.com/ubi8-minimal:latest top 12 seconds ago Up 11 seconds ago funny_zhukovsky
container.service
を停止するには、以下を入力します。
# systemctl --user stop container.service
関連情報
-
systemctl
の man ページ - Running containers with Podman and shareable systemd services
- systemd によるサービス管理
12.5. systemd を使用した Pod の自動起動
複数のコンテナーを systemd サービスとして起動できます。systemctl
コマンドは、Pod でだけ使用するようにしてください。コンテナーは Pod サービスと内部の infra-container で管理されているので systemctl
を使用して個別にコンテナーを開始または停止しないでください。
手順
たとえば、
systemd-pod
などの空の Pod を作成します。$ podman pod create --name systemd-pod 11d4646ba41b1fffa51c108cbdf97cfab3213f7bd9b3e1ca52fe81b90fed5577
オプション:すべての Pod を一覧表示します。
$ podman pod ps POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID 11d4646ba41b systemd-pod Created 40 seconds ago 1 8a428b257111 11d4646ba41b1fffa51c108cbdf97cfab3213f7bd9b3e1ca52fe81b90fed5577
空の Pod に 2 つのコンテナーを作成します。たとえば、
container0
とcontainer1
をsystemd-pod
に作成するには、以下を実行します。$ podman create --pod systemd-pod --name container0 registry.access.redhat.com/ubi8 top $ podman create --pod systemd-pod --name container1 registry.access.redhat.com/ubi8 top
オプション:関連付けられている全 Pod およびコンテナーを一覧表示します。
$ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME 24666f47d9b2 registry.access.redhat.com/ubi8:latest top 3 minutes ago Created container0 3130f724e229 systemd-pod 56eb1bf0cdfe k8s.gcr.io/pause:3.2 4 minutes ago Created 3130f724e229-infra 3130f724e229 systemd-pod 62118d170e43 registry.access.redhat.com/ubi8:latest top 3 seconds ago Created container1 3130f724e229 systemd-pod
新規 Pod の systemd ユニットファイルを生成します。
$ podman generate systemd --files --name systemd-pod /home/user1/pod-systemd-pod.service /home/user1/container-container0.service /home/user1/container-container1.service
systemd ユニットファイルは、3 つ作成される点に注意してください。1 つは
systemd-pod
の Pod 向け、2 つはcontainer0
とcontainer1
のコンテナー向けです。pod-systemd-pod.service
ユニットファイルを表示します。$ cat pod-systemd-pod.service # pod-systemd-pod.service # autogenerated by Podman 3.3.1 # Wed Sep 8 20:49:17 CEST 2021 [Unit] Description=Podman pod-systemd-pod.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor= Requires=container-container0.service container-container1.service Before=container-container0.service container-container1.service [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure TimeoutStopSec=70 ExecStart=/usr/bin/podman start bcb128965b8e-infra ExecStop=/usr/bin/podman stop -t 10 bcb128965b8e-infra ExecStopPost=/usr/bin/podman stop -t 10 bcb128965b8e-infra PIDFile=/run/user/1000/containers/overlay-containers/1dfdcf20e35043939ea3f80f002c65c00d560e47223685dbc3230e26fe001b29/userdata/conmon.pid Type=forking [Install] WantedBy=multi-user.target default.target
-
[Unit]
セクションのRequires
行は、container-container0.service
とcontainer-container1.service
ユニットファイルの依存関係を定義します。両方のユニットファイルがアクティベートされます。 -
[Service]
セクションのExecStart
行およびExecStop
行はそれぞれ infra-container を開始して停止します。
-
container-container0.service
ユニットファイルを表示します。$ cat container-container0.service # container-container0.service # autogenerated by Podman 3.3.1 # Wed Sep 8 20:49:17 CEST 2021 [Unit] Description=Podman container-container0.service Documentation=man:podman-generate-systemd(1) Wants=network-online.target After=network-online.target RequiresMountsFor=/run/user/1000/containers BindsTo=pod-systemd-pod.service After=pod-systemd-pod.service [Service] Environment=PODMAN_SYSTEMD_UNIT=%n Restart=on-failure TimeoutStopSec=70 ExecStart=/usr/bin/podman start container0 ExecStop=/usr/bin/podman stop -t 10 container0 ExecStopPost=/usr/bin/podman stop -t 10 container0 PIDFile=/run/user/1000/containers/overlay-containers/4bccd7c8616ae5909b05317df4066fa90a64a067375af5996fdef9152f6d51f5/userdata/conmon.pid Type=forking [Install] WantedBy=multi-user.target default.target
-
[Unit]
セクションのBindsTo
l 行は、pod-systemd-pod.service
ユニットファイルの依存関係を定義します。 -
[Service]
セクションのExecStart
行およびExecStop
行では、それぞれcontainer0
を起動および停止します。
-
container-container1.service
ユニットファイルを表示します。$ cat container-container1.service
生成されたファイルをすべて
$HOME/.config/systemd/user
にコピーして、root 以外のユーザーとしてインストールします。$ cp pod-systemd-pod.service container-container0.service container-container1.service $HOME/.config/systemd/user
ユーザーのログイン時に、サービスを有効にして開始します。
$ systemctl enable --user pod-systemd-pod.service Created symlink /home/user1/.config/systemd/user/multi-user.target.wants/pod-systemd-pod.service → /home/user1/.config/systemd/user/pod-systemd-pod.service. Created symlink /home/user1/.config/systemd/user/default.target.wants/pod-systemd-pod.service → /home/user1/.config/systemd/user/pod-systemd-pod.service.
サービスは、ユーザーのログアウト時に停止される点に注意してください。
検証手順
サービスが有効になっているかどうかを確認します。
$ systemctl is-enabled pod-systemd-pod.service enabled
関連情報
-
podman-create
の man ページ -
podman-generate-systemd
の man ページ -
systemctl
の man ページ - Running containers with Podman and shareable systemd services
- システム起動時に systemd サービスの開始
12.6. Podman を使用したコンテナーの自動更新
podman auto-update
コマンドを使用すると、自動更新のポリシーに従ってコンテナーを自動的に更新できます。podman auto-update
コマンドは、コンテナーイメージがレジストリーで更新されるとサービスを更新します。自動更新を使用するには、 --label "io.containers.autoupdate=image"
ラベルで作成され、podman generate systemd --new
コマンドで生成される systemd ユニットでコンテナーを実行する必要があります。
Podman は、"io.containers.autoupdate"
ラベルが "image"
に設定されている実行中のコンテナーを検索して、コンテナーのレジストリーと通信します。イメージが変更されると、Podman は対応する systemd ユニットを再起動して古いコンテナーを停止し、新しいイメージで新規のコンテナーを作成します。そのため、コンテナー、その環境、およびすべての依存関係が再起動されます。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
registry.access.redhat.com/ubi8/ubi-init
イメージをもとに、myubi
コンテナーを起動します。# podman run --label "io.containers.autoupdate=image" \ --name myubi -dt registry.access.redhat.com/ubi8/ubi-init top bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d
必要に応じて、実行中または終了したコンテナーを一覧表示します。
# podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 76465a5e2933 registry.access.redhat.com/8/ubi-init:latest top 24 seconds ago Up 23 seconds ago myubi
myubi
コンテナーの systemd ユニットファイルを生成します。# podman generate systemd --new --files --name myubi /root/container-myubi.service
/usr/lib/systemd/system
にユニットファイルをコピーして root ユーザーとしてインストールします。# cp -Z ~/container-myubi.service /usr/lib/systemd/system
systemd マネージャーの設定を再読み込みするには、次のコマンドを実行します。
# systemctl daemon-reload
コンテナーを起動して、ステータスを確認します。
# systemctl start container-myubi.service # systemctl status container-myubi.service
コンテナーを自動更新します。
# podman auto-update
12.7. systemd を使用したコンテナーの自動更新
Podman を使用したコンテナーの自動更新 のセクションで説明したように、
podman auto-update
コマンドを使用してコンテナーを更新できます。カスタムスクリプトに組み込み、必要に応じて呼び出すことができます。コンテナーを自動更新する別の方法として、プレインストールされた podman-auto-update.timer
および podman-auto-update.service
systemd サービスを使用できます。podman-auto-update.timer
は、特定の日付と時刻で自動更新をトリガーするように設定できます。podman-auto-update.service
はさらに systemctl
コマンドから起動することも、他の systemd サービスの依存関係として使用することもできます。その結果、時間およびイベントに基づく自動更新は、個々のニーズやユースケースを満たすためにさまざまな方法でトリガーできます。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
podman-auto-update.service
ユニットファイルを表示します。# cat /usr/lib/systemd/system/podman-auto-update.service [Unit] Description=Podman auto-update service Documentation=man:podman-auto-update(1) Wants=network.target After=network-online.target [Service] Type=oneshot ExecStart=/usr/bin/podman auto-update [Install] WantedBy=multi-user.target default.target
podman-auto-update.timer
ユニットファイルを表示します。# cat /usr/lib/systemd/system/podman-auto-update.timer [Unit] Description=Podman auto-update timer [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target
この例では、
podman auto-update
コマンドは、毎日、深夜に起動します。システム起動時に
podman-auto-update.timer
サービスを有効にします。# systemctl enable podman-auto-update.timer
systemd サービスを起動します。
# systemctl start podman-auto-update.timer
必要に応じて、すべてのタイマーを一覧表示します。
# systemctl list-timers --all NEXT LEFT LAST PASSED UNIT ACTIVATES Wed 2020-12-09 00:00:00 CET 9h left n/a n/a podman-auto-update.timer podman-auto-update.service
podman-auto-update.timer
がpodman-auto-update.service
を有効化したことが確認できます。
第13章 コンテナーでの Skopeo、Buildah、および Podman の実行
コンテナーで Skopeo、Buildah、および Podman を実行できます。
Skopeo を使用すると、すべてのレイヤーでイメージ全体をダウンロードすることなく、リモートレジストリーのイメージを検査できます。また、Sopeo を使用して、イメージのコピー、イメージの署名、イメージの同期、さまざまな形式およびレイヤー圧縮でのイメージ変換を行うこともできます。
Buildah を使用すると、OCI コンテナーイメージのビルドが容易になります。Buildah を使用すると、作業コンテナーをゼロから作成することも、イメージを開始点として使用して作成することも可能です。作業コンテナーからか、Containerfile
の指示を使用して、イメージを作成できます。作業コンテナーの root ファイルシステムをマウントおよびアンマウントできます。
Podman を使用すると、コンテナーおよびイメージ、それらのコンテナーにマウントされたボリューム、およびコンテナーのグループから作成された Pod を管理できます。Podman は、コンテナーライフサイクル管理の libpod
ライブラリーに基づいています。libpod
ライブラリーは、コンテナー、Pod、コンテナーイメージ、およびボリュームを管理するための API を提供します。
コンテナーで Buildah、Skopeo、および Podman を実行する理由:
CI/CD システム:
- Podman および Skopeo: Kubernetes で CI/CD システムを実行するか、OpenShift を使用してコンテナーイメージをビルドし、これらのイメージを異なるコンテナーレジストリーに配布できます。Skopeo を Kubernetes ワークフローに統合するには、Skopeo をコンテナーで実行する必要があります。
-
Buildah: 常にイメージをビルドする Kubernetes または OpenShift CI/CD システムに OCI/コンテナーイメージをビルドします。以前は、Docker ソケットを使用してコンテナーエンジンに接続し、
docker build
コマンドを実行していました。これは、パスワードなしにシステムに root アクセスを提供するのと同じで、安全ではありません。このため、Red Hat はコンテナーで Buildah を使用することを推奨します。
各種バージョン:
- All: ホストで古いオペレーティングシステムを実行していても、最新バージョンの Skopeo、Buildah、または Podman を実行します。このソリューションは、コンテナーでコンテナーツールを実行します。たとえば、これは、最新版をネイティブで使用できない Red Hat Enterprise Linux 7 コンテナーホストで、Red Hat Enterprise Linux 8 で提供される最新版のコンテナーツールを実行するのに役立ちます。
HPC 環境:
- all: HPC 環境で一般的な制限は、root 以外のユーザーがホストにパッケージをインストールできないことです。コンテナーで Skopeo、Buildah、または Podman を実行すると、root 以外のユーザーとしてこの特定のタスクを実行することができます。
13.1. コンテナーでの Skopeo の実行
この手順では、Skopeo を使用してリモートコンテナーイメージを検証する方法を説明します。コンテナーで Skopeo を実行すると、コンテナーの root ファイルシステムがホストの root ファイルシステムから分離されることを意味します。ホストとコンテナー間でファイルを共有またはコピーするには、ファイルとディレクトリーをマウントする必要があります。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
registry.redhat.io レジストリーにログインします。
$ podman login registry.redhat.io Username: myuser@mycompany.com Password: <password> Login Succeeded!
registry.redhat.io/rhel8/skopeo
コンテナーイメージを取得します。$ podman pull registry.redhat.io/rhel8/skopeo
Skopeo を使用して、リモートコンテナーイメージ
registry.access.redhat.com/ubi8/ubi
を検査します。$ podman run --rm registry.redhat.io/rhel8/skopeo \ skopeo inspect docker://registry.access.redhat.com/ubi8/ubi { "Name": "registry.access.redhat.com/ubi8/ubi", ... "Labels": { "architecture": "x86_64", ... "name": "ubi8", ... "summary": "Provides the latest release of Red Hat Universal Base Image 8.", "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi8/images/8.2-347", ... }, "Architecture": "amd64", "Os": "linux", "Layers": [ ... ], "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "container=oci" ] }
--rm
オプションは、コンテナーの終了後にregistry.redhat.io/rhel8/skopeo
イメージを削除します。
13.2. 認証情報を使用したコンテナーでの Skopeo の実行
コンテナーレジストリーを使用する場合には、データへのアクセスや変更に認証が必要です。skopeo は、さまざまな認証情報の指定方法に対応します。
このアプローチでは、--cred USERNAME[:PASSWORD]
オプションを使用してコマンドラインで認証情報を指定できます。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
ロックされたレジストリーに対して Skopeo を使用してリモートコンテナーイメージを検証します。
$ podman run --rm registry.redhat.io/rhel8/skopeo inspect --creds $USER:$PASSWORD docker://$IMAGE
13.3. authfile を使用したコンテナーでの Skopeo の実行
認証ファイル (authfile) を使用して認証情報を指定できます。skopeo login
コマンドは、特定のレジストリーにログインし、認証トークンを authfile に保存します。authfiles を使用する利点は、認証情報を繰り返し入力する必要がないことです。
同じホストで実行する場合、Sopeo、Buildah、Podman などのすべてのコンテナーツールで同じ authfile を共有します。コンテナーで Skopeo を実行する場合は、コンテナーに authfile をボリュームマウントしてホスト上で authfile を共有するか、コンテナー内で再認証する必要があります。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
ロックされたレジストリーに対して Skopeo を使用してリモートコンテナーイメージを検証します。
$ podman run --rm -v $AUTHFILE:/auth.json registry.redhat.io/rhel8/skopeo inspect docker://$IMAGE
-v $AUTHFILE:/auth.json
オプションの volume-mounts は、コンテナー内の /auth.json に authfile をマウントします。Skopeo は、ホストの authfile の認証トークンにアクセスでき、レジストリーにセキュアにアクセスできるようになります。
その他の Skopeo コマンドは、以下の例のように機能します。
-
skopeo-copy
コマンドで--source-creds
および--dest-creds
オプションを使用して、ソースおよび宛先のイメージに、コマンドラインで認証情報を指定します。また、/auth.json
の authfile も読み取ります。 -
ソースイメージおよび宛先イメージに個別の authfile を指定する場合は、
--source-authfile
オプションおよび--dest-authfile
オプションを使用し、ホストからコンテナーにこれらの authfile をボリュームマウントします。
13.4. ホストに対するコンテナーイメージのコピー
skopeo、Buildah、Podman は同じローカルコンテナーイメージストレージを共有します。ホストコンテナーストレージとの間でコンテナーをコピーする場合は、これを Skopeo コンテナーにマウントする必要があります。
ホストコンテナーストレージへのパスは、root (/var/lib/containers/storage
) と root 以外のユーザー ($HOME/.local/share/containers/storage
) の間で異なります。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
registry.access.redhat.com/ubi8/ubi
イメージをローカルストレージにコピーします。$ podman run --privileged --rm -v $HOME/.local/share/containers/storage:/var/lib/containers/storage \ registry.redhat.io/rhel8/skopeo skopeo copy \ docker://registry.access.redhat.com/ubi8/ubi containers-storage:registry.access.redhat.com/ubi8/ubi
-
--privileged
オプションは、すべてのセキュリティーメカニズムを無効にします。Red Hat では、このオプションは信頼できる環境でのみ使用することを推奨します。 セキュリティーメカニズムを無効にするには、イメージを tarball またはその他のパスベースのイメージトランスポートにエクスポートして Skopeo コンテナーにマウントします。
-
$ podman save --format oci-archive -o oci.tar $IMAGE
-
$ podman run --rm -v oci.tar:/oci.tar registry.redhat.io/rhel8/skopeo copy oci-archive:/oci.tar $DESTINATION
-
-
必要に応じて ローカルストレージ内のイメージを一覧表示します。
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi8/ubi latest ecbc6f53bba0 8 weeks ago 211 MB
13.5. コンテナーでの Buildah の実行
この手順では、コンテナーで Buildah を実行し、イメージを基に作業コンテナーを作成する方法を説明します。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
registry.redhat.io レジストリーにログインします。
$ podman login registry.redhat.io Username: myuser@mycompany.com Password: <password> Login Succeeded!
registry.redhat.io/rhel8/buildah
イメージをプルして実行します。# podman run --rm --device /dev/fuse --cap-add sys_chroot -it \ registry.redhat.io/rhel8/buildah /bin/bash
-
--rm
オプションは、コンテナーの終了後にregistry.redhat.io/rhel8/buildah
イメージを削除します。 -
--device
オプションは、ホストデバイスをコンテナーに追加します。 -
sys_chroot
- 別のルートディレクトリーに変更する機能。コンテナーのデフォルト機能には含まれていません。
-
registry.access.redhat.com/ubi8
イメージを使用して、新しいコンテナーを作成します。# buildah from registry.access.redhat.com/ubi8 ... ubi8-working-container
ubi8-working-container
コンテナー内でls /
コマンドを実行します。# buildah run --isolation=chroot ubi8-working-container ls / bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv
必要に応じて、ローカルストレージ内の全イメージを一覧表示します。
# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi8 latest ecbc6f53bba0 5 weeks ago 211 MB
必要に応じて、作業用コンテナーとそのベースイメージを一覧表示します。
# buildah containers CONTAINER ID BUILDER IMAGE ID IMAGE NAME CONTAINER NAME 0aaba7192762 * ecbc6f53bba0 registry.access.redhat.com/ub... ubi8-working-container
必要に応じて、
registry.access.redhat.com/ubi8
イメージをregistry.example.com
にあるローカルレジストリーにプッシュします。# buildah push ecbc6f53bba0 registry.example.com:5000/ubi8/ubi
13.6. 特権および非特権 Podman コンテナー
デフォルトでは、Podman コンテナーは権限がないため、たとえばホスト上のオペレーティングシステムの一部を変更することはできません。これは、デフォルトでは、コンテナーはデバイスへの限定的なアクセスしか許可されないためです。
以下は、特権コンテナーの重要なプロパティーの一覧です。特権コンテナーは、podman run --privileged <image_name>
コマンドを使用して実行できます。
- 特権コンテナーには、コンテナーを起動するユーザーと同じデバイスへのアクセス権限が付与されます。
- 特権コンテナーは、コンテナーをホストから分離するセキュリティー機能を無効にします。削除された機能、制限されたデバイス、読み取り専用マウントポイント、Apparmor/SELinux の分離、および Seccomp フィルターは、すべて無効にされます。
- 特権コンテナーには、それらを起動したアカウント以上の特権を割り当てることはできません。
関連情報
- How to use the --privileged flag with container engines
-
podman-run
の man ページ
13.7. 拡張された権限での Podman の実行
ルートレス環境でワークロードを実行できない場合は、これらのワークロードを root ユーザーとして実行する必要があります。拡張された権限でのコンテナーの実行は、慎重に実施する必要があります。すべてのセキュリティー機能が無効になるためです。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
Podman コンテナー内で Podman コンテナーを実行します。
$ podman run --privileged --name=privileged_podman \ registry.access.redhat.com/ubi8/podman podman run ubi8 echo hello Resolved "ubi8" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf) Trying to pull registry.access.redhat.com/ubi8:latest... ... Storing signatures hello
-
registry.access.redhat.com/rhel8/podman
イメージに基づいて、privileged_podman
という名前の外部コンテナーを実行します。 -
--privileged
オプションは、コンテナーをホストから分離するセキュリティー機能を無効にします。 -
podman run ubi8 echo hello
コマンドを実行して、ubi8
イメージに基づいて内部コンテナーを作成します。 -
ubi8
の短縮イメージ名がエイリアスとして解決されていることに注意してください。これにより、registry.access.redhat.com/ubi8:latest
イメージがプルされます。
検証
すべてのコンテナーを一覧表示します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 52537876caf4 registry.access.redhat.com/ubi8/podman podman run ubi8 e... 30 seconds ago Exited (0) 13 seconds ago privileged_podman
関連情報
- How to use Podman inside of a container
-
podman-run
の man ページ
13.8. 少ない権限での Podman の実行
--privileged
オプションを指定せずに、ネストされた 2 つの Podman コンテナーを実行できます。--privileged
オプションを指定せずにコンテナーを実行することは、より安全なオプションです。
これは、可能な限り安全な方法で異なるバージョンの Podman を試す場合に役立ちます。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
手順
ネストされた 2 つのコンテナーを実行します。
$ podman run --name=unprivileged_podman --security-opt label=disable \ --user podman --device /dev/fuse \ registry.access.redhat.com/ubi8/podman \ podman run ubi8 echo hello
-
registry.access.redhat.com/ubi8/podman
イメージに基づいて、unprivileged_podman
という名前の外部コンテナーを実行します。 -
--security-opt label=disable
オプションは、ホスト Podman での SELinux の分離を無効にします。SELinux では、コンテナー化されたプロセスは、コンテナー内で実行するために必要なすべてのファイルシステムをマウントすることはできません。 -
--user podman
オプションを指定すると、自動的に、外部コンテナー内の Podman がユーザーの名前空間内で実行されるようになります。 -
--device /dev/fuse
オプションは、コンテナー内のfuse-overlayfs
パッケージを使用します。このオプションは/dev/fuse
を外部コンテナーに追加し、コンテナー内の Podman がこれを使用できるようにします。 -
podman run ubi8 echo hello
コマンドを実行して、ubi8
イメージに基づいて内部コンテナーを作成します。 -
ubi8 の短縮イメージ名がエイリアスとして解決されていることに注意してください。これにより、
registry.access.redhat.com/ubi8:latest
イメージがプルされます。
検証
すべてのコンテナーを一覧表示します。
$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a47b26290f43 podman run ubi8 e... 30 seconds ago Exited (0) 13 seconds ago unprivileged_podman
13.9. Podman コンテナー内でのコンテナーのビルド
この手順では、Podman を使用してコンテナー内でコンテナーを実行する方法を説明します。この例では、Podman を使用してコンテナーから別のコンテナーをビルドし、実行する方法を示しています。コンテナーは、簡単なテキストベースのゲーム Moon-buggy を実行します。
前提条件
container-tools
モジュールがインストールされている。# yum module install -y container-tools
registry.redhat.io レジストリーにログインしている。
# podman login registry.redhat.io
手順
registry.redhat.io/rhel8/podman
イメージをベースとするコンテナーを実行します。# podman run --privileged --name podman_container -it \ registry.redhat.io/rhel8/podman /bin/bash
-
registry.access.redhat.com/rhel8/podman
イメージに基づいて、privileged_podman
という名前の外部コンテナーを実行します。 -
--it
オプションは、コンテナー内で対話式 bash シェルを実行します。 -
--privileged
オプションは、コンテナーをホストから分離するセキュリティー機能を無効にします。
-
podman_container
コンテナー内にContainerfile
を作成します。# vi Containerfile FROM registry.access.redhat.com/ubi8/ubi RUN yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm RUN yum -y install moon-buggy && yum clean all CMD ["/usr/bin/moon-buggy"]
Containerfile
のコマンドで以下の build コマンドが実行されます。-
registry.access.redhat.com/ubi8/ubi
イメージからコンテナーをビルドします。 -
epel-release-latest-8.noarch.rpm
パッケージをインストールします。 -
moon-buggy
パッケージをインストールします。 - コンテナーコマンドを設定します。
-
Containerfile
を使用してmoon-buggy
という名前の新しいコンテナーイメージをビルドします。# podman build -t moon-buggy .
必要に応じて、すべてのイメージを一覧表示します。
# podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/moon-buggy latest c97c58abb564 13 seconds ago 1.67 GB registry.access.redhat.com/ubi8/ubi latest 4199acc83c6a 132seconds ago 213 MB
moon-buggy
コンテナーに基づいて新しいコンテナーを実行します。# podman run -it --name moon moon-buggy
必要に応じて、
moon-buggy
イメージをタグ付けします。# podman tag moon-buggy registry.example.com/moon-buggy
必要に応じて、
moon-buggy
イメージをレジストリーにプッシュします。# podman push registry.example.com/moon-buggy
第14章 Buildah でコンテナーイメージの構築
Buildah は、OCI Runtime Specification を満たす OCI コンテナーイメージの構築を容易にします。Buildah を使用すると、作業コンテナーをゼロから作成することも、イメージを開始点として使用して作成することも可能です。作業コンテナーからか、Containerfile
の指示を使用して、イメージを作成できます。作業コンテナーの root ファイルシステムをマウントおよびアンマウントできます。
14.1. Buildah ツール
Buildah を使用することは、以下の点で、docker コマンドでイメージを作成するのと異なります。
- デーモンなし
- Buildah にはコンテナーランタイムは必要ありません。
- ベースイメージまたは scratch
- 別のコンテナーに基づいてイメージをビルドしたり、空のイメージで始めることができます。
- ビルドツールが外部のもの
Buildah では、イメージ自体にはビルドツールが含まれません。その結果、Buildah は以下のようになります。
- ビルドイメージのサイズを縮小します。
- 作成されたイメージからソフトウェア (gcc、make、yum など) を除外して、イメージのセキュリティーを強化します。
- イメージサイズの縮小により、少ないリソースを使用してイメージを転送できます。
- 互換性
- Buildah は、Dockerfile を使用したコンテナーイメージの構築をサポートしており、Docker から Buildah への移行を容易にします。
Buildah がコンテナーストレージにデフォルトで使用する場所は、CRI-O コンテナーエンジンがイメージのローカルコピーを保存するために使用する場所と同じです。そのため、CRI-O または Buildah で、もしくは buildah コマンドでレジストリーから取得したイメージは、同じディレクトリー構造に保存されます。ただし、CRI-O および Buildah が現在イメージを共有できても、コンテナーを共有することはできません。
関連情報
- Buildah - a tool that facilitates building Open Container Initiative (OCI) container images
- Buildah Tutorial 1: Building OCI container images
- Buildah Tutorial 2: Using Buildah with container registries
- Building with Buildah: Dockerfiles, command line, or scripts
- How rootless Buildah works: Building containers in unprivileged environments
14.2. Buildah のインストール
yum
コマンドを使用して Buildah ツールをインストールします。
手順
Buildah ツールをインストールします。
# yum -y install buildah
検証
ヘルプメッセージを表示します。
# buildah -h
14.3. Buildah でイメージの取得
buildah from
コマンドを使用して、新規作業コンテナーをゼロから作成するか、または指定したイメージを開始点として作成します。
手順
registry.redhat.io/ubi8/ubi
イメージをもとに、新しい作業コンテナーを作成します。# buildah from registry.access.redhat.com/ubi8/ubi Getting image source signatures Copying blob… Writing manifest to image destination Storing signatures ubi-working-container
検証
ローカルストレージ内のイメージを一覧表示します。
# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi8/ubi latest 272209ff0ae5 2 weeks ago 234 MB
作業用のコンテナーおよびそれらのベースイメージを一覧表示します。
# buildah containers CONTAINER ID BUILDER IMAGE ID IMAGE NAME CONTAINER NAME 01eab9588ae1 * 272209ff0ae5 registry.access.redhat.com/ub... ubi-working-container
関連情報
-
buildah-from
の man ページ -
buildah-images
の man ページ -
buildah.containers
の man ページ
14.4. コンテナー内でのコマンドの実行
buildah run
コマンドを使用して、コンテナーからコマンドを実行します。
前提条件
- プルしたイメージがローカルシステムで利用できる。
手順
オペレーティングシステムのバージョンを表示します。
# buildah run ubi-working-container cat /etc/redhat-release Red Hat Enterprise Linux release 8.4 (Ootpa)
関連情報
-
buildah-run
の man ページ
14.5. Buildah を使用した Containerfile からのイメージのビルド
buildah bud
コマンドを使用して、Containerfile
からのステップを使用してイメージをビルドします。
buildah bud
コマンドは、コンテキストディレクトリーにある場合に、Containerfile
を使用します。コンテキストディレクトリーにない場合、buildah bud
コマンドは Dockerfile
を使用します。それ以外の場合は、--file
オプションでファイルを指定できます。Containerfile
および Dockerfile
内で使用できる利用可能なコマンドは同じです。
手順
Containerfile
を作成します。# cat Containerfile FROM registry.access.redhat.com/ubi8/ubi ADD myecho /usr/local/bin ENTRYPOINT "/usr/local/bin/myecho"
myecho
スクリプトを作成します。# cat myecho echo "This container works!"
myecho
スクリプトのアクセスパーミッションを変更します。# chmod 755 myecho
現在のディレクトリーの
Containerfile
を使用してmyecho
イメージをビルドします。# buildah bud -t myecho . STEP 1: FROM registry.access.redhat.com/ubi8/ubi STEP 2: ADD myecho /usr/local/bin STEP 3: ENTRYPOINT "/usr/local/bin/myecho" STEP 4: COMMIT myecho ... Storing signatures
検証
すべてのイメージを一覧表示します。
# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/myecho latest b28cd00741b3 About a minute ago 234 MB
localhost/myecho
イメージに基づいてmyecho
コンテナーを実行します。# podman run --name=myecho localhost/myecho This container works!
すべてのコンテナーを一覧表示します。
# podman ps -a 0d97517428d localhost/myecho 12 seconds ago Exited (0) 13 seconds ago myecho
podman history
コマンドを使用して、イメージで使用された各レイヤーに関する情報を表示できます。
関連情報
-
buildah-bud
の man ページ
14.6. Buildah でコンテナーおよびイメージの検証
buildah inspect
コマンドを使用して、コンテナーまたはイメージに関する情報を表示します。
前提条件
- イメージが Containerfile の命令を使用してビルドされている。詳細は、Buildah を使用した Containerfile からのイメージのビルドを参照してください。
手順
イメージを検証します。
myecho イメージを検証するには、以下を入力します。
# buildah inspect localhost/myecho { "Type": "buildah 0.0.1", "FromImage": "localhost/myecho:latest", "FromImageID": "b28cd00741b38c92382ee806e1653eae0a56402bcd2c8d31bdcd36521bc267a4", "FromImageDigest": "sha256:0f5b06cbd51b464fabe93ce4fe852a9038cdd7c7b7661cd7efef8f9ae8a59585", "Config": ... "Entrypoint": [ "/bin/sh", "-c", "\"/usr/local/bin/myecho\"" ], ... }
myecho
イメージから作業コンテナーを検証するには、以下を実行します。localhost/myecho
イメージをもとに作業コンテナーを作成します。# buildah from localhost/myecho
myecho-working-container
コンテナーを検査します。# buildah inspect ubi-working-container { "Type": "buildah 0.0.1", "FromImage": "registry.access.redhat.com/ubi8/ubi:latest", "FromImageID": "272209ff0ae5fe54c119b9c32a25887e13625c9035a1599feba654aa7638262d", "FromImageDigest": "sha256:77623387101abefbf83161c7d5a0378379d0424b2244009282acb39d42f1fe13", "Config": ... "Container": "ubi-working-container", "ContainerID": "01eab9588ae1523746bb706479063ba103f6281ebaeeccb5dc42b70e450d5ad0", "ProcessLabel": "system_u:system_r:container_t:s0:c162,c1000", "MountLabel": "system_u:object_r:container_file_t:s0:c162,c1000", ... }
関連情報
-
buildah-inspect
の man ページ
14.7. buildah mount を使用したコンテナーの変更
buildah inspect
コマンドを使用して、コンテナーまたはイメージに関する情報を表示します。
前提条件
- Containerfile の指示を使用してビルドされたイメージ。詳細は、Buildah を使用した Containerfile からのイメージのビルドを参照してください。
手順
registry.access.redhat.com/ubi8/ubi
イメージをもとに作業コンテナーを作成し、コンテナーの名前をmycontainer
変数に保存します。# mycontainer=$(buildah from localhost/myecho) # echo $mycontainer myecho-working-container
myecho-working-container
コンテナーをマウントし、マウントポイントパスをmymount
変数に保存します。# mymount=$(buildah mount $mycontainer) # echo $mymount /var/lib/containers/storage/overlay/c1709df40031dda7c49e93575d9c8eebcaa5d8129033a58e5b6a95019684cc25/merged
myecho
スクリプトを変更し、実行可能にします。# echo 'echo "We modified this container."' >> $mymount/usr/local/bin/myecho # chmod +x $mymount/usr/local/bin/myecho
myecho-working-container
コンテナーからmyecho2
イメージを作成します。# buildah commit $mycontainer containers-storage:myecho2
検証
ローカルストレージ内のイメージを一覧表示します。
# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/myecho2 latest 4547d2c3e436 4 minutes ago 234 MB localhost/myecho latest b28cd00741b3 56 minutes ago 234 MB
docker.io/library/myecho2
イメージに基づいてmyecho2
コンテナーを実行します。# podman run --name=myecho2 docker.io/library/myecho2 This container works! We even modified it.
関連情報
-
buildah-mount
の man ページ -
buildah-commit
の man ページ
14.8. buildah copy および buildah config を使用したコンテナーの変更
buildah copy
コマンドを使用して、マウントせずにファイルをコンテナーにコピーします。次に、buildah config
コマンドを使用して、デフォルトで作成したスクリプトを実行するコンテナーを設定できます。
前提条件
- Containerfile の指示を使用してビルドされたイメージ。詳細は、Buildah を使用した Containerfile からのイメージのビルドを参照してください。
手順
newecho
という名前のスクリプトを作成し、実行可能にします。# cat newecho echo "I changed this container" # chmod 755 newecho
新しい作業コンテナーを作成します。
# buildah from myecho:latest myecho-working-container-2
newecho スクリプトを、コンテナー内の
/usr/local/bin
ディレクトリーにコピーします。# buildah copy myecho-working-container-2 newecho /usr/local/bin
newecho
スクリプトを、新しいエントリーポイントとして使用するように設定を変更します。# buildah config --entrypoint "/bin/sh -c /usr/local/bin/newecho" myecho-working-container-2
オプション:実行する
newecho
スクリプトのトリガーとなるmyecho-working-container-2
コンテナーを実行します。# buildah run myecho-working-container-2 -- sh -c '/usr/local/bin/newecho' I changed this container
myecho-working-container-2
コンテナーを、mynewecho
という新しいイメージにコミットします。# buildah commit myecho-working-container-2 containers-storage:mynewecho
検証
ローカルストレージ内のイメージを一覧表示します。
# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/mynewecho latest fa2091a7d8b6 8 seconds ago 234 MB
関連情報
-
buildah-copy
の man ページ -
buildah-config
の man ページ -
buildah-commit
の man ページ -
buildah-run
の man ページ
14.9. Buildah でゼロからイメージを新規作成
ベースイメージから開始する代わりに、最低限のコンテナーメタデータのみを保持する新しいコンテナーを作成できます。
スクラッチコンテナーからイメージを作成するときは、次のことを考慮してください。
- scratch イメージに依存関係のない実行ファイルをコピーして、最小コンテナーを機能させるため、いくつかの設定を行うことができます。
-
RPM データベースを初期化し、
yum
やrpm
などのツールを使用するために、コンテナーにリリースパッケージを追加する必要があります。 - パッケージを多数追加する場合は、scratch イメージではなく、標準の UBI イメージまたは最小 UBI イメージの使用を検討してください。
手順
この手順では、コンテナーに Web サービス httpd を追加し、これを実行するように設定します。
空のコンテナーを作成します。
# buildah from scratch working-container
working-container
コンテナーをマウントし、マウントポイントパスをscratchmnt
変数に保存します。# scratchmnt=$(buildah mount working-container) # echo $scratchmnt /var/lib/containers/storage/overlay/be2eaecf9f74b6acfe4d0017dd5534fde06b2fa8de9ed875691f6ccc791c1836/merged
scratch イメージで RPM データベースを初期化し、
redhat-release
パッケージを追加します。# yum install -y --releasever=8 --installroot=$scratchmnt redhat-release
http
httpd
サービスをscratch
ディレクトリーにインストールします。# yum install -y --setopt=reposdir=/etc/yum.repos.d \ --installroot=$scratchmnt \ --setopt=cachedir=/var/cache/dnf httpd
$scratchmnt/var/www/html/index.html
ファイルを作成します。# mkdir -p $scratchmnt/var/www/html # echo "Your httpd container from scratch works!" > $scratchmnt/var/www/html/index.html
コンテナーから直接
httpd
デーモンを実行するようにworking-container
を設定します。# buildah config --cmd "/usr/sbin/httpd -DFOREGROUND" working-container # buildah config --port 80/tcp working-container # buildah commit working-container localhost/myhttpd:latest
検証
ローカルストレージ内のイメージを一覧表示します。
# podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/myhttpd latest 08da72792f60 2 minutes ago 121 MB
localhost/myhttpd
イメージを実行し、コンテナーとホストシステム間のポートマッピングを設定します。# podman run -p 8080:80 -d --name myhttpd 08da72792f60
Web サーバーをテストします。
# curl localhost:8080 Your httpd container from scratch works!
関連情報
-
buildah-config
の man ページ -
buildah-commit
の man ページ
14.10. プライベートレジストリーへのコンテナーのプッシュ
buildah push
コマンドを使用して、イメージをローカルストレージからパブリックリポジトリーまたはプライベートリポジトリーにプッシュします。
前提条件
- イメージが Containerfile の命令を使用してビルドされている。詳細は、Buildah を使用した Containerfile からのイメージのビルドを参照してください。
手順
マシンにローカルレジストリーを作成します。
# podman run -d -p 5000:5000 registry:2
myecho:latest
イメージをlocalhost
レジストリーにプッシュします。# buildah push --tls-verify=false myecho:latest localhost:5000/myecho:latest Getting image source signatures Copying blob sha256:e4efd0... ... Writing manifest to image destination Storing signatures
検証
localhost
リポジトリー内のイメージを一覧表示します。# curl http://localhost:5000/v2/_catalog {"repositories":["myecho2]} # curl http://localhost:5000/v2/myecho2/tags/list {"name":"myecho","tags":["latest"]}
docker://localhost:5000/myecho:latest
イメージを調査します。# skopeo inspect --tls-verify=false docker://localhost:5000/myecho:latest | less { "Name": "localhost:5000/myecho", "Digest": "sha256:8999ff6050...", "RepoTags": [ "latest" ], "Created": "2021-06-28T14:44:05.919583964Z", "DockerVersion": "", "Labels": { "architecture": "x86_64", "authoritative-source-url": "registry.redhat.io", ... }
localhost:5000/myecho
イメージをプルします。# podman pull --tls-verify=false localhost:5000/myecho2 # podman run localhost:5000/myecho2 This container works!
関連情報
-
buildah-push
の man ページ
14.11. Docker Hub へのコンテナーのプッシュ
buildah
コマンドで、Docker Hub の認証情報を使用して、Docker Hub からイメージをプッシュおよびプルします。
前提条件
- Containerfile の指示を使用してビルドされたイメージ。詳細は、Buildah を使用した Containerfile からのイメージのビルドを参照してください。
手順
docker.io/library/myecho:latest
を Docker Hub にプッシュします。username
およびpassword
を、Docker Hub 認証情報に置き換えます。# buildah push --creds username:password \ docker.io/library/myecho:latest docker://testaccountXX/myecho:latest
検証
docker.io/testaccountXX/myecho:latest
イメージを取得して実行します。Podman ツールの使用:
# podman run docker.io/testaccountXX/myecho:latest This container works!
Buildah および Podman ツールの使用:
# buildah from docker.io/testaccountXX/myecho:latest myecho2-working-container-2 # podman run myecho-working-container-2
関連情報
-
buildah-push
の man ページ
14.12. Buildah でイメージの削除
buildah rmi
コマンドを使用して、ローカルに保存されたコンテナーイメージを削除します。ID または名前を使用して、イメージを削除できます。
手順
ローカルシステムにある全イメージの一覧を表示します。
# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/johndoe/webserver latest dc5fcc610313 46 minutes ago 263 MB docker.io/library/mynewecho latest fa2091a7d8b6 17 hours ago 234 MB docker.io/library/myecho2 latest 4547d2c3e436 6 days ago 234 MB localhost/myecho latest b28cd00741b3 6 days ago 234 MB localhost/ubi-micro-httpd latest c6a7678c4139 12 days ago 152 MB registry.access.redhat.com/ubi8/ubi latest 272209ff0ae5 3 weeks ago 234 MB
localhost/myecho
イメージを削除します。# buildah rmi localhost/myecho
複数のイメージを削除するには、以下のコマンドを実行します。
# buildah rmi docker.io/library/mynewecho docker.io/library/myecho2
システムからすべてのイメージを削除するには、以下のコマンドを実行します。
# buildah rmi -a
複数の名前 (タグ) が関連付けられているイメージを削除するには、
-f
オプションを追加して削除します。# buildah rmi -f localhost/ubi-micro-httpd
検証
イメージが削除されていることを確認します。
# buildah images
関連情報
-
buildah-rmi
の man ページ
14.13. Buildah でコンテナーの削除
buildah rm
コマンドを使用して、コンテナーを削除します。コンテナー ID または名前で、削除するコンテナーを指定できます。
前提条件
- 1 つ以上のコンテナーが停止されている。
手順
すべてのコンテナーを一覧表示します。
# buildah containers CONTAINER ID BUILDER IMAGE ID IMAGE NAME CONTAINER NAME 05387e29ab93 * c37e14066ac7 docker.io/library/myecho:latest myecho-working-container
myecho-working-container コンテナーを削除します。
# buildah rm myecho-working-container 05387e29ab93151cf52e9c85c573f3e8ab64af1592b1ff9315db8a10a77d7c22
検証
コンテナーが削除されていることを確認します。
# buildah containers
関連情報
-
buildah-rm
の man ページ
第15章 コンテナーの監視
Podman コマンドを使用して Podman 環境を管理します。これにより、システムおよび Pod 情報を表示し、Podman イベントをモニターすることで、コンテナーの正常性を判別できます。
15.1. コンテナーでヘルスチェックを使用する
ヘルスチェックを使用して、コンテナー内で実行されているプロセスの状態または準備ができているかどうかを判断できます。
ヘルスチェックが成功すると、コンテナーは正常とマークされます。そうでなければ、それは正常ではありません。podman exec
コマンドを実行して終了コードを調べることで、ヘルスチェックを比較できます。ゼロの終了値は、コンテナーが正常であることを意味します。
Containerfile
で HEALTHCHECK
命令を使用してイメージをビルドするとき、またはコマンドラインでコンテナーを作成するときに、ヘルスチェックを設定できます。podman inspect
または podman ps
コマンドを使用して、コンテナーのヘルスチェックのステータスを表示できます。
ヘルスチェックは、次の 6 つの基本コンポーネントで設定されます。
- コマンド
- Retries
- Interval
- Start-period
- Timeout
- コンテナー回収
ヘルスチェックコンポーネントの説明は次のとおりです。
- コマンド (
--health-cmd
オプション) - Podman は、ターゲットコンテナー内でコマンドを実行して終了コードを待ちます。
他の 5 つのコンポーネントは、ヘルスチェックのスケジューリングに関連しており、オプションです。
- 再試行 (
--health-retries
オプション) - 正常でないとマークするまでに、ヘルスチェックで連続して不合格とならなければならないか、その回数を定義します。Healthcheck に成功すると、再試行数がリセットされます。
- 間隔 (
--health-interval
オプション) - 次回に healthcheck コマンドを実行するまでの時間を指定します。間隔が短いと、システムでの healthcheck の実行時間が長くなる点に注意してください。間隔が長いと、タイムアウトの検出が困難になります。
- 開始期間 (
--health-start-period
オプション) - コンテナーを起動してから healthcheck の不合格を無視するまでの時間を指定します。
- タイムアウト (
--health-timeout
オプション) - healthcheck の完了前に不合格とみなされるまでの期間を指定します。
Retries、Interval、および Start-period コンポーネントの値は、30s や 1h15m などの期間です。有効な時間単位は、ns、us、またはµs、ms、s、m、および h です。
- コンテナーの復旧 (
--health-on-failure
オプション) コンテナーのステータスが異常な場合に実行するアクションを決定します。アプリケーションに障害が発生すると、Podman は自動的にアプリケーションを再起動して堅牢性を提供します。
--health-on-failure
オプションは、次の 4 つのアクションをサポートします。-
none
: アクションを実行しません。これがデフォルトのアクションです。 -
kill
: コンテナーを強制終了します。 -
restart
: コンテナーを再起動します。 stop
: コンテナーを停止します。注記--health-on-failure
オプションは、Podman バージョン 4.2 以降で使用できます。
-
restart
アクションを --restart
オプションと組み合わせないでください。systemd ユニット内で実行する場合は、代わりに kill
または stop
アクションを使用して、systemd の再起動ポリシーを利用することを検討してください。
コンテナー内でヘルスチェックが実行されます。ヘルスチェックは、サービスのヘルス状態がどのようなものかを把握しており、ヘルスチェックの成功と失敗を区別できる場合にのみ意味があります。
関連情報
-
podman-healthcheck
man ページ -
podman-run
の man ページ - エッジの Podman: カスタムのヘルスチェックアクションでサービスを維持する
- Monitoring container vitality and availability with Podman
15.2. コマンドラインを使用してヘルスチェックを実行する
コマンドラインでコンテナーを作成するときに、ヘルスチェックを設定できます。
手順
ヘルスチェックを定義します。
$ podman run -dt --name=hc-container -p 8080:8080 --health-cmd='curl http://localhost:8080 || exit 1' --health-interval=0 registry.access.redhat.com/ubi8/httpd-24
-
--health-cmd
オプションは、コンテナーの healthcheck コマンドを設定します。 -
healthcheck を手動で実行するには、
--health-interval=0
オプション で 0 の値を指定します。
-
hc-container
コンテナーのヘルスステータスを確認します。podman inspect
コマンドの使用:$ podman inspect --format='{{json .State.Health.Status}}' hc-container healthy
podman ps
コマンドの使用:$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a680c6919fe localhost/hc-container:latest /usr/bin/run-http... 2 minutes ago Up 2 minutes (healthy) hc-container
podman healthcheck run
コマンドを使用します。$ podman healthcheck run hc-container healthy
関連情報
-
podman-healthcheck
man ページ -
podman-run
の man ページ - エッジの Podman: カスタムのヘルスチェックアクションでサービスを維持する
- Monitoring container vitality and availability with Podman
15.3. Containerfile を使用してヘルスチェックを実行する
Containerfile
で HEALTHCHECK
命令を使用してヘルスチェックを設定できます。
手順
Containerfile
を作成します。$ cat Containerfile FROM registry.access.redhat.com/ubi8/httpd-24 EXPOSE 8080 HEALTHCHECK CMD curl http://localhost:8080 || exit 1
注記HEALTHCHECK
命令は、docker
イメージ形式でのみサポートされています。oci
イメージ形式の場合、命令は無視されます。コンテナーをビルドし、イメージ名を追加します。
$ podman build --format=docker -t hc-container . STEP 1/3: FROM registry.access.redhat.com/ubi8/httpd-24 STEP 2/3: EXPOSE 8080 --> 5aea97430fd STEP 3/3: HEALTHCHECK CMD curl http://localhost:8080 || exit 1 COMMIT health-check Successfully tagged localhost/health-check:latest a680c6919fe6bf1a79219a1b3d6216550d5a8f83570c36d0dadfee1bb74b924e
コンテナーを実行します。
$ podman run -dt --name=hc-container localhost/hc-container
hc-container
コンテナーのヘルスステータスを確認します。podman inspect
コマンドの使用:$ podman inspect --format='{{json .State.Health.Status}}' hc-container healthy
podman ps
コマンドの使用:$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a680c6919fe localhost/hc-container:latest /usr/bin/run-http... 2 minutes ago Up 2 minutes (healthy) hc-container
podman healthcheck run
コマンドを使用します。$ podman healthcheck run hc-container healthy
関連情報
-
podman-healthcheck
man ページ -
podman-run
の man ページ - エッジの Podman: カスタムのヘルスチェックアクションでサービスを維持する
- Monitoring container vitality and availability with Podman
15.4. Podman システム情報の表示
podman system
コマンドを使用すると、システム情報を表示することで Podman システムを管理できます。
手順
Podman システム情報を表示します。
Podman のディスク使用量を表示するには、以下を入力します。
$ podman system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 3 2 1.085GB 233.4MB (0%) Containers 2 0 28.17kB 28.17kB (100%) Local Volumes 3 0 0B 0B (0%)
領域の使用状況に関する詳細情報を表示するには、次のコマンドを実行します。
$ podman system df -v Images space usage: REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS registry.access.redhat.com/ubi8 latest b1e63aaae5cf 13 days 233.4MB 233.4MB 0B 0 registry.access.redhat.com/ubi8/httpd-24 latest 0d04740850e8 13 days 461.5MB 0B 461.5MB 1 registry.redhat.io/rhel8/podman latest dce10f591a2d 13 days 390.6MB 233.4MB 157.2MB 1 Containers space usage: CONTAINER ID IMAGE COMMAND LOCAL VOLUMES SIZE CREATED STATUS NAMES 311180ab99fb 0d04740850e8 /usr/bin/run-httpd 0 28.17kB 16 hours exited hc1 bedb6c287ed6 dce10f591a2d podman run ubi8 echo hello 0 0B 11 hours configured dazzling_tu Local Volumes space usage: VOLUME NAME LINKS SIZE 76de0efa83a3dae1a388b9e9e67161d28187e093955df185ea228ad0b3e435d0 0 0B 8a1b4658aecc9ff38711a2c7f2da6de192c5b1e753bb7e3b25e9bf3bb7da8b13 0 0B d9cab4f6ccbcf2ac3cd750d2efff9d2b0f29411d430a119210dd242e8be20e26 0 0B
Podman のホスト、現在のストレージ統計、およびビルドについての情報を表示するには、以下を入力します。
$ podman system info host: arch: amd64 buildahVersion: 1.22.3 cgroupControllers: [] cgroupManager: cgroupfs cgroupVersion: v1 conmon: package: conmon-2.0.29-1.module+el8.5.0+12381+e822eb26.x86_64 path: /usr/bin/conmon version: 'conmon version 2.0.29, commit: 7d0fa63455025991c2fc641da85922fde889c91b' cpus: 2 distribution: distribution: '"rhel"' version: "8.5" eventLogger: file hostname: localhost.localdomain idMappings: gidmap: - container_id: 0 host_id: 1000 size: 1 - container_id: 1 host_id: 100000 size: 65536 uidmap: - container_id: 0 host_id: 1000 size: 1 - container_id: 1 host_id: 100000 size: 65536 kernel: 4.18.0-323.el8.x86_64 linkmode: dynamic memFree: 352288768 memTotal: 2819129344 ociRuntime: name: runc package: runc-1.0.2-1.module+el8.5.0+12381+e822eb26.x86_64 path: /usr/bin/runc version: |- runc version 1.0.2 spec: 1.0.2-dev go: go1.16.7 libseccomp: 2.5.1 os: linux remoteSocket: path: /run/user/1000/podman/podman.sock security: apparmorEnabled: false capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT rootless: true seccompEnabled: true seccompProfilePath: /usr/share/containers/seccomp.json selinuxEnabled: true serviceIsRemote: false slirp4netns: executable: /usr/bin/slirp4netns package: slirp4netns-1.1.8-1.module+el8.5.0+12381+e822eb26.x86_64 version: |- slirp4netns version 1.1.8 commit: d361001f495417b880f20329121e3aa431a8f90f libslirp: 4.4.0 SLIRP_CONFIG_VERSION_MAX: 3 libseccomp: 2.5.1 swapFree: 3113668608 swapTotal: 3124752384 uptime: 11h 24m 12.52s (Approximately 0.46 days) registries: search: - registry.fedoraproject.org - registry.access.redhat.com - registry.centos.org - docker.io store: configFile: /home/user/.config/containers/storage.conf containerStore: number: 2 paused: 0 running: 0 stopped: 2 graphDriverName: overlay graphOptions: overlay.mount_program: Executable: /usr/bin/fuse-overlayfs Package: fuse-overlayfs-1.7.1-1.module+el8.5.0+12381+e822eb26.x86_64 Version: |- fusermount3 version: 3.2.1 fuse-overlayfs: version 1.7.1 FUSE library version 3.2.1 using FUSE kernel interface version 7.26 graphRoot: /home/user/.local/share/containers/storage graphStatus: Backing Filesystem: xfs Native Overlay Diff: "false" Supports d_type: "true" Using metacopy: "false" imageStore: number: 3 runRoot: /run/user/1000/containers volumePath: /home/user/.local/share/containers/storage/volumes version: APIVersion: 3.3.1 Built: 1630360721 BuiltTime: Mon Aug 30 23:58:41 2021 GitCommit: "" GoVersion: go1.16.7 OsArch: linux/amd64 Version: 3.3.1
未使用のコンテナー、イメージ、およびボリュームデータをすべて削除するには、次のコマンドを実行します。
$ podman system prune WARNING! This will remove: - all stopped containers - all stopped pods - all dangling images - all build cache Are you sure you want to continue? [y/N] y
-
podman system prune
コマンドは、未使用のコンテナー (関連付けられていないコンテナーおよび参照されていないコンテナー両方)、Pod、ローカルストレージのボリューム (任意) をすべて削除します。 -
--all
オプションを使用して、未使用のイメージをすべて削除します。未使用のイメージとは、ベースとするコンテナーのないイメージや、関連付けられていないイメージを指します。 -
ボリュームをプルーニングするには、
--volume
オプションを使用します。デフォルトでは、現在ボリュームを使用するコンテナーがない場合に、重要なデータが削除されないようにボリュームは削除されません。
-
関連情報
-
podman-system-df
の man ページ -
podman-system-info
の man ページ -
podman-system-prune
の man ページ
15.5. Podman イベントタイプ
Podman で発生するイベントをモニターできます。イベントタイプが複数存在し、イベントタイプごとに異なるステータスを報告します。
コンテナー イベントタイプは以下のステータスを報告します。
- attach
- checkpoint
- cleanup
- commit
- create
- exec
- export
- import
- init
- kill
- mount
- pause
- prune
- remove
- restart
- restore
- start
- stop
- sync
- unmount
- unpause
Pod イベントタイプは以下のステータスを報告します。
- create
- kill
- pause
- remove
- start
- stop
- unpause
image イベントタイプは以下のステータスを報告します。
- prune
- push
- pull
- save
- remove
- tag
- untag
system タイプは、以下のステータスを報告します。
- refresh
- renumber
volume タイプは、以下のステータスを報告します。
- create
- prune
- remove
関連情報
-
podman-events
の man ページ
15.6. Podman イベントのモニターリング
Podman で発生するイベントを監視して出力できます。各イベントには、タイムスタンプ、タイプ、ステータス、名前 (該当する場合)、およびイメージ (該当する場合) が含まれます。
手順
Podman イベントを表示します。
すべての Podman イベントを表示するには、以下を入力します。
$ podman events 2020-05-14 10:33:42.312377447 -0600 CST container create 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden) 2020-05-14 10:33:46.958768077 -0600 CST container init 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden) 2020-05-14 10:33:46.973661968 -0600 CST container start 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden) 2020-05-14 10:33:50.833761479 -0600 CST container stop 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden) 2020-05-14 10:33:51.047104966 -0600 CST container cleanup 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden)
ログを終了するには、CTRL+c を押します。
Podman の作成イベントのみを表示するには、以下を入力します。
$ podman events --filter event=create 2020-05-14 10:36:01.375685062 -0600 CST container create 20dc581f6fbf (image=registry.access.redhat.com/ubi8/ubi:latest) 2019-03-02 10:36:08.561188337 -0600 CST container create 58e7e002344c (image=registry.access.redhat.com/ubi8/ubi-minimal:latest) 2019-03-02 10:36:29.978806894 -0600 CST container create d81e30f1310f (image=registry.access.redhat.com/ubi8/ubi-init:latest)
関連情報
-
podman-events
の man ページ
第16章 コンテナーチェックポイントの作成および復元
CRIU (Checkpoint/Restore In Userspace) は、実行中のコンテナーまたは個々のアプリケーションでチェックポイントを設定して、その状態をディスクに保存するソフトウェアです。保存したデータを使用して、再起動後に、チェックポイントの時点にコンテナーを復元できます。
16.1. ローカルでのコンテナーチェックポイントの作成および復元
以下の例は、要求ごとにインクリメントする整数を 1 つ返す Python ベースの Web サーバーをベースとしています。
手順
Python ベースのサーバーを作成します。
# cat counter.py #!/usr/bin/python3 import http.server counter = 0 class handler(http.server.BaseHTTPRequestHandler): def do_GET(s): global counter s.send_response(200) s.send_header('Content-type', 'text/html') s.end_headers() s.wfile.write(b'%d\n' % counter) counter += 1 server = http.server.HTTPServer(('', 8088), handler) server.serve_forever()
以下の定義でコンテナーを作成します。
# cat Containerfile FROM registry.access.redhat.com/ubi8/ubi COPY counter.py /home/counter.py RUN useradd -ms /bin/bash counter RUN yum -y install python3 && chmod 755 /home/counter.py USER counter ENTRYPOINT /home/counter.py
コンテナーは Universal Base Image (UBI 8) をベースとしており、Python ベースのサーバーを使用します。
コンテナーをビルドします。
# podman build . --tag counter
counter.py
ファイルおよびContainerfile
ファイルは、コンテナービルドプロセス (podman build
) の入力情報です。ビルドされたイメージはローカルに保存され、counter
でタグ付けされます。root でコンテナーを起動します。
# podman run --name criu-test --detach counter
実行中のコンテナーの一覧を表示するには、次のコマンドを実行します。
# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e4f82fd84d48 localhost/counter:latest 5 seconds ago Up 4 seconds ago criu-test
コンテナーの IP アドレスを表示します。
# podman inspect criu-test --format "{{.NetworkSettings.IPAddress}}" 10.88.0.247
要求をコンテナーに送信します。
# curl 10.88.0.247:8080 0 # curl 10.88.0.247:8080 1
コンテナーのチェックポイントを作成します。
# podman container checkpoint criu-test
- システムを再起動します。
コンテナーを復元します。
# podman container restore --keep criu-test
要求をコンテナーに送信します。
# curl 10.88.0.247:8080 2 # curl 10.88.0.247:8080 3 # curl 10.88.0.247:8080 4
結果は
0
で開始あれるのではなく、以前の値で継続されます。
これにより、再起動後に完全なコンテナーの状態を簡単に保存できます。
16.2. コンテナー復元を使用した起動時間の短縮
コンテナーマイグレーションを使用して、初期化に特定の時間を必要とするコンテナーの起動時間を短縮できます。チェックポイントを使用すると、同じホストまたは別のホストでコンテナーを複数回復元できます。この例は、コンテナーチェックポイントのローカルでの作成および復元 のコンテナーを基にしています。
手順
コンテナーのチェックポイントを作成し、チェックポイントイメージを
tar.gz
ファイルにエクスポートします。# podman container checkpoint criu-test --export /tmp/chkpt.tar.gz
tar.gz
ファイルからコンテナーを復元します。# podman container restore --import /tmp/chkpt.tar.gz --name counter1 # podman container restore --import /tmp/chkpt.tar.gz --name counter2 # podman container restore --import /tmp/chkpt.tar.gz --name counter3
--name
(-n
) オプションは、エクスポートしたチェックポイントを基に復元したコンテナーに新しい名前を指定します。各コンテナーの ID と名前を表示します。
# podman ps -a --format "{{.ID}} {{.Names}}" a8b2e50d463c counter3 faabc5c27362 counter2 2ce648af11e5 counter1
各コンテナーの IP アドレスを表示します。
#️ podman inspect counter1 --format "{{.NetworkSettings.IPAddress}}" 10.88.0.248 #️ podman inspect counter2 --format "{{.NetworkSettings.IPAddress}}" 10.88.0.249 #️ podman inspect counter3 --format "{{.NetworkSettings.IPAddress}}" 10.88.0.250
各コンテナーに要求を送信します。
#️ curl 10.88.0.248:8080 4 #️ curl 10.88.0.249:8080 4 #️ curl 10.88.0.250:8080 4
同じチェックポイントから異なるコンテナーを使用して復元しているので、結果は、どの場合も
4
になる点に注意してください。
この方法では、最初にチェックポイントを作成したコンテナーのステートフルレプリカを迅速に起動できます。
16.3. システム間のコンテナーの移行
この手順は、コンテナーで実行しているアプリケーションの状態を失うことなく、実行中のコンテナーを別のシステムに移行する方法を示しています。この例は、コンテナーチェックポイントのローカルでの作成および復元 のコンテナーを基にしています。
counter
でタグ付けされたセクション。
前提条件
以下の手順は、コンテナーがレジストリーにプッシュされている場合には不要です。理由は、Podman がローカルでコンテナーを利用できない場合に自動的にコンテナーをレジストリーからダウンロードするためです。この例ではレジストリーを使用しません。以前に構築およびタグ付けしたコンテナー (コンテナーチェックポイントのローカルでの作成および復元
セクションを参照) をエクスポートする必要があります。
以前にビルドしたコンテナーをエクスポートします。
# podman save --output counter.tar counter
エクスポートしたコンテナーイメージを移行先システム (
other_host
) にコピーします。# scp counter.tar other_host:
エクスポートしたコンテナーを移行先システムにインポートします。
# ssh other_host podman load --input counter.tar
このコンテナーの移行先のシステムには、ローカルコンテナーストレージに保存されているのと同じコンテナーイメージがあります。
手順
root でコンテナーを起動します。
# podman run --name criu-test --detach counter
コンテナーの IP アドレスを表示します。
# podman inspect criu-test --format "{{.NetworkSettings.IPAddress}}" 10.88.0.247
要求をコンテナーに送信します。
# curl 10.88.0.247:8080 0 # curl 10.88.0.247:8080 1
コンテナーのチェックポイントを作成し、チェックポイントイメージを
tar.gz
ファイルにエクスポートします。# podman container checkpoint criu-test --export /tmp/chkpt.tar.gz
チェックポイントアーカイブを移行先ホストにコピーします。
# scp /tmp/chkpt.tar.gz other_host:/tmp/
移行先ホスト (
other_host
) のチェックポイントを復元します。# podman container restore --import /tmp/chkpt.tar.gz
宛先ホスト (
other_host
) のコンテナーに要求を送信します。# *curl 10.88.0.247:8080* 2
これで、ステートフルコンテナーが、状態を失うことなく、別のシステムへ移行されました。
第17章 HPC 環境での Podman の使用
Podman を Open MPI (Message Passing Interface) と共に使用して、HPC (High Performance Computing) 環境でコンテナーを実行できます。
17.1. Podman と MPI の使用
この例は、Open MPI から取得した ring.c プログラムを基にしています。この例では、全プロセスで値はリングのように渡されます。メッセージがランク 0 を渡すと必ず、値は 1 つ下がります。各プロセスが 0 メッセージを受信すると、次のプロセスに渡して終了します。0 を最初に渡すと、すべてのプロセスが 0 メッセージを取得し、通常通りに終了できます。
手順
Open MPI をインストールします。
# yum install openmpi
環境モジュールをアクティベートするには、以下を入力します。
$ . /etc/profile.d/modules.sh
mpi/openmpi-x86_64
モジュールを読み込みます。$ module load mpi/openmpi-x86_64
必要に応じて、
mpi/openmpi-x86_64
モジュールを自動的に読み込むには、以下の行を.bashrc
ファイルに追加します。$ echo "module load mpi/openmpi-x86_64" >> .bashrc
mpirun
とpodman
を統合するには、以下の定義でコンテナーを作成します。$ cat Containerfile FROM registry.access.redhat.com/ubi8/ubi RUN yum -y install openmpi-devel wget && \ yum clean all RUN wget https://raw.githubusercontent.com/open-mpi/ompi/master/test/simple/ring.c && \ /usr/lib64/openmpi/bin/mpicc ring.c -o /home/ring && \ rm -f ring.c
コンテナーをビルドします。
$ podman build --tag=mpi-ring .
コンテナーを起動します。このコマンドは、CPU が 4 つあるシステムではコンテナーを 4 つ起動します。
$ mpirun \ --mca orte_tmpdir_base /tmp/podman-mpirun \ podman run --env-host \ -v /tmp/podman-mpirun:/tmp/podman-mpirun \ --userns=keep-id \ --net=host --pid=host --ipc=host \ mpi-ring /home/ring Rank 2 has cleared MPI_Init Rank 2 has completed ring Rank 2 has completed MPI_Barrier Rank 3 has cleared MPI_Init Rank 3 has completed ring Rank 3 has completed MPI_Barrier Rank 1 has cleared MPI_Init Rank 1 has completed ring Rank 1 has completed MPI_Barrier Rank 0 has cleared MPI_Init Rank 0 has completed ring Rank 0 has completed MPI_Barrier
これにより、
mpirun
は 4 つの Podman コンテナーを開始し、コンテナーごとにring
バイナリーのインスタンスを 1 台実行します。4 つプロセスはすべて、MPI 経由で相互に通信しています。
17.2. mpirun オプション
以下の mpirun
オプションは、コンテナーの起動に使用します。
-
--mca orte_tmpdir_base /tmp/podman-mpirun
行は、Open MPI に対し、/tmp
ではなく、/tmp/podman-mpirun
にその一時ファイルをすべて作成するように指示します。複数のノードを使用する場合には、別のノードではこのディレクトリーの名前は異なります。このような場合には、/tmp
ディレクトリー全体をコンテナーにマウントする必要があり、操作がより複雑です。
mpirun
コマンドは、podman
コマンドを起動するコマンドを指定します。以下の podman
オプションは、コンテナーの起動に使用されます。
-
run
コマンドはコンテナーを実行します。 -
--env-host
オプションは、ホストからコンテナーにすべての環境変数をコピーします。 -
-v /tmp/podman-mpirun:/tmp/podman-mpirun
は、Open MPI が一時ディレクトリーとファイルをコンテナーで利用できるように、Podman にディレクトリーのマウントを指示します。 -
--userns=keep-id
行を使用すると、コンテナー内外でのユーザー ID マッピングを保証します。 -
--net=host --pid=host --ipc=host
行では、同じネットワーク、PID、および IPC 名前空間が設定されます。 -
mpi-ring
はコンテナーの名前です。 -
/home/ring
は、コンテナー内の MPI プログラムです。
第18章 特殊なコンテナーイメージの実行
特殊なタイプのコンテナーイメージを実行できます。一部のコンテナーイメージには、事前に設定されたオプションおよび引数を使用してコンテナーを実行できる runlabels と呼ばれる組み込みラベルがあります。podman container runlabel <label>
コマンドでは、コンテナーイメージの <label>
で定義されたコマンドを実行できます。サポートされるラベルは、install
、run
、および uninstall
です。
18.1. ホストへの権限の付与
特権コンテナーと非特権コンテナーにはいくつかの違いがあります。たとえば、toolbox コンテナーは特権コンテナーです。以下は、コンテナーがホストに対して許可する、または許可しない権限の例です。
-
特権: 特権コンテナーは、コンテナーをホストから分離するセキュリティー機能を無効にします。特権コンテナーは、
podman run --privileged <image_name>
コマンドを使用して実行できます。たとえば、root ユーザーが所有するホストからマウントされたファイルおよびディレクトリーを削除できます。 -
プロセステーブル:
podman run --privileged --pid=host <image_name>
コマンドを使用して、コンテナーでホストの PID 名前空間を使用できます。特権コンテナー内でps -e
コマンドを使用して、ホストで実行しているすべてのプロセスを一覧表示できます。ホストから特権コンテナーで実行するコマンドにプロセス ID を渡すことができます (例:kill <PID>
)。 -
ネットワークインターフェイス - デフォルトでは、コンテナーには外部のネットワークインターフェイスとループバックネットワークインターフェイスが 1 つずつだけあります。
podman run --net=host <image_name>
コマンドを使用して、コンテナー内からホストのネットワークインターフェイスに直接アクセスできます。 -
プロセス間のコミュニケーション - ホストの IPC 機能は、特権コンテナーからアクセスできます。
ipcs
などのコマンドを実行して、ホスト上のアクティブなメッセージキュー、共有メモリーセグメント、およびセマフォセットに関する情報を表示できます。
18.2. runlabel が組み込まれたコンテナーイメージ
Red Hat イメージには、そのイメージと連携するために事前に設定されたコマンドラインを提供するラベルが含まれているものがあります。podman container runlabel <label>
コマンドを使用すると、podman
コマンドを使用してイメージの <label>
で定義されたコマンドを実行できます。
既存の runlabel には次のものが含まれます。
- install - イメージを実行する前にホストシステムを設定します。通常、これにより、後で実行するときにコンテナーがアクセスできるホストにファイルとディレクトリーが作成されます。
- run - コンテナーの実行時に使用する podman コマンドラインオプションを特定します。通常、オプションはホストで権限を開き、コンテナーがホストで永続的に維持する必要があるホストのコンテンツをマウントします。
- uninstall - コンテナーの実行を終了した後にホストシステムをクリーンアップします。
18.3. runlabel での rsyslog の実行
rhel8/rsyslog
コンテナーイメージは、rsyslogd
デーモンのコンテナー化されたバージョンを実行するように設計されています。rsyslog
イメージには、install
、run
および uninstall
の runlabel が含まれます。以下の手順に従って、rsyslog
イメージのインストール、実行、アンインストールを行います。
手順
rsyslog
イメージをプルします。# podman pull registry.redhat.io/rhel8/rsyslog
rsyslog
のinstall
runlabel を表示します。# podman container runlabel install --display rhel8/rsyslog command: podman run --rm --privileged -v /:/host -e HOST=/host -e IMAGE=registry.redhat.io/rhel8/rsyslog:latest -e NAME=rsyslog registry.redhat.io/rhel8/rsyslog:latest /bin/install.sh
これは、コマンドがホストに特権を開き、コンテナー内の
/host
にホストの root ファイルシステムをマウントし、install.sh
スクリプトを実行します。rsyslog
のinstall
runlabel を実行します。# podman container runlabel install rhel8/rsyslog command: podman run --rm --privileged -v /:/host -e HOST=/host -e IMAGE=registry.redhat.io/rhel8/rsyslog:latest -e NAME=rsyslog registry.redhat.io/rhel8/rsyslog:latest /bin/install.sh Creating directory at /host//etc/pki/rsyslog Creating directory at /host//etc/rsyslog.d Installing file at /host//etc/rsyslog.conf Installing file at /host//etc/sysconfig/rsyslog Installing file at /host//etc/logrotate.d/syslog
これにより、
rsyslog
イメージが後で使用するホストシステムにファイルが作成されます。rsyslog
のrun
runlabel を表示します。# podman container runlabel run --display rhel8/rsyslog command: podman run -d --privileged --name rsyslog --net=host --pid=host -v /etc/pki/rsyslog:/etc/pki/rsyslog -v /etc/rsyslog.conf:/etc/rsyslog.conf -v /etc/sysconfig/rsyslog:/etc/sysconfig/rsyslog -v /etc/rsyslog.d:/etc/rsyslog.d -v /var/log:/var/log -v /var/lib/rsyslog:/var/lib/rsyslog -v /run:/run -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -e IMAGE=registry.redhat.io/rhel8/rsyslog:latest -e NAME=rsyslog --restart=always registry.redhat.io/rhel8/rsyslog:latest /bin/rsyslog.sh
これは、コマンドがホストへの特権を開き、
rsyslog
コンテナーを起動してrsyslogd
デーモンを実行するときに、コンテナー内のホストから多数のファイルとディレクトリーをマウントすることを示しています。rsyslog
のrun
runlabel を実行します。# podman container runlabel run rhel8/rsyslog command: podman run -d --privileged --name rsyslog --net=host --pid=host -v /etc/pki/rsyslog:/etc/pki/rsyslog -v /etc/rsyslog.conf:/etc/rsyslog.conf -v /etc/sysconfig/rsyslog:/etc/sysconfig/rsyslog -v /etc/rsyslog.d:/etc/rsyslog.d -v /var/log:/var/log -v /var/lib/rsyslog:/var/lib/rsyslog -v /run:/run -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -e IMAGE=registry.redhat.io/rhel8/rsyslog:latest -e NAME=rsyslog --restart=always registry.redhat.io/rhel8/rsyslog:latest /bin/rsyslog.sh 28a0d719ff179adcea81eb63cc90fcd09f1755d5edb121399068a4ea59bd0f53
rsyslog
コンテナーは権限を開き、ホストから必要なものをマウントし、バックグラウンドでrsyslogd
デーモンを実行します (-d
)。rsyslogd
デーモンは、ログメッセージを収集し、メッセージを/var/log
ディレクトリー内のファイルに送信します。rsyslog
のuninstall
runlabel を表示します。# podman container runlabel uninstall --display rhel8/rsyslog command: podman run --rm --privileged -v /:/host -e HOST=/host -e IMAGE=registry.redhat.io/rhel8/rsyslog:latest -e NAME=rsyslog registry.redhat.io/rhel8/rsyslog:latest /bin/uninstall.sh
rsyslog
のuninstall
runlabel を実行します。# podman container runlabel uninstall rhel8/rsyslog command: podman run --rm --privileged -v /:/host -e HOST=/host -e IMAGE=registry.redhat.io/rhel8/rsyslog:latest -e NAME=rsyslog registry.redhat.io/rhel8/rsyslog:latest /bin/uninstall.sh
この場合、uninstall.sh
スクリプトは、/etc/logrotate.d/syslog
ファイルを削除します。設定ファイルはクリーンアップされません。
第19章 container-tools API の使用
varlink ライブラリーを使用する Podman リモート API に代わって、新しい REST ベースの Podman 2.0 API が導入されました。新規 API は、ルートフル環境およびルートレス環境の両方で動作します。
Podman v2.0 RESTful API は、Podman および Docker 互換 API をサポートする Libpod API で設定されます。この新しい REST API を使用すると、cURL、Postman、Google の Advanced REST クライアントなどのプラットフォームから Podman を呼び出すことができます。
19.1. root モードで systemd を使用した Podman API の有効化
この手順では、以下を行う方法を説明します。
- systemd を使用して Podman API ソケットをアクティベートします。
- Podman クライアントを使用して基本的なコマンドを実行します。
前提条件
podman-remote
パッケージがインストールされている。# yum install podman-remote
手順
サービスをすぐに起動します。
# systemctl enable --now podman.socket
docker-podman
パッケージを使用してvar/lib/docker.sock
へのリンクを有効にするには以下を実行します。# yum install podman-docker
検証手順
Podman のシステム情報を表示します。
# podman-remote info
リンクを確認します。
# ls -al /var/run/docker.sock lrwxrwxrwx. 1 root root 23 Nov 4 10:19 /var/run/docker.sock -> /run/podman/podman.sock
19.2. ルートレスモードで systemd を使用した Podman API の有効化
この手順では、systemd を使用して Podman API ソケットおよび Podman API サービスをアクティベートする方法を説明します。
前提条件
podman-remote
パッケージがインストールされている。# yum install podman-remote
手順
サービスをすぐに有効にして起動します。
$ systemctl --user enable --now podman.socket
オプション:Docker を使用してプログラムがルートレス Podman ソケットを操作できるようにするには、以下を実行します。
$ export DOCKER_HOST=unix:///run/user/<uid>/podman//podman.sock
検証手順
ソケットのステータスを確認します。
$ systemctl --user status podman.socket ● podman.socket - Podman API Socket Loaded: loaded (/usr/lib/systemd/user/podman.socket; enabled; vendor preset: enabled) Active: active (listening) since Mon 2021-08-23 10:37:25 CEST; 9min ago Docs: man:podman-system-service(1) Listen: /run/user/1000/podman/podman.sock (Stream) CGroup: /user.slice/user-1000.slice/user@1000.service/podman.socket
podman.socket
はアクティブで、/run/user/<uid>/podman.podman.sock
をリッスンしています。<uid>
はユーザーの ID です。Podman のシステム情報を表示します。
$ podman-remote info
19.3. Podman API の手動実行
この手順では、Podman API の実行方法について説明します。手動での実行は、特に Docker の互換性レイヤーを使用する場合など、API 呼び出しのデバッグに便利です。
前提条件
podman-remote
パッケージがインストールされている。# yum install podman-remote
手順
REST API のサービスを実行します。
# podman system service -t 0 --log-level=debug
-
値が 0 の場合はタイムアウトなしを意味します。ルートフルサービスのデフォルトのエンドポイントは
unix:/run/podman/podman.sock
です。 -
--log-level <level>
オプションは、ロギングレベルを設定します。標準のロギングレベルはdebug
、info
、warn
、error
、fatal
、およびpanic
です。
-
値が 0 の場合はタイムアウトなしを意味します。ルートフルサービスのデフォルトのエンドポイントは
別のターミナルで、Podman のシステム情報を表示します。
podman-remote
コマンドは、通常のpodman
コマンドとは異なり、Podman ソケットを介して通信します。# podman-remote info
Podman API をトラブルシューティングし、要求および応答を表示するには、
curl
コマンドを使用します。JSON 形式で Linux サーバーの Podman インストールの情報を取得するには、以下を実行します。# curl -s --unix-socket /run/podman/podman.sock http://d/v1.0.0/libpod/info | jq { "host": { "arch": "amd64", "buildahVersion": "1.15.0", "cgroupVersion": "v1", "conmon": { "package": "conmon-2.0.18-1.module+el8.3.0+7084+c16098dd.x86_64", "path": "/usr/bin/conmon", "version": "conmon version 2.0.18, commit: 7fd3f71a218f8d3a7202e464252aeb1e942d17eb" }, … "version": { "APIVersion": 1, "Version": "2.0.0", "GoVersion": "go1.14.2", "GitCommit": "", "BuiltTime": "Thu Jan 1 01:00:00 1970", "Built": 0, "OsArch": "linux/amd64" } }
jq
ユーティリティーは、コマンドライン JSON プロセッサーです。registry.access.redhat.com/ubi8/ubi
コンテナーイメージをプルします。# curl -XPOST --unix-socket /run/podman/podman.sock -v 'http://d/v1.0.0/images/create?fromImage=registry.access.redhat.com%2Fubi8%2Fubi' * Trying /run/podman/podman.sock... * Connected to d (/run/podman/podman.sock) port 80 (#0) > POST /v1.0.0/images/create?fromImage=registry.access.redhat.com%2Fubi8%2Fubi HTTP/1.1 > Host: d > User-Agent: curl/7.61.1 > Accept: / > < HTTP/1.1 200 OK < Content-Type: application/json < Date: Tue, 20 Oct 2020 13:58:37 GMT < Content-Length: 231 < {"status":"pulling image () from registry.access.redhat.com/ubi8/ubi:latest, registry.redhat.io/ubi8/ubi:latest","error":"","progress":"","progressDetail":{},"id":"ecbc6f53bba0d1923ca9e92b3f747da8353a070fccbae93625bd8b47dbee772e"} * Connection #0 to host d left intact
プルしたイメージを表示します。
# curl --unix-socket /run/podman/podman.sock -v 'http://d/v1.0.0/libpod/images/json' | jq * Trying /run/podman/podman.sock... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to d (/run/podman/podman.sock) port 80 (0) > GET /v1.0.0/libpod/images/json HTTP/1.1 > Host: d > User-Agent: curl/7.61.1 > Accept: / > < HTTP/1.1 200 OK < Content-Type: application/json < Date: Tue, 20 Oct 2020 13:59:55 GMT < Transfer-Encoding: chunked < { [12498 bytes data] 100 12485 0 12485 0 0 2032k 0 --:--:-- --:--:-- --:--:-- 2438k * Connection #0 to host d left intact [ { "Id": "ecbc6f53bba0d1923ca9e92b3f747da8353a070fccbae93625bd8b47dbee772e", "RepoTags": [ "registry.access.redhat.com/ubi8/ubi:latest", "registry.redhat.io/ubi8/ubi:latest" ], "Created": "2020-09-01T19:44:12.470032Z", "Size": 210838671, "Labels": { "architecture": "x86_64", "build-date": "2020-09-01T19:43:46.041620", "com.redhat.build-host": "cpt-1008.osbs.prod.upshift.rdu2.redhat.com", ... "maintainer": "Red Hat, Inc.", "name": "ubi8", ... "summary": "Provides the latest release of Red Hat Universal Base Image 8.", "url": "https://access.redhat.com/containers//registry.access.redhat.com/ubi8/images/8.2-347", ... }, "Names": [ "registry.access.redhat.com/ubi8/ubi:latest", "registry.redhat.io/ubi8/ubi:latest" ], ... ] } ]
関連情報
- Podman v2.0 RESTful API
- Sneak peek: Podman's new REST API
- Exploring Podman RESTful API using Python and Bash
-
podman-system-service
の man ページ