サーバー向けimmutable Linuxディストリビューション比較

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 つのパッケージのために追加されたサードパーティーリポジトリ。障害対応中に編集され、その後構成管理へ戻されなかった設定ファイル。これを構成ドリフトと呼びます。そのため、メモを基に「同じ」サーバーを再構築しても、動作の異なる環境になることがよくあります。メモに残るのは意図です。ディスクに残るのが実態です。

イメージモードでは、ドリフトが蓄積する場所がなくなります。/usr は実行時に読み取り専用になるため、手動で行ったインストールはそのまま失敗するか、1 つのコマンドで一覧表示できるレイヤーとして記録されます。これにより、2 台のマシンの差異を、痕跡を発掘するのではなく可視化できます。これは 通常の Linux サーバー保守チェックリスト が規律によって対処するのと同じ問題を、ファイルシステムによって処理するものです。

ロールバックは再起動で完了し、それが最大の利点です

このモデルが想定する障害は、すでに説明しているものです。カーネル更新後に起動しない VPS です。パッケージ方式では、プロバイダーのレスキューコンソールから復旧します。ディスクをマウントし、chroot に入り、カーネルパッケージを手動で削除します。これは、ブートローダーが古いカーネルを保持するため機能します。ただし、この方法でバージョン管理されるのはカーネルだけです。同じトランザクションで適用された glibc の更新と systemd の変更は、すでに反映されています。それらをまとめて元に戻す単一のコマンドはありません。

イメージ方式では、単位はシステム全体です。bootc ホストでは、次のようにします。

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc 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 status

rpm-ostree status は、ブートローダーが提示する順序でデプロイメントを一覧表示します。実行中のデプロイメントにはドットを付け、固定したデプロイメントには Pinned: yes を表示します。

Talos では、ワークステーションから API を 1 回呼び出します。

talosctl rollback --nodes 10.20.30.40

Flatcar は 2 つの /usr パーティションを保持し、それらを切り替えます。各スロットには、パーティションテーブル内に優先度と試行回数が記録されています。そのため、正常に起動できないスロットは試行回数を使い果たし、ブートローダーはもう一方のスロットを選択します。現在使用しているスロットと、正常とマークされているかを確認します。

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

正常に動作しているスロットでは、priority=1 tries=0 successful=1 を含む行が出力されます。一致する行がない場合、現在のスロットはまだ確認されていません。これは、更新後から最初の正常な起動までの間にマシンが置かれる状態です。

「パッケージをインストールする」に代わるもの: bootc と Containerfile

bootc は、このパターンを一般化したツールです。OCI (open container initiative) コンテナーイメージを使用した、トランザクショナルなインプレースオペレーティングシステム更新を行うツールであり、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 --apply

bootc 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 配下に置きます。そのため、インストール先ディレクトリ内への書き込みを要求するソフトウェアでは、ビルド時に symlink または systemd の BindPaths= 行を追加する必要があります。また、更新時には /etc が 3-way merge されます。変更していないファイルにはイメージの新しいバージョンが適用され、ローカルで編集したファイルは保持されます。

実行中のサーバーで、1 回のデバッグ作業だけツールが必要になった場合は、次のようにします。

sudo bootc usr-overlay
sudo dnf -y install strace

これにより、/usr 上に一時的な書き込み可能オーバーレイが追加されます。このオーバーレイは次回の再起動時に破棄されます。これは問題を調査するための機能であり、問題を修正するためのものではありません。この方法でカーネルを変更することはできません。また、インストールしたものはすべて、設計上、再起動時に消去されます。

Fedora CoreOS: 1 回プロビジョニングし、更新を継続する

Fedora CoreOS には対話式インストーラーがありません。Butane YAML ファイルを作成し、それを Ignition JSON に変換して、初回起動時にマシンへ渡します。

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition は初回起動時だけ 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

これにより、パッケージを追加した新しいデプロイメントが作成されます。変更が有効になるのは再起動後です。問題は後から発生します。新しいベースイメージが適用されるたびに、レイヤー化したパッケージセットもその上に再適用されます。そのため、更新時にリポジトリからパッケージが消えていると、更新に失敗します。Fedora の公式ドキュメントでは、大規模な構成にはコンテナを使用し、本当に OS を変更する必要がある場合は bootc image を使用することを推奨しています。

Flatcar Container Linux: パッケージマネージャーがまったくない環境

Flatcar は CoreOS Container Linux の後継で、汎用用途の選択肢の中でも最も制約が厳しいものです。利用できるパッケージマネージャーはありません。実行するものはすべてコンテナです。プロビジョニングには Fedora CoreOS と同じく Ignition を使用します。更新は前述の 2 つの A/B /usr パーティションを対象とし、update_engine が更新を実行し、locksmithd が再起動のタイミングを決定します。

update_engine_client -status
update_engine_client -check_for_update

UPDATE_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=1h

REBOOT_STRATEGY=off を指定すると、再起動は手動で行います。同じファイルの SERVER=disabled により、更新確認を完全に停止できます。クラスターでは、REBOOT_STRATEGY=etcd-lock と locksmithctl set-max 4 を組み合わせることで、同時に再起動できるノード数を制限できます。これにより、更新によってフリート全体が同時に停止することを防げます。

Talos Linux: シェル、SSH、コンソールなし

Talos は4つの中で最も用途が限定されており、その目的も最も明確です。Kubernetes ノードを実行します。SSH デーモン、シェル、コンソールログインはありません。すべての操作は、Git で管理しているマシン設定に対して、ワークステーションから talosctl を使って実行する gRPC API 呼び出しです。

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

移行先のリリースに合わせてタグを置き換えます。アップグレードでは、以前のカーネルと OS イメージを保持する A-B 方式を使用します。そのため、新しいイメージで起動に失敗しても、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）パッケージは、そのイメージのカーネルに対してビルドし、イメージに組み込む必要があります。ベースイメージに含まれていないモジュールを必要とするものは、インストールの問題ではなく、ビルドの問題になります。

ベンダーおよびプロバイダーのエージェント。 監視エージェントとバックアップエージェントは通常、/usr に書き込み、unit を有効化するインストールスクリプト付きの .deb または .rpm として提供されます。読み取り専用システムでは、そのスクリプトは失敗します。一部のベンダーはコンテナを公開するか、イメージモードでのインストール方法を説明しています。対応していないベンダーも多数あります。導入を決定する前に確認してください。監視できないフリートは、構成が徐々にずれるフリートよりも悪い状態です。

イメージそのもの。 ほとんどの VPS コントロールパネルでは、Ubuntu や Debian と並んで Fedora CoreOS、Flatcar、Talos を選択できません。ディスクは自分で用意します。次のセクションでは、その方法を説明します。

レンタルした VPS にこれらのシステムのいずれかを導入する

まず、プロバイダーについて次の 2 点を確認します。VNC またはシリアルコンソールによる帯域外コンソールアクセスが利用できること、そしてレスキューシステムを起動できることです。コンソールがなければ、起動しなくなったマシンは 5 分で修復できる問題ではなく、サポートへの問い合わせになります。

プロバイダーがカスタムイメージに対応している場合は、ベンダーの raw または qcow2 イメージをアップロードするだけで完了します。対応していない場合は、レスキューシステムから自分でディスクに書き込みます。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

このコマンドは、置き換え対象のサーバー上ではなく、レスキューシステムから実行してください。実行中にスクリプトが対象デバイスのパーティションを再作成するためです。デバイス上に少なくとも 8 GB の使用可能な領域が必要です。また、レスキュー環境には 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 では、実行中の 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

実行前に、使用するベースイメージのドキュメントを確認してください。また、廃棄できるサーバーで試してください。再起動後はそのマシンがイメージを実行し、それまでインストールされていたパッケージ一式は失われます。

不変サーバーを使うべき人と、使うべきでない人

サーバーを家畜のように扱う場合は、これを選ぶ価値があります。1 つのレシピから多数のマシンを作成する環境が該当します。1 時間だけ稼働する CI（continuous integration）runner も対象です。修復するのではなく交換する k3s または Kubernetes node も該当します。壊れたマシンへの対応が、すでに「削除して新しいものを作る」で決まっている環境では特に有効です。監査担当者にマシン上で実行されているものを説明する必要がある場合にも役立ちます。答えを package list ではなく image digest で示せるためです。

1 台の VPS を手作業で管理し、そこに 3 つのサービスを配置し、必要に応じてソフトウェアをインストールしていて、build pipeline もない場合は選ばないでください。Image mode にすると作業がなくなるわけではありません。作業場所が server から build に移り、その移動のために registry と pipeline が必要になります。その作業を置く場所があるなら、同一構成の server と、再起動で済む rollback を得られます。なければ、問題なく動いていたマシンに構成要素を追加することになり、深夜 2 時の対応が難しくなります。

面白みのない中間案も、今なお有効です。通常の distribution に automatic security updates を適用し、実際に練習した rebuild 手順を用意します。その base を選ぶこと自体が別の判断であり、VPS で実行する OS の選び方で説明しています。Image mode は、ソフトウェアをマシンへ届ける方法をめぐる非常に古い議論の最新の一巡にすぎません。Linux distribution の歴史も、基本的にはその議論が繰り返されてきた歴史です。

FAQ

不変の Linux ディストリビューションは本当に不変ですか？

いいえ。この名前は誤解を招きます。root は引き続きディスクに書き込めます。実際には、/usr が実行時に読み取り専用でマウントされ、次のイメージで全体が置き換えられます。一方、/etc と /var は書き込み可能なままで、更新後も保持されます。/usr 配下で行った変更は、その時点で拒否されるか、次回の更新時に破棄されます。そのため実際には、システムディレクトリが変更されるのはイメージが変更されたときだけです。

Fedora CoreOS または Flatcar を提供していない VPS で実行できますか？

通常は実行できます。プロバイダーが rescue system と console access を提供していることが条件です。rescue system で起動し、ディストリビューションのディスクイメージを block device に書き込んでから再起動します。Flatcar の flatcar-install script は任意の Linux からこの処理を実行します。Fedora CoreOS では coreos-installer が container として提供されており、同じ方法で実行できます。どちらも SSH key を含む Ignition file が必要です。初回起動時に入力する password prompt がないためです。console access がない場合は試行しないでください。復旧しないマシンを確認する手段がなくなります。

不変サーバーに package をインストールするにはどうすればよいですか？

package をイメージに追加して再デプロイします。bootc では、Containerfile に RUN dnf -y install ... line を追加し、rebuild、push を行った後、マシン上で sudo bootc upgrade --apply を実行します。Fedora CoreOS では sudo rpm-ostree install で package を layer 化して再起動できます。ただし、その package は以後のすべての更新時に再適用されます。Flatcar と Talos には package manager がないため、container を使用します。bootc host で一時的に debugging tool を使う場合は、sudo bootc usr-overlay により書き込み可能な /usr が提供されます。この環境は次回の再起動時に消失します。

image mode では、kernel update 後に起動しない VPS を復旧できますか？

復旧方法を rescue console での作業から再起動に変えられます。以前の image は kernel と userspace を含めてディスク上に残っているため、sudo bootc rollback または sudo rpm-ostree rollback -r により以前の image に戻せます。Talos と Flatcar はさらに、新しい slot の起動に失敗すると、指示がなくても rollback します。boot entry は、1 回正常に起動するまで default にならないためです。これらの仕組みで不良な更新そのものを防げるわけではありません。ただし、1 回の更新を簡単に取り消せます。

サーバーにはどの不変ディストリビューションを選ぶべきですか？

container image と同じ方法で構築し、既存のマシンにインストールできる汎用 Linux server が必要なら、bootc を選びます。構築を任せ、そのモデルを automatic updates とともにすぐ利用したいなら、Fedora CoreOS を選びます。最小構成の container host、A/B update scheme、そして利用可能な package manager がない環境を求めるなら、Flatcar を選びます。マシンが Kubernetes node の場合だけ Talos を選びます。Talos には shell がなく、その他の処理は実行しないためです。