Fedora CoreOS本番採用判断｜不変OS設計とzincati自動更新・ロールバック検証

Fedora CoreOSが注目される背景と設計思想

コンテナワークロードが主力となった現場では、OSのライフサイクル管理そのものが課題として浮かび上がっています。パッケージを個別に更新する従来のディストリビューションは「どの時点でどの状態か」の再現性が低く、台数が増えるほど設定のドリフトが避けられません。Fedora CoreOS（以下 FCOS）はこの問題に対して「OSイメージ全体をアトミックに入れ替える」という設計で応えています。

FCOSはCoreOSとContainer LinuxをRed Hatが統合・後継として開発した、コンテナ特化の軽量Linuxです。Ignitionと呼ばれる初回起動時の宣言的プロビジョニング、rpm-ostreeによるOSイメージのバージョン管理、そしてzincatiによる自動更新エンジンの三本柱で構成されています。2026年現在もFedoraプロジェクトの公式リリースサイクルに乗っており、OpenShift/OKDのノードOSとしても採用実績があります。

不変OSアーキテクチャの実体——何が「変わらない」のか

「不変OS」という呼称は誤解を招くことがあります。正確には「/usr 以下がread-onlyマウントされており、通常のパッケージインストールや直接編集ができない」という設計です。設定変更は /etc への書き込み、Ignitionによる初期構成、またはrpm-ostreeのレイヤリングによる追加パッケージ適用に限定されます。

この設計がもたらす実務上のメリットは主に三点です。

• 任意の時点にロールバックできる（rpm-ostreeが直前2世代分のデプロイを保持する）
• ノード間の状態が一致しやすく、Infrastructure as Codeとの相性がよい
• 攻撃面が狭い——インタラクティブなパッケージインストールが原則できないため、侵害後のツール導入が困難になる

一方、従来の手順書がそのまま使えないケースも多くあります。たとえばCronジョブで yum install を実行するような運用スクリプトは動作しません。コンテナランタイム以外のデーモンをOSレイヤに直接インストールするアーキテクチャも再検討が必要です。ノードを「カスタマイズする」という発想から、Ignitionで「状態を宣言する」という発想へのシフトが、FCOS採用における最大のハードルといえます。

zincatiによる自動更新の仕組みと運用上の制御

FCOSの更新はzincatiというデーモンが管理します。zincatiはバックエンドにCincinnati（Fedoraが運営するグラフベースの更新APIサーバ）を利用し、「このバージョンから安全に移行できる次バージョン」をグラフとして管理します。単純な最新バージョンへの直アップデートではなく、安全な移行パスが確認されたものだけが配信される仕組みです。

zincatiのデフォルト挙動は「更新を検知すると自動でダウンロード・適用し、ノードを再起動する」です。この挙動を本番環境でそのまま受け入れるかどうかが、採用検討の最初の論点になります。

メンテナンスウィンドウによる再起動タイミングの制御

zincatiはIgnitionまたは /etc/zincati/config.d/ 以下のTOMLファイルで挙動を制御できます。以下は再起動タイミングを「毎週土曜 UTC 18:00〜20:00（JST 日曜 03:00〜05:00）」に限定する設定例です。

# /etc/zincati/config.d/51-maintenance-window.toml
[updates]
strategy = "periodic"

[[updates.periodic.window]]
days = [ "Saturday" ]
start_time = "18:00"
length_minutes = 120

本番クラスタでは strategy = "external" を選択し、FleetLock互換APIを実装した自前のオーケストレータでローリング再起動を制御する構成も標準的です。KubernetesクラスタのノードであればDrainをかけてから再起動させる必要があるため、FleetLockとkube-drain-agentを組み合わせる実装が現場でよく採用されています。

緊急時に自動更新を一時停止する手順

ロールアウトフリーズが必要な場面では、zincatiサービスを停止することで更新の検知・適用を即座に止められます。

# 自動更新を停止
sudo systemctl stop zincati.service

# 再開する場合
sudo systemctl start zincati.service

ただしzincatiを長期間停止したままにすると、Cincinnatiのグラフ上でそのバージョンが「安全な移行元」から外れ、後続の自動更新パスが存在しなくなる可能性があります。停止期間は数週間を上限とし、手動での rpm-ostree upgrade と組み合わせる運用が安全です。

更新後の検証とrpm-ostreeによるロールバック手順

FCOSの更新はOSイメージ全体の入れ替えであるため、適用後は必ず動作確認を行います。確認すべきポイントはカーネルバージョン・コンテナランタイムのバージョン・systemdユニットの状態の三点が中心です。

# 現在のデプロイ一覧を確認（2世代分が表示される）
rpm-ostree status

# カーネルバージョン確認
uname -r

# podmanのバージョン確認
podman version

rpm-ostree status の出力では、●マークが現在起動中のデプロイ、その下に前バージョンのデプロイが並びます。問題が発生した場合のロールバックは以下の一操作で完了します。

sudo rpm-ostree rollback
sudo reboot

再起動後に再度 rpm-ostree status を実行し、旧バージョンで起動していることを確認します。なお、ロールバックで戻れるのは直前の1世代のみです。2世代以上前に戻す場合は、Ignitionで再プロビジョニングするか、あらかじめOSTreeのコミットハッシュを記録した上で手動で rpm-ostree deploy を指定する対応が必要になります。

Kubernetesクラスタでのノード単体ロールバックフロー

KubernetesクラスタのワーカーノードでFCOSをロールバックする場合は、再起動前にkubectlでノードをcordon・drainしてからrpm-ostreeコマンドを実行するのが安全です。ロールバック後にuncordonし、ワークロードが正常にスケジュールされることを確認してから次のノードへ進みます。この一連の手順をシェルスクリプトやAnsibleで定型化しておくと、障害対応時の作業時間を大幅に短縮できます。

2026年時点の現行環境差分と本番採用の判断基準

2026年9月現在のFedora CoreOSは、Fedoraプロジェクトのリリースサイクルに従い「stable」「testing」「next」の3ストリームが維持されています。本番採用では原則としてstableストリームを選択します。Fedora CoreOSのEOLサイクルはFedora本体と連動するため、約1年サイクルでのメジャーバージョンアップへの追随が必要です。

2025〜2026年にかけての主な変更点として以下が挙げられます。

• cgroup v2がデフォルト化され、v1の互換レイヤは非推奨となっています。古いコンテナランタイムや一部のJavaアプリは事前の動作確認が必要です。
• Ignition仕様はv3.4系が安定版です。v3.2以前との後方互換性は保たれていますが、ButaneからのトランスパイルをベースとしたIgnitionファイル管理が公式推奨になっています。
• rpm-ostree自体はcompositionの管理がbootc（OSTree Native Containers）へ移行する過渡期にあります。将来的にはDockerfileベースでOSイメージをビルドするbootcワークフローが主流になる可能性があり、FCOSとbootcの役割分担は引き続き注視が必要な状況です。

本番採用の可否を判断する際に事前確認しておくべき点を整理します。

• ワークロードがコンテナ化されているか：非コンテナのデーモンやバイナリをOSに直接インストールする運用はFCOSと相性が悪く、rpm-ostreeのレイヤリングで対応できるか事前検証が必要です。
• メンテナンスウィンドウを設定できるか：ゼロダウンタイムを要求するサービスでは、FleetLock等による再起動の協調制御が必須となります。
• Ignitionによるプロビジョニングが整備できるか：既存の構築手順書をIgnitionに変換する工数は、導入前に見積もりを取っておく必要があります。
• Fedoraリリースサイクルに追随できるか：年1回程度のOSバージョンアップが発生します。CI/CDパイプラインでノードイメージの入れ替えを自動化する体制が整っていると、長期的な運用コストを低く抑えられます。

FCOSはOS管理をコードで完結させたい環境、特にIaCとコンテナオーケストレーションを組み合わせたクラスタ運用において強みを発揮します。一方、汎用サーバとして手に馴染んだ感覚で運用したい場面や、アドホックなパッケージインストールが頻発する環境には向いていません。設計方針がシステム全体の方向性と一致しているかを先に確認したうえで、ステージング環境での十分な検証を経て本番採用を判断するのが、現場で推奨されるアプローチです。