4.18. コンテナー

log-location オプションが Podman の設定で利用可能になりました

podman-kube systemd を使用すると、containers.conf ファイルでカスタムの log-location オプションを指定して、ユーザーごとの設定を行うことができます。以前は、ログの保存場所はデフォルトの場所に限定されており、カスタマイズすることはできませんでした。今回のリリースにより、設定ファイル内でカスタムログパスを直接定義できるようになりました。これにより、podman run コマンドで手動で指定する必要性が軽減されます。

Jira:RHEL-3114^[1]

aardvark-dns 機能の拡張により、プロセス全体の再起動なしで resolv.conf ファイルが再読み込みされるようになりました

今回のアップデートにより、Aardvark-DNS プロセスが、Red Hat Enterprise Linux (RHEL) 上の Podman 5.x スタックにおいて、DNS 設定を動的に再読み込みするようになりました。これにより、DNS 設定ファイルに変更を加えた際にプロセス全体を停止して再起動する必要がなくなりました。その結果、効率が向上し、エンドユーザーのダウンタイムが短縮されます。

Jira:RHEL-85839^[1]

container-selinux がバージョン 2.244.0-1 にリベースされました

コンテナーランタイムを制限および保護するために必要な SELinux ポリシー、タイプ、およびルールを提供する container-selinux パッケージが、バージョン 2.244.0-1 にリベースされました。このバージョンでは重要な機能拡張が行われました。特に、プロセスを効率化し、データ保護を強化し、デプロイメントにおける機密性を確保すると同時に、パブリックストレージのエンドポイントに関連する潜在的なセキュリティーリスクを軽減します。

Jira:RHEL-112187

runc が 1.3.3 にリベースされました

コンテナーの起動と実行を行うための低レベルの CLI ツールである runc パッケージが、アップストリームバージョン 1.3.3 にリベースされました。このバージョンでは、特に以下の点を含む重要な修正と機能拡張が行われています。

専用の Azure Kubernetes Service (AKS) クラスター上に、独自のプライベートコンテナーレジストリーを作成および管理できます。この機能拡張により、コンテナーイメージの保存と配布のためのプライベートな領域が得られ、不正アクセスのリスクが軽減されます。そのため、コンテナーのワークフローが効率化され、セキュリティーが強化され、効率が向上します。
定型業務を自動化し、時間と労力を節約し、ユーザーインターフェイスを改善します。これにより、サードパーティー製アプリケーションとのシームレスな統合が可能になり、プラットフォームの機能性とユーザーにとっての汎用性が向上します。

Jira:RHEL-124800

ルートレス Podman で統一された設定が利用可能になりました

今回のアップデートにより、ルートレス Podman 向けにシステム全体で統一された設定ファイルが導入されました。これにより、一元的なポリシー管理、一貫したセキュリティー基準、および全ユーザーにわたる運用上の標準化が可能になります。

その結果、手動で設定することなく適切なデフォルト設定を継承しながら、個人設定ファイルを通じてシステム設定をオーバーライドできる柔軟性も維持できます。さらに、今回のアップデートでは下位互換性が確保されているため、既存のユーザーワークフローや設定が変更されることはありません。

Jira:RHEL-126643

Container Tools パッケージが更新されました

Podman、Buildah、Skopeo、crun、runc ツールを含む、更新された Container Tools RPM メタパッケージを利用できます。Buildah パッケージはバージョン 1.43.1 に更新され、Skopeo はバージョン 1.22.2 に更新されました。Podman リリース 5.8.2 には、以前のバージョンに対する次の主なバグ修正と機能拡張が含まれています。

podman machine init --image コマンドを Windows 上の Hyper-V バックエンドで使用する場合、ユーザー指定のイメージパスから PowerShell-escaped コマンドがホストの PowerShell セッションで実行される可能性があります (CVE-2026-33414)。
Quadlets を使用している場合、再起動後に BoltDB から SQLite への自動移行を行うと、部分的な移行は行われなくなり、一部のコンテナーは SQLite に、その他は BoltDB に残ります。
podman quadlet install コマンドは、複数の個別の Quadlet ファイルを含むファイルをインストールします。新しい Quadlet に名前を付けるには、各ファイルを新しい行で --- delimiter で区切り、各セクションを # FileName=<name> 行で始める必要があります。
Quadlet .container ファイルには、コンテナーの AppArmor プロファイルを設定するための AppArmor 鍵が含まれています。
Podman は、システムの再起動時に、以前の BoltDB データベースを SQLite に自動的に移行しようとします。これは、Podman 6.0 リリースで BoltDB のサポートが削除されたため、必要です。自動移行が不可能な場合は、新しい podman system migrate --migrate-db オプションを使用して、手動で移行を強制できます。
Podman Machine の仮想マシンに対して podman artifact add コマンドを実行すると、Podman は仮想マシンのファイルシステムからパスを読み込みます。これは、REST API を介してデータをストリーミングする代わりに、仮想マシンにロードまたは構築するパスを共有する場合にパフォーマンスを向上させます。
podman update コマンドに、コンテナーの ulimit を更新するための新しいオプション --ulimit が追加されました。
podman exec コマンドに新しい --no-session オプションを使用すると、exec セッションの追跡を無効にでき、パフォーマンスと起動時間が向上します。
podman-restart.service サービスを有効にすると、リスタートポリシーに unless-stopped が設定されたコンテナーは、システムの再起動後にも自動的に再起動します。
Quadlet.container ファイル内では、以下が可能です。
- Entrypoint="" を設定して、コンテナーのエントリーポイントをクリアできます。
- HealthCmd は、二重引用符を含むコマンドをサポートし、ヘルスチェックが正常に機能するようにします。
- RequiresMountsFor フィールドは、スペースを含むバインドマウントパスを正しく処理します。
ホストネットワークモードでコンテナーを検査しても、FreeBSD システムがパニックを起こすことがなくなりました。
Libpod のシステムチェックエンドポイントは、400 エラーを返した後は、不正なデータを使用した処理を実行しないようになりました。
コンテナー (Libpod および Compat) のリモートアタッチ API において、まれに発生していた競合状態が原因でパニックを起こすことがなくなりました。
システムがデフォルトドライバーのオプションを誤って追加しなくなりました。この問題は以前、Secret Create API がシェルドライバーを使用して正常に機能するシークレットを作成するのを妨げていました。パイプ経由で渡す代わりに、podman secret create コマンドを使用して、ターミナルで直接シークレットを入力できます。
Quadlet とのやり取り用の新しい API を追加しました。
- GET /libpod/quadlets/{name}/file: Quadlet ファイルの内容を出力します。
- GET /libpod/quadlets/{name}/exists: 指定された Quadlet が存在するか確認します。
- POST /libpod/quadlets: 1 つ以上の Quadlet をインストールします。
- DELETE /libpod/quadlets: 1 つ以上の Quadlet を削除します。
- DELETE /libpod/quadlets/{name}: 単一の Quadlet を削除します。
podman play kube コマンドで作成されたコンテナーは、initialDelaySeconds オプションの有効期限前にヘルスチェックを実行しなくなりました。また、podman kube play コマンドは、envFrom フィールドと env フィールドの両方で設定された環境変数間の優先順位を正しく処理するようになりました。
podman build コマンドの --pull=newer オプションが正しく機能するようになりました。
podman artifact push と podman artifact pull コマンドは、--authfile オプションで指定された認証情報を無視しなくなりました。
podman run --pod-id-file オプションが正しく検証されるようになり、ユーザー名前空間の設定が不適切な Pod 内でコンテナーが作成されることが防止されるようになりました。
主な変更点の詳細は、アップストリームのリリースノートを参照してください。

Jira:RHEL-127908

エアギャップ環境および非接続環境における更新がサポートされます

今回のアップデートでは、RHEL デプロイメント向けにエアギャップ環境および非接続環境での更新が導入され、エッジデプロイメントでもインターネット接続なしで更新を実行できるようになります。その結果、オフライン更新における柔軟性と信頼性が向上し、リモート環境やセキュアな環境におけるデプロイメント管理が改善されます。

Jira:RHELDOCS-20708^[1]

新しいコンテナーイメージが利用可能になりました

rhel9/ruby-40、rhel9/postgresql-18、rhel9/python-314-minimal、rhel9/mariadb-118、および rhel9/python-314 コンテナーイメージが、Red Hat Container Registry で利用可能になりました。各イメージにおける主な機能拡張は以下のとおりです。

rhel9/ruby-40: Ruby 4.0 コンテナーをベースプラットフォームとして使用し、さまざまな Ruby 4.0 アプリケーションやフレームワークをビルドおよび実行します。このコンテナーイメージには npm ユーティリティーが含まれているため、Web アプリケーション用の JavaScript モジュールをインストールできます。
rhel9/postgresql-18: このコンテナーイメージを使用すると、PostgreSQL の postgres デーモンとクライアントアプリケーションをコンテナーにパッケージ化できます。postgres サーバーデーモンは、クライアントからの接続を受け付け、PostgreSQL データベースのコンテンツへのアクセスを提供します。
rhel9/python-314-minimal: コンテナー化されたアプリケーションを構築するための汎用ベースイメージとして、完全なコンテナーイメージを使用します。しかし、この汎用的な性質により、結果として作成されるコンテナーのディスク消費容量が増加します。これは主に、イメージに npm、コンパイラー、ヘッダーファイル、およびアプリケーションのインストールとデプロイに必要となる可能性のあるその他のパッケージが含まれていることに起因します。
rhel9/mariadb-118: このコンテナーイメージは、MariaDB の mysqld デーモンとクライアントアプリケーションをコンテナーにパッケージ化するために使用します。mysqld サーバーデーモンは、クライアントからの接続を受け付け、MySQL データベースのコンテンツへのアクセスを提供します。
rhel9/python-314: Python 3.14 コンテナーをベースプラットフォームとして使用して、Python 3.14 アプリケーションやフレームワークを構築および実行できます。このコンテナーイメージには npm ユーティリティーが含まれているため、Web アプリケーション用の JavaScript モジュールをインストールできます。現在、Red Hat はイメージに含まれる npm や Node.js の特定のバージョンに対するサポートを提供していません。

Jira:RHELDOCS-22067^[1]

4.18. コンテナー

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

Red Hat ドキュメントについて

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links