著者 サーバー向けImmutable Linuxディストリビューション比較
Immutable LinuxはOSを1つのイメージとして更新し、再起動でロールバックできます。bootc、Fedora CoreOS、Flatcar、TalosをVPSで使う際の代償を比較します。
What an immutable Linux distro is
An immutable Linux distro ships the operating system as one image, so you replace the system instead of patching it in place. There is no apt upgrade rewriting files under /usr on a running box. You build or pull a new image, the machine stages it beside the one it is running, and the next reboot swaps which one is active. The previous image is still on disk, so undoing a bad update is a reboot.
The word "immutable" oversells it. Nothing physically stops root from writing to the disk. What these systems do is mount the system directories read only and give ownership of them to the image. Persistent data lives in /var. Machine-specific configuration lives in /etc. Everything under /usr belongs to the image, which is why two servers running the same image tag hold identical system files.
Red Hat's names for the two models are the clearest ones: package mode and image mode. Package mode is a running system plus a package manager that edits it. Image mode is a build step somewhere else that produces an artifact, and a server whose only job is to boot the artifact you point it at. Everything below follows from that one difference.
サーバーで読み取り専用システムがより重要になる理由
2 年間稼働してきたサーバーには、誰も記録していない履歴が蓄積されています。急いで作業した夜に加えられた make install。1 つのパッケージのために追加したサードパーティーリポジトリ。障害対応中に編集し、その後 configuration management に戻されなかった設定ファイル。これを configuration drift と呼びます。そのため、メモを基に「同じ」サーバーを再構築しても、動作が異なるマシンになることがよくあります。メモに残るのは意図です。ディスクに残るのが事実です。
Image mode では、drift が蓄積する場所がなくなります。/usr は実行時に読み取り専用であるため、手動で行ったインストールはそのまま失敗するか、1 つのコマンドで一覧表示できる layer として記録されます。これにより、2 台のマシンの違いが、発掘調査をしなくても明確になります。これは 通常の Linux サーバー保守チェックリストが規律によって対処するのと同じ問題を、filesystem 側で処理するものです。
ロールバックは再起動で完了します。それがこの方式の要点です
この方式が想定する障害は、すでに説明しているものです。カーネル更新後に起動しなくなった VPS です。パッケージ方式では、プロバイダーのレスキューコンソールから復旧します。ディスクをマウントし、chroot に入り、カーネルパッケージを手動で削除します。これは、ブートローダーが古いカーネルを保持するため機能します。ただし、この方法でバージョン管理されるのはカーネルだけです。同じトランザクションで適用された glibc の更新と systemd の変更は、すでに反映されています。これらをまとめて元に戻す単一のコマンドはありません。
イメージ方式では、単位はシステム全体です。bootc ホストでは、次のようにします。
sudo bootc status
sudo bootc rollback
sudo systemctl rebootbootc rollback は、ブートローダーの順序を以前のブートエントリに戻します。これは、1 時間前に実行していたイメージであり、カーネルとユーザー空間が一体になっています。古いイメージはディスク上に残っているため、ダウンロードも再構築も行われません。
Fedora CoreOS でも、名称は異なりますが同じことを行えます。
sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r最初に Zincati を停止します。Zincati は Fedora CoreOS マシンを最新リリースに維持するエージェントです。実行したままにすると、ロールバックした更新を再びステージングします。-r は、ロールバックのステージング後に 1 回再起動します。信頼できるデプロイメントをガベージコレクションから保護するには、次のようにします。
sudo ostree admin pin 0
rpm-ostree statusrpm-ostree status は、ブートローダーが提示する順序でデプロイメントを一覧表示します。実行中のデプロイメントにはドットを付け、ピン留めしたデプロイメントには Pinned: yes を表示します。
Talos では、ワークステーションから 1 回の API 呼び出しで実行します。
talosctl rollback --nodes 10.20.30.40Flatcar は 2 つの /usr パーティションを保持し、それらを切り替えます。各スロットには、パーティションテーブル内に優先度と試行回数のカウンターがあります。そのため、正常に起動できないスロットは試行回数を使い切り、ブートローダーはもう一方のスロットを選択します。現在使用しているスロットと、正常なスロットとしてマークされているかを確認します。
sudo cgpt show "$(rootdev -s /usr)" | grep successful=1正常に動作しているスロットでは、priority=1 tries=0 successful=1 を含む行が出力されます。一致する行がない場合、現在のスロットはまだ確認されていません。これは、更新後、初回の正常な起動が完了するまでマシンが置かれる状態です。
「パッケージをインストールする」に代わるもの: bootc と Containerfile
bootc は、このパターンを一般化したツールです。OCI (open container initiative) コンテナーイメージを使用した、トランザクション方式のインプレース OS 更新ツールです。CNCF Sandbox プロジェクトでもあります。サーバーは Containerfile になります。2026 年 8 月時点で、Fedora のベースイメージは quay.io/fedora/fedora-bootc:44、CentOS Stream のベースイメージは quay.io/centos-bootc/centos-bootc:stream10 です。
FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx他のイメージと同じように、ビルドして push します。
sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19次に、サーバー上で実行します。
sudo bootc upgrade --check
sudo bootc upgrade --applybootc upgrade はイメージのソースを確認し、新しいイメージを次回のブート用にキューへ登録します。--check は更新が利用可能かどうかを報告するだけで、変更は行いません。--apply は新しいイメージで再起動します。bootc switch registry.example.com/edge/web:next は、/etc と /var を保持したまま、マシンの参照先を別のイメージに変更します。これにより、再インストールせずにサーバーをイメージストリーム間で移行できます。
無人更新を行うには、プロジェクトが提供する timer を有効にします。
sudo systemctl enable --now bootc-fetch-apply-updates.timerこれは、Ubuntu の無人アップグレード および Rocky と Alma の dnf-automatic に相当する、イメージモードでの方法です。違いは、適用される対象です。パッケージモードの timer は、その夜にリポジトリが保持しているバージョンを適用するため、結果のパッケージセットはマシンごとに少しずつ異なります。イメージモードの timer は、別の場所ですでにブートした単一の成果物を適用します。
この Containerfile から、2 つのビルドルールが導かれます。書き込み可能なデータは /var 以下に置きます。そのため、インストールディレクトリ内への書き込みを要求するソフトウェアには、ビルド時にシンボリックリンクまたは systemd の BindPaths= 行を追加する必要があります。また、/etc は更新時に 3-way merge されます。つまり、一度も変更していないファイルにはイメージの新しいバージョンが反映され、ローカルで編集したファイルは保持されます。
稼働中のマシンで、1 回のデバッグ作業だけツールが必要な場合は、次のように実行します。
sudo bootc usr-overlay
sudo dnf -y install straceこれにより、/usr 上に一時的な書き込み可能 overlay が追加されます。この overlay は次回の再起動時に破棄されます。これは問題の調査に使用するものであり、問題の修正には使用しません。この方法で kernel を変更することはできません。インストールしたものはすべて、設計上、再起動時に消失します。
Fedora CoreOS: 一度プロビジョニングし、以後は継続的に更新
Fedora CoreOS には対話式インストーラーがありません。Butane YAML ファイルを作成し、それを Ignition JSON に変換して、初回起動時にマシンへ渡します。
podman run --interactive --rm quay.io/coreos/butane:release \
--pretty --strict < your_config.bu > transpiled_config.ignIgnition が initramfs で実行されるのは、初回起動時だけです。cloud-init を使ってきた場合に混乱しやすい点です。設定に SSH key が含まれていないと、マシンは接続手段のない状態で起動します。その場合は、最初から再度プロビジョニングする必要があります。重要なサーバーに適用する前に、使い捨てのマシンで設定をテストしてください。
live environment からディスクへインストールする場合:
sudo coreos-installer install /dev/sda \
--ignition-url https://example.com/example.ignデフォルトでは、更新は自動的に行われます。制御できるのは更新するかどうかではなく、更新するタイミングです。/etc/zincati/config.d/55-updates-strategy.toml に TOML ファイルを配置し、定期的な更新方法を指定します。
[updates]
strategy = "periodic"この方法では、array-of-tables の各エントリにメンテナンスウィンドウを1つずつ追加します。各ウィンドウは、二重角括弧内に updates.periodic.window と記述したヘッダーで始まり、その後に3つのキーを指定します。
days: 曜日の名前のリスト。たとえば"Sat"や"Sun"です。start_time: ウィンドウの開始時刻。"22:30"の形式で記述します。length_minutes: ウィンドウを開く時間。たとえば60です。
時刻は UTC です。更新を完全に停止するには sudo systemctl disable --now zincati.service を実行します。その場合、パッチ適用のスケジュールを自分で管理する必要があります。
パッケージのレイヤリングは、例外的な要件に対応する手段です。
sudo rpm-ostree install --allow-inactive vim
sudo systemctl rebootこれにより、パッケージを追加した新しい deployment が作成されます。変更が有効になるのは再起動後です。問題は後から発生します。レイヤー化したパッケージセットは、新しい base image ごとにその上へ再適用されます。そのため、更新日にパッケージが repository から消えていると、その更新は失敗します。Fedora の公式ドキュメントでは、大規模な構成には containers を使い、本当に OS を変更する必要がある場合は bootc image を使うことが推奨されています。
Flatcar Container Linux: パッケージマネージャーがまったくない
Flatcar は CoreOS Container Linux の後継で、汎用 OS の中で最も制約が厳しい選択肢です。利用できるパッケージマネージャーはありません。実行するものはすべてコンテナです。プロビジョニングには Fedora CoreOS と同じく Ignition を使用します。更新は、前述した2つの A/B /usr パーティションを対象とし、update_engine が更新を実行し、locksmithd が再起動のタイミングを決定します。
update_engine_client -status
update_engine_client -check_for_updateUPDATE_STATUS_UPDATED_NEED_REBOOT は、待機スロットに新しいイメージがすでに格納され、再起動だけが残っていることを意味します。デフォルトの再起動方式は reboot で、5分の遅延があります。そのため、特に指定しない限り、単一の本番 VPS は設定されたスケジュールで自動的に再起動します。/etc/flatcar/update.conf に時間帯を設定します。
REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1hREBOOT_STRATEGY=off を指定すると、再起動は手動で行うことになります。同じファイルの SERVER=disabled は、更新チェックを完全に停止します。クラスタでは、locksmithctl set-max 4 と組み合わせた REBOOT_STRATEGY=etcd-lock により、同時に再起動できるノード数を制限できます。これにより、更新によってフリート全体が同時に停止することを防げます。
Talos Linux: シェル、SSH、コンソールなし
Talos は 4 つの中で最も用途を絞った OS であり、目的が最も明確です。Kubernetes ノードを実行します。SSH デーモン、シェル、コンソールログインはありません。すべての操作は、ワークステーションから talosctl を使用し、git で管理しているマシン設定に対して実行する gRPC API 呼び出しです。
talosctl upgrade --nodes 10.20.30.40 \
--image ghcr.io/siderolabs/installer:v1.10.6移行先のリリースでタグを置き換えます。アップグレードには A-B 方式が使われ、以前のカーネルと OS イメージが保持されます。そのため、新しい構成で起動に失敗しても、Talos は介入なしで自動的にロールバックします。シェルがないため、デバッグ方法も異なります。対象マシン上で journalctl を使う代わりに、talosctl logs と talosctl dmesg を使用します。
ワークロードが Kubernetes でない場合、Talos は適切な選択ではありません。Kubernetes であれば、インシデントの一分類をなくせます。「誰かがノードにログインして何かを変更した」という事象が発生しないためです。
VPS テナントが実際に失うもの
稼働中のシステムへの場当たり的なインストール。 これが最大の違いです。インシデント発生時の午前2時に実行する sudo apt install htop は利用できません。bootc では、再起動時に消える一時的なオーバーレイを使用します。Fedora CoreOS では、再起動が必要なレイヤー化デプロイを使用します。Flatcar と Talos では、何も提供されません。
以前は必要なかったビルドパイプライン。 パッケージを追加するには、Containerfile を編集し、イメージをビルドしてレジストリへ push し、サーバーを順次更新します。パイプラインがすでにあれば、この作業のコストは低く済みます。存在しない状態から構築するには、実際の作業が必要です。また、サーバーから到達できるレジストリも必要になるため、別のサービスを運用するか、追加料金を支払う必要があります。
カーネルモジュール。 カーネルはイメージに含まれるため、稼働中のカーネル用にコンパイルしたモジュールは、次回の更新後も残るとは限りません。ツリー外モジュールと DKMS (dynamic kernel module support) パッケージは、そのイメージのカーネル用にイメージへ組み込む必要があります。ベースイメージに含まれていないモジュールを必要とするものは、インストールの問題ではなく、ビルドの問題になります。
ベンダーおよびプロバイダーのエージェント。 監視エージェントとバックアップエージェントは通常、.deb または .rpm として提供され、インストールスクリプトによって /usr へ書き込み、unit を有効化します。読み取り専用システムでは、そのスクリプトは失敗します。一部のベンダーはコンテナを公開するか、イメージモードでのインストール方法を説明しています。対応していないベンダーも多数あります。導入を決める前に確認してください。監視できないフリートは、構成が徐々にずれていくフリートよりも悪い状態です。
イメージそのもの。 ほとんどの VPS コントロールパネルでは、Ubuntu や Debian と並べて Fedora CoreOS、Flatcar、Talos を選択できません。ディスクは自分で用意します。次のセクションで説明します。
レンタルした VPS にこれらのシステムを導入する
まず、プロバイダーについて次の2点を確認します。VNC またはシリアルコンソールによる帯域外コンソールアクセスがあることと、rescue system を起動できることです。コンソールがなければ、起動しなくなったマシンは5分で直せる問題ではなく、サポートへの問い合わせになります。
プロバイダーがカスタムイメージに対応している場合は、ベンダーの raw または qcow2 イメージをアップロードすれば完了です。それ以外の場合は、rescue system から自分でディスクに書き込みます。Flatcar にはこの用途専用の自己完結型スクリプトが用意されており、任意の Linux 環境から実行できます。
curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.jsonこのスクリプトは、置き換える対象のサーバーではなく、rescue system から実行してください。実行中に対象デバイスのパーティションを再構成するためです。対象デバイスには、使用可能な領域が少なくとも 8 GB 必要です。また、rescue 環境には bash、bzip2 または lbzip2、lsblk、wget、udevadm、gpg、gawk が必要です。ignition.json には SSH key が含まれていなければなりません。含まれていない場合、インストール後のシステムに接続する方法がありません。
Fedora CoreOS も同様の構成で、インストーラーはコンテナとして実行します。
sudo podman run --pull=always --privileged --rm \
-v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
quay.io/coreos/coreos-installer:release \
install /dev/vdb -i config.ign実行前に lsblk でデバイス名を確認してください。誤ったデバイスに書き込むと、そのデバイスにあったデータがすべて破壊され、確認プロンプトも表示されません。
bootc では、rescue mode を使わずに済む方法があります。実行中の Linux システムをその場で変換する方法です。
sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
--pid=host --security-opt label=type:unconfined_t \
quay.io/fedora/fedora-bootc:44 \
bootc install to-existing-root実行前に、使用する base image のドキュメントを確認してください。また、廃棄できるサーバーで試してください。再起動後、マシンはそのイメージで動作し、以前インストールしていたパッケージセットは失われます。
不変サーバーを使うべき人、使うべきでない人
サーバーを「cattle」として扱う場合は、不変サーバーが適しています。同じレシピから多数のマシンを作成する構成です。1 時間だけ稼働する CI（continuous integration）runner にも適しています。修復するのではなく交換する k3s または Kubernetes node にも適しています。障害が発生したマシンへの対応が、すでに「削除して別のマシンを作成する」になっている環境が対象です。監査人にマシン上で稼働しているものを示す必要がある場合にも効果があります。回答が package list ではなく、image digest になるためです。
1 台の VPS を手作業で管理し、その上で 3 つのサービスを運用し、必要に応じてソフトウェアをインストールしていて、build pipeline もない場合は、適していません。Image mode によって作業がなくなるわけではありません。作業場所がサーバーから build に移り、その移動のために registry と pipeline が必要になります。作業を置く場所があるなら、同一構成のサーバーと、reboot だけで行える rollback を得られます。そうでなければ、問題なく動いていたマシンに構成要素を追加し、深夜の障害対応を難しくするだけです。
特別な仕組みを使わない中間的な構成も有効です。通常の distribution に automatic security updates を適用し、実際に練習した rebuild 手順を用意します。その基盤を選ぶ判断自体については、VPS で実行する OS の選び方で説明しています。Image mode は、ソフトウェアをマシンに届ける方法をめぐる非常に古い議論の最新の一巡にすぎません。Linux distribution の歴史も、その議論が繰り返されてきた歴史と言えます。
FAQ
不変の Linux ディストリビューションは本当に不変ですか？
いいえ。この名称は誤解を招きます。root は引き続きディスクに書き込めます。実際には、実行時に /usr が読み取り専用でマウントされ、次のイメージ全体に置き換えられます。一方、/etc と /var は書き込み可能なまま更新後も保持されます。/usr 配下で行った変更は、その時点で拒否されるか、次回の更新時に破棄されます。そのため実質的には、システムディレクトリが変わるのはイメージが変わったときだけです。
Fedora CoreOS または Flatcar を提供していない VPS でも実行できますか？
通常は可能です。プロバイダーがレスキューシステムとコンソールアクセスを提供していることが条件です。レスキューシステムを起動し、ディストリビューションのディスクイメージをブロックデバイスに書き込んでから再起動します。Flatcar の flatcar-install スクリプトを使えば、任意の Linux からこの操作を実行できます。Fedora CoreOS では、同じ方法で実行できるコンテナとして coreos-installer が提供されています。どちらも SSH key を含む Ignition ファイルが必要です。初回起動時にパスワードを入力するプロンプトがないためです。コンソールアクセスがない場合は実行しないでください。起動に失敗して復帰しなければ、確認する手段がありません。
不変サーバーにパッケージをインストールするにはどうすればよいですか？
パッケージをイメージに追加して再デプロイします。bootc では、Containerfile に RUN dnf -y install ... 行を追加し、再ビルドして push した後、マシン上で sudo bootc upgrade --apply を実行します。Fedora CoreOS では sudo rpm-ostree install を使ってパッケージをレイヤー化し、再起動できます。ただし、そのパッケージは以後の更新ごとに再適用されます。Flatcar と Talos にはパッケージマネージャーがないため、答えはコンテナです。bootc ホストで一時的にデバッグツールを使う場合は、sudo bootc usr-overlay により書き込み可能な /usr が提供されます。この領域は次回の再起動時に消えます。
カーネル更新後に起動しなくなった VPS を、イメージモードで修復できますか？
復旧作業をレスキューコンソールでの対応から再起動に変えられます。以前のイメージは、カーネルとユーザー空間を含めてディスク上に残っています。そのため、sudo bootc rollback または sudo rpm-ostree rollback -r を実行すれば、以前のイメージに戻せます。Talos と Flatcar はさらに進んでおり、新しいスロットで起動に失敗すると、自動的にロールバックします。起動エントリは、1 回の起動に成功して初めてデフォルトになります。これで不適切な更新を防げるわけではありません。更新を容易に元へ戻せるようになります。
サーバーにはどの不変ディストリビューションを選ぶべきですか？
コンテナイメージと同じように構築し、手元にあるマシンへインストールできる汎用 Linux サーバーが必要なら、bootc を選びます。構築を自分で行わず、このモデルと標準の自動更新を利用したいなら、Fedora CoreOS を選びます。A/B 更新方式の最小構成コンテナホストが必要で、パッケージマネージャーを使わせたくないなら、Flatcar を選びます。マシンが Kubernetes node の場合だけ Talos を選びます。Talos には shell がなく、他の処理も実行しないためです。