CentOS Stream 10 本番評価フロー｜ローリングリリースの更新予測と RHEL 互換性検証設計

CentOS Stream 10 が求められる背景

RHEL 10 が 2025 年 5 月に正式リリースされてから、上流開発プラットフォームである CentOS Stream 10 への関心が運用現場で高まっています。CentOS Stream はかつての「RHEL の安定版無償クローン」という立ち位置とは根本的に異なり、RHEL マイナーリリースの先行開発ブランチとして機能します。つまり今後 RHEL 10.1・10.2 として出荷されるパッケージが、Stream 10 のリポジトリに数週間〜数か月先行して投入される仕組みです。

この構造を正しく理解しないまま「無料の RHEL 10 互換」として本番投入すると、予期せぬ挙動変化やソフトウェアライフサイクルのずれに苦労することになります。一方で、次期 RHEL マイナーリリースに追従したい ISV 向け検証環境や、内部ツールチェーンのテストベッドとして活用するシナリオでは、Stream 10 は依然として合理的な選択肢です。本記事では「本番評価を前に進めるための設計判断」に焦点を当て、更新予測・互換性検証・切り戻し設計を一貫したフローとして整理します。

ローリングリリースの更新サイクルと予測手法

CentOS Stream 10 の更新はコミットレベルから追跡できます。Red Hat の内部ビルドシステムを経由したパッケージが centos-stream-10 の Koji インスタンスに投入され、その後 dnf リポジトリへ反映されます。更新頻度はコンポーネントによって大きく異なり、カーネルは週次〜隔週ペース、glibc や OpenSSL といったコアライブラリは月次前後、周辺ユーティリティはより不規則な投入が見られます。

更新を事前に察知する実用的な手段として、https://gitlab.com/redhat/centos-stream/rpms 以下の各コンポーネントリポジトリへの RSS / Atom フィードの監視があります。また CentOS Stream のメーリングリスト（centos-devel）には大きな変更が告知されることが多く、カーネルの ABI 変更や glibc の互換性影響を伴う更新は数日前に議論が行われる傾向があります。運用チームがこれらのシグナルを定期チェックするスクリプトを組み込んでおくと、「気づかぬうちにデプロイ済み環境と差分が広がる」状況を防げます。

現時点（2026 年 10 月）では CentOS Stream 10 は RHEL 10.1 相当の開発フェーズにあり、特にカーネル 6.12 系列の後継ブランチへの移行パッチが断続的に投入されています。RHEL 10.1 の一般提供（GA）に向けたコードフリーズ前後は変更量が増える傾向があるため、本番評価スケジュールを組む際はこの時期を「更新密度の高い局面」として想定しておくことが実際的です。

本番評価前の検証環境設計

Stream 10 を本番評価に持ち込む前に、ステージング環境を「本番の縮小コピー」として構成することが出発点になります。単純に同一スペックの VM を 1 台用意するだけでは不十分で、以下の要素を意識した設計が必要です。

• 更新隔離レイヤーの設置：本番と同一のリポジトリ構成を維持しつつ、dnf versionlock や Satellite/Foreman のコンテンツビューを使って「評価対象バージョンのスナップショット」を固定できる仕組みを用意する。
• アプリケーションスモークテストの自動化：デプロイ後 5〜10 分で基本疎通・API レスポンス・クリティカルなジョブの完了を確認するテストスイートを CI/CD パイプラインに組み込む。手動確認に頼ると、更新密度が高い局面で確認漏れが発生しやすくなります。
• カーネルパニックと OOM の記録体制：新カーネル投入後 24〜48 時間は kdump と systemd-coredump を有効化し、クラッシュダンプを自動収集する設定を入れておく。Stream では実験的なドライバパッチが先行投入されることがあり、特定ハードウェア構成でのリグレッションを早期に検出できます。

コンテナワークロードを中心に運用している環境では、ホスト OS の評価とコンテナランタイム（containerd / CRI-O）の互換性検証を分離して実施することを強く推奨します。Stream 10 ではカーネルの cgroup v2 挙動や seccomp フィルタの更新が RHEL 10.x に先行して入るため、コンテナレイヤーでの動作変化がホスト OS の更新より先に問題化するケースが確認されています。

RHEL 互換性検証の具体的な進め方

「Stream 10 上で動いたから RHEL 10 でも動く」という前提は概ね成立しますが、逆方向（RHEL 10 でのみ動作保証されたバイナリを Stream 10 で動かす）については慎重な確認が必要です。RHEL 10 ではロック済みの ABI に対し、Stream 10 では同 ABI が更新途中の状態で存在することがあるためです。

互換性検証を体系化するには、以下のフローが実務的に機能します。

ステップ 1：パッケージ epoch/version の差分確認
rpm -qa --queryformat '%{NAME} %{EPOCH}:%{VERSION}-%{RELEASE}\n' | sort を RHEL 10 GA 環境と Stream 10 環境の両方で実行し、diff を取ります。epoch が異なる場合は dnf のアップグレードパスに影響するため、移行計画に注意が必要です。

ステップ 2：共有ライブラリの ABI チェック
abidiff（abigail-tools パッケージ）を使い、glibc・libssl・libcrypto の SO ファイルを RHEL 10 と Stream 10 で比較します。関数シグネチャや構造体レイアウトの差分が出た場合、自社ビルドの共有ライブラリがそれらに依存していると再コンパイルが必要になります。

ステップ 3：SELinux ポリシーの差分確認
Stream 10 では selinux-policy のマイナー更新が頻繁に入ります。sesearch や audit2why を活用し、更新前後で AVC 拒否ログの傾向変化がないかを確認する運用を標準手順に組み込むと、「突然アプリケーションが起動しなくなる」トラブルを事前に防げます。

ステップ 4：systemd ユニットの動作確認
RHEL 10 / Stream 10 では systemd 256 以降を採用しており、DefaultDependencies= の扱いや PrivateTmp= のデフォルト挙動が以前のメジャーバージョンと異なります。カスタムサービスユニットは systemd-analyze verify でシンタックスチェックを行い、journalctl -u <service> -p warning で起動直後の警告ログを確認する手順を標準化します。

更新後の切り戻し設計と注意点

Stream 10 はローリングリリースであるため、パッケージのダウングレードを前提とした切り戻し設計は推奨されません。dnf downgrade は依存関係の連鎖が複雑になり、特にカーネルとカーネルモジュールの組み合わせでは予期しない不整合を引き起こすリスクがあります。

現場で有効とされる切り戻し設計は、主に 2 つのアプローチです。

アプローチ A：スナップショットベースのロールバック
仮想化基盤（KVM/libvirt、VMware、クラウドの EBS スナップショット等）のスナップショット機能を利用し、更新適用前にスナップショットを取得してから dnf update を実行します。問題発生時はスナップショットを戻すことで環境全体を確実に巻き戻せます。ベアメタルでは代替として Rear（Relax-and-Recover）によるシステムバックアップが機能します。

アプローチ B：immutable インフラとして運用する
コンテナ・VM イメージをビルドパイプラインで管理し、更新のたびに新しいイメージをデプロイして古いインスタンスを廃棄するパターンです。RHEL Image Builder（osbuild）を Stream 10 で利用することで、評価済みの RPM セットを含む再現性の高いイメージを生成できます。切り戻しは「前バージョンのイメージに戻す」だけになるため、ロールバック手順が単純化されます。

いずれのアプローチでも、カーネル更新だけは GRUB のブートエントリとして前バージョンが残るため、起動時に切り替えられます。grubby --info=ALL で現在のエントリ一覧を確認し、緊急時に旧カーネルへ切り替えられるよう手順を文書化しておくことも忘れないようにしましょう。

2026 年時点の現行環境差分と評価判断の指針

2026 年 10 月現在、CentOS Stream 10 の運用に関していくつかの現行環境固有の注意点があります。

まず、AlmaLinux 10 / Rocky Linux 10 との位置関係を整理しておく必要があります。AlmaLinux 10 および Rocky Linux 10 は RHEL 10 GA をベースにした 1:1 バイナリ互換を目指す「安定版クローン」です。「本番環境には Stream ではなくクローンディストリを使い、Stream は評価・開発用に留める」という分業構成が、多くの組織で標準的な選択になっています。Stream 10 を本番に採用する判断は、RHEL マイナーリリースを先行検証したい特定の目的がある場合に限定するのが妥当です。

次に、Subscription Manager なしでのサポート範囲についてです。CentOS Stream 10 は Red Hat のサポート契約なしで利用できますが、セキュリティ修正のリードタイムや CVE 対応スピードは RHEL 10 とは異なります。Red Hat Product Security が公開する RHSA アドバイザリは RHEL 向けであり、Stream への反映タイミングは一致しません。セキュリティ要件の厳しい本番環境への Stream 採用は、この非同期性をリスク評価に含める必要があります。

また、Podman 5.x と Quadlet の普及も 2026 年の実務では見逃せません。Stream 10 には Podman 5 系が標準搭載されており、Quadlet（.container ユニットファイルで Podman コンテナを systemd で管理）が実用レベルで使えます。従来の docker-compose ベースの設計を systemd ネイティブなアーキテクチャへ移行する検証基盤として Stream 10 を位置づけることは、現行環境に即した現実的な活用シナリオです。

最後に、評価フローを組織内で再現可能にするために、Ansible Playbook または Kickstart + post スクリプトによる環境構築の自動化を検証初期段階で整備することを強く推奨します。Stream の更新頻度を考えると、手動構築を繰り返す運用は技術的負債になりやすく、評価環境の再現性確保が検証品質を直接左右します。評価環境の Infrastructure as Code 化は、Stream 10 を継続的に追いかける上での基盤投資として位置づけると、組織内での合意も取りやすくなります。