openSUSE MicroOSをコンテナホストに採用する段階移行と自動更新失敗時のロールバック設計

なぜ MicroOS をコンテナホストに選ぶのか

コンテナワークロードを安定稼働させるうえで、ホスト OS 側の変動をできる限り排除したいという要求は、多くの運用現場で共有されています。openSUSE MicroOS はそのニーズに応えるイミュータブル Linux の一実装で、読み取り専用のルートファイルシステムと原子的なトランザクション更新を組み合わせた設計が特徴です。

従来の汎用ディストリビューションでは、zypper update や apt upgrade を実行した直後からパッケージが混在状態になり、「更新前」への完全な巻き戻しが困難でした。MicroOS は更新をスナップショット単位で管理し、起動時に適用するかどうかを選択できます。更新後に問題が発生した場合も、再起動時に前のスナップショットを選ぶだけで確実に戻せるため、コンテナホストとしての「変わらない土台」を維持しやすくなっています。

また MicroOS は Podman をデフォルトの OCI ランタイムとして採用しており、デーモンレス構成によるセキュリティ上のメリットも継承されています。Kubernetes ノードとして使う場合は containerd に切り替えるパターンも一般的で、2026 年時点では Podman 5 系と containerd 2 系の両系統が実務で使われています。

段階移行の設計思想と進め方

既存の汎用 openSUSE Leap や他ディストリから MicroOS へ一斉切り替えするのは現実的ではありません。多くの現場では「新規プロビジョニングした MicroOS ノードにコンテナワークロードをひとつずつ移す」という段階移行が採用されています。

段階移行を設計する際に押さえておきたい点は以下のとおりです。

• ステート管理の分離：コンテナデータや設定は /var 以下か外部ストレージに置く。ルートパーティションはあくまでイミュータブルに保つ。
• プロビジョニング方法の統一：MicroOS は Combustion（シェルスクリプト）または Ignition（JSON 設定）で初回起動時の構成を注入できる。既存の Ansible などと組み合わせる場合は、第 1 回起動でユーザー追加・SSH 鍵投入だけを Combustion に任せ、その後の設定管理を Ansible に引き渡す二段構えが安定しやすい。
• 旧ノードとの並走期間の設定：DNS や L4 ロードバランサのウェイトを徐々に新ノード側に振り向け、問題なければ旧ノードを解体する。期間の目安は 1 ワークロードあたり最低 1 週間のオブザーバビリティを確保することが推奨されています。

Combustion スクリプトの配置は USB または ISO イメージ内の /combustion/script が基本形で、クラウド環境では user-data として渡せる事業者も増えています。

transactional-update の動作と自動更新の仕組み

MicroOS の更新は transactional-update コマンドが担います。内部では Btrfs のスナップショットを作成し、その中で zypper を実行してパッケージを更新します。更新後のスナップショットはデフォルトでは「次回起動時に適用」となり、現在稼働中のシステムには即時影響しません。

自動更新は transactional-update.timer（systemd タイマー）によって制御されており、デフォルトでは日次で動作します。更新完了後に自動再起動させるかどうかは /etc/transactional-update.conf の REBOOT_METHOD で設定します。代表的な値として auto（即時再起動）・systemd（systemd の scheduled-reboot を利用）・none（手動再起動）の 3 種があります。

コンテナホスト用途では、実行中のコンテナを安全に停止してから再起動したいケースが大半です。その場合は REBOOT_METHOD=systemd と組み合わせ、メンテナンスウィンドウに systemctl reboot を投入する運用が適しています。また transactional-update dup でディストリビューションバージョン跨ぎのアップグレードも行えます。

Btrfs スナップショットによるロールバック設計

MicroOS のロールバック基盤は Btrfs と Snapper の組み合わせです。transactional-update が更新を行うたびにスナップショット番号が増分され、snapper list で一覧を確認できます。Snapper は自動的に古いスナップショットを削除するクリーンアップポリシーも持っており、デフォルトでは直近 10 世代程度が保持されます。

設計上のポイントは「何世代保持するか」と「/var をスナップショット対象から外す」の 2 点です。

MicroOS のサブボリューム構成では @/.snapshots がスナップショット格納先、@/var が書き込み可能な領域として分離されており、コンテナイメージや Podman の設定（/var/lib/containers）はスナップショットに巻き込まれません。つまり OS レイヤーをロールバックしてもコンテナデータはそのまま残ります。これは運用上大きな安心材料で、OS の問題だけを切り離してロールバックできます。

ただし、カーネルモジュールやランタイムのバージョンと、実行中のコンテナイメージが組み合わせ上の非互換を起こす可能性はゼロではありません。ロールバック後はコンテナの動作確認を自動ヘルスチェックで補うことを推奨します。

自動更新失敗時のロールバック手順

自動更新が何らかの理由で失敗した場合、MicroOS は health-checker によって起動直後に異常を検知し、前のスナップショットへ自動的にロールバックします。health-checker は systemd サービス群の起動状態を確認し、失敗ユニットが閾値を超えた場合に snapper rollback を呼び出す仕組みです。

手動でロールバックが必要な場面では、GRUB のブートメニューからスナップショットを直接選択する方法が最もシンプルです。GRUB 起動時に「openSUSE MicroOS Snapshots」エントリが展開でき、番号ごとのスナップショットを選んで起動できます。これは SSH すら届かない状況でも適用できるため、物理・クラウドを問わずコンソールアクセスがあれば使えます。

SSH が届く状況であれば、以下の手順で特定スナップショットへのロールバックを宣言できます。

# スナップショット一覧を確認
snapper list

# 番号を指定してロールバックを宣言（次回起動時に適用）
snapper rollback <番号>

# 再起動して適用
systemctl reboot

ロールバック宣言後に再起動すると、指定スナップショットが新しい「現在」として設定され、以降の更新はそのスナップショットを起点に積み重なります。ロールバック先スナップショットの番号は snapper list の「Important」列や Description 欄に記録されているため、問題発生時刻と照合して選択します。

2026 年現行環境での注意点と運用差分

2026 年時点で実務に影響する変化点をいくつか整理します。

まず Podman 5 系では Netavark がデフォルトのネットワークスタックとなり、CNI プラグインは非推奨扱いになっています。既存の CNI ベースの設定を MicroOS 新環境に持ち込む場合は、Netavark 向けの再設定が必要です。また Podman 5 以降では Quadlet（systemd ユニットとしてコンテナを管理する仕組み）が正式機能として整備されており、Compose ファイルよりも MicroOS の宣言的設定スタイルとの親和性が高い場面が増えています。

次に transactional-update 自体も更新が続いており、2024 年後半以降のバージョンでは --drop-if-no-change オプションが安定して使えるようになっています。このオプションを有効にすると、更新対象パッケージがなかった場合にスナップショットを作らないため、番号の無駄な増加を防ぎます。

クラウド環境固有の注意点としては、AWS・Azure・GCP のいずれでも MicroOS の公式イメージが提供されていますが、プロバイダごとの cloud-init との共存方法が異なります。openSUSE 側のドキュメントでは Combustion を優先し cloud-init は無効化することを推奨していますが、既存の CI/CD パイプラインで cloud-init を必須としている場合は、役割分担を明確に定義してから移行する必要があります。

最後に、コンテナホストとして MicroOS を採用する際に見落とされがちな点として、カーネルモジュールの追加があります。MicroOS のルートパーティションは読み取り専用であるため、modprobe で手動ロードしたモジュールの永続化は /etc/modules-load.d/ への記述だけでなく、必要に応じて transactional-update shell でパッケージとしてインストールする手順が求められます。特に NFS クライアントや特定のネットワークドライバなど、デフォルトカーネルに含まれないモジュールを使う場合は事前確認を徹底することが重要です。