Red Hat Training

A Red Hat training course is available for RHEL 8

コンテナーの実行および管理

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8 での Linux コンテナーの構築、実行、および管理

概要

本ガイドでは、podman、buildah、skopeo、runc などのコマンドラインツールを使用して、RHEL 8 システムで Linux コンテナーを使用する方法を説明します。

はじめに

Red Hat は、コンテナーのユースケースを、シングルノードとマルチノードという別々のグループに分類します。マルチノードは、分散システムと呼ばれることもあります。OpenShift は、コンテナー化されたアプリケーションをパブリックでスケーラブルにデプロイメントするために構築されました。ただし、OpenShift 以外では、コンテナーを操作する、小規模で機敏なツールセットがあると便利です。

参照するコンテナツールセットは、シングルノードのユースケースで使用できます。ただし、既存のビルドシステム (CI/CD 環境) にこのツールを接続することもできます。また、これを使用して、ビッグデータなどのワークロード固有のユースケースを処理することもできます。Red Hat Enterprise Linux (RHEL) 8 は、シングルノードのユースケースを対象として、個々のコンテナーを検索、実行、ビルド、および共有するツールセットを提供します。

本ガイドでは、podman、buildah、skopeo、runc などのコマンドラインツールを使用して、RHEL 8 システムで Linux コンテナーを使用する方法を説明します。以上のツールに加えて、Red Hat は、お客様が所有するイメージの基盤として機能するベースイメージを提供します。このベースイメージの一部は、ビジネスアプリケーション (Node.js、PHP、Java、Python など) からインフラストラクチャー (ロギング、データ収集、認証など) までのユースケースを対象としています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

  • 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 コンテナーの使用

Linux コンテナーは、イメージベースのデプロイメント方法の柔軟性と、軽量アプリケーションの分離を組み合わせた、主要なオープンソースアプリケーションをパッケージ化して、配信するテクノロジーとして登場しました。RHEL は、以下のようなコア技術を使用して Linux コンテナーを実装します。

  • リソース管理用のコントロールグループ (cgroup)
  • プロセス分離用の namespace
  • SELinux (セキュリティー用)
  • セキュアなマルチテナンシー

このような技術は、セキュリティーエクスプロイトの可能性を軽減し、エンタープライズ品質のコンテナーを生成および実行する環境を提供します。

Red Hat OpenShift は、強力なコマンドラインと Web UI ツールを提供し、Pod と呼ばれる単位でコンテナーを構築、管理、および実行します。Red Hat では、OpenShift 外で個々のコンテナーおよび コンテナーイメージ をビルドして管理できます。本書では、RHEL システムで直接実行されるタスクを実行するためのツールについて説明します。

他のコンテナーツールの実装とは異なり、ここで説明するツールはモノリシック Docker の コンテナーエンジン と、docker コマンドを中心としたものではありません。代わりに、Red Hat はコンテナーエンジンがなくても動作できる一連のコマンドラインツールを提供します。これには、以下が含まれます。

  • Podman - Pod およびコンテナーイメージの直接管理 (runstopstartpsattachexec など)
  • buildah - コンテナーイメージの構築、プッシュ、および署名
  • skopeo - イメージのコピー、検証、削除、および署名
  • runc - podman および buildah へのコンテナーの実行機能と構築機能の提供
  • crun - ルートレスコンテナーの柔軟性、制御、セキュリティーを向上するために設定可能なオプションのランタイム。

これは、このツールが、Docker が生成して管理するのと同じ Linux コンテナーや、その他の OCI 互換コンテナー エンジン の管理に使用する Open Container Initiative (OCI) と互換性があるためです。ただし、シングルノードのユースケースでは、Red Hat Enterprise Linux で直接実行することが特に適しています。

マルチノードコンテナープラットフォームの場合は、「OpenShift」および「CRI-O Container Engine の使用」を参照してください。

1.1. Docker を使用せずにコンテナーを実行

Red Hat では、RHEL 8 から Docker コンテナーエンジンと、docker コマンドが削除されました。

注記
RHEL 8 では、Docker に対応していません。

Docker コマンド機能に代わる、Podman、Skopeo、Buildah ツールが開発されました。このシナリオの各ツールはより軽量になり、機能のサブセットに焦点を当てています。

Podman、Skopeo、Buildah ツールの主な利点は次のとおりです。

  • ルートレスモードでの実行 - ルートレスコンテナーは、特権を追加しなくても実行されるため、はるかに安全です。
  • デーモンの必要なし - コンテナーが実行されていない場合に、Podman でデーモンが常に実行されるわけではないので、これらのツールではアイドル時のリソース要件がはるかに少なくなります。
  • ネイティブ systemd 統合 - Podman では systemd ユニットファイルを作成し、コンテナーをシステムサービスとして実行できます。

RHEL で Docker を使用する場合は、異なるアップストリームプロジェクトから Docker を取得できますが、RHEL 8 では対応していません。Podman に Docker コマンドライン機能が多数実装されているため、docker と入力して podman が実行されるようにエイリアスを設定できます。

podman-docker パッケージをインストールすると、このエイリアスが設定されます。したがって、docker コマンドを実行するたびに、実際には podman コマンドを実行します。

Podman は Docker Socket API にも対応しているため、podman-docker パッケージは /var/run/docker.sock/var/run/podman/podman.sock の間でリンクを設定します。そのため、Docker デーモンを必要とせずに、docker-pydocker-compose ツールを使用して Docker API コマンドをそのまま実行できます。Podman はこのような要求を処理します。

1.2. コンテナーの RHEL アーキテクチャーの選択

Red Hat は、以下のコンピューターアーキテクチャーに、コンテナーイメージとコンテナー関連のソフトウェアを提供します。

  • AMD64 および Intel 64 (ベースイメージおよびレイヤー構造イメージ。32 ビットアーキテクチャーはサポートされません)
  • PowerPC 8 および 9 の 64 ビット (ベースイメージおよび大概のレイヤー構造イメージ)
  • 64 ビット IBM Z (ベースイメージと、大概の階層構造イメージ)
  • ARM 64 ビット (ベースイメージのみ)

初めは、すべてのアーキテクチャーですべての Red Hat イメージがサポートされたわけではありませんが、一覧に挙げられているすべてのアーキテクチャーでほぼすべてが利用可能になりました。

1.3. コンテナーツールの取得

この手順では、Podman、Buildah、Skopeo、runc ツールを含む container-tools モジュールをインストールする方法を説明します。

手順

  1. RHEL をインストールします。
  2. RHEL の登録: ユーザー名とパスワードを入力します。ユーザー名とパスワードは、Red Hat カスタマーポータルのログイン認証情報と同じです。

    # subscription-manager register
    Registering to: subscription.rhsm.redhat.com:443/subscription
    Username: ********
    Password: **********
  3. RHEL にサブスクライブします。

    • RHEL に自動的にサブスクライブするには、以下を実行します。

      # subscription-manager attach --auto
    • プール ID で RHEL をサブスクライブするには、次のコマンドを実行します。

      # subscription-manager attach --pool PoolID
  4. container-tools モジュールをインストールします。

    # yum module install -y container-tools
  5. オプション: podman-docker パッケージをインストールします。

    # yum install -y podman-docker

    podman-docker パッケージは、Docker コマンドラインインターフェースと docker-api を、同等の Podman コマンドに置き換えます。

1.4. ルートレスコンテナーの設定

システムで利用可能な機能をコンテナーで完全利用できるように、Podman、Skopeo、Buildah などのコンテナーツールをスーパーユーザー特権 (root ユーザー) が割り当てられたユーザーで実行するのが最善の方法です。ただし、RHEL 8.1 以降で一般的に利用可能な「ルートレスコンテナー」と呼ばれる機能を使用すると、コンテナーを一般ユーザーとして使用できます。

Docker などのコンテナーエンジンでは、通常の (root 以外の) ユーザーとして Docker コマンドを実行できますが、これらの要求を実行する Docker デーモンは root として実行されます。これにより、一般ユーザーがコンテナー経由で要求を送信でき、システムに影響を与える可能性があります。システム管理者は、ルートレスコンテナーユーザーを設定して、一般ユーザーがコンテナーアクティビティーに損害を与える可能性を回避しつつ、一般ユーザーが自分のアカウントで大半のコンテナー機能を安全に実行できるようにします。

この手順では、Podman、Skopeo、および Buildah ツールを使用して、root 以外のユーザー (ルートレス) としてコンテナーを操作するようにシステムを設定する方法を説明します。また、一般ユーザーのアカウントは、コンテナーの実行に必要なすべてのオペレーティングシステム機能に完全にアクセスできないために発生する可能性のある制限についても説明します。

前提条件

  • root 以外のユーザーでコンテナーツールを使用できるように、RHEL システムを設定する必要があります。

手順

  1. RHEL をインストールします。
  2. podman パッケージおよび slirp4netns パッケージをインストールします。

    # yum install slirp4netns podman -y
  3. ユーザーアカウントを新規作成します。

    # useradd -c "Joe Jones" joe
    # passwd joe

    ユーザーは、ルートレス Podman を使用できるように自動的に設定されます。useradd コマンドは、/etc/subuid/etc/subgid ファイルに、アクセス可能なユーザー ID とグループ ID の範囲を自動的に設定します。

  4. ユーザーに接続します。

    $ ssh joe@server.example.com
    注記
    これらのコマンドでは正しい環境変数が設定されないため、su または su - コマンドは使用しないでください。Red Hat カスタマーポータルの認証情報を使用します。
  5. registry.access.redhat.com/ubi8/ubi コンテナーイメージをプルします。

    $ podman pull registry.access.redhat.com/ubi8/ubi
  6. myubi という名前のコンテナーを実行し、OS バージョンを表示します。

    $ podman run --name=myubi registry.access.redhat.com/ubi8/ubi cat
        /etc/os-release
    NAME="Red Hat Enterprise Linux"
    VERSION="8.4 (Ootpa)"

1.5. ルートレスコンテナーへのアップグレード

本セクションでは、RHEL 7 からルートレスコンテナーにアップグレードする方法を説明します。ユーザーおよびグループ ID を手動で設定する必要があります。

以下は、RHEL 7 からルートレスコンテナーにアップグレードするおt機に考慮すべき事項です。

  • 複数のルートレスコンテナーユーザーを設定する場合は、ユーザーごとに一意の範囲を使用します。
  • 既存のコンテナーイメージとの互換性を最大限にするために、UID および GID に 65536 を使用します。ただし、この数は減らすことができます
  • 1000 未満の UID または GID を使用したり、既存のユーザーアカウントから UID または GID を再利用したりしないでください (デフォルトでは 1000 から開始します)。

前提条件

  • ユーザーアカウントが作成されている。

手順

  1. usermod コマンドを実行して、UID と GID をユーザーに割り当てます。

    # usermod --add-subuids 200000-201000 --add-subgids 200000-201000 username
    • usermod --add-subuid コマンドは、アクセス可能なユーザー ID の範囲をユーザーのアカウントに追加します。
    • usermod --add-subgids コマンドは、アクセス可能なユーザー GID およびグループ ID の範囲をユーザーのアカウントに手動で追加します。
  2. オプション: UID および GID が正しく設定されていることを確認します。

    # grep username /etc/subuid /etc/subgid
    #/etc/subuid:username:200000:1001
    #/etc/subgid:username:200000:1001

1.6. ルートレスコンテナーに関する特別な考慮事項

root 以外のユーザーでコンテナーを実行する場合は、考慮事項が複数あります。

  • ホストコンテナーストレージへのパスは、root ユーザー (/var/lib/containers/storage) と root 以外のユーザー ($HOME/.local/share/containers/storage) との間では異なります。
  • ルートレスコンテナーを実行するユーザーには、ホストシステムでユーザー ID およびグループ ID の範囲として実行する特別な権限が付与されます。ただし、ホストのオペレーティングシステムに対する root 権限はありません。
  • ルートレスコンテナー環境を設定する必要がある場合は、ホームディレクトリーに設定ファイルを作成します ($HOME/.config/containers)。設定ファイルには、storage.conf (ストレージ設定用) および containers.conf (さまざまなコンテナー設定用) が含まれます。また、registries.conf ファイルを作成し、Podman を使用してイメージをプル、検索、または実行する時に利用可能なコンテナーレジストリーを識別することもできます。
  • root 権限なしで変更できないシステム機能もいくつかあります。たとえば、コンテナー内で SYS_TIME 機能を設定し、ネットワークタイムサービス (ntpd) を実行してシステムクロックを変更できません。root としてコンテナーを実行し、ルートレスコンテナー環境を省略して root ユーザーの環境を使用する必要があります。以下に例を示します。

    $ sudo podman run -d --cap-add SYS_TIME ntpd

    この例では、ntpd がコンテナー内だけでなく、システム全体の時間を調整できることに注意してください。

  • ルートレスコンテナーは、1024 未満のポート番号にアクセスできません。たとえば、ルートレスコンテナーの namespace 内では、コンテナーの httpd サービスからポート 80 を公開するサービスを開始しますが、この namespace の外部からはアクセスできません。

    $ podman run -d httpd

    ただし、そのポートをホストシステムに公開するには、コンテナーには root ユーザーのコンテナー環境を使用するルート権限が必要です。

    $ sudo podman run -d -p 80:80 httpd
  • ワークステーションの管理者は、ユーザーが 1024 未満のポートでサービスを公開できるようにしますが、セキュリティーへの影響を理解する必要があります。たとえば、一般ユーザーは、公式のポート 80 で Web サーバーを実行し、外部ユーザーに対して、管理者が設定したと見せかけることができます。これは、テスト用のワークステーションで問題ありませんが、ネットワークにアクセス可能な開発サーバーでは適切ではなく、実稼働サーバーでは実行しないでください。ユーザーがポート 80 にバインドできるようにするには、次のコマンドを実行します。

    # echo 80 > /proc/sys/net/ipv4/ip_unprivileged_port_start

第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 イメージを自由に使用および再配布できます。

2.3. UBI 標準イメージの概要

標準イメージ (名称 ubi) は、RHEL で実行されるアプリケーション用に設計されています。UBI 標準イメージの主な機能には、以下が含まれます。

  • init system - systemd サービスの管理に必要な systemd 初期化システムのすべての機能は、標準のベースイメージで利用できます。この init システムを使用すると、Web サーバー (httpd) や FTP サーバー (vsftpd) などのサービスを自動的に起動するように事前設定された RPM パッケージをインストールできます。
  • yum: ソフトウェアの追加や更新が可能な、無料の yum リポジトリーにアクセスできます。yum コマンドの標準のセットを使用できます (yum 、yum-config-manageryumdownloader など)。
  • utilities: ユーティリティには tardmidecodegzipgetfacl や他の 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+3StopSignal として設定しています。これは、ubi8-init の systemd が通常の終了信号 (SIGTERM および SIGKILL) を無視しているためですが、SIGRTMIN+3 を受け取った場合は無効になります。
  • ubi8:

    • CMD は /bin/bash に設定されます。
    • ps およびプロセス関連のコマンド (procps-ng パッケージ) は含まれません。
    • 通常の終了シグナルを無視しません (SIGTERM および SIGKILL)。

2.5. UBI の最小イメージの理解

ubi-minimal という名前の UBI の最小イメージは、事前にインストールされたコンテンツセットおよびパッケージマネージャー (microdnf) の最小イメージを提供します。これにより、Dockerfile または Containerfile を使用し、イメージに含まれる依存関係を最小化できます。

UBI 最小イメージの主な機能には、以下が含まれます。

  • サイズが小さい - 最小イメージは、ディスク上では約 92M、圧縮時は 32M です。これにより、サイズが、標準イメージの半分に満たなくなります。
  • ソフトウェアインストール (microdnf) - ソフトウェアリポジトリーおよび RPM ソフトウェアパッケージを使用する完全に開発された yum 機能を追加する代わりに、最小イメージには microdnf ユーティリティーが含まれます。microdnfdnf の縮小バージョンであるため、リポジトリーの有効化/無効化、パッケージの削除と更新、パッケージのインストール後にキャッシュを削除できます。
  • RHEL パッケージをベースとする - 最小イメージには、通常の RHEL ソフトウェアの RPM パッケージから機能がいくつか削除されたものです。最小イメージには、systemd や System V init、Python ランタイム環境、および一部のシェルユーティリティーなど、初期化およびサービス管理システムが含まれません。RHEL リポジトリーを使用してイメージを構築することができますが、オーバーヘッドの量は最小限に抑えられます。
  • microdnf のモジュールは対応しています: microdnf コマンドで使用されるモジュールにより、利用可能な場合は、同じソフトウェアの複数のバージョンをインストールできます。microdnf モジュール enable、microdnf モジュール disable、および microdnf モジュールリセットを使用して、モジュールストリームを有効、無効化、およびリセットできます。

    • たとえば、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 コンテナーイメージと呼ばれます。

2.7. UBI init イメージの使用

この手順では、Containerfile を使用してコンテナーを構築する方法を紹介します。この Containerfile は、コンテナーがホストシステムで実行されている場合に Web サーバー (httpd) をインストールして、systemd サービス (/sbin/init) により Web サーバーが自動的に起動されるように設定します。podman build コマンドは、コンテキストディレクトリーにある場合に、 Containerfile を使用します。ない場合には、podman build コマンドは Dockerfile を使用します。それ以外の場合は、--file オプションでファイルを指定できます。Containerfile および Dockerfile 内で使用できる利用可能なコマンドは同じです。

手順

  1. 新しいディレクトリーに以下の内容を含む 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) を開始します。

  2. コンテナーをビルドします。

    # podman build --format=docker -t mysysd .
  3. 任意。お使いのシステムで systemd を使用してコンテナーを実行し、SELinux を有効にする場合は、container_manage_cgroup ブール値変数を設定する必要があります。

    # setsebool -P container_manage_cgroup 1
  4. 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

    1025 以降のポート番号を使用するには、net.ipv4.ip_unprivileged_port_start 変数を変更する必要があります。

    $ sudo sysctl net.ipv4.ip_unprivileged_port_start=80
  5. コンテナーが実行していることを確認します。

    # podman ps
    a282b0c2ad3d  localhost/mysysd:latest  /sbin/init  15 seconds ago  Up 14 seconds ago  0.0.0.0:80->80/tcp  mysysd_run
  6. Web サーバーをテストします。

    # curl localhost/index.html
    Successful Web Server Test

2.8. UBI マイクロイメージの使用

この手順では、Buildah ツールを使用して ubi-micro コンテナーイメージを構築する方法を説明します。

前提条件

  • container-tools モジュールがインストールされている。

    #  yum module install -y container-tools

手順

  1. registry.access.redhat.com/ubi8/ubi-micro イメージをプルしてビルドします。

    # microcontainer=$(buildah from registry.access.redhat.com/ubi8/ubi-micro)
  2. 作業中のコンテナーの root ファイルシステムをマウントします。

    # micromount=$(buildah mount $microcontainer)
  3. httpd サービスを micromount ディレクトリーにインストールします。

    # yum install \
        --installroot $micromount \
        --releasever 8 \
        --setopt install_weak_deps=false \
        --nodocs -y \
        httpd
    # yum clean all \
        --installroot $micromount
  4. 作業コンテナーで root ファイルシステムをアンマウントします。

    # buildah umount $microcontainer
  5. 作業コンテナーから ubi-micro-httpd イメージを作成します。

    # buildah commit $microcontainer ubi-micro-httpd

検証手順

  1. ubi-micro-httpd イメージの詳細を表示します。

    # podman images ubi-micro-httpd
    localhost/ubi-micro-httpd latest 7c557e7fbe9f  22 minutes ago  151 MB

第3章 コンテナーイメージの使用

ここでは、コンテナーイメージの使用方法について説明します。また、イメージをプル、検査、タグ、保存、ロード、再配布を行い、イメージ署名の定義方法も説明します。

3.1. コンテナーレジストリーの設定

podman search コマンドを使用すると、イメージ用に選択したコンテナーレジストリーを検索できます。また、Red Hat コンテナーレジストリー でイメージを検索することもできます。Red Hat コンテナーレジストリーには、イメージの説明、コンテンツ、ヘルスインデックスなど情報が含まれます。

registries.conf の設定ファイルで、レジストリーの一覧を確認できます。root ユーザーとして、/etc/containers/registries.conf ファイルを編集し、デフォルトのシステム全体の検索設定を変更します。

ユーザーとして $HOME/.config/containers/registries.conf ファイルを作成し、システム全体の設定を上書きします。

[registries.search]
registries = ['registry.access.redhat.com', 'registry.redhat.io', 'docker.io']

[registries.insecure]
registries = []

[registries.block]
registries = []
  • デフォルトでは、podman search コマンドは、指定の順序で [registries.search] セクションに記載されているレジストリーからコンテナーイメージを検索します。このような場合には、コマンドは要求されたイメージを registry.access.redhat.comregistry.redhat.io、および docker.io の順に検索します。
  • [registries.insecure] セクションは、レジストリーとの通信に TLS 暗号化を使用しないレジストリーを定義します (この設定はセキュアではありません)。
  • [registries.block] セクションは、ローカルシステムがアクセスできないレジストリーを定義します。

コンテナーレジストリーの設定時に、以下の条件を満たしていることを確認します。

  • 各レジストリーは一重引用符で囲む必要があります。
  • registries = key に複数のレジストリーが設定されている場合は、それらのレジストリーをコンマで区切る必要があります。
  • IP アドレスまたはホスト名のいずれかでレジストリーを識別できます。
  • レジストリーが標準以外のポート (暗号化されている接続用の TCP ポート 443 および暗号化されていない接続用の TCP ポート 80 以外の)を使用する場合は、ポート番号をレジストリー名とともに入力します。たとえば、host.example.com:9999 などと指定します。
  • システムは、registries.search 一覧に表示される順序でレジストリーを検索します。

セキュアではないレジストリーにアクセスするには、レジストリーの完全修飾名 (FQDN) を /etc/containers/registries.conf ファイルの [registries.insecure] セクションに追加します。以下に例を示します。

[registries.insecure]
registries = ['insecure-registry.example.com']

3.2. コンテナーイメージの検索

このセクションでは、quay.io レジストリーで postresql-10 イメージを検索する方法を説明します。

前提条件

  • レジストリーが設定されている。

手順

  1. レジストリーに対して認証します。

    # podman login quay.io
  2. イメージを検索します。

    • 特定のレジストリーで特定のイメージを検索するには、以下を入力します。

      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 オプションをコマンドに渡します。

3.3. レジストリーからのイメージの取得 (プル)

リモートレジストリー (Red Hat の独自のコンテナーレジストリーなど) からコンテナーイメージを取得して、ローカルシステムに追加するには、podman pull コマンドを使用します。

# podman pull <registry>[:<port>]/[<namespace>/]<name>:<tag>

たとえば、registry.redhat.io/ubi8/ubi コンテナーイメージは以下によって識別されます。

  • レジストリーサーバー (registry.redhat.io)
  • namespace (ubi8)
  • イメージ名 (ubi)

同じイメージにバージョンが複数ある場合は、イメージ名を明示的に指定するタグを追加します。デフォルトでは、podman:latest を使用します (例: ubi8/ubi:latest)。

手順

  1. registry.redhat.io レジストリーにログインします。

    $ podman login registry.redhat.io
    Username: username
    Password: **********
    Login Succeeded!
  2. 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

3.4. Podman を使用したイメージのプル

レジストリー、名前空間、イメージ名、タグなどの完全修飾イメージ名を常に使用します。短縮名を使用する場合は、なりすましの固有リスクが常にあります。不明なユーザーや匿名ユーザーが任意の名前でアカウントを作成できないように、信頼できるレジストリー (つまりレジストリー) を追加します。

たとえば、ユーザーは example.registry.com レジストリーから example コンテナーイメージをプルします。example.registry.com が検索リストの最初にない場合には、攻撃者は検索リストの前のほうに別の example イメージを配置することができてしまいます。目的のコンテンツではなく、攻撃者が配置したイメージを間違ってプルして実行する可能性があります。

一部のレジストリーは、生の <name> をサポートします。ここでは、<namespace> は任意です。ただし、それが含まれている場合は、追加の階層レベル <namespace> Provides が、同じ <name> を持つ複数のイメージを区別するため便利です。以下に例を示します。

名前空間(<namespace>/<name>) の例

organization

redhat/kubernetesgoogle/kubernetes

login (ユーザー名)

alice/applicationbob/application

role

devel/databasetest/databaseprod/database

Red Hat が提供するレジストリーは以下のとおりです。

  • registry.redhat.io (認証が必要)
  • registry.access.redhat.com (認証なし)
  • registry.connect.redhat.com (Red Hat Partner Connect プログラムイメージ)

registry.redhat.io への移行の詳細は、「Red Hat Container Registry Authentication」 を参照してください。registry.redhat.io からコンテナーを取得する前に、RHEL サブスクリプション認証情報を使用して認証する必要があります。

3.5. イメージの一覧表示

podman images コマンドを使用して、ローカルストレージのイメージを一覧表示します。

前提条件

  • プルしたイメージがローカルシステムで利用できる。

手順

  • ローカルストレージ内のイメージをすべて一覧表示します。

    $ podman images
    REPOSITORY                           TAG     IMAGE ID      CREATED      SIZE
    registry.access.redhat.com/ubi8/ubi  latest  3269c37eae33  6 weeks ago  208 MB

3.6. ローカルイメージの検証

ローカルシステムにイメージをプルして実行したら、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" の値が使用されます)。

3.7. リモートイメージの検証

skopeo inspect を使用して、システムにイメージをプルする前に、リモートコンテナーレジストリーからイメージに関する情報を表示します。

手順

  1. 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": [
            "8.2-13-source",
            "8.0-15",
            "8.1-28",
            ...
            "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
            ...

3.8. タグ付けイメージ

podman tag コマンドを使用して、ローカルイメージに名前を追加します。この追加した名前は、registryhost/username/NAME:tag のように複数の部分で構成されます。

前提条件

  • プルしたイメージがローカルシステムで利用できる。

手順

  1. すべてのイメージを一覧表示します。

    $ podman images
    REPOSITORY                           TAG     IMAGE ID      CREATED      SIZE
    registry.redhat.io/ubi8/ubi          latest  3269c37eae33  7 weeks ago  208 MB
  2. 以下のいずれかを使用して、myubi 名を registry.redhat.io/ubi8/ubi イメージに割り当てます。

    • イメージ名:

      $ podman tag registry.redhat.io/ubi8/ubi myubi
    • イメージ ID:

      $ podman tag 3269c37eae33 myubi

      どちらのコマンドも、同じ結果になります。

  3. すべてのイメージを一覧表示します。

    $ 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 に割り当てられていることを確認できます。

  4. 以下のいずれかを使用して registry.redhat.io/ubi8/ubi イメージに 8.4 タグを追加します。

    • イメージ名:

      $ podman tag registry.redhat.io/ubi8/ubi myubi:8.4
    • イメージ ID:

      $ podman tag 3269c37eae33 myubi:8.4

      どちらのコマンドも、同じ結果になります。

  5. すべてのイメージを一覧表示します。

    $ 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.4     3269c37eae33  2 months ago  208 MB

    デフォルトのタグがいずれのイメージでも latest であることに注意してください。すべてのイメージ名が単一のイメージ ID 3269c37eae33 に割り当てられていることを確認できます。

registry.redhat.io/ubi8/ubi イメージにタグ付けした後に、コンテナーを実行するオプションが 3 つあります。

  • ID (3269c37eae33)
  • 名前 (localhost/myubi:latest)
  • 名前 (localhost/myubi:8.4)

3.9. イメージの保存および読み込み

podman save コマンドを使用して、イメージをコンテナーアーカイブに保存します。別のコンテナー環境に後で復元したり、別のユーザーに送信することもできます。--format オプションを使用して、アーカイブ形式を指定できます。サポート対象の形式は以下のとおりです。

  • docker-archive
  • oci-archive
  • oci-dir (oci マニフェストタイプのあるディレクトリー)
  • docker-dir (v2s2 マニフェストタイプを含むディレクトリー)

デフォルトの形式は docker-dir です。

podman load コマンドを使用して、コンテナーイメージアーカイブからコンテナーストレージにイメージを読み込みます。

前提条件

  • プルしたイメージがローカルシステムで利用できる。

手順

  1. 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 で実行されます。

  2. myrsyslog.tar のファイルタイプを確認します。

    $ file myrsyslog.tar
    myrsyslog.tar: POSIX tar archive
  3. myrsyslog.tar から registry.redhat.io/rhel8/rsyslog:latest イメージを読み込むには、以下を実行します。

    $ podman load -i myrsyslog.tar
    ...
    Loaded image(s): registry.redhat.io/rhel8/rsyslog:latest

3.10. UBI イメージの再配布

podman push コマンドを使用して、UBI イメージを独自のレジストリーやサードパーティーのレジストリーにプッシュするか、他のと共有します。UBI yum リポジトリーから、必要に応じてイメージをアップグレードまたは追加できます。

前提条件

  • プルしたイメージがローカルシステムで利用できる。

手順

  1. 必要に応じて、ubi イメージに別の名前を追加します。

    # podman tag registry.redhat.io/ubi8/ubi registry.example.com:5000/ubi8/ubi
  2. 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.11. イメージ署名の検証ポリシーの定義

Red Hat は、Red Hat コンテナーレジストリーでイメージの署名を提供します。root で実行時に /etc/containers/registries.d/ ディレクトリーの YAML ファイルと /etc/containers/policy.json ファイルは、署名検証ポリシーを定義します。

/etc/containers/policy.json ファイルの信頼ポリシーは、信頼のレジストリースコープ (レジストリーやリポジトリー) について記述します。

デフォルトでは、コンテナーツールは、$HOME/.config/containers/policy.json ファイル (ある場合) からポリシーを読み取ります。それ以外の場合には、コンテナーツールは /etc/containers/policy.json ファイルからポリシーを読み取ります。

信頼は、3 つのパラメーターを使用して定義されます。

  1. レジストリー または レジストリー/リポジトリー
  2. 1 つ以上のパブリック GPG キー
  3. 署名サーバー

Red Hat は、以下の URI から署名を配布します。

手順

  1. /etc/containers/policy.json ファイルを表示します。

    # cat /etc/containers/policy.json
    {
        "default": [
            {
                "type": "insecureAcceptAnything"
            }
        ],
        "transports":
        {
            "docker-daemon":
            {
                "": [{"type":"insecureAcceptAnything"}]
            }
        }
    }
  2. レジストリー registry.access.redhat.com および registry.redhat.io の既存の信頼スコープを更新するには、次のコマンドを実行します。

    # podman image trust set -f /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release registry.access.redhat.com
    # podman image trust set -f /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release registry.redhat.io
  3. 信頼ポリシーの設定を確認するには、/etc/containers/policy.json ファイルを表示します。

           "docker": {
                "registry.access.redhat.com": [
                    {
                        "type": "signedBy",
                        "keyType": "GPGKeys",
                        "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                    }
                ],
                "registry.redhat.io": [
                    {
                        "type": "signedBy",
                        "keyType": "GPGKeys",
                        "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                    }
                ]
            },

    "registry.access.redhat.com""registry.redhat.io" のセクションが追加されれていることが分かります。

  4. 以下の内容で /etc/containers/registries.d/registry.access.redhat.com.yaml ファイルを作成し、registry.access.redhat.com レジストリーからのコンテナーイメージの署名ストアを特定します。

    docker:
         registry.access.redhat.com:
             sigstore: https://access.redhat.com/webassets/docker/content/sigstore
  5. 以下の内容で etc/containers/registries.d/registry.redhat.io.yaml ファイルを作成します。

    docker:
         registry.redhat.io:
             sigstore: https://registry.redhat.io/containers/sigstore
  6. 信頼設定を表示するには、以下を入力します。

    # podman image trust show                                                          default                     accept
    registry.access.redhat.com  signedBy                security@redhat.com, security@redhat.com  https://access.redhat.com/webassets/docker/content/sigstore
    registry.redhat.io          signedBy                security@redhat.com, security@redhat.com  https://registry.redhat.io/containers/sigstore
                                insecureAcceptAnything
  7. デフォルトの信頼ポリシーを拒否するには、以下を入力します。

    # podman image trust set -t reject default
  8. 信頼ポリシーの設定を確認するには、/etc/containers/policy.json ファイルを表示します。

    # cat /etc/containers/policy.json
    {
        "default": [
        {
            "type": "reject"
        }
    ...
    }

    "default" セクションが "insecureAcceptAnything" から "reject" に変更されていることが分かります。

  9. registry.access.redhat.com レジストリーから最小の Red Hat Universal Base Image 8 (ubi8-minimal) イメージをプルします。

    # podman --log-level=debug pull registry.access.redhat.com/ubi8-minimal
    ....
    DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration
    DEBU[0000]  Using "docker" namespace registry.access.redhat.com
    DEBU[0000]   Using https://access.redhat.com/webassets/docker/content/sigstore
    ...

    access.redhat.com/webassets/docker/content/sigstore の署名ストレージアドレスが /etc/containers/registries.d/registry.access.redhat.com.yaml で指定したアドレスと一致していることが確認できます。

  10. registry.redhat.io レジストリーにログインします。

    # podman login registry.redhat.io
    Username: username
    Password: ***********
    Login Succeeded!
  11. registry.redhat.io レジストリーから support-tools イメージをプルします。

    # podman --log-level=debug pull registry.redhat.io/rhel8/support-tools
    ...
    DEBU[0000] Using registries.d directory /etc/containers/registries.d for sigstore configuration
    DEBU[0000]  Using "docker" namespace registry.redhat.io
    DEBU[0000]   Using https://registry.redhat.io/containers/sigstore
    ...

    registry.redhat.io/containers/sigstore の署名ストレージアドレスが /etc/containers/registries.d/registry.redhat.io.yaml で指定したアドレスと一致していることが確認できます。

  12. ローカルシステムにプルしたすべてのイメージを一覧表示するには、次のコマンドを入力します。

    # podman images
    REPOSITORY                               TAG     IMAGE ID      CREATED       SIZE
    registry.redhat.io/rhel8/support-tools   latest  5ef2aab09451  13 days ago   254 MB
    registry.access.redhat.com/ubi8-minimal  latest  86c870596572  13 days ago   146 MB

関連情報

3.12. イメージの削除

podman rmi コマンドを使用して、ローカルに保存されたコンテナーイメージを削除します。ID または名前を使用して、イメージを削除できます。

手順

  1. ローカルシステムにある全イメージの一覧を表示します。

    $ 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
  2. すべてのコンテナーを一覧表示します。

    $ 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 または名前を使用して停止できます。

  3. mysyslog コンテナーを停止します。

    $ podman stop mysyslog
    7ccd6001166e9720c47fbeb077e0afd0bb635e74a1b0ede3fd34d09eaf5a52e9
  4. 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...

第4章 コンテナーの使用

コンテナーは、展開されたコンテナーイメージにあるファイルから作成された、実行中プロセスまたは停止プロセスを表します。Podman ツールを使用してコンテナーと連携できます。

4.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 と記述されます。

4.2. ホストからのコンテナーでのコマンド実行

この手順では、podman run コマンドを使用して、コンテナーのオペレーティングシステムタイプを表示する方法を説明します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. 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"
    VERSION="8.2 (Ootpa)"
    ID="rhel"
    ID_LIKE="fedora"
    VERSION_ID="8.2"
    PLATFORM_ID="platform:el8"
    PRETTY_NAME="Red Hat Enterprise Linux 8.2 (Ootpa)"
    ANSI_COLOR="0;31"
    CPE_NAME="cpe:/o:redhat:enterprise_linux:8.2:GA"
    HOME_URL="https://www.redhat.com/"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    
    REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
    REDHAT_BUGZILLA_PRODUCT_VERSION=8.2
    REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
    REDHAT_SUPPORT_PRODUCT_VERSION="8.2"
  2. オプション: すべてのコンテナーを一覧表示します。

    $ podman ps
    CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES

    --rm オプションがあるのでコンテナーは表示されません。コンテナーが削除されました。

関連情報

  • man podman-run

4.3. コンテナー内でのコマンドの実行

この手順では、podman run コマンドを使用して、コンテナーを対話的に実行する方法を説明します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. 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 オプションを指定しないと、シェルが開き、終了します。
  2. システムユーティリティーのセットが含まれる procps-ng パッケージをインストールします (例: pstopuptime など)。

    [root@6ccffd0f6421 /]# yum install procps-ng
  3. 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
  4. exit を実行してコンテナーを終了し、ホストに戻ります。

    # exit
  5. 必要に応じて、すべてのコンテナーを一覧表示します。

    $ 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

    コンテナーが終了ステータスであることを確認できます。

関連情報

  • man podman-run

4.4. コンテナーの一覧表示

podman ps コマンドを使用して、システムで実行中のコンテナーの一覧を表示します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. registry.redhat.io/rhel8/rsyslog イメージをベースとするコンテナーを実行します。

    $ podman run -d registry.redhat.io/rhel8/rsyslog
  2. すべてのコンテナーを一覧表示します。

    • 実行中のコンテナーの一覧を表示するには、以下のコマンドを実行します。

      $ 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 オプション) コンテナーが存在する場合には、コンテナーがあるので、再起動できます。

関連情報

  • man podman-ps

4.5. コンテナーの起動

コンテナーを実行してから停止し、削除しない場合には、ローカルシステムに保存されて再び実行する準備ができます。podman start コマンドを使用して、コンテナーを再実行できます。コンテナー ID または名前を使用して、コンテナーを指定できます。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools
  • 1 つ以上のコンテナーが停止されている。

手順

  1. myubi コンテナーを起動します。

    • 非対話モードで以下を行います。

      $ podman start myubi

      または、podman start 1984555a2c27 を使用することもできます。

    • 対話モードで、 -a (--attach) および -t (--interactive) を使用して、コンテナーの bash シェルと連携します。

      $ podman start -a -i myubi

      または、podman start -a -i 1984555a2c27 を使用することができます。

  2. exit を実行してコンテナーを終了し、ホストに戻ります。

    [root@6ccffd0f6421 /]# exit

関連情報

  • man podman-start

4.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 タイムスタンプ (StartedAtState の配下にある) を確認するには、--format オプションとコンテナー ID または名前を使用します。

検証する他の項目の例には、以下が含まれます。

  • .path: コンテナーとともに実行するコマンドを表示します。
  • .Args: コマンドに指定する引数
  • .Config.ExposedPorts: コンテナーから公開する TCP または UDP ポート
  • .state.Pid: コンテナーのプロセス ID を表示します。
  • .HostConfig.PortBindings: コンテナーからホストへのポートマッピング

関連情報

  • man podman-inspect

4.7. localhost のディレクトリーのコンテナーへのマウント

以下の手順では、コンテナーでホストの /dev/log デバイスをマウントして、コンテナー内のログメッセージをホストシステムに公開する方法を説明します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. 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"
  2. journalctl ユーティリティーを使用してログを表示します。

    # journalctl -b | grep Testing
    Dec 09 16:55:00 localhost.localdomain root[14634]: Testing logging to the host

    --rm オプションは、終了時にコンテナーを削除します。

関連情報

  • man podman-run

4.8. コンテナーのファイルシステムのマウント

podman mount コマンドを使用して、ホストからアクセス可能な場所に、作業コンテナーの root ファイルシステムをマウントします。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. mysyslog という名前のコンテナーを実行します。

    # podman run -d --name=mysyslog registry.redhat.io/rhel8/rsyslog
  2. 必要に応じて、すべてのコンテナーを一覧表示します。

    # 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
  3. mysyslog コンテナーをマウントします。

    # podman mount mysyslog
    /var/lib/containers/storage/overlay/990b5c6ddcdeed4bde7b245885ce4544c553d108310e2b797d7be46750894719/merged
  4. 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
  5. OS バージョンを表示します。

    # cat /var/lib/containers/storage/overlay/990b5c6ddcdeed4bde7b245885ce4544c553d108310e2b797d7be46750894719/merged/etc/os-release
    NAME="Red Hat Enterprise Linux"
    VERSION="8.3 (Ootpa)"
    ID="rhel"
    ID_LIKE="fedora"
    VERSION_ID="8.3"

関連情報

  • man podman-mount

4.9. 静的 IP を使用したデーモンとしてのサービスの実行

以下の例は、rsyslog サービスをバックグラウンドでデーモンプロセスとして実行します。--ip オプションは、コンテナーのネットワークインターフェースを特定の IP アドレスに設定します (例: 10.88.0.44)。その後、podman inspect コマンドを実行して、IP アドレスを適切に設定できます。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. コンテナーのネットワークインターフェースを IP アドレス 10.88.0.44 に設定します。

    # podman run -d --ip=10.88.0.44 registry.access.redhat.com/rhel7/rsyslog
    efde5f0a8c723f70dd5cb5dc3d5039df3b962fae65575b08662e0d5b5f9fbe85
  2. IP アドレスが正しく設定されていることを確認します。

    # podman inspect efde5f0a8c723 | grep 10.88.0.44
    "IPAddress": "10.88.0.44",

関連情報

  • man podman-run

4.10. 実行中のコンテナー内でのコマンドの実行

podman exec コマンドを使用して、実行中のコンテナーでコマンドを実行し、そのコンテナーを調べます。コンテナーアクティビティーを中断せずに実行中のコンテナーを調査できるので、podman run コマンドの代わりに podman exec コマンドを使用します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools
  • コンテナーが実行されている。

手順

  1. 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
    ...
  2. myrsyslog コンテナーで /bin/bash コマンドを実行します。

    $ podman exec -it myrsyslog /bin/bash
  3. システムユーティリティーのセットが含まれる procps-ng パッケージをインストールします (例: pstopuptime など)。

    # yum install procps-ng
  4. コンテナーを検査します。

    • システムにある全プロセスを一覧表示するには、以下のコマンドを実行します。

      # 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

関連情報

  • man podman-exec

4.11. 2 つのコンテナー間でのファイルの共有

コンテナーが削除されても、ボリュームを使用してコンテナー内のデータを永続化できます。ボリュームは、複数のコンテナー間でのデータ共有に使用できます。ボリュームとは、ホストマシンに保存されているフォルダーです。ボリュームはコンテナーとホスト間で共有できます。

主な利点は以下のとおりです。

  • ボリュームはコンテナー間で共有できます。
  • ボリュームは、他と比べるとバックアップまたは移行が簡単です。
  • ボリュームを使用するとコンテナーのサイズが増えません。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. ボリュームを作成します。

    $ podman volume create hostvolume
  2. ボリュームに関する情報を表示します。

    $ 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 に変わります。

  3. パスを使用してディレクトリーにテキストファイルを作成し、mntPoint 変数に格納します。

    $ echo "Hello from host" >> $mntPoint/host.txt
  4. mntPoint 変数で定義されたディレクトリー内の全ファイルを一覧表示します。

    $ ls $mntPoint/
    host.txt
  5. 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 を使用します。

  6. コンテナー上にある共有ボリューム内のファイルを一覧表示します。

    # ls /containervolume1
    host.txt

    ホスト上で作成した host.txt ファイルが表示されます。

  7. /containervolume1 ディレクトリーにテキストファイルを作成します。

    # echo "Hello from container 1" >> /containervolume1/container1.txt
  8. CTRL+p および CTRL+q を使用してコンテナーからデタッチします。
  9. ホスト上にある共有ボリューム内のファイルを一覧表示します。以下の 2 つのファイルが表示されるはずです。

    $ ls $mntPoint
    container1.rxt  host.txt

    この時点で、コンテナーとホスト間でファイルを共有しています。2 つのコンテナー間でファイルを共有するには、myubi2 という名前の別のコンテナーを実行します。手順 10: 手順 135 から 8 の手順に類似しています。

  10. myubi2 という名前のコンテナーを実行し、ホストのボリューム名 hostvolume で定義したディレクトリーを コンテナーの /containervolume2 ディレクトリーにマッピングします。

    $ podman run -it --name myubi2 -v hostvolume:/containervolume2 registry.access.redhat.com/ubi8/ubi  /bin/bash
  11. コンテナー上にある共有ボリューム内のファイルを一覧表示します。

    # ls /containervolume2
    container1.txt host.txt

    ホストで作成した host.txt ファイルと、myubi1 コンテナー内に作成した container1.txt ファイルが表示されます。

  12. /containervolume2 ディレクトリーにテキストファイルを作成します。

    # echo "Hello from container 2" >> /containervolume2/container2.txt
  13. CTRL+p および CTRL+q を使用してコンテナーからデタッチします。
  14. ホスト上にある共有ボリューム内のファイルを一覧表示します。以下の 3 つのファイルが表示されるはずです。

    $ ls $mntPoint
    container1.rxt  container2.txt host.txt

関連情報

  • man podman-volume

4.12. コンテナーのエクスポートおよびインポート

podman export コマンドを使用して、実行中のコンテナーのファイルシステムをローカルマシンの tarball にエクスポートできます。たとえば、頻繁に使用しない大規模なコンテナーがある場合、スナップショットを保存して後で復元できるようにする場合には、podman export コマンドを使用して、実行中のコンテナーの現在のスナップショットを tarball にエクスポートできます。

podman import コマンドを使用して tarball をインポートし、ファイルシステムイメージとして保存できます。これにより、このファイルシステムイメージを実行するか、他のイメージのレイヤーとして使用できます。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. registry.access.redhat.com/ubi8/ubi イメージに基づいて、myubi コンテナーを実行します。

    $ podman run -dt --name=myubi registry.access.redhat.com/ubi8/ubi
  2. 必要に応じて、すべてのコンテナーを一覧表示します。

    $ podman ps -a
    CONTAINER ID  IMAGE                                    COMMAND          CREATED     STATUS         PORTS   NAMES
    a6a6d4896142  registry.access.redhat.com/ubi8:latest   /bin/bash        7 seconds ago  Up 7 seconds ago          myubi
  3. myubi コンテナーに割り当てます。

    $ podman attach myubi
  4. testfile という名前のファイルを作成します。

    [root@a6a6d4896142 /]# echo "hello" > testfile
  5. CTRL+p および CTRL+q を使用してコンテナーからデタッチします。
  6. ローカルマシンで、myubi のファイルシステムを myubi-container.tar としてエクスポートします。

    $ podman export -o myubi.tar a6a6d4896142
  7. 必要に応じて、現在のディレクトリーの内容を一覧表示します。

    $ ls -l
    -rw-r--r--. 1 user user 210885120 Apr  6 10:50 myubi-container.tar
    ...
  8. 必要に応じて、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 にコンテナーのファイルシステムが含まれていることを確認できます。

  9. 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
  10. すべてのイメージを一覧表示します。

    $ podman images
    REPOSITORY                              TAG     IMAGE ID      CREATED         SIZE
    docker.io/library/myubi-imported       latest  c296689a17da  51 seconds ago  211 MB
  11. testfile ファイルの内容を表示します。

    $ podman run -it  --name=myubi-imported docker.io/library/myubi-imported cat testfile
    hello

関連情報

  • podman-export man ページ
  • podman-import man ページ

4.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

関連情報

  • man podman-stop
  • man podman-kill

4.14. コンテナーの削除

podman rm コマンドを使用して、コンテナーを削除します。コンテナー ID または名前でコンテナーを指定できます。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools
  • 1 つ以上のコンテナーが停止されている。

手順

  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
  2. コンテナーを削除します。

    • 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

関連情報

  • man podman-rm

第5章 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 イメージ上にあります。

5.1. Pod の作成

以下の手順では、コンテナーが 1 つ含まれる Pod を作成する方法を説明します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. 空の Pod を作成します。

    $ podman pod create --name mypod
    223df6b390b4ea87a090a4b5207f7b9b003187a6960bd37631ae9bc12c433aff
    The pod is in the initial state Created.

    Pod の初期状態は Created です。

  2. 必要に応じて、すべての 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 つあることに注意してください。

  3. 必要に応じて、関連付けられている全 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 イメージをベースとしています。

  4. mypod という名前の既存 Pod 内で、名前が myubi のコンテナーを実行します。

    $ podman run -dt --name myubi --pod mypod registry.access.redhat.com/ubi8/ubi  /bin/bash
    5df5c48fea87860cf75822ceab8370548b04c78be9fc156570949013863ccf71
  5. 必要に応じて、すべての 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 つあることが分かります。

  6. 必要に応じて、関連付けられている全 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

関連情報

5.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 ページ

5.3. Pod の停止

1 つ以上の Pod を停止するには、podman pod stop コマンドを使用します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools
  • Pod が作成されている。詳細は、「Pod の作成」を参照してください。

手順

  1. Pod mypod を停止します。

    $ podman pod stop mypod
  2. 必要に応じて、関連付けられている全 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/ubi8/pause                           About a minute ago  Exited (0) 7 seconds ago          8a4e6527ac9d-infra  223df6b390b4  mypod

    Pod mypod およびコンテナー myubi のステータスが「Exited」であることが分かります。

関連情報

  • podman-pod-stop man ページ

5.4. Pod の削除

停止されている Pod またはコンテナーを削除するには、podman pod rm コマンドを使用します。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools
  • Pod が作成されている。詳細は、「Pod の作成」を参照してください。
  • Pod が停止されている。詳細は、「Pod の停止」を参照してください。

手順

  1. 以下を入力して、Pod mypod を削除します。

    $ podman pod rm mypod
    223df6b390b4ea87a090a4b5207f7b9b003187a6960bd37631ae9bc12c433aff

    Pod を削除すると、その Pod 中の全コンテナーが自動的に削除されることに注意してください。

  2. 必要に応じて、すべてのコンテナーおよび Pod が削除されたことを確認します。

    $ podman ps
    $ podman pod ps

関連情報

  • podman-pod-rm man ページ

第6章 実行中の UBI コンテナーへのソフトウェアの追加

UBI イメージは、Red Hat のコンテンツで構築されます。また、この UBI イメージは、UBI でインストールするのに自由に利用できる Red Hat Enterprise Linux パッケージのサブセットも提供します。ソフトウェアを追加または更新する場合、UBI イメージは、公式の Red Hat の RPM を保持するのに利用できる無料の yum リポジトリーを指定するように事前設定されています。

UBI コンテナーを実行するパッケージを UBI リポジトリーから追加するには、以下を行います。

  • ubi イメージで、yum コマンドをインストールするとパッケージを取り出せます。
  • ubi-minimal イメージには、yum の代わりに、microdnf コマンド (小規模な機能セット) が含まれます。

実行中のコンテナーでソフトウェアパッケージを直接インストールして作業する場合は、パッケージを一時的に追加します。もしくは、リポジトリーについて学ぶことになります。UBI ベースのイメージを構築する詳細な方法は「UBI ベースのイメージの構築」を参照してください。

UBI イメージを使用する際に考慮すべき問題を以下に示します。

  • 既存のアプリケーションストリームランタイムイメージで使用される数百の RPM パッケージは、新しい UBI イメージに同梱されている yum リポジトリーに保存されます。UBI イメージにこの RPM をインストールして、必要なランタイム (python、php、nodejs など) をエミュレートします。
  • UBI の最小イメージ (ubi8/ubi-minimal) には、いくつかの言語ファイルとドキュメントが含まれていないため、そのコンテナーで rpm -Va を実行すると、多くのパッケージの内容が欠落しているか変更されているものとして表示されます。そのコンテナーの中にファイルの完全なリストがあることが重要な場合は、Tripwire などのツールを使用してファイルをコンテナーに記録し、後で確認することを考慮してください。
  • レイヤー構造のイメージを作成したら、podman history を使用して、どの UBI イメージが構築されたかを確認します。たとえば、前に示した webserver の例を完了したら、podman history johndoe/webserver と入力して、それが構築されたイメージに、Dockerfile の FROM 行に追加した UBI イメージのイメージ ID が含まれていることを確認します。

UBI コンテナーにソフトウェアを追加する場合は、サブスクライブしている RHEL ホスト、またはサブスクライブしていない (または非 RHEL) システムで UBI イメージを更新する手順が異なります。UBI イメージを使用する 2 つの方法を以下に示します。

6.1. UBI コンテナーへのソフトウェアの追加 (サブスクライブされたホスト)

登録およびサブスクライブされた RHEL ホストで UBI コンテナーを実行している場合は、主要な RHEL Server リポジトリーが、標準の UBI コンテナーとすべての UBI リポジトリーで有効になります。そのため、Red Hat パッケージの全セットが利用できます。UBI の最小コンテナーでは、すべての UBI リポジトリーがデフォルトで有効になりますが、デフォルトではホストではリポジトリーが有効になっていません。

6.2. 標準の UBI コンテナーへのソフトウェアの追加

構築するコンテナーが再配布されるようにするには、ソフトウェアを追加するときに、標準の UBI イメージで非 UBI の yum リポジトリーを無効にします。UBI リポジトリー以外の yum リポジトリーをすべて無効にする場合は、ソフトウェアを追加するときに、自由に利用可能なリポジトリーのパッケージのみが使用されます。

サブスクライブしている RHEL ホストから、標準の UBI ベースイメージコンテナー (ubi8/ubi) でシェルを開いた状態で、次のコマンドを実行して、そのコンテナーにパッケージ (bzip2 パッケージなど) を追加します。

# yum install --disablerepo=* --enablerepo=ubi-8-appstream --enablerepo=ubi-8-baseos bzip2

RHEL サーバーのリポジトリーにあり UBI リポジトリーにない標準の UBI コンテナーにソフトウェアを追加するには、リポジトリーを無効にせずに、パッケージをインストールします。

# yum install zsh

標準の UBI コンテナーから、別のホストのリポジトリーにあるパッケージをインストールするには、必要なリポジトリーを明示的に有効にする必要があります。以下に例を示します。

# yum install --enablerepo=rhel-7-server-optional-rpms zsh-html
警告

Red Hat UBI リポジトリーに含まれていない Red Hat パッケージをインストールすると、サブスクライブしたホスト外にコンテナーを配信できる範囲が制限される可能性があります。

6.3. 最小 UBI コンテナー内へのソフトウェアの追加

UBI の yum リポジトリーは、デフォルトで UBI 最小イメージで有効になります。

UBI 最小コンテナーでサブスクライブしている RHEL ホストのいずれかの UBI yum リポジトリーから、上記と同じパッケージ (bzip2) をインストールするには、以下を入力します。

# microdnf install bzip2

(UBI yum リポジトリーに含まれない) サブスクライブしたホストで利用可能なリポジトリーの最小 UBI コンテナーにパッケージをインストールするには、このリポジトリーを明示的に有効にする必要があります。以下に例を示します。

# microdnf install --enablerepo=rhel-7-server-rpms zsh
# microdnf install --enablerepo=rhel-7-server-rpms \
        --enablerepo=rhel-7-server-optional-rpms zsh-html
警告

UBI 以外の RHEL リポジトリーを使用して、UBI イメージにパッケージをインストールすると、そのイメージを共有し、サブスクライブしている RHEL システム以外で実行する機能が制限される可能性があります。

6.4. UBI コンテナーへのソフトウェアの追加 (サブスクライブしていないホスト)

サブスクライブしていない RHEL ホストまたはその他の Linux システムにある実行中のコンテナーにソフトウェアパッケージを追加するには、yum リポジトリーを無効にする必要がありません。以下に例を示します。

# yum install bzip2

UBI の最小コンテナーから、サブスクライブしていない RHEL ホストにそのパッケージをインストールする場合は、次のコマンドを実行します。

# microdnf install bzip2

前述のように、実行中の UBI コンテナーにソフトウェアを追加するこの両方の手段は、永続的な UBI ベースのコンテナーイメージを作成することを目的としているわけではありません。そのため、次のセクションで説明するように、UBI イメージに新しいレイヤーを構築する必要があります。

6.5. UBI ベースのイメージの構築

UBI ベースのコンテナーイメージは、他のイメージを構築するのと同じ方法で構築できますが、例外があります。再配布できる Red Hat ソフトウェアのみがイメージに含まれるようにするには、イメージを実際にビルドするときに非 UBI yum リポジトリーをすべて無効にする必要があります。

これは、buildah ユーティリティーを使用して、Dockerfile から、UBI ベースの Web サーバーコンテナーを作成する例です。

注記

ubi8/ubi-minimal イメージの場合は、以下のように、yum の代わりに microdnf を使用します。

RUN microdnf update -y && rm -rf /var/cache/yum
RUN microdnf install httpd -y && microdnf clean all
  1. Dockerfile の作成 - 以下の内容を含む Dockerfile を、新しいディレクトリーに追加します。

    FROM registry.access.redhat.com/ubi8/ubi
    USER root
    LABEL maintainer="John Doe"
    # Update image
    RUN yum update --disablerepo=* --enablerepo=ubi-8-appstream --enablerepo=ubi-8-baseos -y && rm -rf /var/cache/yum
    RUN yum install --disablerepo=* --enablerepo=ubi-8-appstream --enablerepo=ubi-8-baseos 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"]
  2. 新しいイメージの構築 - そのディレクトリーにいるときに、buildah を使用して、新しい UBI レイヤー構造のイメージを作成します。

    # 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 --enablerepo=ubi-8-baseos -y
    . . .
    No packages marked for update
    STEP 5: RUN yum install --disablerepo=* --enablerepo=ubi-8-appstream --enablerepo=ubi-8-baseos httpd -y
    Loaded plugins: ovl, product-id, search-disabled-repos
    Resolving Dependencies
    --> Running transaction check
    =============================================================
     Package                  Arch               Version                        Repository                    Size
    =============================================================
    Installing:
     httpd              x86_64 2.4.37-10
                                                  latest-rhubi-8.0-appstream 1.4 M
    Installing dependencies:
     apr                x86_64 1.6.3-9.el8        latest-rhubi-8.0-appstream 125 k
     apr-util           x86_64 1.6.1-6.el8        latest-rhubi-8.0-appstream 105 k
     httpd-filesystem   noarch 2.4.37-10
                                                  latest-rhubi-8.0-appstream  34 k
     httpd-tools        x86_64 2.4.37-10.
    ...
    
    Transaction Summary
    ...
    Complete!
    STEP 6: RUN echo "The Web Server is Running" > /var/www/html/index.html
    STEP 7: EXPOSE 80
    STEP 8: CMD ["-D", "FOREGROUND"]
    STEP 9: ENTRYPOINT ["/usr/sbin/httpd"]
    STEP 10: COMMIT
    ...
    Writing manifest to image destination
    Storing signatures
    --> 36a604cc0dd3657b46f8762d7ef69873f65e16343b54c63096e636c80f0d68c7
  3. テスト - UBI レイヤー構造の webserver イメージをテストします。

    # podman run -d -p 80:80 johndoe/webserver
    bbe98c71d18720d966e4567949888dc4fb86eec7d304e785d5177168a5965f64
    # curl http://localhost/index.html
    The Web Server is Running

6.6. アプリケーションストリームランタイムイメージの使用

Red Hat Enterprise Linux 8 Application Stream は、コンテナービルドのベースとして使用できる別のコンテナーイメージセットを提供します。このイメージは、RHEL 標準ベースイメージに基づいて構築されており、ほとんどはすでに UBI イメージとして更新されています。このイメージには、特定のランタイム環境で使用する追加ソフトウェアが含まれます。

PHP ランタイムソフトウェアなどが必要な複数のイメージを構築することが予想される場合は、PHP Application Stream ソフトウェアコレクションイメージから始めることで、そのイメージに対してより一貫性のあるプラットフォームを提供できます。

以下は、UBI ベースイメージに構築された Application Stream コンテナーイメージの例です。これは、Red Hat レジストリー (registry.access.redhat.com または registry.redhat.io) から入手できます。

  • ubi8/php-72 - アプリケーションを構築して実行する PHP 7.2 プラットフォーム
  • ubi8/nodejs-10 - アプリケーションを構築して実行する Node.js 10 プラットフォーム。Node.js 10 Source-To-Image ビルドで使用
  • ubi8/ruby25 - アプリケーションを構築して実行する Ruby 2.5 プラットフォーム
  • ubi8/python-27 - アプリケーションを構築して実行する Python 2.7 プラットフォーム
  • ubi8/python-36 - アプリケーションを構築して実行する Python 3.6 プラットフォーム
  • ubi8/s2i-core - perl、python、ruby などのビルダーイメージのベースとして使用する、基本的なライブラリーおよびツールを含むベースイメージ
  • ubi8/s2i-base - Source-to-Image ビルドのベースイメージ

このような UBI イメージコンテナーには、従来のイメージと同じ基本ソフトウェアが含まれているため、詳細は『Using Red Hat Software Collections Container Images』を参照してください。このようなイメージを取得するには、UBI イメージ名を使用してください。

RHEL 8 Application Stream コンテナーイメージは、RHEL 8 ベースイメージが更新されるたびに更新されます。RHEL 7 の場合、このイメージ (Red Hat Software Collections イメージと呼ばれています) は、(Dotnet および DevTools の関連イメージである) RHEL ベースイメージの更新とは別のスケジュールで更新されます。このようなイメージの詳細は「Red Hat Container Catalog」を検索します。更新スケジュールの詳細は「Red Hat Container Image Updates」を参照してください。

6.7. UBI コンテナーイメージソースコードの取得

すべての Red Hat UBI ベースのイメージのソースコードは、ダウンロード可能なコンテナーの形で入手できます。続行する前に、Red Hat ソースコンテナーに注意してください。

  • コンテナーとしてパッケージ化されているにもかかわらず、ソースコンテナーイメージを実行できません。システムに Red Hat ソースコンテナーイメージをインストールするには、podman pull コマンドを使用する代わりに、skopeo コマンドを使用します。

    • skopeo copy コマンドを使用して、ソースコンテナーイメージをローカルシステムのディレクトリーにコピーします。
    • skopeo inspect コマンドを使用して、ソースコンテナーイメージを検査します。
  • skopeo コマンドの詳細は、セクション 1.5.「Using skopeo to work with container registries」を参照してください。
  • ソースコンテナーイメージは、それらが表すバイナリーコンテナーに基づいて名前が付けられます。たとえば、ある標準的な RHEL UBI 8 コンテナーでは、registry.access.redhat.com/ubi8:8.1-397-source を追加してソースコンテナーイメージを取得します (registry.access.redhat.com/ubi8:8.1-397-source)。
  • ソースコンテナーイメージがローカルディレクトリーにコピーされたら、tar コマンド、gzip コマンド、および rpm コマンドの組み合わせを使用して、そのコンテンツを操作できます。
  • コンテナーイメージがリリースされてから、関連するソースコンテナーが利用可能になるまでに数時間かかる場合があります。

手順

  1. 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
    Copying blob 26fe858c966c done
    Copying blob ba4b5f020b99 done
    Copying blob f7d970ccd456 done
    Copying blob ade06f94b556 done
    Copying blob cc56c782b513 done
    Copying blob dcf9396fdada done
    Copying blob feb6d2ae2524 done
    Copying config dd4cd669a4 done
    Writing manifest to image destination
    Storing signatures
  2. 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
    }
  3. すべてのコンテンツを展開するには、次のコマンドを実行します。

    $ cd $HOME/TEST
    $ for f in $(ls); do tar xvf $f; done
  4. 結果を確認するには、次のコマンドを実行します。

    $ find blobs/ rpm_dir/
    blobs/
    blobs/sha256
    blobs/sha256/10914f1fff060ce31388f5ab963871870535aaaa551629f5ad182384d60fdf82
    rpm_dir/
    rpm_dir/gzip-1.9-4.el8.src.rpm
  5. コンテンツの調査と使用を開始します。

6.8. 関連情報

  • Red Hat パートナーおよびお客様は、標準の方法でサポートチケットを作成することにより、パッケージリクエストを含む新機能を要求できます。Red Hat 以外のお客様はサポートを受けませんが、適切な RHEL 製品向けの標準 Red Hat Bugzilla でリクエストを作成できます。詳細は、「Red Hat Bugzilla Queue」を参照してください。
  • Red Hat パートナーおよびお客様は、サポートされる Red Hat プラットフォーム (OpenShift/RHEL) で UBI を実行している場合に、通常の方法でサポートチケットを作成できます。Red Hat サポートスタッフがパートナーとお客様の問題に対応します。詳細は 「サポートケースの作成」を参照してください。

第7章 コンテナーでの Skopeo、Buildah、および Podman の実行

本章では、コンテナーで Skopeo、Buildah、および Podman を実行する方法について説明します。

Skopeo を使用すると、すべてのレイヤーでイメージ全体をダウンロードすることなく、リモートレジストリーのイメージを検査できます。また、Sopeo を使用して、イメージのコピー、イメージの署名、イメージの同期、さまざまな形式およびレイヤー圧縮でのイメージ変換を行うこともできます。

Buildah を使用すると、OCI コンテナーイメージのビルドが容易になります。Buildah を使用すると、作業コンテナーをゼロから作成することも、イメージを開始点として使用して作成することも可能です。作業コンテナーからか、Dockerfile の手順を使用して、イメージを作成できます。作業コンテナーの 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: ホストで古い OS を実行していても、最新バージョンの Skopeo、Buildah、または Podman を実行します。このソリューションは、コンテナーでコンテナーツールを実行します。たとえば、これは、最新版をネイティブで使用できない RHEL 7 コンテナーホストで、RHEL 8 で提供される最新版のコンテナーツールを実行するのに役立ちます。
  • HPC 環境:

    • all: HPC 環境で一般的な制限は、root 以外のユーザーがホストにパッケージをインストールできないことです。コンテナーで Skopeo、Buildah、または Podman を実行すると、root 以外のユーザーとしてこの特定のタスクを実行することができます。

7.1. コンテナーでの Skopeo の実行

この手順では、Skopeo を使用してリモートコンテナーイメージを検証する方法を説明します。コンテナーで Skopeo を実行すると、コンテナーの root ファイルシステムがホストの root ファイルシステムから分離されることを意味します。ホストとコンテナー間でファイルを共有またはコピーするには、ファイルとディレクトリーをマウントする必要があります。

前提条件

  • container-tools モジュールがインストールされている。

    # yum module install -y container-tools

手順

  1. registry.redhat.io レジストリーにログインします。

    $ podman login registry.redhat.io
    Username: myuser@mycompany.com
    Password: ***********
    Login Succeeded!
  2. registry.redhat.io/rhel8/skopeo コンテナーイメージを取得します。

    $ podman pull registry.redhat.io/rhel8/skopeo
  3. 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 イメージを削除します。

関連情報

7.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

関連情報

7.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 をボリュームマウントします。

関連情報

7.4. ホストに対するコンテナーイメージのコピー

skopeo、Buildah、Podman は同じローカルコンテナーイメージストレージを共有します。ホストコンテナーストレージとの間でコンテナーをコピーする場合は、これを Skopeo コンテナーにマウントする必要があります。

注記

ホストコンテナーストレージへのパスは、root (/var/lib/containers/storage) と root 以外のユーザー ($HOME/.local/share/containers/storage) の間で異なります。

前提条件

  • container-tools モジュールがインストールされている。

    # yum module install -y container-tools

手順

  1. 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
  2. 必要に応じて ローカルストレージ内のイメージを一覧表示します。

    $ podman images
    REPOSITORY                               TAG     IMAGE ID      CREATED       SIZE
    registry.access.redhat.com/ubi8/ubi      latest  ecbc6f53bba0  8 weeks ago   211 MB

関連情報

7.5. コンテナーでの Buildah の実行

この手順では、コンテナーで Buildah を実行し、イメージを基に作業コンテナーを作成する方法を説明します。

前提条件

  • container-tools モジュールがインストールされている。

    # yum module install -y container-tools

手順

  1. registry.redhat.io レジストリーにログインします。

    $ podman login registry.redhat.io
    Username: myuser@mycompany.com
    Password: ***********
    Login Succeeded!
  2. registry.redhat.io/rhel8/buildah イメージをプルして実行します。

    # podman run --rm --device /dev/fuse -it registry.redhat.io/rhel8/buildah  /bin/bash
    • --rm オプションは、コンテナーの終了後に registry.redhat.io/rhel8/buildah イメージを削除します。
    • --device オプションは、ホストデバイスをコンテナーに追加します。
  3. registry.access.redhat.com/ubi8 イメージを使用して、新しいコンテナーを作成します。

    # buildah from registry.access.redhat.com/ubi8
    ...
    ubi8-working-container
  4. 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
  5. 必要に応じて、ローカルストレージ内の全イメージを一覧表示します。

    # buildah images
    REPOSITORY                        TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi8   latest   ecbc6f53bba0   5 weeks ago   211 MB
  6. 必要に応じて、作業用コンテナーとそのベースイメージを一覧表示します。

    # buildah containers
    CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
    0aaba7192762     *     ecbc6f53bba0 registry.access.redhat.com/ub... ubi8-working-container
  7. 必要に応じて、registry.access.redhat.com/ubi8 イメージを registry.example.com にあるローカルレジストリーにプッシュします。

    # buildah push ecbc6f53bba0 registry.example.com:5000/ubi8/ubi

7.6. コンテナーでの Podman の実行

この手順では、Podman を使用してコンテナー内でコンテナーを実行する方法を説明します。この例では、Podman を使用してコンテナーから別のコンテナーをビルドし、実行する方法を示しています。コンテナーは、簡単なテキストベースのゲーム「Moon-buggy」を実行します。

前提条件

  • container-tools モジュールがインストールされている。

    # yum module install -y container-tools
  • registry.redhat.io レジストリーにログインしている。

    # podman login registry.redhat.io

手順

  1. registry.redhat.io/rhel8/podman イメージをベースとするコンテナーを実行します。

    # podman run --privileged --name podman_container -it registry.redhat.io/rhel8/podman /bin/bash
    • --it オプションは、コンテナー内で対話式 bash シェルを実行します。
    • --privileged オプションは、Podman で Podman の実行に必要な追加機能を追加します。
  2. 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 パッケージをインストールします。
    • コンテナーコマンドを設定します。
  3. Containerfile を使用して moon-buggy という名前の新しいコンテナーイメージをビルドします。

    # podman build -t moon-buggy .
  4. 必要に応じて、すべてのイメージを一覧表示します。

    # 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
  5. moon-buggy コンテナーに基づいて新しいコンテナーを実行します。

    # podman run -it --name moon moon-buggy
  6. 必要に応じて、moon-buggy イメージをタグ付けします。

    # podman tag moon-buggy registry.example.com/moon-buggy
  7. 必要に応じて、moon-buggy イメージをレジストリーにプッシュします。

    # podman push registry.example.com/moon-buggy

第8章 特殊なコンテナーイメージの実行

本章では、特種なコンテナーイメージについて説明します。これには、以下が含まれます。

  • toolbox - 問題のデバッグや機能の監視に必要なツールをインストールしてホストシステムに負担をかける代わりに、toolbox コマンドを実行できます。Toolbox は、ホストでレポートを実行したり問題を診断したりするために使用できるツールを保持する support-tools コンテナーイメージを起動します。
  • Runlabels - 一部のコンテナーイメージには、あらかじめ設定されたオプションと引数を使用してコンテナーを実行できるラベルが組み込まれています。podman container runlabel <label> コマンドでは、コンテナーイメージに対して <label> で定義されているコマンドを実行できます。サポートされるラベルは、installrun、および uninstall です。

8.1. toolbox でコンテナーホストのトラブルシューティング

toolbox ユーティリティーを使用すればトラブルシューティングツールを RHEL 8 システムに直接インストールする代わりに、このツールを一時的に追加し、完了したら簡単に破棄できます。toolbox ユーティリティーは次のように機能します。

  • registry.redhat.io/rhel8/support-tools イメージをローカルシステムにプルします。
  • イメージからコンテナーを起動し、ホストシステムにアクセスできるコンテナー内でシェルを実行します。

support-tools コンテナーを使用すると、以下を行うことができます。

  • ホストシステムにインストールされていない可能性のあるコマンド (例: sosreportstrace、または tcpdump) を、ホストシステムで動作できるように実行します。
  • ホストシステムで使用するコンテナーに、追加ソフトウェアをインストールします。
  • 作業が完了したら、コンテナーを破棄します。

以下は、典型的な toolbox セッションを示しています。

手順

  1. toolbox パッケージおよび podman パッケージがインストールされていることを確認します。

    # yum module list container-tools

    コンテナーツールの完全なセットをインストールするには、以下を入力します。

    # yum module install container-tools -y
  2. toolbox コマンドを実行して、support-tools イメージをプルして実行します (プロンプトが表示されたら、Red Hat カスタマーポータルの認証情報を入力します)。

    # toolbox
    Trying to pull registry.redhat.io/rhel8/support-tools...
    ...
    Would you like to authenticate to registry: 'registry.redhat.io' and try again? [y/N] y
    Username: johndoe
    Password: *************
    Login Succeeded!
    Trying to pull registry.redhat.io/rhel8/support-tools...Getting image source signatures
    ...
    Storing signatures
    30e261462851238d38f4ef2afdaf55f1f8187775c5ca373b43e0f55722faaf97
    Spawning a container 'toolbox-root' with image 'registry.redhat.io/rhel8/support-tools'
    Detected RUN label in the container image. Using that as the default...
    command: podman run -it --name toolbox-root --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=toolbox-root -e IMAGE=registry.redhat.io/rhel8/support-tools:latest -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host registry.redhat.io/rhel8/support-tools:latest
  3. bash シェルを開き、コンテナー内でコマンドを実行します。

    # bash-4.4#
  4. コンテナー内から、ホストの root ファイルシステムが /host ディレクトリーから利用できます。ここに表示されるその他のディレクトリーは、コンテナーの中にすべて表示されます。

    # ls /
    bin   dev  home  lib	lost+found  mnt  proc  run   srv  tmp  var
    boot  etc  host  lib64	media	    opt  root  sbin  sys  usr
  5. コンテナー内でコマンドを実行してください。sosreport コマンドでは、システムに関する情報を生成して、Red Hat サポートに送信できます。

    bash-4.4# sosreport
    
    sosreport (version 3.6)
    This command will collect diagnostic and configuration information from
    this Red Hat Enterprise Linux system and installed applications.
    
    An archive containing the collected information will be generated in
    /host/var/tmp/sos.u82evisb and may be provided to a Red Hat support
    representative.
    ...
    Press ENTER to continue, or CTRL-C to quit.   <Press ENTER>
    ...
    Your sosreport has been generated and saved in:
      /host/var/tmp/sosreport-rhel81beta-12345678-2019-10-29-pmgjncg.tar.xz
    The checksum is: c4e1fd3ee45f78a17afb4e45a05842ed
    Please send this file to your support representative.

    sosreport コマンドは、レポートをホスト (/host/var/tmp/sosreport-<ID>) に保存します。

  6. コンテナーにソフトウェアパッケージをインストールして、コンテナーにないツールを追加します。たとえば、ホストで実行中のプロセスのコアダンプを取得するには、procps パッケージおよび gcore パッケージをインストールし、ps を使用して実行中のデーモンのプロセス ID を取得し、gcore を使用してコアダンプを取得します。

    bash-4.4# yum install procps gdb -y
    bash-4.4# ps -ef | grep chronyd
    994        809     1  0 Oct28 ?        00:00:00 /usr/sbin/chronyd
    bash-4.4# gcore -o /host/tmp/chronyd.core 809
    Missing separate debuginfo for target:/usr/sbin/chronyd
    Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/96/0789a8a3bf28932b093e94b816be379f16a56a.debug
    ...
    Saved corefile /host/tmp/chronyd.core.809
    [Inferior 1 (process 809) detached]
  7. コンテナーからログアウトしてホストに戻るには、exit と入力します。ファイルは /host/tmp/chronyd.core.809 に保存され、ホストの /tmp/chronyd.core.809 から利用できます。
  8. toolbox-root コンテナーを削除するには、以下を入力します。

    # podman rm toolbox-root

以下を追加することで、toolbox で使用されるレジストリー、イメージ、またはコンテナー名を変更できます。

  • REGISTRY - toolbox イメージがプルされるレジストリーを変更します。たとえば、REGISTRY=registry.example.com です。
  • IMAGE - 使用されるイメージを変更します。たとえば、IMAGE=mysupport-tools などです。
  • TOOLBOX_NAME - 実行中のコンテナーに割り当てられた名前を変更します。たとえば、TOOLBOX_NAME=mytoolbox となります。

次回の toolbox を実行すると、.toolboxrc ファイルから新しい値が使用されます。

8.1.1. ホストへの権限の付与

support-tools コンテナー (または特権コンテナー) 内からその他のコマンドを実行すると、非特権コンテナー内で実行した場合と異なる動作をする場合があります。sosreport は、コンテナーで実行しているタイミングを指示できますが、その他のコマンドは、ホストシステム (/host ディレクトリー) で機能するように指示する必要があります。以下は、コンテナーからホストに開くことができる、または開くことができない機能の例です。

  • 特権 - 特権コンテナー (--privileged) は、デフォルトでホストのアプリケーションを root ユーザーとして実行します。SELinux セキュリティーコンテキスト unconfined_t で実行しているため、コンテナーにはこの機能があります。そのため、たとえば、root ユーザーが所有するホストからマウントされたファイルおよびディレクトリーを削除できます。
  • プロセステーブル: コンテナー内で実行しているプロセスのみを表示する通常のコンテナーとは異なり、特権コンテナー内で (--pid=host セットを使用して) ps -e コマンドを実行すると、ホストで実行しているすべてのプロセスを表示できます。ホストから特権コンテナーで実行するコマンドにプロセス ID を渡すことができます (例: kill <PID>)。ただし、コマンドによっては、コンテナーからプロセスにアクセスしようとすると、パーミッションの問題が発生することがあります。
  • ネットワークインターフェース - デフォルトでは、コンテナーには外部のネットワークインターフェースとループバックネットワークインターフェースが 1 つずつだけあります。ネットワークインターフェースをホストに開く (--net=host) と、コンテナーからネットワークインターフェースに直接アクセスできます。
  • プロセス間のコミュニケーション - ホストの IPC 機能は、特権コンテナーからアクセスできます。ipcs などのコマンドを実行して、ホスト上のアクティブなメッセージキュー、共有メモリーセグメント、およびセマフォセットに関する情報を表示できます。

8.2. ランレベルでコンテナーの実行

Red Hat イメージには、そのイメージと連携するために事前に設定されたコマンドラインを提供するラベルが含まれているものがあります。podman container runlabel <label> コマンドを使用すると、その <label> で定義されたコマンドをイメージに対して実行するように podman に指示できます。既存のラベルには次のものが含まれます。

  • install - イメージを実行する前にホストシステムを設定します。通常、これにより、後で実行するときにコンテナーがアクセスできるホストにファイルとディレクトリーが作成されます。
  • run - コンテナーの実行時に使用する podman コマンドラインオプションを特定します。通常、オプションはホストで権限を開き、コンテナーがホストで永続的に維持する必要があるホストのコンテンツをマウントします。
  • uninstall - コンテナーの実行後にホストシステムを削除します。

1 つ以上のランレベルを持つ Red Hat イメージには、rsyslog および support-tools イメージが含まれます。以下の手順では、このイメージの使用方法を説明します。

8.2.1. ランレベルでの rsyslog の実行

rhel8/rsyslog コンテナーイメージは、rsyslogd デーモンのコンテナー化されたバージョンを実行するように設計されています。rsyslog イメージ内の runlabel には、installrun および uninstall があります。以下の手順に従って、rsyslog イメージのインストール、実行、アンインストールを行います。

手順

  1. rsyslog イメージをプルします。

    # podman pull registry.redhat.io/rhel8/rsyslog
  2. rsysloginstall ランレベルを表示します (ただし実行はしていません)。

    # 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 スクリプトを実行します。

  3. rsysloginstall 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 イメージが後で使用するホストシステムにファイルが作成されます。

  4. rsyslogrun 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 デーモンを実行するときに、コンテナー内のホストから多数のファイルとディレクトリーをマウントすることを示しています。

  5. rsyslogrun 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 ディレクトリー内のファイルに送信します。

  6. rsysloguninstall 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
  7. rsysloguninstall 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 ファイルを削除します。設定ファイルは消去されないことに注意してください。

8.2.2. Runlabel を使用した support-tools の実行

rhel8/support-tools コンテナーイメージは、sosreportsos-collector などのツールを実行して、ホストシステムを解析するのに役に立ちます。support-tools イメージの実行を簡素化するために、run の runlabel が追加されています。以下の手順では、support-tools イメージの実行方法を説明します。

手順

  1. support-tools イメージをプルします。

    # podman pull registry.redhat.io/rhel8/support-tools
  2. support-toolsrun runlabel を表示します (ただし実行はしていません)。

    # podman container runlabel run --display rhel8/support-tools
    command: podman run -it --name support-tools --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=support-tools -e IMAGE=registry.redhat.io/rhel8/support-tools:latest -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host registry.redhat.io/rhel8/support-tools:latest

    これは、コマンドがディレクトリーをマウントし、ホストシステムに対して特権と名前空間 (ipc、net、およびpid) を開くことを示しています。ホストの root ファイルシステムを、コンテナーの /host ディレクトリーに割り当てます。

  3. support-tools に、run runlabel を実行します。

    # podman container runlabel run rhel8/support-tools
    command: podman run -it --name support-tools --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=support-tools -e IMAGE=registry.redhat.io/rhel8/support-tools:latest -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host registry.redhat.io/rhel8/support-tools:latest
    bash-4.4#

    これにより、support-tools コンテナー内に bash シェルが開きます。ホストシステム (/host) に対してレポートツールまたはデバッグツールを実行できるようになりました。

  4. コンテナーからログアウトしてホストに戻るには、exit と入力します。

    # exit

第9章 Podman を使用した OpenShift へのコンテナーの移植

本章では、YAML (YAML Ain't Markup Language) 形式を使用してコンテナーおよび Pod の移植可能な記述を生成する方法を説明します。YAML は、設定データの記述に使用されるテキスト形式です。

YAML ファイルは以下のとおりです。

  • 読み取り可能
  • 生成が簡単
  • 環境間の移植性 (RHEL と OpenShift の間など)
  • プログラミング言語間で移植が可能
  • 使いやすい (全パラメーターをコマンドラインに追加する必要はない)。

YAML ファイルを使用する理由:

  1. 必要最小限の入力でオーケストレーションされたコンテナーおよび Pod のローカルオーケストレーションセットを再実行でき、反復型開発に役立ちます。
  2. 同じコンテナーおよび Pod を別のマシンで実行できます。たとえば、OpenShift 環境でアプリケーションを実行し、アプリケーションが正常に機能していることを確認します。podman generate kube コマンドを使用して、Kubernetes YAML ファイルを生成できます。次に、podman play コマンドを使用して、生成された YAML ファイルを Kubernetes または OpenShift 環境に転送する前に、ローカルシステムで Pod およびコンテナーの作成をテストできます。podman play コマンドを使用して、OpenShift または Kubernetes 環境で作成された Pod およびコンテナーを再作成することもできます。

9.1. Podman を使用した Kubernetes YAML ファイルの生成

この手順では、1 つのコンテナーで Pod を作成し、podman generate kube コマンドを使用して Kubernetes YAML ファイルを生成する方法を説明します。

前提条件

手順

  1. 関連付けられている全 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
  2. Pod 名または ID を使用して Kubernetes YAML ファイルを生成します。

    $ podman generate kube mypod > mypod.yaml

    podman generate コマンドは、コンテナーに接続されている論理ボリュームマネージャー (LVM) の論理ボリュームまたは物理ボリュームへは反映されないので注意してください。

  3. 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: {}

関連情報

9.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 コマンドを使用できます。

9.3. Podman でのコンテナーおよび Pod の起動

生成された YAML ファイルを使用すると、任意の環境でコンテナーおよび Pod を自動的に起動できます。YAML ファイルは Podman では生成されないことに注意してください。podman play kube コマンドを使用すると、YAML 入力ファイルに基づいて Pod およびコンテナーを再作成できます。

手順

  1. mypod.yaml ファイルから Pod およびコンテナーを作成します。

    $ podman play kube mypod.yaml
    Pod:
    b8c5b99ba846ccff76c3ef257e5761c2d8a5ca4d7ffa3880531aec79c0dacb22
    Container:
    848179395ebd33dd91d14ffbde7ae273158d9695a081468f487af4e356888ece
  2. すべての Pod を一覧表示します。

    $ podman pod ps
    POD ID         NAME    STATUS    CREATED          # OF CONTAINERS   INFRA ID
    b8c5b99ba846   mypod   Running   19 seconds ago   2                 aa4220eaf4bb
  3. 関連付けられている全 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 が一致します。

関連情報

9.4. OpenShift 環境でのコンテナーおよび Pod の起動

oc create コマンドを使用して、OpenShift 環境で Pod およびコンテナーを作成できます。

手順

  • OpenShift 環境で YAML ファイルから Pod を作成します。

    $ oc create -f mypod.yaml
注記

Kubernetes 環境では、同じフラグを指定して kubectl create コマンドを使用できます。

第10章 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 の移植可能な記述を生成する方法を説明します。

10.1. systemd サービスの有効化

サービスの有効化には、さまざまなオプションがあります。

手順

  • サービスの有効化:

    • システムの起動時にサービスを有効にするには、ユーザーがログインしているかどうかに拘らず、次のコマンドを実行します。

      # systemctl enable <service>

      systemd ユニットファイルを /etc/systemd/system ディレクトリーにコピーする必要があります。

    • ユーザーのログイン時にサービスを起動し、ユーザーのログアウト時に停止するには、次のコマンドを実行します。

      $ systemctl --user enable <service>

      systemd ユニットファイルを $HOME/.config/systemd/user ディレクトリーにコピーする必要があります。

    • システムの起動時にサービスを起動し、ログアウト後もそのまま起動した状態を保つには、次のコマンドを実行します。

      # loginctl enable-linger <username>

関連情報

10.2. Podman を使用した systemd ユニットファイルの生成

Podman を使用することで、systemd はコンテナープロセスを制御および管理できます。podman generate systemd コマンドを使用して既存のコンテナーと Pod の systemd ユニットファイルを生成できます。生成されたユニットファイルは頻繁に変更され (Podman に対する更新)、podman generate systemd で最新のユニットファイルの取得を確認できるので、podman generate systemd の使用を推奨します。

手順

  1. コンテナー (例: myubi) を作成します。

    $ podman create -d --name myubi registry.access.redhat.com/ubi8:latest top
    0280afe98bb75a5c5e713b28de4b7c5cb49f156f1cce4a208f13fee2f75cb453
  2. コンテナー名または 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 2.0.0
    # Tue Aug 11 10:51:04 CEST 2020
    
    [Unit]
    Description=Podman container-myubi.service
    Documentation=man:podman-generate-systemd(1)
    Wants=network.target
    After=network-online.target
    
    [Service]
    Environment=PODMAN_SYSTEMD_UNIT=%n
    Restart=on-failure
    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/0280afe98bb75a5c5e713b28de4b7c5cb49f156f1cce4a208f13fee2f75cb453/userdata/conmon.pid
    KillMode=none
    Type=forking
    
    [Install]
    WantedBy=multi-user.target default.target
    • Restart=on-failure 行は、再起動ポリシーを設定し、サービスを正常に開始または停止できない場合、またはプロセスがゼロ以外のステータスで終了した場合に、systemd にサービスを再開するように指示します。
    • ExecStart 行は、コンテナーの開始方法を示しています。
    • ExecStop 行は、コンテナーを停止して削除する方法を示しています。

10.3. Podman を使用した systemd ユニットファイルの自動生成

デフォルトで、Podman は既存のコンテナーまたは Pod のユニットファイルを生成します。podman generate systemd --new を使用して、移植可能な別の systemd ユニットファイルを生成できます。--new フラグでは、コンテナーの作成、起動、削除を行うユニットファイルを生成するように Podman に指示します。

手順

  1. システムで使用するイメージをプルします。たとえば、busybox イメージをプルするには、次のコマンドを実行します。

    # podman pull busybox:latest
  2. システムで利用可能なイメージの一覧を表示します。

    # podman images
    REPOSITORY                 TAG     IMAGE ID      CREATED      SIZE
    docker.io/library/busybox  latest  c7c37e472d31  3 weeks ago  1.45 MB
  3. busybox コンテナーを作成します。

    # podman create --name busybox busybox:latest
    1e12cf95e305435c0001fa7d4a14cf1d52f737c1118328937028c0bd2fdec5ca
  4. コンテナーが作成されたことを確認するには、すべてのコンテナーを一覧表示します。

    # podman ps -a
    CONTAINER ID  IMAGE                             COMMAND  CREATED        STATUS   PORTS   NAMES
    1e12cf95e305  docker.io/library/busybox:latest  sh       7 seconds ago  Created          busybox
  5. busybox コンテナーの systemd ユニットファイルを生成します。

    # podman generate systemd --new --files --name busybox
    /root/container-busybox.service
  6. 生成された container-busybox.service systemd ユニットファイルの内容を表示します。

    # vim container-busybox.services
    
    # container-busybox.service
    # autogenerated by Podman 2.0.0-rc7
    # Mon Jul 27 11:06:32 CEST 2020
    
    [Unit]
    Description=Podman container-busybox.service
    Documentation=man:podman-generate-systemd(1)
    Wants=network.target
    After=network-online.target
    
    [Service]
    Environment=PODMAN_SYSTEMD_UNIT=%n
    Restart=on-failure
    ExecStartPre=/usr/bin/rm -f %t/container-busybox.pid %t/container-busybox.ctr-id
    ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-busybox.pid --cidfile %t/container-busybox.ctr-id --cgroups=no-conmon -d --replace --name busybox busybox:latest
    ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-busybox.ctr-id -t 10
    ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-busybox.ctr-id
    PIDFile=%t/container-busybox.pid
    KillMode=none
    Type=forking
    
    [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 は、サービスの完全な名前です。
  7. /usr/lib/systemd/system にユニットファイルをコピーして root ユーザーとしてインストールします。

    # cp -Z container-busybox.service  /usr/lib/systemd/system
    Created symlink /etc/systemd/system/multi-user.target.wants/container-busybox.service /usr/lib/systemd/system/container-busybox.service.
    Created symlink /etc/systemd/system/default.target.wants/container-busybox.service → /usr/lib/systemd/system/container-busybox.service.

10.4. systemd を使用したコンテナーの自動起動

systemctl コマンドを使用して、systemd システムおよびサービスマネージャーの状態を制御できます。本セクションでは、root 以外のユーザーでサービスの有効化、起動、停止を行う方法を説明します。root ユーザーとしてサービスをインストールするには、--user オプションを省略します。

手順

  1. systemd マネージャーの設定を再読み込みするには、次のコマンドを実行します。

    # systemctl --user daemon-reload
  2. サービス container.service を有効にし、起動時に開始します。

    # systemctl --user enable container.service
  3. サービスをすぐに開始するには、以下を実行します。

    # systemctl --user start container.service
  4. サービスの状況を表示するには、次のコマンドを実行します。

    $ 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

10.5. systemd を使用した Pod の自動起動

複数のコンテナーを systemd サービスとして起動できます。systemctl コマンドは、Pod でだけ使用するようにしてください。コンテナーは Pod サービスと内部の infra-container で管理されているので systemctl を使用して個別にコンテナーを開始または停止しないでください。

手順

  1. たとえば、systemd-pod などの空の Pod を作成します。

    $ podman pod create --name systemd-pod
    11d4646ba41b1fffa51c108cbdf97cfab3213f7bd9b3e1ca52fe81b90fed5577
  2. すべての Pod を一覧表示します。

    $ podman pod ps
    POD ID        NAME         STATUS   CREATED         # OF CONTAINERS  INFRA ID
    11d4646ba41b  systemd-pod  Created  40 seconds ago  1                8a428b257111
    11d4646ba41b1fffa51c108cbdf97cfab3213f7bd9b3e1ca52fe81b90fed5577
  3. 空の Pod に 2 つのコンテナーを作成します。たとえば、container0container1systemd-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
  4. 関連付けられている全 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
  5. 新規 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 つは container0container1 のコンテナー向けです。

  6. pod-systemd-pod.service ユニットファイルを表示します。

    $ cat pod-systemd-pod.service
    # pod-systemd-pod.service
    # autogenerated by Podman 2.0.3
    # Tue Jul 28 14:00:46 EDT 2020
    
    
    [Unit]
    Description=Podman pod-systemd-pod.service
    Documentation=man:podman-generate-systemd(1)
    Wants=network.target
    After=network-online.target
    Requires=container-container0.service container-container1.service
    Before=container-container0.service container-container1.service
    
    [Service]
    Environment=PODMAN_SYSTEMD_UNIT=%n
    Restart=on-failure
    ExecStart=/usr/bin/podman start c852fbaba568-infra
    ExecStop=/usr/bin/podman stop -t 10 c852fbaba568-infra
    ExecStopPost=/usr/bin/podman stop -t 10 c852fbaba568-infra
    PIDFile=/run/user/1000/containers/overlay-containers/a7ff86382608add27a03ac2166d5d0164199f01eadf80b68b06a406c195105fc/userdata/conmon.pid
    KillMode=none
    Type=forking
    
    [Install]
    WantedBy=multi-user.target default.target
    • [Unit] セクションの Requires 行は、container-container0.servicecontainer-container1.service ユニットファイルの依存関係を定義します。両方のユニットファイルがアクティベートされます。
    • [Service] セクションの ExecStart 行および ExecStop 行はそれぞれ infra-container を開始して停止します。
  7. container-container0.service ユニットファイルを表示します。

    $ cat container-container0.service
    # container-container0.service
    # autogenerated by Podman 2.0.3
    # Tue Jul 28 14:00:46 EDT 2020
    
    [Unit]
    Description=Podman container-container0.service
    Documentation=man:podman-generate-systemd(1)
    Wants=network.target
    After=network-online.target
    BindsTo=pod-systemd-pod.service
    After=pod-systemd-pod.service
    
    [Service]
    Environment=PODMAN_SYSTEMD_UNIT=%n
    Restart=on-failure
    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/12e85378f2854b8283f791974494a02aa6c92630d76d1050237839b61508a008/userdata/conmon.pid
    KillMode=none
    Type=forking
    
    [Install]
    WantedBy=multi-user.target default.target
    • [Unit] セクションの BindsTo l行は、pod-systemd-pod.service ユニットファイルの依存関係を定義します。
    • [Service] セクションの ExecStart 行および ExecStop 行では、それぞれ container0 を起動および停止します。
  8. container-container1.service ユニットファイルを表示します。

    $ cat container-container1.service
  9. 生成されたファイルをすべて $HOME/.config/systemd/user にコピーして、root 以外のユーザーとしてインストールします。

    $ cp pod-systemd-pod.service container-container0.service container-container1.service $HOME/.config/systemd/user
  10. ユーザーのログイン時に、サービスを有効にして開始します。

    $ 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

関連情報

10.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

手順

  1. 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
  2. 必要に応じて、実行中または終了したコンテナーを一覧表示します。

    # podman ps -a
    CONTAINER ID  IMAGE                                            COMMAND  CREATED         STATUS             PORTS   NAMES
    76465a5e2933  registry.access.redhat.com/ubi8/ubi-init:latest  top      24 seconds ago  Up 23 seconds ago          myubi
  3. myubi コンテナーの systemd ユニットファイルを生成します。

    # podman generate systemd --new --files --name myubi
    /root/container-myubi.service
  4. /usr/lib/systemd/system にユニットファイルをコピーして root ユーザーとしてインストールします。

    # cp -Z ~/container-myubi.service /usr/lib/systemd/system
  5. systemd マネージャーの設定を再読み込みするには、次のコマンドを実行します。

    # systemctl daemon-reload
  6. コンテナーを起動して、ステータスを確認します。

    # systemctl start container-myubi.service
    # systemctl status container-myubi.service
  7. コンテナーを自動更新します。

    # podman auto-update

10.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

手順

  1. 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
  2. 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 コマンドは、毎日、深夜に起動します。

  3. システム起動時に podman-auto-update.timer サービスを有効にします。

    # systemctl enable podman-auto-update.timer
  4. systemd サービスを起動します。

    # systemctl start podman-auto-update.timer
  5. 必要に応じて、すべてのタイマーを一覧表示します。

    # 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.timerpodman-auto-update.service を有効化したことが確認できます。

第11章 Buildah でコンテナーイメージの構築

buildah コマンドを使用すると、作業中コンテナーまたは Dockerfile から、またはゼロからコンテナーイメージを作成できます。作成されたイメージは OCI に準拠しているため、「OCI Runtime Specification」 (Docker、CRI-O など) を満たす任意のコンテナーランタイムで動作します。

このセクションでは、buildah コマンドを使用して、コンテナーおよびコンテナーイメージを作成し、作業する方法を説明します。

11.1. Buildah について

Buildah を使用することは、以下の点で、docker コマンドでイメージを作成するのと異なります。

  • デーモンは使用されない - Docker デーモンが無効になります。したがって、Buildah を使用する場合に、コンテナーランタイム (Docker、CRI-O など) が必要ありません。
  • ベースイメージまたは scratch- 別のコンテナーに基づいてイメージを構築するだけでなく、空のイメージ (scratch) で開始することもできます。
  • 外部のビルドツール -イメージ自体にはビルドツールが含まれません。その結果、Buildah は以下のようになります。

    • 構築するイメージのサイズは小さくなります。
    • 作成されるイメージに、コンテナーを構築するのに使用されるソフトウェア (gcc、make、yum など) がなく、イメージの安全性が高まります。
    • イメージの転送に必要なリソースが少ないイメージを作成します (サイズが小さくなるため)。

Buildah は、データを個別に保存し、イメージを構築するだけでなく、そのイメージをコンテナーとして実行することで、Docker やその他のコンテナーランタイムを使用せずに動作させることができます。デフォルトでは、Buildah は、イメージを、containers-storage (/var/lib/containers) のように識別される領域に保存します。

注記

buildah コマンドがデフォルトで使用するコンテナーの保管場所は、CRI-O コンテナーエンジンが、イメージのローカルコピーを保存するのに使用する場所と同じになります。そのため、CRI-O または Buildah で、もしくは buildah コマンドでレジストリーから取得したイメージは、同じディレクトリー構造に保存されます。ただし、現在、CRI-O および Buildah は、イメージを共有することはできますが、コンテナーを共有することはできません。

buildah コマンドと一緒に使用するオプションが多数あります。buildah コマンドで可能な主なアクティビティーには、以下のことが含まれます。

  • Dockerfile からコンテナーを構築 - Dockerfile を使用して新規コンテナーイメージ (buildah bud) を構築します。
  • 別のイメージまたは scratch イメージにコンテナーを構築 - 既存のベースイメージ (<imagename> から buildah) または新規 (scratch の buildah) から、scratch コンテナーを構築します。
  • コンテナーまたはイメージの検証 - コンテナーまたはイメージ (buildah inspect) に関連付けられているメタデータを表示します。
  • コンテナーのマウント - コンテナーの root ファイルシステムをマウントして、このコンテンツを追加または変更します (buildah mount)。
  • 新しいコンテナーレイヤーの作成 - コンテナーの root ファイルシステムで更新された内容をファイルシステムレイヤーとして使用して、コンテンツを新しいイメージにコミット (buildah commit) します。
  • コンテナーのアンマウント - マウントされたコンテナーのマウントを解除します (buildah umount)。
  • コンテナーまたはイメージの削除 - コンテナー (buildah rm) またはコンテナーイメージ (buildah rmi) を削除します。

Buildah の詳細は、GitHub Buildah のページ を参照してください。GitHub Buildah サイトには、man ページと、RHEL バージョンで利用できるよりも新しい可能性があるソフトウェアが含まれています。以下は、Buildah に関するその他の記事です。

11.1.1. Buildah のインストール

buildah パッケージは、RHEL 8 の container-tools モジュールで利用できます (yum module install container-tools)。buildah パッケージを個別にインストールするには、以下のコマンドを実行します。

# yum -y install buildah

buildah パッケージをインストールすると、buildah パッケージに含まれている man ページで、その使用方法の詳細を確認できます。利用可能な man ページとその他のドキュメントを表示して、man ページを開くには、以下のコマンドを入力します。

# rpm -qd buildah
# man buildah
buildah(1)         General Commands Manual         buildah(1)

NAME
 Buildah - A command line tool that facilitates building OCI container images.
...

次のセクションでは、buildah を使用してコンテナーを取得し、Dockerfile または scratch からコンテナーを構築し、さまざまな方法でコンテナを管理する方法を説明します。

11.2. Buildah でイメージの取得

buildah で使用するコンテナーイメージを取得するには、buildah from コマンドを使用します。RHEL 8.0 を使用している場合は、リポジトリーへの認証で問題が発生する可能性があることに注意してください。バグ を参照してください。これは、buildah コマンドを使用して、Red Hat Registry から、RHEL 8 イメージを作業コンテナーとして取得する方法です。

# buildah from registry.redhat.io/ubi8/ubi
Getting image source signatures
Copying blob…
Writing manifest to image destination
Storing signatures
ubi-working-container
# buildah images
IMAGE ID      IMAGE NAME                          CREATED AT         SIZE
3da40a1670b5  registry.redhat.io/ubi8/ubi:latest  May 8, 2019 21:55  214 MB
# buildah containers
CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME         CONTAINER NAME
c6c9279ecc0f     *     3da40a1670b5 ...ubi8/ubi:latest ubi-working-container

buildah from コマンドの結果として、イメージ (registry.redhat.io/ubi8/ubi:latest) と、そのイメージから実行する準備ができている作業コンテナー (ubi-working-container) が返されていることが分かります。そのコンテナーからコマンドを実行する方法の例を以下に示します。

# buildah run ubi-working-container cat /etc/redhat-release
Red Hat Enterprise Linux release 8.0

これで、イメージとコンテナーを Buildah で使用できるようになりました。

11.3. Buildah で Dockerfile からのイメージの構築

buildah コマンドを使用して、Dockerfile から新しいイメージを作成できます。次の手順では、イメージの実行時に実行される簡単なスクリプトを含むイメージを構築する方法を説明します。

この簡単な例では、現在のディレクトリーにある Dockerfile (コンテナーイメージを構築するための命令を保持) と myecho (画面に数単語を表示するスクリプト) の 2 つのファイルで始まります。

# ls
Dockerfile  myecho
# cat Dockerfile
FROM registry.redhat.io/ubi8/ubi
ADD myecho /usr/local/bin
ENTRYPOINT "/usr/local/bin/myecho"
# cat myecho
echo "This container works!"
# chmod 755 myecho
# ./myecho
This container works!

現行ディレクトリーの Dockerfile で、以下のように新しいコンテナーを構築します。

# buildah bud -t myecho .
STEP 1: FROM registry.redhat.io/ubi8/ubi
STEP 2: ADD myecho /usr/local/bin
STEP 3: ENTRYPOINT "/usr/local/bin/myecho"

buildah bud コマンドは、myecho という名前の新規イメージを作成します。新しいイメージを表示するには、以下を入力します。

# buildah images
IMAGE NAME        IMAGE TAG  IMAGE ID      CREATED AT          SIZE
localhost/myecho  latest     a3882af49784  Jun 21, 2019 12:21  216 MB

次に、イメージを実行して、それが機能していることを確認します。

11.3.1. 構築するイメージの実行

以前ビルドしたイメージが機能することを確認するには、podman run を使用してイメージを実行します。

# podman run localhost/myecho
This container works!

11.3.2. Buildah でのコンテナーの検証

buildah inspect を使用して、コンテナやイメージに関する情報を表示できます。たとえば、myecho イメージをビルドして検査するには、次のように入力します。

# buildah from localhost/myecho
# buildah inspect localhost/myecho | less
{
 "Type": "buildah 0.0.1",
 "FromImage": "docker.io/library/myecho:latest",
 "FromImage-ID": "e2b190ac8...",
 "Config": "{\"created\":\"2018-11-13...

 "Entrypoint": [
      "/usr/local/bin/myecho"
   ],
   "WorkingDir": "/",
   "Labels": {
      "architecture": "x86_64",
      "authoritative-source-url": "registry.access.redhat.com",
      "build-date": "2018-09-19T20:46:28.459833",

同じイメージのコンテナーを検証するには、以下を入力します。

# buildah inspect myecho-working-container | less
{
    "Type": "buildah 0.0.1",
    "FromImage": "docker.io/library/myecho:latest",
    "FromImage-ID": "e2b190a...",
    "Config": "{\"created\":\"2018-11-13T19:5...
...
    "Container": "myecho-working-container",
    "ContainerID": "c0cd2e494d...",
    "MountPoint": "",
    "ProcessLabel": "system_u:system_r:svirt_lxc_net_t:s0:c89,c921",
    "MountLabel": "",

コンテナーの出力には、コンテナー名、コンテナー ID、プロセスラベル、マウントラベルなどの情報がイメージ内のものに追加されました。

11.4. Buildah で新規イメージを作成するコンテナーの変更

buildah コマンドを使用して、既存のコンテナーを変更し、この変更を新しいコンテナーイメージに適用する方法はいくつかあります。

  • コンテナーをマウントして、そのコンテナーにファイルをコピーします。
  • buildah copy および buildah config を使用して、コンテナーを変更します。

コンテナーを修正したら、buildah commit を使用して、新しいイメージに変更を適用します。

11.4.1. buildah mount でコンテナーの変更

buildah from でイメージを取得したあと、そのイメージを新しいイメージの基盤として使用できます。以下のテキストは、作業コンテナーをマウントし、そのコンテナーにファイルを追加して、新しいイメージへの変更をコミットすることで、新しいイメージを作成する方法を示しています。

以前使用した作業コンテナーを表示するには、以下を入力します。

# buildah containers
CONTAINER ID BUILDER IMAGE ID     IMAGE NAME  CONTAINER NAME

dc8f21af4a47   *     1456eedf8101 registry.redhat.io/ubi8/ubi:latest
               ubi-working-container
6d1ffccb557d   *     ab230ac5aba3 docker.io/library/myecho:latest
               myecho-working-container

コンテナーイメージをマウントし、マウントポイントを変数 ($mymount) に設定すると、処理が容易になります。

# mymount=$(buildah mount myecho-working-container)
# echo $mymount
/var/lib/containers/storage/devicemapper/mnt/176c273fe28c23e5319805a2c48559305a57a706cc7ae7bec7da4cd79edd3c02/rootfs

マウントしたコンテナーで、以前作成したスクリプトに内容を追加します。

# echo 'echo "We even modified it."' >> $mymount/usr/local/bin/myecho

(myecho という名前の) 新しいイメージを作成するために追加した内容をコミットするには、以下を入力します。

# buildah commit myecho-working-container containers-storage:myecho2

新しいイメージに変更が含まれることを確認するには、作業コンテナーを作成して実行します。

# buildah images
IMAGE ID     IMAGE NAME     CREATED AT          SIZE
a7e06d3cd0e2 docker.io/library/myecho2:latest
                            Oct 12, 2017 15:15  3.144 KB
# buildah from docker.io/library/myecho2:latest
myecho2-working-container
# podman run docker.io/library/myecho2
This container works!
We even modified it.

そのスクリプトに追加された新しい echo コマンドが、追加のテキストを表示するのを確認できます。

終了すると、コンテナーをアンマウントできます。

# buildah umount myecho-working-container

11.4.2. buildah copy および buildah config でコンテナーの変更

buildah copy を使用して、最初にマウントしなくても、ファイルをコンテナにコピーできます。以下は、前のセクションで作成 (およびマウントを解除) した myecho-working-containerを使用して、新しいスクリプトをコンテナーにコピーし、コンテナーの設定を変更して、デフォルトでそのスクリプトを実行します。

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 コマンドが実行します。

# buildah run myecho-working-container-2
I changed this container

期待したようにコンテナーが動作すれば、新しいイメージ (mynewecho) にコミットできます。

# buildah commit myecho-working-container-2 containers-storage:mynewecho

11.5. Buildah で scratch からイメージを新規作成

ベースイメージから開始する代わりに、中身がない新規コンテナーと、少数のコンテナーメタデータのみを保持する新規コンテナーを作成できます。これは、scratch コンテナーと呼ばれます。ここで、buildah コマンドを使用して、scratch コンテナーから始まるイメージを作成することを選択するときに、考慮すべきいくつかの問題があります。

  • scratch コンテナーでは、scratch イメージに依存関係のない実行ファイルをコピーして、最小コンテナーを機能させるため、いくつかの設定を行うことができます。
  • yum パッケージや rpm パッケージなどのツールを使用して、scratch コンテナーを作成するには、少なくともコンテナー内の RPM データベースを初期化し、リリースパッケージを追加する必要があります。以下の例は、実行方法を示しています。
  • たくさんの RPM パッケージを追加した場合は、scratch イメージではなく、ベースイメージの ubi または ubi-minimal を使用することを検討してください。このベースイメージには、ドキュメント、言語パック、およびその他のコンポーネントが含まれ、結果としてイメージのサイズが小さくなる可能性があります。

この例では、コンテナーに Web サービス (httpd) を追加し、これを実行するように設定します。まず、scratch コンテナーを作成します。

# buildah from scratch
working-container

これにより、以下のようにマウントできる空のコンテナー (イメージなし) のみが作成されます。

# scratchmnt=$(buildah mount working-container)
# echo $scratchmnt
/var/lib/containers/storage/devicemapper/mnt/cc92011e9a2b077d03a97c0809f1f3e7fef0f29bdc6ab5e86b85430ec77b2bf6/rootfs

scratch イメージで RPM データベースを初期化し、redhat-release パッケージを追加します (RPM が機能するために必要なその他のファイルが含まれます)。

# yum install -y --releasever=8 --installroot=$scratchmnt redhat-release

httpd サービスを scratch ディレクトリーにインストールします。

# yum install -y --setopt=reposdir=/etc/yum.repos.d \
     --installroot=$scratchmnt \
     --setopt=cachedir=/var/cache/dnf httpd

コンテナーの index.html ファイルにテキストを追加すると、後でテストできるようになります。

# echo "Your httpd container from scratch worked." > $scratchmnt/var/www/html/index.html

init サービスとして httpd を実行する代わりに、buildah config オプションをいくつか設定して、httpd デーモンをコンテナーから直接実行するオプションを設定します。

# buildah config --cmd "/usr/sbin/httpd -DFOREGROUND" working-container
# buildah config --port 80/tcp working-container
# buildah commit working-container localhost/myhttpd:latest

現在のところ、podman コマンドを使用して、イメージ ID を使用して新しいイメージをコンテナーとして実行できます。

# podman images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
localhost/myhttpd   latest              47c0795d7b0e        9 minutes ago       665.6 MB
# podman run -p 8080:80 -d --name httpd-server 47c0795d7b0e
# curl localhost:8080
Your httpd container from scratch worked.

11.6. Buildah でイメージまたはコンテナーの削除

特定のコンテナーやイメージの使用を終えたら、それぞれ buildah rm または buildah rmi で削除します。以下に例をいくつか示します。

前のセクションで作成したコンテナーを削除する場合は、以下を入力して、マウントされたコンテナーを表示し、マウントを解除して削除します。

# buildah containers
CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
05387e29ab93     *     c37e14066ac7 docker.io/library/myecho:latest  myecho-working-container
# buildah mount
05387e29ab93 /var/lib/containers/storage/devicemapper/mnt/9274181773a.../rootfs
# buildah umount 05387e29ab93
# buildah rm 05387e29ab93
05387e29ab93151cf52e9c85c573f3e8ab64af1592b1ff9315db8a10a77d7c22

以前作成したイメージを削除する場合は、以下を入力します。

# buildah rmi docker.io/library/myecho:latest
untagged: docker.io/library/myecho:latest
ab230ac5aba3b5a0a7c3d2c5e0793280c1a1b4d2457a75a01b70a4b7a9ed415a

11.7. Buildah でコンテナーレジストリーの使用

Buildah を使用すると、ローカルシステムと、パブリックまたはプライベートのコンテナーレジストリーとの間で、コンテナーイメージをプッシュまたはプルできます。以下の例では、方法を説明します。

  • buildah を使用して、コンテナーをプッシュして、プライベートレジストリーからプルします。
  • ローカルシステムと Docker レジストリー間でコンテナーをプッシュし、プルします。
  • 認証情報を使用して、コンテナーをプッシュする際にレジストリーアカウントにコンテナーを関連付けます。

buildah コマンドと一緒に skopeo コマンドを使用して、コンテナーイメージの情報に関するレジストリーを問い合わせます。

11.7.1. プライベートレジストリーへのコンテナーのプッシュ

コンテナーをプライベートコンテナーレジストリーにプッシュする buildah コマンドは、コンテナーをプッシュする docker コマンドと同じように機能します。以下が必要です。

  • プライベートレジストリーを設定します (OpenShift のコンテナーレジストリーを使用するか、Red Hat Quay コンテナーレジストリーを設定できます)。
  • プッシュするコンテナーイメージを作成または取得します。
  • buildah push を使用して、イメージをレジストリーにプッシュします。

ローカルの Buildah コンテナーストレージからイメージをプッシュするには、イメージ名を確認してから、buildah push コマンドを使用してプッシュします。ローカルイメージ名と、場所を含む新しい名前の両方を忘れないでください。たとえば、TCP ポート 5000 でリッスンしているローカルシステムで実行しているレジストリーは、localhost:5000 として識別されます。

# buildah images
IMAGE ID     IMAGE NAME                       CREATED AT          SIZE
cb702d492ee9 docker.io/library/myecho2:latest Nov 12, 2018 16:50     3.143 KB

# buildah push --tls-verify=false myecho2:latest localhost:5000/myecho2:latest
Getting image source signatures
Copying blob sha256:e4efd0...
...
Writing manifest to image destination
Storing signatures

curl コマンドを使用して、レジストリー内のイメージを一覧表示し、skopeo で、イメージに関するメタデータを検証します。

# curl http://localhost:5000/v2/_catalog
{"repositories":["myatomic","myecho2"]}
# curl http://localhost:5000/v2/myecho2/tags/list
{"name":"myecho2","tags":["latest"]}
# skopeo inspect --tls-verify=false docker://localhost:5000/myecho2:latest | less
{
    "Name": "localhost:5000/myecho2",
    "Digest": "sha256:8999ff6050...",
    "RepoTags": [
        "latest"
    ],
    "Created": "2017-11-21T16:50:25.830343Z",
    "DockerVersion": "",
    "Labels": {
        "architecture": "x86_64",
        "authoritative-source-url": "registry.redhat.io",

この時点で、コンテナーレジストリーからコンテナーイメージをプルできるツールは、プッシュしたイメージのコピーを取得できます。たとえば、RHEL 7 システムでは、docker デーモンを起動してイメージをプルすると、以下のように docker コマンドを実行してそのイメージを使用できるようにします。

# systemctl start docker
# docker pull localhost:5000/myecho2
# docker run localhost:5000/myecho2
This container works!

11.7.2. Docker Hub へのコンテナーのプッシュ

buildah コマンドで、Docker Hub の認証情報を使用して、Docker Hub からイメージをプッシュおよびプルできます。この例では、ユーザー名とパスワード (testaccountXX:My00P@sswd) を、自身の Docker Hub 認証情報に置き換えます。

# buildah push --creds testaccountXX:My00P@sswd \
     docker.io/library/myecho2:latest docker://testaccountXX/myecho2:latest

プライベートレジストリーと同様に、podman コマンド、buildah コマンド、または docker コマンドを使用して、Docker Hub からコンテナーを取得して実行できます。

# podman run docker.io/textaccountXX/myecho2:latest
This container works!
# buildah from docker.io/textaccountXX/myecho2:latest
myecho2-working-container-2
# podman run myecho2-working-container-2
This container works!

第12章 コンテナーの監視

本章では、コンテナーの正常性の判別、システムおよび Pod 情報の表示、Podman イベントの監視など、Podman 環境を管理できる便利な Podman コマンドについて主に説明します。

12.1. コンテナーでの Healthcheck の実行

Healthcheck を使用すると、コンテナー内で実行されるプロセスの健全性または準備状態を判別できます。Healthcheck は、以下の基本的なコンポーネント 5 つで構成されます。

  • Command
  • Retries
  • Interval
  • Start-period
  • Timeout

以下は、healthcheck コンポーネントの説明です。

Command
Podman は、ターゲットコンテナー内でコマンドを実行して終了コードを待ちます。

他の 4 つのコンポーネントは任意で healthcheck のスケジューリングに関係があります。

Retries
「正常でない」とマークするまでに、ヘルスチェックで連続して不合格とならなければならないか、その回数を定義します。Healthcheck に成功すると、再試行数がリセットされます。
Interval
次回に healthcheck コマンドを実行するまでの時間を指定します。間隔が短いと、システムでの healthcheck の実行時間が長くなる点に注意してください。間隔が長いと、タイムアウトの検出が困難になります。
Start-period
コンテナーを起動してから healthcheck の不合格を無視するまでの時間を指定します。
Timeout
healthcheck の完了前に不合格とみなされるまでの期間を指定します。

Healthcheck はコンテナー内で実行されます。Healthcheck は、サービスが正常な状態を理解しており、ヘルスチェックの成功と不合格を区別できる場合にだけ役に立ちます。

手順

  1. Healthcheck を定義します。

    $ sudo podman run -dt --name hc1 --health-cmd='curl http://localhost || exit 1' --health-interval=0 quay.io/libpod/alpine_nginx:latest
    D25ee6faaf6e5e12c09e734b1ac675385fe4d4e8b52504dd01a60e1b726e3edb
    • --health-cmd オプションは、コンテナーの healthcheck コマンドを設定します。
    • healthcheck を手動で実行するには、-health-interval=0 オプション で 0 の値を指定します。
  2. Healthcheck を手動で実行します。

    $ sudo podman healthcheck run hc1
    Healthy
  3. 必要に応じて、最後のコマンドの終了ステータスを確認できます。

    $ echo $?
    0

    「0」値は成功したことを指します。

関連情報

12.2. Podman システム情報の表示

podman system コマンドを使用すると、Podman システムを管理できます。このセクションでは、Podman システム情報を表示する方法を説明します。

手順

  • Podman システム情報を表示します。

    • Podman のディスク使用量を表示するには、以下を入力します。

      $ podman system df
      TYPE            TOTAL   ACTIVE   SIZE    RECLAIMABLE
      Images          3       1        255MB   255MB (100%)
      Containers      1       0        0B      0B (0%)
      Local Volumes   0       0        0B      0B (0%)
    • 領域の使用量に関する詳細情報を表示するには、次のコマンドを実行します。

      $ podman system df -v
      Images space usage:
      
      REPOSITORY                            TAG      IMAGE ID       CREATED         SIZE     SHARED SIZE   UNQUE SIZE   CONTAINERS
      docker.io/library/alpine              latest   e7d92cdc71fe   3 months ago    5.86MB   0B            5.86MB       0
      registry.access.redhat.com/ubi8/ubi   latest   8121a9f5303b   6 weeks ago     240MB    0B            240MB        1
      quay.io/libpod/alpine_nginx           latest   3ef70f7291f4   18 months ago   9.21MB   0B            9.21MB       0
      
      Containers space usage:
      
      CONTAINER ID    IMAGE   COMMAND     LOCAL VOLUMES   SIZE   CREATED          STATUS   NAMES
      ff0167c6c271    8121    /bin/bash   0               0B     10 seconds ago   exited   playTest
      
      Local Volumes space usage:
      
      VOLUME NAME   LINKS   SIZE
    • Podman のホスト、現在のストレージ統計、およびビルドについての情報を表示するには、以下を入力します。

      $ podman system info
      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'
        cpus: 1
        distribution:
          distribution: '"rhel"'
          version: "8.3"
        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-227.el8.x86_64
        linkmode: dynamic
        memFree: 69713920
        memTotal: 1376636928
        ociRuntime:
          name: runc
          package: runc-1.0.0-66.rc10.module+el8.3.0+7084+c16098dd.x86_64
          path: /usr/bin/runc
          version: 'runc version spec: 1.0.1-dev'
        os: linux
        remoteSocket:
          path: /run/user/1000/podman/podman.sock
        rootless: true
        slirp4netns:
          executable: /usr/bin/slirp4netns
          package: slirp4netns-1.1.1-1.module+el8.3.0+7084+c16098dd.x86_64
          version: |-
            slirp4netns version 1.1.1
            commit: bbf27c5acd4356edb97fa639b4e15e0cd56a39d5
            libslirp: 4.3.0
            SLIRP_CONFIG_VERSION_MAX: 3
        swapFree: 1833693184
        swapTotal: 2147479552
        uptime: 145h 19m 14.55s (Approximately 6.04 days)
      registries:
        search:
        - registry.access.redhat.com
        - registry.redhat.io
        - docker.io
      store:
        configFile: /home/user/.config/containers/storage.conf
        containerStore:
          number: 1
          paused: 0
          running: 0
          stopped: 1
        graphDriverName: overlay
        graphOptions:
          overlay.mount_program:
            Executable: /usr/bin/fuse-overlayfs
            Package: fuse-overlayfs-1.1.1-1.module+el8.3.0+7121+472bc0cf.x86_64
            Version: |-
              fuse-overlayfs: version 1.1.0
              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: 15
        runRoot: /run/user/1000/containers
        volumePath: /home/user/.local/share/containers/storage/volumes
      version:
        APIVersion: 1
        Built: 0
        BuiltTime: Thu Jan  1 01:00:00 1970
        GitCommit: ""
        GoVersion: go1.14.2
        OsArch: linux/amd64
        Version: 2.0.0
    • 未使用のコンテナー、イメージ、およびボリュームデータをすべて削除するには、次のコマンドを実行します。

      $ 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 オプションを使用します。デフォルトでは、現在ボリュームを使用するコンテナーがない場合に、重要なデータが削除されないようにボリュームは削除されません。

関連情報

  • man podman-system-df
  • man podman-system-info
  • man podman-system-prune

12.3. 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

関連情報

  • man podman-events

12.4. 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)

関連情報

  • man podman-events

第13章 container-tools CLI の使用

13.1. podman

podman コマンド (Pod Manager の略) を使用すると、Kubernetes、Docker ランタイム、またはその他のコンテナーランタイムを使用せずに、コンテナーをスタンドアロンエンティティーとして実行できます。それは、docker コマンドの代わりに機能できるツールです。同じコマンドライン構文を実装しながら、さらにコンテナーの管理機能を追加します。podman 機能は次のとおりです。

  • docker インターフェースに基づいている - podman 構文は docker コマンドに似ているため、docker に精通している場合には、podman への移行が簡単です。
  • コンテナーおよびイメージの管理 - 以下を行うために、Docker 互換と OCI 互換の両方のコンテナーイメージを、podman とともに使用できます。

    • コンテナーの実行、停止、および再起動
    • コンテナーイメージの作成および管理(プッシュ、コミット、設定、ビルドなど)
  • Pod の管理 - 個々のコンテナーを実行する以外に、podman は、Pod にグループ化された一連のコンテナーを実行できます。Pod は、Kubernetes が管理するコンテナーの最小単位です。
  • ランタイムなしでの動作 - ランタイム環境は、コンテナーと連携するため、podman では使用されません。

以下は、知っておくべき Podman の実装機能です。

  • Podman、Buildah、および CRI-O のコンテナーエンジンはすべて、Docker の保存場所 (/var/lib/docker) をデフォルトで使用する代わりに、同じバックエンドストアディレクトリー /var/lib/containers を使用します。
  • Podman、Buildah、および CRI-O は、同じストレージディレクトリーを共有しているため、互いのコンテナーと対話することはできません。ただし、このツールはイメージを共有できます。また、この機能は、コンテナーを共有できます。
  • docker などの podman コマンドは、Dockerfile からコンテナーイメージを構築できます。
  • podman コマンドは、CRI-O サービスが利用できない場合に有益なトラブルシューティングツールです。
  • podman が対応していない dockerコマンドのオプションには、network、node、plugin (podman はプラグインをサポートしません)、rename (rm および create を使用して podman でコンテナーの名前を変更します)、secret、service、stack、swarm (podman は Docker Swarm をサポートしません) が含まれます。container および imageオプションは、podman で直接使用されるサブコマンドを実行するのに使用します。
  • プログラムで Podman と対話するには、ルートおよびルートレス環境の両方で動作する Podman v2.0 RESTful API を使用してください。詳細は、「コンテナーツール API の使用」 の章を参照してください。

13.1.1. podman コマンドの使用

docker コマンドを使用してコンテナーを操作するのに慣れている場合は、そのほとんどの機能とオプションが podman の機能とオプションに一致することが分かるでしょう。表 1 は、podman で使用できるコマンドの一覧です (podman -h を実行するとこの一覧を表示できます)。

表13.1 podman が対応するコマンド

podman コマンド

説明

podman コマンド

説明

attach

実行中のコンテナーに割り当てる

commit

変更したコンテナーから新規イメージを作成する

build

Dockerfile 命令を使用してイメージを構築する

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 つ以上のコンテナーを削除する。実行している場合は、-f を追加する

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 つ以上のコンテナーをブロックする

  

13.1.2. crun コンテナーランタイムの使用

crun は、C 言語で書かれた高速および低メモリーフットプリントの OCI Container Runtime で、crun バイナリーはrunc バイナリーと比べると最大 1/50 のサイズで、 2 倍の速さとなります。crun を使用して、コンテナーの実行時に最小限のプロセス数を設定することもできます。crun ランタイムは OCI フックもサポートしています。

crun の追加機能には、以下が含まれます。

  • ルートレスコンテナーのグループによるファイルの共有
  • OCI フックの標準出力および標準エラーの制御
  • cgroup v2 での古いバージョンの systemd の実行
  • 他のプログラムによって使用される C ライブラリー
  • 拡張性
  • 移植性

13.1.3. コンテナーランタイムとしての crun の一時使用

podman run コマンドに --runtime オプションを指定して使用して、コンテナーのランタイムを変更できます。

前提条件

  • Podman ツールがインストールされている。

    #  yum module install -y container-tools

手順

  1. registry.access.redhat.com/ubi8/ubi コンテナーイメージをプルします。

    $ podman pull registry.access.redhat.com/ubi8/ubi
  2. --runtime オプションを使用してコンテナーランタイムを変更します。

    $ podman run --name=myubi -dt --runtime=crun ubi8 bash
    e4654eb4df12ac031f1d0f2657dc4ae6ff8eb0085bf114623b66cc664072e69b
  3. 必要に応じて、すべてのイメージを一覧表示します。

    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 コンテナーで crun に設定されていることを確認します。

    $ podman inspect myubi --format "{{.OCIRuntime}}"
    crun

13.1.4. コンテナーランタイムとしての crun の永続使用

コンテナーランタイムおよびそのオプションを containers.conf 設定ファイルで設定できます。

手順

  1. containers.conf ファイルで、ランタイムを runc から crun に変更します。

    # vim /etc/containers/containers.conf
    [engine]
    runtime = "crun"
  2. myubi という名前のコンテナーを実行します。

    # podman run --name=myubi -dt ubi8 bash

検証手順

  • OCI ランタイムが myubi コンテナーで crun に設定されていることを確認します。

    # podman inspect myubi --format "{{.OCIRuntime}}"
    crun

13.1.5. コンテナーの SELinux ポリシーの作成

コンテナーの SELinux ポリシーを生成するには、UDICA ツールを使用します。詳細は「udica の SELinux ポリシージェネレーターの概要」を参照してください。

13.1.6. MPI での Podman の使用

Podman を Open MPI (Message Passing Interface) と共に使用して、HPC (High Performance Computing) 環境でコンテナーを実行できます。

この例は、Open MPI から取得した ring.c プログラムを基にしています。この例では、全プロセスで値はリングのように渡されます。メッセージがランク 0 を渡すと必ず、値は 1 つ下がります。各プロセスが 0 メッセージを受信すると、次のプロセスに渡して終了します。0 を最初に渡すと、すべてのプロセスが 0 メッセージを取得し、通常通りに終了できます。

手順

  1. Open MPI をインストールします。

    $ sudo yum install openmpi
  2. 環境モジュールをアクティベートするには、以下を入力します。

    $ . /etc/profile.d/modules.sh
  3. mpi/openmpi-x86_64 モジュールを読み込みます。

    $ module load mpi/openmpi-x86_64

    必要に応じて、mpi/openmpi-x86_64 モジュールを自動的に読み込むには、以下の行を .bashrc ファイルに追加します。

    $ echo "module load mpi/openmpi-x86_64" >> .bashrc
  4. mpirunpodman を統合するには、以下の定義でコンテナーを作成します。

    $ 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
  5. コンテナーをビルドします。

    $ podman build --tag=mpi-ring .
  6. コンテナーを起動します。このコマンドは、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 経由で相互に通信しています。

    以下の 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 プログラムです。

詳細は、Adwell Reber による 「Podman in HPC environments」 の記事を参照してください。

13.1.7. コンテナーチェックポイントの作成および復元

CRIU (Checkpoint/Restore In Userspace) は、実行中のコンテナーまたは個々のアプリケーションでチェックポイントを設定して、その状態をディスクに保存するソフトウェアです。保存したデータを使用して、再起動後に、チェックポイントの時点にコンテナーを復元できます。

13.1.7.1. ローカルでのコンテナーチェックポイントの作成および復元

以下の例は、要求ごとにインクリメントする整数を 1 つ返す Python ベースの Web サーバーをベースとしています。

手順

  1. 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()
  2. 以下の定義でコンテナーを作成します。

    # 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 ベースのサーバーを使用します。

  3. コンテナーをビルドします。

    # podman build . --tag counter

    counter.py ファイルおよび Containerfile ファイルは、コンテナービルドプロセス (podman build) の入力情報です。ビルドされたイメージはローカルに保存され、counter でタグ付けされます。

  4. root でコンテナーを起動します。

    # podman run --name criu-test --detach counter
  5. 実行中のコンテナーの一覧を表示するには、次のコマンドを実行します。

    # podman ps
    CONTAINER ID  IMAGE  COMMAND  CREATED   STATUS  PORTS NAMES
    e4f82fd84d48  localhost/counter:latest  5 seconds ago  Up 4 seconds ago  criu-test
  6. コンテナーの IP アドレスを表示します。

    # podman inspect criu-test --format "{{.NetworkSettings.IPAddress}}"
    10.88.0.247
  7. 要求をコンテナーに送信します。

    # curl 10.88.0.247:8080
    0
    # curl 10.88.0.247:8080
    1
  8. コンテナーのチェックポイントを作成します。

    # podman container checkpoint criu-test
  9. システムを再起動します。
  10. コンテナーを復元します。

    # podman container restore --keep criu-test
  11. 要求をコンテナーに送信します。

    # curl 10.88.0.247:8080
    2
    # curl 10.88.0.247:8080
    3
    # curl 10.88.0.247:8080
    4

    結果は 0 で開始あれるのではなく、以前の値で継続されます。

これにより、再起動後に完全なコンテナーの状態を簡単に保存できます。

詳細は、Adrian Reber による「Adding checkpoint/restore support to Podman」 の記事を参照してください。

13.1.7.2. コンテナー復元を使用した起動時間の短縮

コンテナーマイグレーションを使用して、初期化に特定の時間を必要とするコンテナーの起動時間を短縮できます。チェックポイントを使用すると、同じホストまたは別のホストでコンテナーを複数回復元できます。この例は、「コンテナーチェックポイントのローカルでの作成および復元」セクションのコンテナーを基にしています。

手順

  1. コンテナーのチェックポイントを作成し、チェックポイントイメージを tar.gz ファイルにエクスポートします。

    # podman container checkpoint criu-test --export /tmp/chkpt.tar.gz
  2. 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) オプションは、エクスポートしたチェックポイントを基に復元したコンテナーに新しい名前を指定します。

  3. 各コンテナーの ID と名前を表示します。

    # podman ps -a --format "{{.ID}} {{.Names}}"
    a8b2e50d463c counter3
    faabc5c27362 counter2
    2ce648af11e5 counter1
  4. 各コンテナーの 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
  5. 各コンテナーに要求を送信します。

    #️ curl 10.88.0.248:8080
    4
    #️ curl 10.88.0.249:8080
    4
    #️ curl 10.88.0.250:8080
    4

    同じチェックポイントから異なるコンテナーを使用して復元しているので、結果は、どの場合も 4 になる点に注意してください。

この方法では、最初にチェックポイントを作成したコンテナーのステートフルレプリカを迅速に起動できます。

詳細は、Adrian Reber による「Container migration with Podman on RHEL」を参照してください。

13.1.7.3. システム間のコンテナーの移行

この手順は、コンテナーで実行しているアプリケーションの状態を失うことなく、実行中のコンテナーを別のシステムに移行する方法を示しています。この例は、counter とタグ付けされた 「コンテナーのチェックポイントの作成および復元のコンテナー」セクションのコンテナーを基にしています。

前提条件

以下の手順は、コンテナーがレジストリーにプッシュされている場合には不要です。理由は、Podman がローカルでコンテナーを利用できない場合に自動的にコンテナーをレジストリーからダウンロードするためです。この例ではレジストリーを使用していません。以前に構築およびタグ付けされたコンテナーをローカルにエクスポートし (「コンテナーチェックポイントのローカルでの作成および復元」セクションを参照)、この移行先システムにコンテナーをインポートする必要があります。

  • 以前にビルドしたコンテナーをエクスポートします。

    # podman save --output counter.tar counter
  • エクスポートしたコンテナーイメージを移行先システム (other_host) にコピーします。

    # scp counter.tar other_host:
  • エクスポートしたコンテナーを移行先システムにインポートします。

    # ssh other_host podman load --input counter.tar

このコンテナーの移行先のシステムには、ローカルコンテナーストレージに保存されているのと同じコンテナーイメージがあります。

手順

  1. root でコンテナーを起動します。

    # podman run --name criu-test --detach counter
  2. コンテナーの IP アドレスを表示します。

    # podman inspect criu-test --format "{{.NetworkSettings.IPAddress}}"
    10.88.0.247
  3. 要求をコンテナーに送信します。

    # curl 10.88.0.247:8080
    0
    # curl 10.88.0.247:8080
    1
  4. コンテナーのチェックポイントを作成し、チェックポイントイメージを tar.gz ファイルにエクスポートします。

    # podman container checkpoint criu-test --export /tmp/chkpt.tar.gz
  5. チェックポイントアーカイブを移行先ホストにコピーします。

    # scp /tmp/chkpt.tar.gz other_host:/tmp/
  6. 移行先ホスト (other_host) のチェックポイントを復元します。

    # podman container restore --import /tmp/chkpt.tar.gz
  7. 宛先ホスト (other_host) のコンテナーに要求を送信します。

    # curl 10.88.0.247:8080
    2

これで、ステートフルコンテナーが、状態を失うことなく、別のシステムへ移行されました。

詳細は、Adrian Reber による「Container migration with Podman on RHEL」を参照してください。

13.2. runc

「 runC」コンテナーランタイムは、Open Container Initiative (OCI) コンテナーランタイム仕様の軽量で移植可能な実装です。runC は、低レベルの機能を多数統合し、コンテナーの実行を可能にします。多くの低レベルコードを Docker と共有しますが、Docker プラットフォームのコンポーネントには依存しません。

runc は Linux 名前空間とライブ移行をサポートしており、移植可能なパフォーマンスプロファイルがあります。また、SELinux、コントロールグループ (cgroups)、seccomp などの Linux セキュリティー機能に完全に対応します。runc でイメージをビルドして実行したり、runc で OCI 互換イメージを実行したりできます。

13.2.1. runc でコンテナーの実行

runc では、コンテナーはバンドルを使用して設定します。コンテナーのバンドルは、config.json という名前の仕様ファイルと、root ファイルシステムを含むディレクトリーです。root ファイルシステムには、コンテナーの内容が含まれます。

バンドルを作成するには、以下を実行します。

$ runc spec

このコマンドは、編集が必要な、必要最小限の構造のみを含む config.json ファイルを作成します。実行するファイルを指定するために args パラメーターを変更する必要があるということが最も重要です。デフォルトでは、argssh に設定されています。

    "args": [
      "sh"
    ],

たとえば、podman を使用して Red Hat Enterprise Linux ベースイメージ (ubi8/ubi) をダウンロードしてエクスポートし、runc でそのイメージ用の新しいバンドルを作成し、config.json ファイルを編集してそのイメージを指定します。次に、コンテナーイメージを作成し、runc を使用してそのイメージのインスタンスを実行します。以下のコマンドを使用します。

# podman pull registry.redhat.io/ubi8/ubi
# podman export $(podman create registry.redhat.io/ubi8/ubi) > rhel.tar
# mkdir -p rhel-runc/rootfs
# tar -C rhel-runc/rootfs -xf rhel.tar
# runc spec -b rhel-runc
# vi rhel-runc/config.json   Change any setting you like
# runc create -b rhel-runc/ rhel-container
# runc start rhel-container
sh-4.2#

この例では、コンテナーインスタンスの名前は rhel-container です。そのコンテナーを実行すると、デフォルトでシェルを起動するため、そのコンテナーからコマンドの検索や実行が可能になります。終了したら、exit と入力します。

コンテナーインスタンスの名前は、ホストで一意のものである必要があります。コンテナーの新しいインスタンスを起動するには、以下を実行します。

# runc start <container_name>

bundle ディレクトリーは、-b オプションで指定できます。デフォルトでは、bundle の値は現在のディレクトリーになります。

runc でコンテナーを起動するには、root 権限が必要になります。runc で利用可能なコマンドとその使用方法をすべて表示するには、 runc --help を実行します。

13.3. skopeo

skopeo コマンドを使用すれば、docker デーモンや docker コマンドを使用しなくても、レジストリーからコンテナーイメージを扱うことができます。レジストリーには、Docker レジストリー、独自のローカルレジストリー、Red Hat Quay、または OpenShift レジストリーを追加できます。skopeo で実行できることは次のとおりです。

  • 検証 - skopeo inspect コマンドの出力は、docker inspect コマンドで表示されるもの (コンテナーイメージに関する詳細な情報) と似ています。この出力は、json 形式 (デフォルト) または raw 形式 (--raw オプションを使用) の可能性があります。
  • コピー - skopeo copy を使用すると、コンテナーイメージをレジストリーから別のレジストリーまたはローカルディレクトリーにコピーできます。
  • レイヤー - skopeo layers コマンドを使用すると、イメージに関連付けられているレイヤーをダウンロードして、tarball および関連付けられているマニフェストファイルとしてローカルディレクトリーに保存できます。

コンテナーまたはイメージライブラリーに依存する buildah コマンドやその他のツールのように、skopeo コマンドは、Docker に関連付けられているもの以外のコンテナーストレージ領域からのイメージを処理できます。他のタイプのコンテナーストレージへの利用可能な変換には、コンテナーストレージ (buildah および CRI-O が保存するイメージ用)、ostree (アトミックおよびシステムコンテナー用)、oci (OCI 準拠のディレクトリーに格納されているコンテンツ用) などがあります。詳細は skopeo の man ページ を参照してください。

skopeo を試すには、ローカルレジストリーを設定してから、イメージレイヤーの検証、コピー、およびダウンロードを行うコマンドを実行します。この例に従う場合は、まず次の手順を実行します。

  • ローカルレジストリー(Red Hat Quay など) をインストールします。RHEL 7 の docker-distribution パッケージで利用可能なコンテナーレジストリーソフトウェアは、RHEL 8 では利用できません。
  • 最新の RHEL イメージをローカルシステム (podman pull ubi8/ubi) にプルします。
  • RHEL イメージのタグを再登録し、以下のようにローカルレジストリーにプッシュします。

    # podman tag ubi8/ubi localhost/myubi8
    # podman push localhost/myubi8

本セクションの残りの部分では、RHEL イメージからレイヤーを検証、コピー、および取得する方法を説明します。

注記

デフォルトでは、skopeo ツールは TLS 接続を必要とします。暗号化されていない接続を使用しようとすると失敗します。デフォルトを上書きして http レジストリーを使用するには、文字列 <registry>/<image> の前に http: と付けます。

13.3.1. skopeo でコンテナーイメージの検証

レジストリーからコンテナーイメージを検証する場合は、コンテナーの形式 (docker など)、レジストリーの場所 (docker.io、localhost など)、およびリポジトリー/イメージ (ubi8/ubi など) を指定する必要があります。

以下の例では、Docker レジストリーから mariadb コンテナーイメージを検証します。

# skopeo inspect docker://docker.io/library/mariadb
{
    "Name": "docker.io/library/mariadb",
    "Tag": "latest",
    "Digest": "sha256:d3f56b143b62690b400ef42e876e628eb5e488d2d0d2a35d6438a4aa841d89c4",
    "RepoTags": [
        "10.0.15",
        "10.0.16",
        "10.0.17",
        "10.0.19",
...
    "Created": "2018-06-10T01:53:48.812217692Z",
    "DockerVersion": "1.10.3",
    "Labels": {},
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
...

タグ付けされた localhost/myubi8 を、ローカルシステムで実行しているコンテナーリポジトリーへプッシュしたとすると、次のコマンドでそのイメージを検証します。

# skopeo inspect docker://localhost/myubi8
{
    "Name": "localhost/myubi8",
    "Tag": "latest",
    "Digest": "sha256:4e09c308a9ddf56c0ff6e321d135136eb04152456f73786a16166ce7cba7c904",
    "RepoTags": [
        "latest"
    ],
    "Created": "2018-06-16T17:27:13Z",
    "DockerVersion": "1.7.0",
    "Labels": {
        "Architecture": "x86_64",
        "Authoritative_Registry": "registry.access.redhat.com",
        "BZComponent": "rhel-server-docker",
        "Build_Host": "rcm-img01.build.eng.bos.redhat.com",
        "Name": "myubi8",
        "Release": "75",
        "Vendor": "Red Hat, Inc.",
        "Version": "8.0"
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:16dc1f96e3a1bb628be2e00518fec2bb97bd5933859de592a00e2eb7774b6ecf"
    ]
}

13.3.2. skopeo でコンテナーイメージのコピー

このコマンドは、myubi8 コンテナーイメージを、ローカルレジストリーからローカルシステムのディレクトリーにコピーします。

# skopeo copy docker://localhost/myubi8 dir:/root/test/
INFO[0000] Downloading myubi8/blobs/sha256:16dc1f96e3a1bb628be2e00518fec2bb97bd5933859de592a00e2eb7774b6ecf
# ls /root/test
16dc1f96e3a1bb628be2e00518fec2bb97bd5933859de592a00e2eb7774b6ecf.tar manifest.json

skopeo copy コマンドの結果は、指定したディレクトリーへコピーするイメージを表す tarball (16d*.tar) と manifest.json です。レイヤーが複数になる場合は、tarball も複数になります。skopeo copy コマンドは、別のレジストリーにイメージをコピーすることもできます。宛先レジストリーに書き込むのに使用する署名を提供する必要がある場合は、コマンドラインに --sign-by= オプションを追加し、その後に必要な key-id を追加します。

13.3.3. skopeo でイメージレイヤーの取得

skopeo layers コマンドは、skopeo copy に似ており、相違点は、copy オプションはイメージを別のレジストリーまたはローカルディレクトリーにコピーできますが、layers オプションは現在のディレクトリーにあるレイヤー (tarball ファイルおよび manifest.json ファイル) を削除するだけとなります。以下に例を示します。

# skopeo layers docker://localhost/myubi8
INFO[0000] Downloading myubi8/blobs/sha256:16dc1f96e3a1bb628be2e00518fec2bb97bd5933859de592a00e2eb7774b6ecf
# find .
./layers-myubi8-latest-698503105
./layers-myubi-latest-698503105/manifest.json
./layers-myubi8-latest-698503105/16dc1f96e3a1bb628be2e00518fec2bb97bd5933859de592a00e2eb7774b6ecf.tar

この例では、新しいディレクトリー (layers-myubi8-latest-698503105) を作成し、このケースでは 1 つのレイヤーの tarball と manifest.json ファイルがそのディレクトリーにコピーされます。

第14章 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 を呼び出すことができます。

14.1. root モードで systemd を使用した Podman API の有効化

この手順では、以下を行う方法を説明します。

  1. systemd を使用して Podman API ソケットをアクティベートします。
  2. Podman クライアントを使用して基本的なコマンドを実行します。

前提条件

  • podman-remote パッケージがインストールされている。

    # yum install podman-remote

手順

  1. Podman ソケットの systemd ユニットファイルを設定します。

    # cat /usr/lib/systemd/system/podman.socket
    
    [Unit]
    Description=Podman API Socket
    Documentation=man:podman-api(1)
    
    [Socket]
    ListenStream=%t/podman/podman.sock
    SocketMode=0660
    
    [Install]
    WantedBy=sockets.target
  2. systemd マネージャー設定を再読み込みします。

    # systemctl daemon-reload
  3. サービスをすぐに起動します。

    # systemctl enable --now podman.socket
  4. docker-podman パッケージを使用して var/lib/docker.sock へのリンクを有効にするには以下を実行します。

    # yum install podman-docker

検証手順

  1. Podman のシステム情報を表示します。

    # podman-remote info
  2. リンクを確認します。

    # ls -al /var/run/docker.sock
    lrwxrwxrwx. 1 root root 23 Nov  4 10:19 /var/run/docker.sock -> /run/podman/podman.sock

関連情報

14.2. ルートレスモードで systemd を使用した Podman API の有効化

この手順では、systemd を使用して Podman API ソケットおよび Podman API サービスをアクティベートする方法を説明します。

前提条件

  • podman-remote パッケージがインストールされている。

    # yum install podman-remote

手順

  1. Podman のルートレスソケットを作成します。

    $ vim ~/.config/systemd/user/podman.socket
    
    [Unit]
    Description=Podman API Socket
    Documentation=man:podman-api(1)
    
    [Socket]
    ListenStream=%t/podman/podman.sock
    SocketMode=0660
    
    [Install]
    WantedBy=sockets.target
  2. Podman のルートレスサービスを作成します。

    $ vim ~/.config/systemd/user/podman.service
    [Unit]
    Description=Podman API Service
    Requires=podman.socket
    After=podman.socket
    Documentation=man:podman-api(1)
    StartLimitIntervalSec=0
    
    [Service]
    Type=oneshot
    Environment=REGISTRIES_CONFIG_PATH=/etc/containers/registries.conf
    ExecStart=/usr/bin/podman system service unix:///%t/podman.sock
    TimeoutStopSec=30
    KillMode=process
    
    [Install]
    WantedBy=multi-user.target
    Also=podman.socket
    • [Unit] セクションの After 行では、podman.socket ユニットファイルの依存関係を定義します。podman.socket ユニットは、設定済みの podman.service の前に起動します。
  3. systemd マネージャー設定を再読み込みします。

    $ systemctl --user daemon-reload
  4. サービスをすぐに有効にして起動します。

    $ systemctl --user enable --now podman.socket
  5. Docker を使用してプログラムがルートレス Podman ソケットを操作できるようにするには、以下を実行します。

    $ export DOCKER_HOST=unix:///var/run/<username>/podman.sock

検証手順

  • Podman のシステム情報を表示します。

    $ podman-remote info

関連情報

14.3. Podman API の手動実行

この手順では、Podman API の実行方法について説明します。手動での実行は、特に Docker の互換性レイヤーを使用する場合など、API 呼び出しのデバッグに便利です。

前提条件

  • podman-remote パッケージがインストールされている。

    # yum install podman-remote

手順

  1. REST API のサービスを実行します。

    # podman system service -t 0 --log-level=debug
    • 値が 0 の場合はタイムアウトなしを意味します。ルートフルサービスのデフォルトのエンドポイントは unix:/run/podman/podman.sock です。
    • --log-level <level> オプションは、ロギングレベルを設定します。標準のロギングレベルは debuginfowarnerrorfatal、および panic です。
  2. 別のターミナルで、Podman のシステム情報を表示します。podman-remote コマンドは、通常の podman コマンドとは異なり、Podman ソケットを介して通信します。

    # podman-remote info
  3. 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 プロセッサーです。

  4. 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
  5. プルしたイメージを表示します。

    # 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"
        ],
        ...
        ]
      }
    ]

関連情報

第15章 関連情報