bootcで構成するイミュータブルLinuxサーバ運用｜コンテナイメージ型OS更新の段階ロールアウトとロールバック設計

なぜイミュータブルOSが運用現場に広がり始めたのか

従来のLinuxサーバ運用では、yum updateやapt upgradeを定期実行し、パッケージを上書き更新するのが標準でした。この方式には「動いている環境と再構築した環境が一致しない」「どのパッケージがいつ、誰の手で変更されたか追いにくい」という根本的な問題があります。特に複数台構成のサーバ群では、長期運用後に個体差（スノーフレーク化）が生じ、障害対応のたびに調査コストが膨らむ状況が多くの現場で報告されています。

この課題へのひとつの解答が、イミュータブルOS（変更不可OS）です。システムパーティションを読み取り専用にして実行時の意図しない変更を防ぎ、更新はイメージの丸ごと差し替えで行います。Fedora CoreOSやFlatcar Container Linuxといった先行実装が知られていましたが、2024年以降に注目を集めているのがbootc（Boot from Container）です。bootcはOCIコンテナイメージをそのままOSのブートイメージとして扱う設計で、既存のコンテナビルドパイプラインをOS管理に流用できる点が運用担当者の関心を引いています。

bootcのアーキテクチャ：OCIイメージがOSになる仕組み

bootcの核心は、ostree（Gitに近い差分管理構造を持つOSファイルシステムライブラリ）とOCIレイヤーの統合にあります。ビルド済みのコンテナイメージをレジストリにpushし、対象サーバ上でbootc upgradeを実行すると、ostreeがイメージのdiffレイヤーを取得してローカルに展開します。次回ブート時に新しいルートファイルシステムへ切り替わり、古いOSツリーはGRUBメニューに残ります。

重要な点は、ランタイム時のシステムパーティションは読み取り専用であることです。アプリケーションの設定や永続データは/etc（3-wayマージで管理）と/varに分離されます。コンテナイメージに含まれる/etcの変更と、ローカルで加えた変更はostreeが自動的にマージ処理するため、慎重な運用が必要です。

2026年現在、bootcが動作する主な環境は以下のとおりです。

• RHEL 9.4以降 / CentOS Stream 9・10：bootcパッケージが公式リポジトリに含まれ、bootc-image-builderでディスクイメージを生成できます。
• Fedora 40以降：Fedora CoreOSとbootcが並立する形で提供。Fedora IoTもbootcベースに移行中です。
• Universal Blue派生イメージ（Bazzite・Aurora等）：デスクトップ向けが先行していますが、サーバ構成のカスタムイメージも事例が増えています。

段階ロールアウトの設計とbootc upgradeの実行フロー

コンテナイメージ型の更新はイメージタグで世代管理できるため、カナリアデプロイと相性が良い設計です。典型的な段階ロールアウトは次の流れで構成します。

1. イメージのビルドとタグ戦略

Dockerfileと同様のContainerfileでOSイメージを記述します。ベースイメージにはregistry.access.redhat.com/ubi9/bootcやquay.io/fedora/fedora-bootc:40を使い、必要なパッケージやsystemdユニット、設定ファイルをレイヤーに積みます。CIでビルドしたイメージには:stable・:canary・:YYYYMMDDの3タグを付与するのが現場でよく見られるパターンです。

2. canaryグループへの適用

対象サーバ上で参照イメージを変更するにはbootc switchを使います。

# canaryノードでのイメージ切り替え
bootc switch registry.example.com/myos:canary
# 即時再起動して新ツリーを有効化
systemctl reboot

bootc switchは参照先レジストリURLそのものを変更します。同じレジストリの別タグへ移る場合も、このコマンドで対応できます。

3. stableグループへの展開

canaryグループでの動作確認後、stableタグをcanaryと同じダイジェストに上書きpushします。各サーバではbootc upgradeを実行すると、参照先タグの最新ダイジェストを取得して次回ブート用ツリーとして準備します。

# stableタグ更新後、各サーバで実行
bootc upgrade
# --apply オプションで再起動まで一括実行（自動化向け）
bootc upgrade --apply

Ansibleやsystemdタイマーを使ってbootc upgrade --applyをメンテナンス時間帯に分散実行するパターンが、2025〜2026年の事例では主流になりつつあります。

ロールバック設計：ostreeとGRUBによる確実な切り戻し

bootcのロールバックはostreeのデプロイメント管理を直接利用します。更新前のOSツリーはデフォルトでローカルに保持されており、コマンド一発で切り戻せます。

# 現在のデプロイメント一覧を確認
bootc status
# 直前のデプロイメントに切り戻し（次回ブートで有効）
bootc rollback
systemctl reboot

bootc statusの出力ではbooted（現在）とstaged（次回ブート予定）、rollback（直前世代）の3状態が確認できます。ネットワーク障害などでレジストリに到達できない状況でも、ローカルに保持されたツリーへのロールバックは問題なく実行できます。

ostreeは通常2世代のデプロイメントを保持します。3世代以上前へのロールバックが必要な場合は、レジストリ側のイメージダイジェストで特定バージョンを指定してbootc switchする手順を用意しておくと安全です。

# ダイジェスト指定で特定バージョンに固定
bootc switch registry.example.com/myos@sha256:abc123...

このダイジストをCI/CDの成果物として記録しておけば、「3週間前の状態に戻す」という要件にも対応できます。イメージタグは可変ですが、ダイジェストは不変である点が運用上の重要な特性です。

本番適用前に確認すべき注意点と検証フロー

bootcへの移行・運用で現場がつまずきやすいポイントを整理します。

/etc の3-wayマージ挙動を把握する

ostreeはイメージ側の/etc変更とローカルの/etc変更をマージしますが、同一ファイルに競合がある場合はローカル変更が優先されます。Ansible等で/etcを直接管理している構成では、イメージ更新後に意図しないファイル残存が起きることがあります。設定ファイルはできる限りイメージに含め、ローカル変更を最小化する方針が安全です。

SELinuxラベルの再付与タイミング

イメージに含まれるファイルのSELinuxコンテキストはビルド時に設定されますが、初回起動時に/.autorelabelが存在するとシステム全体の再ラベル付けが走り、起動時間が延びます。新規イメージビルド後の初回テスト起動では、この挙動を見込んだ余裕を持ちます。

カーネルパラメータとドライバモジュールの検証

カーネルはイメージに含まれます。ハードウェア固有のドライバやkmodをイメージ外で管理していた場合、更新後に認識されなくなるケースがあります。特にGPU・InfiniBandドライバを使うワークロードでは、カーネルバージョンとドライバモジュールの組み合わせをイメージビルド時に固定する手順が必要です。

検証フローの推奨構成

• CI段階：bootc-image-builderでqcow2イメージを生成し、KVM/QEMUで自動起動テストを実施
• ステージング：本番同等の構成でcanaryノード1台に適用、監視メトリクスを24時間観察
• 本番展開：Ansibleのrolling_updateやsystemdタイマーの時差実行で段階適用
• 完了判定：bootc statusの全台確認と、アプリケーションヘルスチェック通過をもって確定

2026年現行環境の差分と今後の見通し

2024年時点ではbootcは「技術プレビュー」扱いのディストリビューションが多い状況でしたが、2025年後半から2026年にかけて状況が変わっています。

RHEL 10 / CentOS Stream 10の正式サポート

RHEL 10ではbootcがサポート対象のOS管理手法として文書化されており、bootc-image-builderも同梱されています。エンタープライズ環境での採用障壁が大きく下がりました。RHELのサブスクリプション管理（subscription-manager）はbootcイメージにも組み込めますが、レジストリ認証とサブスク認証の2系統を整理しておく必要があります。

podman quadlet との連携

イミュータブルOSとコンテナアプリケーションの組み合わせでは、podman quadlet（systemdユニットとしてコンテナを管理する仕組み）との相性が良好です。アプリレイヤーはquadletで管理し、OSレイヤーはbootcで管理するという責務分離が、2026年現在の実践的な構成として定着しつつあります。

Kubernetes Node管理への応用

OpenShiftのMachine Config Operatorがbootcと統合される動きも進んでいます。ノードOSをbootcイメージで管理することで、クラスタ全体のOSバージョンをCIパイプラインで一元管理する構成が実用段階に入っています。

bootcはまだ新しい技術であり、すべての運用環境に即時適用できるわけではありません。ただ、「OSをコードとして管理し、更新を冪等な操作にする」という方向性は、コンテナ・Infrastructure as Codeが普及した現在の運用観と整合しています。まずはステージング環境での試験運用から始め、チームのノウハウを蓄積していくアプローチが、リスクを抑えながら移行を進める現実的な道筋です。