3 年前、Red Hat Enterprise Linux 8 (RHEL 8) のリリースに伴い、Red Hat は アプリケーション・ストリーム と呼ばれる新しいコンセプトのコンテナツールを新たに提供しました。それを使用することで、RHEL ユーザーはコンテナの検索、実行、ビルド、共有が可能になりました。RHEL が Docker から Podman に移行した理由 (およびその過程) について、詳しくは RHEL 8、ソフトウェア・クラフトマンシップ・ツール搭載コンテナの実現 を参照してください。
前回のリリースでは、RHEL 9 への移行に必要な多くの基礎機能および性能を導入しました (Red Hat Enterprise Linux 8.5 コンテナツールの新機能)。
RHEL 9 リリースでも、Pod Manager (podman)、Buildah、Skopeo、Udica、CRIU などの Linux ユーティリティをベースとするコンテナツールを引き続き提供しています。RHEL 9 は、ジョブに最適だと確信できるツールを提供するという信念を引き継いでおり、コンテナユーザーは容易に RHEL 8 から RHEL 9 にアップグレードできます。この記事では、RHEL 9 でパッケージ化されたコンテナツールに関する最新テクノロジーと変更点を詳しく説明します。
RHEL 8.6 と RHEL 9.0 の変更点
まず、RHEL の背景情報を説明します。RHEL 8.6 および RHEL 9.0 は、いわゆる同期リリースです。ほぼ同時にリリースされ、RHEL 8 が 8.10 に達してメンテナンス・サポート・フェーズが始まるまで同期は継続します。その後、新機能を搭載して RHEL 9 に引き継がれます。その結果、ユーザーにはアップグレードするプラットフォームとウィンドウの両方で、約 2 年間の機能更新が提供されます。RHEL のライフサイクルは、アップグレードが容易になるよう意図的に設計されており、これはコンテナツールにも適用されます。
次の図は、RHEL 8 および RHEL 9 の同期バージョンを示しています。
-
RHEL 9 Alpha -> RHEL 8.4
-
RHEL 9 Beta -> RHEL 8.5
-
RHEL 9.0 GA -> RHEL 8.6
-
RHEL 9.1 -> RHEL 8.7
-
RHEL 9.2 -> RHEL 8.8
-
RHEL 9.3 -> RHEL 8.9
-
RHEL 9.4 -> RHEL 8.10
RHEL 8 と 9 を同期することでアップグレードが単純化され、Podman、Buildah、Skopeo のバージョンにも拡張されます。つまり、バージョンが変わっても、Podman、Buildah、Skopeo の高速かつ安定したバージョンが確保されます。たとえば、RHEL 8 と RHEL 9 における Podman の最新バージョンは同じになります。
RHEL 8 の場合
cat /etc/redhat-release Red Hat Enterprise Linux release 8.6 (Ootpa) [root@lance ~]# podman --version podman version 4.0.2
RHEL 9 の場合
cat /etc/redhat-release Red Hat Enterprise Linux release 9.0 (Plow) podman --version podman version 4.0.2
Podman などの重要なソフトウェアを RHEL のメジャーバージョン間で同期することでアップグレードが単純化されますが、それでも認識すべき変更点がいくつかあります。RHEL 8.X では、2 つのアプリケーション・ストリームをリリースしました。1 つは開発者に Podman、Buildah、Skopeo の最新バージョンへのアクセスを提供するストリーム、もう 1 つはオペレーションチームに 2 年間のサポートライフサイクルを提供する安定化ストリームです。
RHEL 8 アプリケーション・ストリーム
RHEL 8 で採用された手法にはいくつかの課題がありました。まず、RHEL 8 の導入時に想定していた安定化ストリームの普及が進まなかったことが挙げられます。ユーザーは Linux kernel や systemd をはじめとする最新の優れたオペレーティング・システム・ビットを使用する場合も、安定したコンテナ API (Podman) へのアクセスを必要としているという想定のもと、RHEL 8 では高速および安定化ストリームを導入しました。これはコンテナベースのオペレーティングシステムでは、常に望まれていたことです。
しかし、この想定は間違っていました。RHEL ユーザーが主に必要としていたのは、安定したコンテナツールストリームへのアクセスと RHEL 全体における 2 年間の延長アップデートサポート (EUS) です。RHEL 上でビルドするユーザーは、より長いライフサイクルでオペレーティングシステム全体へのアクセスを望んでいました。これを踏まえて、RHEL 9 ではコンテナツールのリリース方法を変更しました。
RHEL 9 Rolling Application Stream と EUS
RHEL 9 では、2 種つのコンテナーツール使用方法を提供しており、1 つは迅速性、もう 1 つは安定性を重視しています。Podman、Buildah、Skopeo の優れた最新バージョンへのアクセスを希望する開発者やユーザーは、最大で 12 週間ごと (RHEL 8 と同じ) にリリースされる アプリケーション・ストリーム を使用できます。設計上、このストリームは (RHEL 8 の速度が開発スピードが落ち着く 8.10 まで) RHEL 8 の高速ストリームとの同期が維持されるため、メジャーバージョン間のアップグレードやダウングレードを容易に行なえます。
RHEL 9 ユーザーが、セキュリティバックポートで 2 年間サポートされる安定化ストリームへのアクセスを必要とする場合、RHEL 延長アップデートサポート (EUS) を通してアクセスできますが、これは別のサブスクリプションとなります。設計上、RHEL 9 の EUS リリースにおけるコンテナツールの各バージョンは、RHEL 8 の対応する安定化ストリームとの同期が維持されます。その結果、ここでも RHEL 8 から RHEL 9 へのアップグレードが容易になり、Podman のバージョンが統一され、リグレッションが発生する可能性が低下します。
RHEL 8 は、引き続き当初の設計どおり提供される点に注意してください。RHEL 9 で使用される手法には変換されません。開発者、管理者、アーキテクトが安定化ストリームをベースとする RHEL 8 の導入を計画している場合、そのまま計画を続行してください。延長アップデートサポートは必要ありません。
また、RHEL 8.6 では container-tools:2.0 モジュールが非推奨になり、引き続きセキュリティパッチを使用するには新しいバージョン (3.0、4.0 など) に移行する必要がある点にも注意してください。詳細は、RHEL アプリケーション・ストリームのライフサイクル のページを参照してください。
アイデンティティ・マッピングの一元管理
ルートレス Podman は優れたテクノロジーです。システム上で通常プロセスが実行されるのと同じように非ルートユーザーとして実行することで、コンテナのセキュリティを高めることができます。つまり攻撃側は、まずコンテナの制御を破り、次にルートになる方法を解明する必要があり、追加のセキュリティレイヤーを突破しなければなりません。これは、HPC 環境下にある多くのノートブック/デスクトップ、さらには共有サーバー上の開発者にとっても有用です。
しかし、多数の RHEL ワークステーション、HCP ノード、共有サーバー上に存在する多くの非ルートユーザーを管理するために、管理者は各ノード上の /etc/sugid ファイルを手動で管理する必要があり、それは過去において非常に困難な作業でした。
しかし今後は違います。RHEL 9 では Identity Management (IdM) 機能が導入され、管理者は多数のユーザーおよび RHEL ノードでルートレス Podman を容易に管理できるようになりました。ユーザーは、subuids/subgids を 1 人のユーザーまたはディレクトリーサーバーの全ユーザーに割り当てることができます。これは非常に便利な機能です。詳細は、第 29 章:subID 範囲の手動管理 を参照してください。
コンテナストレージ用 NFS のサポート
前述したとおり、ルートレス Podman は優れた機能であり、多くの場合、管理者は多数のノード (ワークステーション、HPC、共有開発者サーバーなど) で多数のユーザーを管理しています。このような状況では、ユーザーは自分のデータを自分で持ち運びたいと考えます。たとえば、1 つのノードで「podman pull」を実行する場合、そのイメージをクラスタ内の全ノードで使用可能にしたいと考えるでしょう。通常のプロセスでこれを簡単に行うには NFS を使用しますが、これまで Podman/コンテナでは正常に動作しませんでした。
新機能の導入により、Podman は拡張属性 (xattrs) をサポートする任意の NFS サーバーにデータを保存できるようになりました。非ルート/ルートレスユーザーは、イメージを一度プルすれば、それをホームディレクトリが使用可能な任意の場所で使用できます。これは、ワークステーション、HPC ノード、さらには CI/CD を行う共有開発サーバーでも非常に有用な機能です。詳細は、アップストリーム記事: NFS 上でルートレス Podman を使用してコンテナを実行するための新機能 を参照してください。
Podman 4.0 の高度なネットワークスタック
Podman 4.X を搭載した RHEL 9 のリリースでは、新しいネットワークスタックを使用できます。また、IPv6 サポートの向上、複数ネットワークにおけるコンテナサポートの向上、パフォーマンスの向上など、新しい機能が付加されています。
その概要については、Podman 4.0 の新しいネットワークスタック:知るべき情報 を参照してください。
移植可能な証明書および署名コンテナ
RHEL 8.4 のリリースでは、業界でも最小および最速レベルのコンテナイメージである UBI Micro が導入されました (Red Hat の UBI Micro とは)。
RHEL 9 のリリースでは、このテクノロジーをベースとして、SSL 証明書要求の生成、SSL 証明書の検証、ファイルへの証明をはじめとする単純な暗号化ユースケースに使用できる、小規模な (1.25 MB) OpenSSL コンテナイメージを作成しました。
その結果、開発者は実稼働中も、デスクトップやノートパソコン上でも、信頼できる暗号化ユースケースを実行できる標準的な方法を獲得しました。すべての Red Hat Universal Base Image と同様に、ユーザーや開発者はこの新しい移植可能な証明書および署名コンテナを必要な場所で使用し、配布できます。
詳細は、Red Hat Ecosystem Catalog のリストを参照してください。
crun が RHEL 9.0 のデフォルトコンテナランタイムに
2020 年に、Red Hat のコントリビューターは OCI に準拠した高速かつ低メモリーの コンテナランタイム である crun を導入 しました。RHEL 9 では、crun がデフォルトのコンテナランタイムになります。crun と runc は、RHEL 9 のライフサイクルを通してサポートされます。
デフォルトを crun にすることで、管理者が実行する低いレベルでの設定タスクの多くが単純化され、パフォーマンスおよびメモリー使用率が改善し、さまざまな優れたユースケースが促進されます。詳細は、crun の概要:高速かつ低メモリーフットプリントのコンテナランタイム を参照してください。
RHEL 9 および Podman で Control Group v2 (cgroup 2) がデフォルトに
cgroup 2 プロジェクトの説明によると、cgroup 2 は「サーバー上のプロセスコレクションに対するリソースの配布を分離、測定、制御するメカニズムを提供する Linux カーネルコンポーネント」です。 これを使用することで、管理者およびインフラストラクチャ・ソフトウェア (例:コンテナエンジン や ランタイム) は、強力なメカニズムで任意のプロセスが使用するリソースを制限できます。これは、特にコンテナで有用な機能です。
cgroup 2 は、まず RHEL 8 でサポート対象になりましたが、ユーザーによる有効化と再起動が必要でした。RHEL 9 では、初期状態で cgroup 2 がデフォルトのメカニズムに設定されており、ルートレスコンテナをより緻密に制御できます (ファーストルック: Fedora 31 上のルートレスコンテナとcgroup v2)。cgroup 2 の概要については、RHEL 8 の cgroup による世界制覇:cgroups v2 の台頭 を参照してください。
まとめ
Podman 4.0.2 を搭載した RHEL 9.0 には、有用な新しいコンテナ機能が多数ありますが、その多くは RHEL 8.6 でも使用できます。コンテナツール・アプリケーション・ストリームの設計およびアーキテクチャは、優れた最新版に移行する場合にも、既存のインストールをさらに有効活用する場合にも適しています。
RHEL 9 では、引き続き Podman、Buildah、Skopeo の最新版にアクセスできますが、EUS 経由で安定化ストリームにもアクセスできるようになりました。ユーザーにとって、さらに使いやすい RHEL 9 を実現できているはずです。ぜひ、ご意見をお聞かせください。
フィードバック送信先:コンテナツール担当製品マネージャー Mark Russell (https://www.linkedin.com/in/marrusl/)、RHEL Server 担当製品マネージャー Scott McCarty (@fatherlinux)、テクニカルマーケティングマネージャー Eric Hendricks (@itguyeric)、または Red Hat Enterprise Linux の Twitter 公式アカウント (@rhel)。
執筆者紹介
At Red Hat, Scott McCarty is Senior Principal Product Manager for RHEL Server, arguably the largest open source software business in the world. Focus areas include cloud, containers, workload expansion, and automation. Working closely with customers, partners, engineering teams, sales, marketing, other product teams, and even in the community, he combines personal experience with customer and partner feedback to enhance and tailor strategic capabilities in Red Hat Enterprise Linux.
McCarty is a social media start-up veteran, an e-commerce old timer, and a weathered government research technologist, with experience across a variety of companies and organizations, from seven person startups to 20,000 employee technology companies. This has culminated in a unique perspective on open source software development, delivery, and maintenance.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit