ログイン / 登録 アカウント

Red Hat Enterprise Linux 8.1 では、ルートレス Podman、Podman Play/generate Kube、および Golang ツールセットのコンテナイメージのフルサポートを含む新しいコンテナ機能を追加しました (「主要な新しいコンテナ機能を備えたマイナーリリース」) 。Red Hat Enterprise Linux 8.2 は、さらに多くの機能セットを備えています。 

要点を簡単に説明すると次のとおりです。

  • fast moving ストリーム container-tools:rhel8 の更新

  • stable ストリーム container-tools:1.0 のサポートを継続

  • 新しいstable ストリーム container-tools:2.0

  • CRIU を container-tools:rhel8 ストリームに追加

  • Udica を container-tools:rhel8 ストリームに追加

  • OpenJDK イメージを Red Hat Universal Base Image の一部としてリリース

  • ソースコンテナイメージをすべての Red Hat Universal Base Image 向けに作成

  • Buildah と Skopeo のコンテナイメージ

  • パートナー向けに Red Hat Universal Base Image EULA に拡張

盛りだくさんですので、各機能をもう少し詳しく説明していきましょう。

コンテナツール

Container Tools RHEL 8 Fast Stream (container-tools:rhel8)

RHEL 8.2 の container-tools:rhel8 ストリームでは、Podman 1.6.4、Buildah 1.11.6、Skopeo 0.1.40 といった安定したバージョンを引き続き利用できます。これらのバージョンは、RHEL 7.8 でリリースされたバージョンに合わせて特別に選ばれており、RHEL 8 への移行が容易になります。

一部ではありますが、RHEL 8.1 以降の興味深い新機能について、こちらに簡単にまとめました。

  • HPC (高性能計算) 環境での Message Passing Interface (MPI) のサポート。これは、Podman で HPC ワークロードをサポートするための、より大きなイニシアチブの一部です。詳細は、製品ドキュメント (コンテナの構築、実行、および管理 - MPI での podman の使用) を参照してください。

  • コンテナが DNS 名を介して他のコンテナの IP を解決できるようにするコンテナ・ネットワーク・インタフェース (CNI) DNS プラグインの初期サポートが追加されました。

  • Podman が匿名の名前付きボリュームをサポートするようになりました。これは、podman create および podman run コマンド-v フラグに宛先のみを指定することで作成されます。

  • podman info コマンドを root なしで実行すると、ルートレスユーザー名前空間の UID および GID マッピングに関する情報が表示されるようになりました。

  • podman build --squash-all フラグが追加されました。これは、すべてのレイヤー (ベースイメージのレイヤーを含む) を 1 つのレイヤーに圧縮します。

  • podman network createpodman network rmpodman network inspect、および podman network ls コマンドが追加され、Podman で使用される CNI ネットワークを管理できるようになりました。

  • podman volume create コマンドでは、オプションによるボリュームの作成とマウントが可能になり、NFS、tmpfs、その他多くのファイルシステムによってボリュームがバックアップされます。

  • ルートレス Podman は、--storage-opt ignore_chown_errors をパスすることで、イメージ内のすべての UID と GID を単一の UID と GID (newuidmap および newgidmap 実行可能ファイルの使用を必要としない) に試験的に圧縮できます。

  • --privileged set を使用した ルートレス Podman コンテナは、ユーザーがアクセスできるすべてのホストデバイスにマウントされるようになりました。

  • ルートレス Podman がヘルスチェックをサポートするようになりました (#3523)。

詳細は、man コマンドで表示されるマニュアル、製品ドキュメントリリースノートを参照してください。

Container Tools 1.0 Stable Stream (container-tools:1.0)

ユーザーの多くは最新バージョンの Podman、Buildah、Skopeo を利用したいと考えていますが、より安定したものを求めるユーザーもいます。このようなユーザーは、バージョンは変更しないもののセキュリティアップデートは受信する、安定したバージョンの Podman、Buildah、Skopeo へのアクセスを望んでいます。

このようなユースケースを想定している場合は、このストリームが適しています。このストリームは、RHEL 8.4 まで継続してセキュリティアップデートを受信します。つまり、このバージョンをもう 1 年使用することができ、最終的には container-tools:2.0 ストリームまたは container-tools:3.0 (RHEL 8.4 で予定) に移行できます。

stableストリーム container-tools:3.0 を備えた RHEL 8.4 がリリースされてサポートが終了するまでの間、container-tools:1.0 ストリームでは Podman 1.0、Buildah 1.5、Skopeo 0.1.32 を引き続き利用できます。

Container Tools 2.0 Stable Stream (container-tools:2.0)

Container Tools 2.0 ストリームには、RHEL 8.2 でリリースされた container-tools:rhel8 ストリームと同じバージョンの Podman、Buildah、Skopeo が追加されました。これにより、ユーザーは安定したバージョンを使用できます。

Checkpoint/Restore in Userspace (CRIU)

コンテナが停止する (podman stop) と、そのコンテナ専用のコピーオンライトレイヤーのコンテンツはオーバーレイ・ファイルシステムに残ります (podman rmを実行しない限り) が、メモリ内のコンテンツは破棄されます。

CRIU logoApache または Nginx サーバーのようなほとんどの一時的なワークロードでは、これで問題ありません。しかし、Java ワークロード (JVM の起動に時間がかかる場合がある) や、キャッシュが大きいデータベース (ウォームアップに数時間かかる場合がある) の場合、これは最適ではありません。この問題を解決するために、Podman と CRIU が連携して、コンテナのメモリのコンテンツを保存します。これは、コンテナ化されたワークロードを再起動するために使用でき、起動やキャッシュのウォームアップ時間が不要になります。

RHEL 8.2 のリリースにより、Checkpoint/Restore In Userspace (CRIU と呼ばれることが多い) が、container-tools:rhel8 および container-tools:2.0 モジュールストリームの一部としてリリースされます。これは、Podman と対応づけられた安定バージョンの CRIU をユーザーに提供し、各モジュールストリームそれぞれのライフサイクルで互換性が維持されます。

詳細は、製品ドキュメント (Red Hat Enterprise Linux 8 での Linux コンテナの構築、実行、および管理 - コンテナチェックポイントの作成および復元) を参照してください。

Udica

標準の SELinux ポリシーは、コンテナごとに自動生成されたマルチカテゴリセキュリティ (MCS) ラベルを使用して実行中のコンテナを動的に分離することにより、全面的な優れた保護を提供します (What Is SVirt And How Does It Isolate Linux Containers? も併せてご参照ください)。 

Udica logoこれにより、コンテナがお互いを攻撃したり、ホストを攻撃したりするのを防ぎます。しかし、コンテナが使用できるポート、ファイル、ソケットなどを正確に制限したい場合はどうなるでしょうか。たとえば、そのコンテナに最小限のセキュリティ機能のみを許可したいとします。そこで登場するのが、Udica (ユディーツァ) です。

Udica を使用すると、管理者とコンテナ開発者は、コンテナを分析し、デフォルトのポリシーと連携する追加のポリシーモジュールを生成することにより、必要な機能だけを許可するセキュリティポリシーを作成できます。これを保護のオーバーレイ層と考えてください。

CRIU と同様に、container-tools:rhel8 および container-tools:2.0 モジュールストリームには Udica が含まれており、それぞれのライフサイクル全体で互換性を確保しています。詳細は、製品ドキュメント (SELinux の使用 - カスタムコンテナーの SELinux ポリシーを作成して使用) を参照してください。

Red Hat Universal Base Image に OpenJDK イメージを追加

Red Hat Universal Base Image を使用すると、ユーザーは OpenShift および RHEL でサポート可能なエンタープライズ品質のビット上に独自のアプリケーションを構築して配布できます。RHEL 8.2 のリリースに伴い、OpenJDK 8 および OpenJDK 11 Red Hat Universal Base Image の GA を発表していますが、これにより、UBI のすべてのメリットがもたらされることに加えて、コンテナ内で実行される Java アプリケーションを、Red Hat ビルドの OpenJDK が支援する安全で安定したテスト済みの手法で開発したいと考えるすべての人に適したベースラインが設定されます。

Red Hat ビルドの OpenJDK は、アップストリームの OpenJDK 8u および 11u プロジェクトをベースとしています。Red Hat はこれらのプロジェクトをアップストリームで維持し、Red Hat ビルドに機能を追加します。また、OpenJDK の主要なバージョンに対して、指定された期間のサポートとメンテナンスを提供します。 

長期サポート付きのバージョンは、8 が 2026 年 6 月まで、11 が 2024 年 10 月までとなります (OpenJDK のライフサイクルおよびサポートポリシーも併せてご参照ください)。最後に、こちらは OpenJDK の最新機能の一部です。

  • 停止時間が短いガベージコレクタの Shenandoah が含まれている。

  • セキュリティおよびその他のバグ修正と機能強化のために、少なくとも四半期に一度の更新が計画されている。

詳細は、Red Hat Ecosystem Catalog で新しいイメージを確認してください。

ソースコンテナイメージ

コンテナイメージは、ソフトウェアの消費を非常に便利にします。ソフトウェアのユーザーは実行したいソフトウェアに集中でき、コンテナイメージのビルダーは必要な依存関係をすべて備えたそのソフトウェアの構築を自動化できます。船積みに例えて説明すると、コンテナイメージによって、予測不可能な天候の影響を受ける、袋や樽、木枠、箱だらけの港のドックではなく、再現可能な環境である工場で荷物を積み込むことができます。 

Load applications at the factory, not the doc slide

この便利さには、いくつかの課題もあります。コンテナイメージの前は、Linux のほとんどのソフトウェアはパッケージ管理 (RPM または DEB) を使用して配布されていましたが、これは主に単一のアップストリーム・プロジェクトの配布に焦点を当てていました。これらのパッケージのビルダーやメンテナーは、パッケージ化するソフトウェアのオープンソース・ライセンス要件などの深い専門知識を持っています。さらに、Source RPM のようなツールを使用すると、特定のパッケージのソースコードと、そのソースコードのすべてのビルド手順を簡単にプルできるようになります。

コンテナは、さまざまなオープンソース・ライセンスを含め、多くのパッケージを単一のコンテナイメージに含めることで、これらのオープンソース・ライセンス要件をさらに複雑にします。オープンソースとコンテナの法的課題についての詳細は、Scott K Peterson の What's in a container image: Meeting the legal challenges を参照してください。

Red Hat Enterprise Linux 8.2 のリリースにより、パートナー、顧客、コミュニティが、Red Hat Universal Base Image (UBI) の一部であるバイナリコンテナイメージに対応するソースコンテナイメージを配布することで、これらのオープンソースの法的要件とガイドラインを満たすことが容易になっています。このテクノロジーにより、UBI ユーザーは工場での作業を Red Hat にオフロードできます。

Buildah と Skopeo のコンテナイメージ

ソフトウェアをコンテナイメージとしてパッケージ化すると、他のクリエーターは消費の方に集中して作業を始めることができます (Life in The Container - When it comes to code, be a consumer)。これは、アプリケーションの依存関係や、アプリケーションの作成に使用するツールにも当てはまります。摩擦を軽減し、可能なあらゆるユースケースで OCI 準拠のツールを実現するために、Red Hat は、Buildah、Skopeo、そして Podman (RHEL 8.3 での出荷を目標とする) などのコンテナツールのコンテナ化バージョンの開発に取り組んでいます。

RHEL 8.2 のリリースに伴い、Buildah および Skopeo 用のテクノロジー・プレビュー・コンテナイメージを提供しています。これらのイメージをご利用になり、フィードバックをお寄せください。その目標は、コンテナをすでに実行している任意の場所で他のアプリケーションを構築するために使用できるコンテナ化アプリケーションを一式提供することです。

UBI EULA への拡張

Red Hat Partner Connect プログラムのアプリケーション開発者は、Red Hat Enterprise Linux (RHEL) ユーザースペース・パッケージ (カーネル以外) のフルセットからコンテナ・アプリケーションを構築し、選択したコンテナレジストリを通じて再配布できるようになりました。これにより、UBI だけの場合にくらべてパッケージ数がほぼ 3 倍になります。

2019 年 5 月に Red Hat Universal Base Image (UBI) を導入したとき、当社は、Red Hat パートナーに、Red Hat プラットフォームと Red Hat 以外のプラットフォームの両方にデプロイできるかなりの数の RHEL パッケージを自由に使用し、再配布できるようにしました。これにより開発者は、Red Hat Enterprise Linux を基盤としてコンテナベースのソフトウェアを構築し、どこにでもデプロイできるようになりました。

これに関するフィードバックは圧倒的に肯定的なものが多く、それには感謝していますが、さらに多くの要望があることがわかったため、Red Hat パートナー向けのパッケージセットを拡張しています。併せて、『 Red Hat、コンテナの開発と Red Hat Enterprise Linux の再配布を単純化』もご参照ください。

まとめ

コンテナは Linux から始まります。Linux なしでアプリケーションをコンテナに配置したり、コンテナを実行したりすることはできないからです。Red Hat のコンテナは Red Hat Enterprise Linux で始まり、RHEL 8.2 の最新バージョンは、OpenShift 以降の基盤となる非常に多くの機能を提供します。

製品ドキュメントリリースノートEcosystem Catalog にある新しい UBI イメージなど、当社が提供するすべての新機能をぜひご覧ください。


About the author

Scott McCarty is technical product manager for the container subsystem team, which enables key product capabilities in OpenShift Container Platform and Red Hat Enterprise Linux. Focus areas includes container runtimes, tools, and images. Working closely with engineering teams, at both a product and upstream project level, he combines personal experience with customer and partner feedback to enhance and tailor strategic container features and capabilities.