rpm-ostreeからbootcイメージベースOSへの移行判断｜パッケージ互換とロールバック設計

rpm-ostreeとbootcの技術的な位置づけ

rpm-ostreeは、OStreeをバックエンドにしてRPMパッケージ管理を重ねる仕組みです。Fedora Silverblue・Fedora CoreOS・RHEL CoreOSといった「イミュータブルOS」系ディストリビューションで長らく採用されてきました。ベースイメージはアトミックに更新され、追加パッケージは「レイヤー」として差分管理されます。このモデルにより、OSそのものをコード管理しやすくなった反面、レイヤーが積み重なると再ベース時の互換性確認が煩雑になるという課題が現場でよく聞かれます。

これに対してbootcは、OCI準拠のコンテナイメージをそのままOSのデプロイ単位として扱う設計です。Containerfile（Dockerfile互換）でOSイメージをビルドし、レジストリに push して、対象ホストで bootc switch または bootc upgrade を実行するだけで切り替えられます。Podman・Buildahと同じビルドパイプラインに乗れるため、CI/CDとの親和性が高い点が注目されています。2024年後半からFedora/CentOS StreamのTechnology Previewが進み、2025〜2026年にかけてRHEL系での正式サポートが広がっています。

どちらも「OSをアトミックに更新する」という思想は共通ですが、差分管理の単位がOStreeコミットかOCIレイヤーかという点で根本的に異なります。移行を判断するにあたっては、この違いが運用フローのどこに影響するかを把握しておく必要があります。

移行を検討すべき運用シナリオ

すべての環境でbootcへの移行が望ましいわけではありません。現場でよく見られるのは次のようなケースです。

• Kubernetes/OpenShiftのノードイメージをアプリコンテナと同じレジストリ・同じCIパイプラインで一元管理したい
• rpm-ostreeのレイヤー数が増えすぎ、再ベース（rpm-ostree rebase）のたびに依存関係エラーが出て運用コストが高騰している
• GitOps的にOSイメージのバージョン管理を行い、特定のダイジェスト（SHA256）にいつでも戻せるピン管理を実現したい
• エッジデバイス・工場ライン等で完全オフライン・エアギャップ環境でのOSデプロイが必要で、レジストリミラーだけで完結させたい

逆に、レイヤーが少なく安定運用できているFedora Silverblue環境や、rpm-ostreeのデスクトップユースケースでは、あえて移行するメリットが薄い場合もあります。移行判断は「現状の課題を解決するか」を起点にするのが妥当です。

パッケージ互換性の事前確認

rpm-ostreeでは rpm-ostree status でベースコミットと追加レイヤーの一覧を確認できます。移行前にまずこの出力を保存しておきます。

rpm-ostree status --json | tee ~/ostree-snapshot.json

追加レイヤーとして入っているパッケージ群（requested-packages・requested-local-packages）が、bootcベースイメージの Containerfile でどう扱われるかを確認します。bootcイメージはあくまでコンテナイメージなので、追加パッケージはすべて RUN dnf install -y ... の形でイメージビルド時に焼き込む必要があります。rpm-ostreeのレイヤー方式のように「ベースを変えても追加だけ保持」という仕組みは存在しないため、ここが最初の互換性チェックポイントになります。

確認手順としては次の流れが有効です。

1. rpm-ostree status の requested-packages をリスト化する
2. ターゲットのbootcベースイメージ（例: quay.io/centos-bootc/centos-bootc:stream9）をローカルにpullし、podman run --rm -it <image> dnf list available で各パッケージが存在するか確認する
3. 存在しないパッケージについて、COPR・サードパーティリポジトリ追加が必要かどうかを調べる
4. SELinuxポリシーやsystemdユニットファイルの持ち込みが必要な場合は、Containerfile内で COPY・RUN semodule -i の手順を組み込む

特にRHEL/CentOS Stream環境でのリポジトリ有効化には注意が必要です。bootcイメージのビルド時に subscription-manager や dnf config-manager でサブスクリプション・リポジトリを有効化する処理をCI環境でどう扱うかは、事前にセキュリティポリシーと突き合わせておく必要があります。

bootcへの実際の移行手順

前提として、移行元ホストは bootc パッケージがインストール済みである必要があります。Fedora CoreOS 40以降・CentOS Stream 9（bootc拡張版）では標準で含まれています。rpm-ostree環境でbootcパッケージ自体が存在しない場合は、まず rpm-ostree install bootc でレイヤー追加してから再起動します。

移行の核心は bootc switch コマンドです。

# 移行先イメージを指定してスイッチをステージング
sudo bootc switch quay.io/myorg/myos:latest

# ステージング状態の確認
bootc status

# 再起動で適用
sudo systemctl reboot

bootc switch は即時再起動を行わず、次回起動時に新イメージが適用される「ステージング」方式を採っています。bootc status で staged フィールドに移行先イメージのダイジェストが表示されていれば、ステージングは成功です。再起動前であれば bootc switch を別のイメージ名で再実行してキャンセル・上書きができます。

本番環境での適用は、メンテナンスウィンドウ内での再起動と組み合わせるのが一般的な運用です。複数台のノードにロールアウトする場合は、Ansibleプレイブックで bootc switch 実行→ステータス確認→再起動という順序を組むと、ロールアウトの進捗管理が容易になります。

ロールバック設計と検証

bootcはOStreeの二重ブート構造を継承しており、直前のイメージは自動的に「rollback slot」に保持されます。起動後に問題が発生した場合は次のコマンドで即座に戻せます。

# ロールバックをステージング
sudo bootc rollback

# 再起動で旧バージョンへ
sudo systemctl reboot

ロールバックスロットが保持するのは直前の1世代のみです。rpm-ostreeが複数の「デプロイメント」エントリをGRUBメニューに持つのと異なり、bootcは現行+直前の2スロット構成が基本です。このため、「2世代前に戻したい」という要件がある場合はレジストリ上のダイジェストを指定して bootc switch を再実行する形で対応します。イメージのダイジェストをタグとは別に管理・記録しておくことが運用上の重要なポイントになります。

移行後の検証項目としては以下が最低限のチェックリストになります。

• bootc status で booted フィールドが移行先イメージのダイジェストを示しているか
• systemdの重要ユニット（systemctl --failed）でエラーが出ていないか
• SELinuxが Enforcing のまま維持されているか（getenforce）
• 追加インストールしたパッケージ・カスタム設定ファイルが正しく配置されているか
• アプリケーションコンテナの再起動・動作確認

特にSELinuxのコンテキストずれはブート後しばらく経ってから症状が出ることがあるため、移行直後だけでなく翌日のaudit.logも確認する習慣が現場では推奨されています。

2026年現行環境での選択指針と注意点

2026年9月時点の状況を整理すると、Fedora CoreOS 41以降ではbootcが実質的に主経路となり、rpm-ostreeとの並存期間はしばらく続くものの、新機能開発の重心はbootcに移っています。RHEL 9.xではbootcがGA（一般提供）に到達しており、RHEL CoreOSとの統合も進んでいます。CentOS Stream 9はbootcイメージの公式提供が行われており、quay.io/centos-bootc のイメージを起点にカスタムイメージをビルドする構成が現実的な選択肢となっています。

rpm-ostreeが引き続き有効な場面もあります。Fedora Silverblueのようなデスクトップ用途では、Flatpak・レイヤーパッケージの柔軟な管理が依然として運用しやすく、bootcへの全面移行が必須というわけではありません。一方、サーバー・エッジ・クラスターノードの用途では、OCIイメージの標準エコシステムに乗れるbootcの優位性が高まっています。

移行コストの観点では、既存のrpm-ostreeレイヤーが少ない環境ほど移行は容易です。レイヤーが10を超えるような環境では、Containerfileへの再整理に一定の工数が必要になります。その作業は単なる移行コストではなく、「OSの構成をコードとして明文化する」機会でもあるため、長期的な運用改善の文脈で捉えると取り組みやすくなります。

移行判断の結論としては、新規構築・大規模再構築のタイミングであればbootcへの移行を積極的に検討する価値があります。既存の安定稼働環境に対してはrpm-ostreeのまま継続運用し、次のOSメジャーバージョンアップ時にbootcへ切り替えるというアプローチが、リスクと運用負荷のバランスとして現実的です。