RHEL 9→10 本番移行設計｜パッケージ互換性の事前検証と段階ロールアウト計画

RHEL 10 移行の背景と主な変更点

Red Hat Enterprise Linux 10（以下 RHEL 10）は 2025 年にリリースされ、Fedora 40/41 ベースのカーネル 6.11 系、Python 3.12 をデフォルトインタープリタとして採用しました。RHEL 9 からの移行では、単なるカーネルバージョンの変更にとどまらず、C ライブラリ（glibc）の更新、OpenSSL 3.x への完全移行、SHA-1 証明書のデフォルト無効化、そして systemd 256 系への移行が重なります。これらの変更が組み合わさることで、RHEL 9 上で動作していたアプリケーションやミドルウェアが RHEL 10 で予期せぬ動作をするケースが生じます。

また、RHEL 10 ではイメージベースのシステム管理（bootc）が本格的に選択肢に加わりました。従来の RPM ベースのインプレース更新に加え、コンテナイメージとしてOS全体を管理するアプローチが公式にサポートされています。ただし、既存の RPM 環境からの移行は依然として leapp ツールを中心とした手順が主流であり、本記事ではそちらを中心に扱います。

事前検証フェーズ：leapp preupgrade による互換性診断

インプレース移行の事前検証には leapp preupgrade コマンドを使います。このコマンドは実際のアップグレード処理を行わず、対象ホストの現状を分析してレポートを生成します。実行前に RHEL サブスクリプションが有効であること、および leapp パッケージと leapp-repository の最新版がインストールされていることを確認してください。

sudo dnf install leapp leapp-upgrade
sudo leapp preupgrade

レポートは /var/log/leapp/leapp-report.txt に生成されます。出力の各項目は「inhibitor（移行ブロック）」「high（要対処）」「medium（確認推奨）」の 3 段階で分類されます。inhibitor が残った状態ではアップグレードが進みません。

よく検出される inhibitor の例

• カスタム RPM パッケージのうち RHEL 10 の AppStream に対応するバージョンが存在しないもの
• Python 2 系バイナリへの依存（RHEL 10 では python2 が完全に除去）
• SHA-1 署名の自己証明書が TLS 設定に含まれている場合
• GRUB2 の非標準設定やカスタムカーネルパラメータ
• サードパーティのカーネルモジュール（dkms 経由で導入されたドライバ等）

inhibitor を解消せずに移行を強行することはできませんが、medium 以下の警告についても、本番稼働に影響する可能性があるものは個別に調査しておくことを推奨します。

パッケージ互換性の体系的な確認手順

leapp のレポートだけでは把握しきれない依存関係を洗い出すために、移行前に以下の確認作業を行います。

インストール済みパッケージの棚卸し

rpm -qa --queryformat '%{NAME} %{VERSION} %{RELEASE} %{ARCH}\n' | sort > /tmp/rhel9-packages.txt

このリストを RHEL 10 の AppStream および BaseOS のパッケージ一覧と突き合わせます。Red Hat の dnf repoquery を RHEL 10 リポジトリに向けた一時環境（コンテナや VM）で実行するとより正確です。

Python スクリプト・アプリケーションの依存確認

Python 3.12 では、いくつかの標準ライブラリが削除または移動されています。distutils は Python 3.12 で完全に除去されており、setuptools 経由での提供に切り替わっています。既存の pip パッケージや自作スクリプトが distutils に直接依存している場合は移行前に修正が必要です。

grep -r "from distutils" /opt/your-app/ /usr/local/lib/

OpenSSL 3.x への移行と暗号化ポリシー

RHEL 10 では OpenSSL 3.x と systemwide crypto-policies がさらに厳格化されています。SHA-1 は既定で完全に無効となり、レガシーな TLS 1.0 / 1.1 接続も許可されません。内部サービス間の mTLS、古いバージョンの Java アプリケーションが使用する KeyStore、LDAPS 接続などは事前に動作確認環境で検証してください。

暗号化ポリシーの現在の設定は update-crypto-policies --show で確認できます。移行後に問題が発生した場合は update-crypto-policies --set LEGACY で一時的に緩和することも可能ですが、長期的な解決策にはなりません。

段階ロールアウト計画の設計

本番環境への RHEL 10 移行は、単一のメンテナンスウィンドウで全台を切り替えるのではなく、段階的なフェーズに分けて実施することが一般的な運用上の判断です。以下は典型的な段階設計の考え方です。

フェーズ 1：検証環境・ステージング環境での完全移行テスト

本番と同等の構成を持つ検証環境で leapp upgrade を実行し、アプリケーション動作・サービス起動・ログ出力を確認します。この段階で判明した問題を修正スクリプトや Ansible プレイブックにまとめておくことで、後続フェーズの作業を均質化できます。

フェーズ 2：低リスクのサーバー群（バッチ処理・内部ツール等）

トラフィックや可用性要件が低いサーバーから移行を開始します。ここで運用手順の実効性を確認し、想定外の事象が起きた場合の対応時間を把握します。移行後 1 週間程度の監視期間を設け、問題がなければ次フェーズへ進みます。

フェーズ 3：本番サービス群（ブルーグリーン or ローリング）

フェーズ 3：本番サービス群（ブルーグリーン / ローリング）

本番サービス群の移行では、ロードバランサ配下で RHEL 10 ノードと RHEL 9 ノードを共存させるブルーグリーン方式か、順次切り替えるローリング方式のいずれかを選択します。ブルーグリーン方式は切り戻しが即時に行えますが、一時的に倍のリソースが必要です。ローリング方式はリソース効率が高い反面、切り戻しに時間がかかります。サービスの性質とリソース制約に応じて選択してください。

いずれの方式でも、移行対象ノードを切り替える前後でアプリケーションのヘルスチェックが正常を示していることをロードバランサのログで確認する手順を Runbook に明記しておくことが重要です。

移行後の検証と切り戻し計画

移行直後の確認項目

• systemctl --failed でサービス起動失敗がないことを確認
• journalctl -p err -b で移行後の起動ログにエラーがないか確認
• アプリケーション固有のヘルスチェックエンドポイントへの疎通確認
• cronジョブ・systemd timer の動作確認
• SELinux のアクセス拒否ログ確認（ausearch -m avc -ts today）

切り戻し手順の事前設計

leapp によるインプレース移行は、完了後に RHEL 9 へ自動で戻す機能を持っていません。切り戻しを担保するためには、移行前に以下のいずれかを準備しておく必要があります。

• 仮想マシン・クラウドインスタンスの場合：移行前のスナップショットを取得し、移行後 24〜48 時間は削除しない運用ルールを設ける
• 物理サーバーの場合：移行前にシステムディスクのバックアップ（Relax-and-Recover 等）を取得するか、RHEL 9 用の予備ディスクを用意する
• ブルーグリーン方式の場合：RHEL 9 ノードをロードバランサから外しても完全に廃棄せず、一定期間保持する

切り戻し判断の基準（例：移行後のエラーレートが閾値を超えた場合、特定のサービス起動に失敗した場合）をあらかじめ Runbook に記載し、現場判断のブレを防ぐことが大切です。

2026年現行環境での注意点と差分情報

2026 年時点で RHEL 10 は GA 後の初期マイナーアップデート（10.1 系）が提供されており、leapp ツール自体もアップデートされています。以下の点は 2025 年初期の情報から変化している可能性があるため、実施前に公式ドキュメントと Red Hat ナレッジベースで最新情報を確認してください。

• leapp のバージョン確認：leapp --version を実行し、Red Hat の公式サポートマトリクスで RHEL 9→10 のパスが現在もサポートされているか確認する
• EUS（Extended Update Support）の扱い：RHEL 9 の特定マイナーリリースを EUS で固定している場合、leapp の前提条件として最新マイナーへの更新が必要になる場合がある
• FIPS モード環境：FIPS 準拠環境では移行手順に追加の考慮事項が加わります。Red Hat の FIPS 対応ガイドを別途参照してください
• SELinux ポリシーの更新：RHEL 10 では SELinux ポリシーが更新されており、RHEL 9 で permissive モードで運用していたカスタムポリシーが移行後に予期せぬ拒否を引き起こすケースが報告されています。enforcing モードでのテストを移行前のステージング環境で必ず実施してください
• NetworkManager の設定形式：一部の古い ifcfg 形式の設定ファイルは RHEL 10 で読み込まれない場合があります。/etc/NetworkManager/system-connections/ 配下の keyfile 形式への変換を事前に確認してください

RHEL 9 のメンテナンスフェーズは 2032 年まで続く予定ですが、RHEL 10 への移行を中長期の運用計画に組み込んでおくことで、ソフトウェアスタック全体の近代化と将来的なサポート切れリスクの低減につながります。段階ロールアウトと事前検証のフレームを整えておくことが、本番移行の安定性を支える基盤になります。