DNFモジュールストリーム切替の本番影響評価｜RHEL10移行期の依存関係管理設計

DNFモジュールストリームが本番環境に影響する理由

DNFモジュールシステムはRHEL8で本格導入された仕組みで、同一パッケージの複数バージョンを「ストリーム」として並行提供できます。たとえばPHP 7.4と8.1、あるいはNodeJS 16と18をそれぞれ独立した単位として管理し、システムにどちらを「有効化」するかを明示的に選択できます。

この仕組みの特徴は、インストール済みのパッケージ群がモジュール単位で依存関係を持つ点にあります。ストリームを切り替えると、同じモジュールに属するパッケージが一括でアップデート・ダウングレード対象になります。個別パッケージのyum updateとは異なり、関連パッケージの連鎖的な変更が起きやすいため、本番環境では事前の影響範囲把握が不可欠です。

なお、RHEL9ではすでにモジュールストリームの対象が大幅に絞り込まれており、RHEL10（2025年5月リリース）では従来型のAppStreamモジュラリティが廃止されています。2026年時点でRHEL8からRHEL10への移行を計画している組織にとって、現行のモジュール依存設計をどう整理するかは重要な移行課題の一つです。

ストリーム切替前の影響評価：変更範囲の洗い出し

切替作業の前に行うべき最初のステップは、現在有効なモジュールとインストール済みパッケージの対応を確認することです。

# 現在有効なモジュールとストリームの一覧
dnf module list --enabled

# 特定モジュールの詳細（依存するパッケージの確認）
dnf module info php

# 有効ストリームのパッケージが何かを確認
dnf module info --profile php:8.1/common

次に、切替後に何が変わるかをドライランで確認します。

# モジュールの切替対象ストリームを仮指定してシミュレーション
dnf module switch-to php:8.2 --assumeno

--assumenoオプションを使うと、変更の計画だけを表示して実行はしません。出力の「Removing」「Installing」「Upgrading」の各セクションを確認し、意図しないパッケージが巻き込まれていないかを必ず確認してください。

競合と依存エラーの事前確認

モジュールストリームを切り替える際によくあるつまずきとして、別のモジュールと暗黙的な依存競合が発生するケースがあります。たとえばPHPのストリームを上げると、php-pecl系の外部リポジトリパッケージが競合状態になることがあります。

# 切替対象モジュールに関連するパッケージを一覧化
rpm -qa | grep php | sort

# 外部リポジトリ（EPEL等）由来パッケージの確認
rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -i php

外部リポジトリ由来のパッケージがある場合、ストリーム切替後にそれらが競合状態になることがあります。切替前にこれらを把握しておき、切替後の対処方針（除外・再インストール）を決めておくと作業が滞りにくくなります。

ストリーム切替の実行手順と事後検証

影響範囲の確認が終わったら、実際の切替を進めます。基本的な流れは次のとおりです。

# ステップ1：対象モジュールを新ストリームに切替
sudo dnf module switch-to php:8.2

# ステップ2：切替の確定（ストリームが変わったことの確認）
dnf module list php

# ステップ3：関連パッケージの更新
sudo dnf update php*

switch-toサブコマンドは、現在のストリームから別ストリームに切り替える際にRHEL8.6以降で利用できます。古い環境ではresetしてからenableする手順が必要でしたが、switch-toにより一度の操作でストリーム変更と依存パッケージの整合が行われます。

切替後の動作検証チェックリスト

切替直後に確認すべき項目を整理します。

• サービス（php-fpm、httpd等）が正常に起動しているか（systemctl statusで確認）
• アプリケーション側でバージョン非互換の構文エラー・廃止関数のエラーが出ていないか（アプリケーションログを確認）
• 依存パッケージのバージョンが期待通りか（rpm -q パッケージ名で確認）
• 設定ファイルが上書きされていないか（rpm -V パッケージ名で変更済みファイルを確認）

設定ファイルについては、rpm -Vの出力で5（MD5/チェックサム変更）やc（設定ファイル）フラグが付いているファイルを重点的に確認してください。パッケージ更新時に.rpmnewや.rpmsaveファイルが生成されている場合もあります。

# rpm管理ファイルの変更検知
sudo rpm -Va --nomtime 2>/dev/null | grep "^..5" | grep " c "

# .rpmnew / .rpmsave ファイルの探索
find /etc -name "*.rpmnew" -o -name "*.rpmsave" 2>/dev/null

切り戻し手順と本番適用前の準備

ストリーム切替は、基本的にはDNFのトランザクション履歴で切り戻せます。

# 直近のDNFトランザクション履歴を確認
sudo dnf history list

# 特定のトランザクションの詳細を確認
sudo dnf history info <トランザクションID>

# トランザクションを取り消し（undo）
sudo dnf history undo <トランザクションID>

dnf history undoは対象トランザクションで行った変更を逆順に戻します。ただし、戻し先のパッケージバージョンがリポジトリから削除されていると取り消しに失敗します。切替前にパッケージをローカルにキャッシュしておくか、内部ミラーを保持する運用であれば切り戻しの確実性が上がります。

本番適用前に整えるべき環境

一般的には、本番でのストリーム切替前に以下の準備をしておくと、問題発生時の対応速度が上がります。

• スナップショット取得：仮想環境やクラウドであれば切替前にVMスナップショットまたはディスクスナップショットを取得する。OSレベルの切り戻しが最も確実
• ステージング環境での検証：本番と同一のOSバージョン・リポジトリ構成でストリーム切替とアプリ動作確認を先行して実施する
• メンテナンスウィンドウの確保：切替後の検証と想定外のロールバックに必要な時間を含めたウィンドウ設定が重要。一般的には最低1〜2時間程度のバッファを見込む
• サービスの切り離し：ロードバランサ配下のサーバであれば、事前に対象ノードをトラフィックから切り離してから作業する

RHEL10移行期における依存関係管理設計の変化（2026年現行環境）

2025年5月にリリースされたRHEL10では、RHEL8で導入された従来型のAppStreamモジュラリティが廃止されました。dnf moduleコマンド自体はRHEL10にも存在しますが、RHEL8/9のようにストリームを切り替えてバージョンを管理するモデルは採用されていません。

RHEL10のAppStreamでは、パッケージのバージョン管理をモジュールではなくパッケージセット（リポジトリの通常パッケージ）として提供する方向に移行しています。複数バージョンが必要な場合はSCL（Software Collections）の後継的な仕組みや、コンテナによる分離が主な選択肢になります。

この変化がRHEL10移行設計に与える影響として押さえておくべき点は次のとおりです。

• RHEL8でモジュールストリームによって固定していたパッケージバージョンが、RHEL10移行後には同じ方法で固定できなくなる
• 移行前に「何のバージョンをどの理由で固定しているか」を棚卸しし、RHEL10上での代替管理手段（コンテナ化・dnf versionlock・独自リポジトリ管理）を検討する必要がある
• RHEL9はモジュール対象を絞りながらも従来構造を維持しており、RHEL8→RHEL9→RHEL10の段階移行では依存関係の変化が2回発生する点に注意が必要
• EUS（Extended Update Support）を使って移行時期をコントロールしている場合でも、モジュラリティの廃止はサポート期間とは独立した設計課題として扱う

RHEL10への移行を計画中の環境では、現在のモジュール依存設計の文書化を早めに進めることが、移行後のトラブルを減らすうえで有効です。dnf module list --enabledとrpm -qaの出力を組み合わせ、有効ストリームごとにどのパッケージが紐づいているかを整理しておくと、移行計画のインプットとして使いやすくなります。

モジュールストリームの切替は、適切な事前確認と検証プロセスを踏めばリスクを管理できる作業です。2026年時点ではRHEL8のEOLが2029年まで延長されており、まだしばらくRHEL8の本番環境は稼働し続けます。モジュール依存の設計を今のうちに整理しておくことが、将来の移行作業をスムーズにする土台になります。