Red Hat Enterprise Linux（RHEL）10で正式な選択肢となった「Image Mode（イメージモード）」は、OSそのものをコンテナイメージとしてビルドし、配布し、更新する仕組みです。アプリケーションの世界で当たり前になったコンテナのワークフローを、OSレイヤーにまで広げるものだと考えると分かりやすいでしょう。本記事では、Image Modeの仕組み、従来のパッケージモードとの違い、導入前に押さえるべき制約、そして評価から標準化へ進めるための現実的なステップを整理して解説します。
RHEL 10のImage Modeとは
Image Modeは、RHELを「ブータブルコンテナ（bootc）」として扱うデプロイ方式です。カーネル、initrd、ブートローダー、ファームウェアといった、通常のアプリケーションコンテナには含まれない起動に必要な要素までを含んだベースイメージ（registry.redhat.io/rhel10/rhel-bootc）を起点に、Containerfileで自社標準のOSを組み立てます。
できあがるのは、OCI準拠のコンテナイメージです。つまりPodmanでビルドし、コンテナレジストリに保管し、タグで世代を管理し、CI/CDパイプラインに乗せられます。そしてそのイメージを物理サーバー、仮想マシン、クラウドインスタンス、エッジデバイスに「OSとして」インストールして起動します。
ポイントは、運用フェーズでも同じイメージが主役であり続けることです。設定変更もパッケージ追加も、稼働中のサーバーに手を入れるのではなく、新しいイメージをビルドして差し替える。これがImage Modeの基本思想です。
なぜ今、Image Modeなのか
構成ドリフトという積年の課題
同じ手順書で構築したはずのサーバー群が、数年経つと少しずつ違うものになっている。緊急対応で入れた一時的な設定、担当者が個別に追加したパッケージ、適用タイミングのずれたパッチ。こうした差異の蓄積は「構成ドリフト」と呼ばれ、障害調査のコストを押し上げ、標準化を骨抜きにしてきました。
構成管理ツールによる「あるべき状態への収束」は有効な対策ですが、稼働中のシステムを変更し続ける以上、ドリフトの発生源そのものはなくなりません。Image Modeは発想を変えて、稼働中のシステムを変更可能な対象から外します。OSの中身はビルド時に確定し、その後は差し替えるだけ。同じイメージから起動したサーバーは、同じ状態であることが保証されます。
開発と運用で道具を揃えられる
もうひとつの利点は、アプリケーション基盤とOS基盤で使う道具が揃うことです。Gitでの変更管理、プルリクエストによるレビュー、パイプラインでのビルドとテスト、レジストリでの成果物管理、脆弱性スキャン。アプリケーション側で確立した仕組みを、そのままOSにも適用できます。監査対応の観点でも、「いつ、誰が、何を変更したイメージなのか」がGitの履歴とイメージのダイジェストで追跡できる意味は小さくありません。
パッケージモードとImage Modeの違い
従来のRPMベースのRHEL（パッケージモード）と比較すると、違いは次のように整理できます。なお、Image ModeはパッケージモードRHELを置き換えるものではなく、用途に応じて選択する並列の選択肢です。
| 観点 | パッケージモード（従来型） | Image Mode（bootc） |
|---|---|---|
| OSの構成単位 | RPMパッケージの集合 | OCIコンテナイメージ |
| 構築方法 | Kickstart＋構成管理ツール | Containerfileからビルド |
| 変更の適用 | 稼働中システムへdnf update等 | 新イメージをビルドし差し替え |
| 更新の単位 | パッケージ単位（部分更新） | イメージ単位（アトミック） |
| 切り戻し | スナップショットやバックアップから復旧 | 前世代へ再起動でロールバック |
| 成果物の管理 | 手順書・Playbook・RPMリポジトリ | コンテナレジストリ＋タグ／ダイジェスト |
| ファイルシステム | 全体が書き込み可能 | /usr等は読み取り専用、/etcと/varは書き込み可 |
| 適した用途 | 個別最適が必要なシステム、既存資産の継続運用 | 台数の多い定型サーバー、エッジ、標準化重視の基盤 |
Image Modeを構成する主要コンポーネント
rhel-bootcベースイメージ
すべての起点となるベースイメージです。Red Hatが提供・保守し、Red Hat Ecosystem Catalogから取得します。アプリケーション向けのUBI（Universal Base Image）との最大の違いは、起動に必要なカーネルやブートローダーなどを含んでいる点です。x86_64（x86-64-v2）と64bit ARM（ARMv8.0-A）向けが提供されています。
ライフサイクルを固定したい場合は、EUS（Extended Update Support）に対応したbootcベースイメージも用意されています。マイナーバージョンを止めて運用したい要件にも対応可能です。
bootcコマンド
レジストリからイメージを取得してシステムにインストールし、OSを更新し、必要に応じて前の世代へ戻すためのツールです。rhel-bootcイメージには標準で含まれています。従来のrpm-ostreeの後継にあたる位置づけで、Image Mode環境ではrpm-ostreeによる変更は行いません。
bootc-image-builder
ビルドしたbootcコンテナイメージを、各プラットフォーム向けのディスクイメージへ変換するツールです。qcow2、AMI、VMDK、RAW、ISOなど、配置先に応じた形式を生成できます。仮想化基盤やクラウドへ配るとき、あるいはネットワーク接続のない環境へインストールメディアとして持ち込むときに使います。
コンテナレジストリ
ビルド済みイメージの保管と配布を担います。閉域環境やオンプレミス中心の構成では、Red Hat QuayやRed Hat Satelliteをローカルレジストリとして利用する構成が一般的です。SatelliteはRed Hat Ecosystem Catalogからベースイメージをミラーし、Content Viewを通じて派生イメージを配布する使い方ができます（Satellite 6.17以降）。
ビルドからロールバックまでのライフサイクル
- 定義：Containerfileに、ベースイメージ、追加パッケージ、設定ファイル、セキュリティ設定を記述しGitで管理します。
- ビルド：PodmanまたはCI/CDパイプラインでイメージをビルドします。この段階でテストやコンプライアンススキャンを組み込めます。
- 配布：レジストリへpushし、タグやダイジェストで世代を識別します。追従先を示すチャネルタグ（
:stableなど）と、世代を固定するバージョンタグ（:v3など）を併用すると、追従と切り戻しの両方を扱いやすくなります。 - デプロイ：bootc-image-builderでディスクイメージへ変換して配置するか、Anacondaによるネットワークインストールで導入します。
- 更新：新しいイメージをビルドしてpushし、対象ホストで
bootc upgradeを実行します。更新はA/B方式で、新しい世代を用意したうえで再起動により切り替えます。 - 切り戻し：問題があれば
bootc rollbackで前世代へ戻します。前の世代はローカルに保持されているため、バックアップからの復旧は不要です。
更新がアトミックである点は、運用設計上とりわけ重要です。パッケージ単位の更新では「一部だけ適用された中途半端な状態」が起こり得ますが、Image Modeでは新しい世代への切り替えが成功するか、元の世代のまま起動するかのどちらかになります。
「取得・ステージ」と「適用」は別の工程
ここはパッケージ更新の感覚と最も食い違いが出るところです。bootc upgradeをフラグなしで実行すると、新しいイメージを取得して次回起動用の世代として「ステージ」しますが、稼働中のシステムはその時点では変わりません。取得・準備と、どの世代で起動するかの確定は、分かれた工程として扱われます。
bootc upgrade：レジストリを確認して取得し、次回起動用にステージするbootc upgrade --apply：ステージから起動反映、再起動までをまとめて実行するbootc upgrade --download-only：取得のみ行い、次回再起動でも適用しない状態で保持するbootc upgrade --from-downloaded：レジストリを再確認せず、取得済みの世代を適用する
メンテナンス時間帯の前にイメージだけ配っておき、当日に適用する、という運用は--download-onlyと--from-downloadedの組み合わせで実現できます。ステージ状態はbootc status --verboseで確認できます。
自動更新は既定で有効
Image Modeのシステムでは、自動更新が既定で有効になっています。systemdのタイマーユニットとサービスユニットが定期的にレジストリを確認し、新しいイメージがあれば取得・ステージ・再起動までを自動で行います。実体はbootc-fetch-apply-updates.timerと対応するサービスで、サービスが実行するのはbootc update --applyに相当する処理です。
変更管理のもとで計画的に更新を行う運用では、この既定のままでは意図しないタイミングで再起動が発生します。メンテナンス時間帯を定めた運用にする場合は、Containerfileの段階でタイマーを無効化しておくか、タイマーのスケジュールを自社の運用時間に合わせて上書きするのが実務的です。Red Hatのドキュメントにも、管理サービス側で更新タイミングを決める構成としてタイマーを無効化する例が示されています。
ロールバック後に起きること
bootc rollbackはブートローダーのエントリ順序を変更し、ロールバック対象の世代を次回起動に割り当てます。このとき、適用されていないステージ済みの変更は破棄されます。
注意が必要なのは、自動更新が有効なままの場合です。ロールバック完了後、更新タイマーが1〜3時間以内に動作し、たった今戻したはずのイメージへ自動的に更新して再起動してしまいます。障害対応で切り戻したのに元に戻ってしまう、という事態を避けるため、ロールバックを運用手順に含めるのであれば自動更新の制御は必須と考えてください。
追跡するイメージそのものを切り替える
bootc switchを使うと、システムが追跡するコンテナイメージの参照先自体を変更できます。動作としてはbootc upgradeと同じで、違いは追跡対象のイメージが変わる点だけです。切り替えを行っても/etcと/varの状態は保持されるため、ホストのSSH鍵やホームディレクトリは引き継がれます。
この仕組みは、一部のホストだけを新しいイメージ系統へ移すブルー／グリーン的な展開に応用できます。段階的ロールアウトを設計する際の基本要素になります。
実際の流れをコードで見る
Containerfileの例
FROM registry.redhat.io/rhel10/rhel-bootc:latest
# 標準パッケージの導入
RUN dnf -y install nginx firewalld chrony && \
dnf clean all
# 設定ファイルの投入
COPY etc/nginx/nginx.conf /etc/nginx/nginx.conf
COPY etc/chrony.conf /etc/chrony.conf
# サービスの有効化
RUN systemctl enable nginx firewalld chronyd
# セキュリティベースラインの適用（例：PCI-DSSプロファイル）
RUN dnf -y install openscap-utils scap-security-guide && \
oscap-im --profile pci-dss \
/usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml && \
dnf clean all注目したいのは、セキュリティベースラインの適用をビルド時に組み込める点です。CIS、PCI-DSS、STIG、HIPAAといったプロファイルや自社プロファイルをイメージに焼き込めるため、「構築後にハードニングを適用し、監査前に再確認する」という手順を、ビルドパイプラインの中に閉じ込められます。
ビルドとディスクイメージ化
# イメージのビルドとpush
podman build -t registry.example.com/base/rhel10-web:1.0 .
podman push registry.example.com/base/rhel10-web:1.0
# qcow2形式のディスクイメージを生成
sudo podman run --rm -it --privileged \
--security-opt label=type:unconfined_t \
-v /var/lib/containers/storage:/var/lib/containers/storage \
-v $(pwd)/output:/output \
registry.redhat.io/rhel10/bootc-image-builder:latest \
--type qcow2 \
registry.example.com/base/rhel10-web:1.0更新と切り戻し
# 現在の状態とステージ状況を確認
sudo bootc status --verbose
# メンテナンス時間帯の前に取得だけ済ませる
sudo bootc upgrade --download-only
# 当日、取得済みの世代を適用して再起動する
sudo bootc upgrade --from-downloaded --apply
# 取得から適用・再起動までを一度に行う場合
sudo bootc upgrade --apply
# 問題があれば前の世代へ戻す
sudo bootc rollback
sudo systemctl reboot
# 自動更新を止めてメンテナンス時間帯運用にする場合
sudo systemctl disable --now bootc-fetch-apply-updates.timer導入前に押さえておきたい制約と注意点
Image Modeは強力ですが、従来の運用習慣がそのまま通用しない領域があります。評価の初期段階でつまずきやすいポイントを挙げます。
稼働中のシステムに直接パッケージを追加できない
/usrをはじめとする主要な領域は読み取り専用です。書き込み可能なのは/etcと/varに限られます。「とりあえず本番サーバーでdnf installして様子を見る」という対応は成立しません。必要なものはビルド時に組み込む前提で、標準イメージの設計と変更フローを最初に決めておく必要があります。
初期ユーザーと認証情報の設計が必須
ベースイメージにはデフォルトユーザーが含まれません。ログイン手段を用意せずにデプロイすると、起動したサーバーに入れない状態になります。bootc-image-builderの--configオプションでユーザーとSSH鍵を注入する、cloud-initやIgnitionで初回起動時に構成する、といった方法をあらかじめ選定してください。
Containerfileの一部命令はOS起動時の挙動を規定しない
ENTRYPOINT、CMD、ENV、EXPOSE、USERといった命令は、あくまでコンテナランタイムで実行する際の設定です。OSとして起動したシステムの挙動は、systemdのユニット設定、ファイアウォール設定、サービスの実行ユーザー設定で制御します。アプリケーションコンテナと同じ感覚で書くと意図した結果になりません。
レジストリ認証情報の置き場所がPodmanとは異なる
認証が必要なレジストリからOSの更新を取得する場合、bootcはPodmanとは別の場所にある認証情報ファイルを参照します。具体的には/etc/ostree/auth.jsonなどで、podman loginが書き込む場所とは異なります。
これは設計上の理由によるものです。Podmanが受け付ける認証情報の場所は/run配下と/root配下にありますが、前者は再起動で消え、後者はrootのホームディレクトリという可変領域に属します。いずれもシステムサービスが恒久的に参照する先としては適していません。手元ではpodman pullできるのにbootc upgradeだけ認証エラーになる、という状況はこの違いから生じます。
Red Hatのドキュメントでは、共通の永続ファイルをイメージに埋め込み、bootc側とPodman側の双方からシンボリックリンクで参照させることで認証情報を一元化する方法が示されています。プライベートレジストリを使う構成では、この設計を最初に決めておく必要があります。
bootc-image-builderはローカルストレージを参照する
bootc-image-builderはリモートレジストリから自らイメージを取得しません。ディスクイメージを生成する前に、対象イメージをローカルのコンテナストレージに用意し、そのストレージをマウントして実行する必要があります。またリポジトリ設定はホスト側のものではなく、ビルドするコンテナイメージ内に持たせる必要があります。閉域環境での構成では特に注意が必要な点です。
提供形態とサポートステータスの確認
RHEL 10ではキックスタートにbootcコマンドが追加され、Anacondaを使ったネットワークインストールからbootcイメージを直接導入できるようになりました。一方で、bootc-image-builderでブート可能なISOを作成するAnaconda／キックスタートのワークフローについては、テクノロジープレビューとして提供される旨の記載があります。テクノロジープレビュー機能はサポートSLAの対象外で本番利用は推奨されません。採用を検討する構成が正式サポート対象かどうかは、必ず最新の製品ドキュメントで確認してください。
サードパーティ製ソフトウェアの取り扱い
ドライバや監視エージェント、バックアップエージェントなど、外部ベンダーのソフトウェアはImage Mode環境での動作が前提になっていない場合があります。カーネルモジュールを伴うものは特に検証が必要です。加えて、rhel-bootcおよびそれを基に作成したイメージはRHELのEULAの対象であり、公開の場での再配布はできません。社内レジストリでの管理を前提に設計してください。
向いているシステム、慎重に判断すべきシステム
相性が良いケース
- 同一構成のサーバーを多数展開するWeb／APサーバー基盤
- 拠点・店舗・工場などに分散配置するエッジシステム（現地作業を最小化したい用途）
- 構成の証跡とハードニング状態の維持が求められる、規制対応が厳しい基盤
- 既にコンテナとCI/CDを実践しており、OSにも同じ運用を広げたい組織
- 短時間で環境を再現したい検証・開発用のサーバー群
慎重に判断すべきケース
- サーバーごとに構成が大きく異なり、個別のチューニングが前提のシステム
- 運用中の手動変更を許容する前提で業務プロセスが組まれている環境
- Image Mode対応が未確認のサードパーティ製品に依存しているシステム
- デスクトップ／ワークステーション用途
なお、RHEL 10ではRHEL image builderによるRHEL for Edge（OSTree）向けイメージのビルドが提供されなくなりました。エッジ向けの構成はImage Modeへの移行が想定される流れになっているため、RHEL for Edgeを利用中の環境では移行計画の検討が必要です。
Satellite・Insights・Ansible Automation Platformとの連携
Image Modeの価値は、単体の機能よりも「適用から運用までを一本の流れにできるか」で決まります。Red Hatのポートフォリオと組み合わせた場合、次のような役割分担が考えられます。
| コンポーネント | 担う役割 |
|---|---|
| Git／CI/CD | Containerfileの変更管理、レビュー、自動ビルドとテスト |
| Red Hat Quay／Satellite | イメージの保管・配布、脆弱性スキャン、ライフサイクル管理 |
| Red Hat Insights | Image Modeホストの可視化、更新タスクの実行、コンプライアンス確認 |
| Ansible Automation Platform | ビルドから配布、更新適用、再起動までの一連のワークフロー化 |
| Terraform等のIaC | 生成したディスクイメージを用いたインフラのプロビジョニング |
特にAnsible Automation Platformとの組み合わせは実務上の効果が大きい領域です。Containerfileの変更をトリガーに、ビルド・検査・push・対象ホストへの更新適用・再起動までをワークフローとして定義すれば、「イメージを作る」と「本番に行き渡らせる」の間にある人手の工程を圧縮できます。Image Mode単体では個々のサーバーの更新手段が提供されるだけであり、台数分の適用順序、メンテナンス時間帯の制御、失敗時の切り戻し判断といった運用の組み立ては別途必要になるためです。
評価から標準化へ進めるステップ
- 小さく試す：クラウド上の仮想マシン1台で、ベースイメージのビルドからデプロイ、更新、ロールバックまでを一巡させます。この段階で認証情報の注入方法とストレージ構成の癖を把握できます。
- 自社標準イメージを設計する：共通で必要なパッケージ、監視・バックアップエージェント、セキュリティベースライン、時刻同期、ログ転送設定を洗い出し、階層化したイメージ構成（共通ベース＋用途別）を定義します。
- 既存ツールとの接続を確認する：サードパーティ製エージェントの動作、レジストリ／閉域環境での配布経路、Satelliteとの連携を検証します。ここが実質的な採否の分岐点になります。
- 運用フローを自動化する：ビルドから更新適用までをパイプラインとワークフローに載せ、承認・メンテナンス時間帯・切り戻し手順を含めて設計します。
- 適用範囲を広げる：新規構築案件から適用を始め、既存システムは更改タイミングに合わせて段階的に移行します。全面移行を前提にしないことが現実的です。
よくあるご質問
Image Modeを使うために追加のサブスクリプションは必要ですか
Image ModeはRHELの機能として提供されるものです。ベースイメージもRHELの一部として扱われます。ただし、SatelliteやAnsible Automation Platform、Quayなどを組み合わせる場合は、それぞれの製品のサブスクリプションが必要です。構成に応じた要否は個別にご確認ください。
既存のパッケージモードのRHELから変換できますか
稼働中のパッケージモードのシステムを、その場でImage Modeへ切り替える手段が用意されています（system-reinstall-bootcなど）。切り替え後は従来のルートファイルシステムが/sysroot配下へ退避されるため、旧環境のデータや追加マウントをどう引き継ぐかを事前に設計しておく必要があります。対象システムの構成や利用しているソフトウェアによって成否が分かれるため、実務上は新規構築時にImage Modeを選択し、既存システムは更改タイミングで移行する進め方が無理のない選択です。
アプリケーションのデータはどこに置きますか
書き込みが発生するデータは/var配下、または別途マウントした永続領域に配置します。イメージの差し替えで消えてしまう場所にデータを置かない設計が前提です。ステートフルなミドルウェアを載せる場合は、データ領域の分離設計を最初に固めてください。
アプリケーションコンテナも一緒に管理できますか
OSイメージのライフサイクルに紐付けてアプリケーションコンテナを配布する仕組み（論理的にバインドされたイメージ）が用意されています。bootc upgradeの実行時には、新しいベースイメージからバインドされたイメージが検出され、bootcが管理するストレージへ自動的に取得されたうえでPodmanなどのコンテナランタイムから利用できる状態になります。OSとアプリケーションの版数を揃えて配布したいエッジ用途などで有効です。
まとめ
RHEL 10のImage Modeは、OSを「運用しながら育てる対象」から「ビルドして差し替える成果物」へと位置づけ直す仕組みです。構成ドリフトの抑制、アトミックな更新と確実な切り戻し、監査に耐える証跡といった効果が期待できる一方、稼働中の直接変更ができない、初期ユーザー設計が必須、サードパーティ製品の検証が必要といった前提の転換も伴います。
重要なのは、機能を単体で評価するのではなく、標準イメージの設計と、ビルドから配布・適用までの運用の流れをセットで組み立てることです。ここが整理できていれば、Image Modeは標準化を確実に前へ進める仕組みになります。
サイオステクノロジーでは、Red Hat製品のディストリビューターとして、Image Modeの適用検討からAnsible Automation Platformと組み合わせた運用設計まで、導入の各段階をご支援しています。評価環境の構築や標準イメージの設計についてのご相談も承ります。
参考資料
- Image Mode for RHEL を使用したオペレーティングシステムの構築、デプロイ、管理（Red Hat Documentation）
- Managing RHEL bootc images（更新・ロールバックなどDay-2運用／Red Hat Documentation）
- RHEL 10 Bootc Base Image（Red Hat Ecosystem Catalog）
- Image mode for Red Hat Enterprise Linux is generally available（Red Hat Blog）
本記事の内容は公開時点の情報に基づいています。製品の仕様およびサポート状況は変更される場合がありますので、最新情報はRed Hatの公式ドキュメントをご確認ください。
