Rocky Linux 10移行を本番前に検証する｜9系との差分把握とサービス動作確認・切り戻し設計

Rocky Linux 10移行が現場に突きつける課題

Rocky Linux 10はRHEL 10を上流とするメジャーバージョンであり、9系から継続してきた環境をそのまま移行できるわけではありません。カーネル・暗号ポリシー・パッケージエコシステムのいずれにも9系との非互換変更が含まれており、「apt upgradeのように上書きすればOK」という感覚で臨むと本番環境で予期しないサービス停止を招きます。

特に2026年時点での現場では、Rocky 9上でPython 3.9系のアプリケーションを動かしてきた環境や、iptablesの設定をそのまま流用してきたサーバが少なくありません。Rocky 10ではこれらの前提が崩れるケースがあるため、本番投入前に検証環境で差分を把握し、サービスごとに動作確認と切り戻し設計を済ませておくことが実務上の最低ラインとなります。

本記事では、検証環境の構築から9系との主要差分の確認、サービス動作テストの進め方、そして切り戻し設計の考え方まで、移行作業を1本で完結できるよう整理します。

Rocky Linux 10と9系の主要差分を整理する

移行を検討する前に、9系から10系で変わる点を把握しておく必要があります。以下は実務で影響を受けやすい主要な変更です。

カーネルと暗号ポリシー

Rocky Linux 10はカーネル6.12系LTSを採用しており、Rocky 9のカーネル5.14系から大きく進んでいます。eBPFの機能拡張・io_uringの安定化が進んでいる一方、一部のカーネルモジュールの名称変更やパラメータ非互換が生じています。modprobeで独自モジュールを読み込んでいる環境では事前に確認が必要です。

暗号ポリシーの面では、SHA-1がデフォルトで無効化されています。Rocky 9ではupdate-crypto-policies --set DEFAULT:SHA1で有効化できましたが、10系ではさらに制約が厳しくなっており、古いSSL証明書や古いSSH鍵形式を使ったシステムとの通信が切れるケースが報告されています。

パッケージマネージャとアプリケーションランタイム

Rocky 10ではDNF5がデフォルトのパッケージマネージャとなりました。コマンド体系自体は後方互換性を保っていますが、プラグインAPIが変更されており、Rocky 9向けのDNFプラグインをそのまま持ち込もうとすると動作しない場合があります。

Pythonのデフォルトバージョンは3.12系となり、Python 3.9はAppStreamからも外れています。Django・FastAPI・Flask系のアプリを動かしている環境では、venvの再構築とパッケージの依存解決を検証環境で先行して確認する必要があります。同様に、PHP 8.4がデフォルト提供となり、PHP 7.4系は公式リポジトリからは入手できません。

ネットワークとファイアウォール

Rocky 9でも非推奨とされていたiptablesは、Rocky 10ではnftablesに完全置き換えされており、iptablesコマンド自体がデフォルトでインストールされません。firewalldのバックエンドはnftablesに統一されているため、/etc/sysconfig/iptablesやip6tablesのルールファイルを直接管理していた環境は移行が必要です。

検証環境の構築方針

本番と切り離した検証環境を用意することが移行作業の前提です。物理サーバが用意できない場合も、KVMやlibvirtを使った仮想マシン、あるいはPodmanのコンテナを組み合わせることで、ほぼ同等の動作確認が可能です。

推奨される構成は、本番のRocky 9環境をrsyncまたはスナップショットで複製し、Rocky 10のクリーンインストール環境に対してサービスを一本ずつ移植していく方法です。「本番環境のクローンを10系に上書き」という手順は、公式もサポートしていないため避けてください。Rocky Linux 10への移行はin-placeアップグレードではなく、新規インストール＋設定移植が基本です。

検証環境の準備手順の概要は次のとおりです。

• Rocky Linux 10の最小構成ISOを入手し、検証用VMまたはベアメタルにインストールする
• 本番環境でインストール済みパッケージ一覧をrpm -qa --qf '%{NAME}\n' | sort > pkg_list_rl9.txtで書き出す
• 検証環境に同名パッケージが存在するかdnf install $(cat pkg_list_rl9.txt)を試行し、解決できなかったパッケージを記録する
• 本番の設定ファイル（/etc以下の主要ファイル）を検証環境にコピーし、差分をdiffで確認する
• サービスごとに起動確認と疎通テストを実施する

パッケージ名が変更・統合されているものも少なくないため、インストール失敗が出た場合はDNF5のdnf searchやdnf providesで代替パッケージを探します。

サービスごとの動作確認手順

検証環境が整ったら、サービス単位で動作確認を進めます。ここでは典型的な構成（Webサーバ・データベース・スクリプト処理）ごとのポイントを整理します。

Webサーバ（Apache / Nginx）

ApacheはRocky 10でもhttpdパッケージとして提供されています。ただし、モジュールの構成が一部変更されており、mod_sslの暗号スイート設定がシステムの暗号ポリシーに従うよう強制されています。Rocky 9から引き継いだSSLCipherSuiteの設定値が拒否される場合は、update-crypto-policiesの設定またはApache側の設定を見直します。

Nginxも同様に、TLSの設定ファイルを移植した際に古いssl_protocolsの指定でエラーになるケースがあります。検証環境でnginx -tを実行して構文エラーがないことを確認したうえで、実際のHTTPS通信が成立するかをcurlの-vオプション付きで確認します。

データベース（MySQL / PostgreSQL）

MySQL 8.4系がRocky 10のAppStreamで提供される見通しですが、8.0から8.4へのアップグレードはデータ辞書の構造変更を伴うため、ダンプ＋リストアによるデータ移行を推奨します。mysqldumpで取得したSQLファイルを検証環境のMySQL 8.4にインポートし、文字コード設定（utf8mb4）やストレージエンジンの設定が引き継がれているかを確認します。

PostgreSQLはメジャーバージョン間の移行にpg_upgradeが使えますが、エクステンションのバイナリ互換がなくなるケースがあるため、pg_upgrade --checkで事前チェックを必ず実施します。

スクリプト・バッチ処理

cronやsystemd timerで動作するPythonスクリプトについては、Python 3.12での文法非互換（型アノテーションの変更、asyncioAPIの一部変更など）がないかを静的解析ツール（pyflakes・ruffなど）で確認します。特に、datetime.utcnow()はPython 3.12でdeprecationワーニングが出るため、datetime.now(timezone.utc)への書き換えが必要です。

シェルスクリプトでiptablesコマンドを直接呼んでいる場合は、nftablesの等価な記述への書き換えか、firewalld経由での操作に変更します。

切り戻し設計の考え方

本番移行時に問題が発生した場合に備え、切り戻し手順を事前に設計・文書化しておくことが運用上の基本です。Rocky Linuxの場合、in-placeダウングレードはサポートされていないため、切り戻しは「旧環境への復帰」として設計します。

物理サーバや仮想マシンの場合、最も確実な切り戻し手段はスナップショットまたはフルバックアップです。KVM/libvirt環境ではvirsh snapshot-create-asで移行前スナップショットを取得しておくと、問題発生時に数分でRocky 9の状態に戻せます。クラウド環境であれば、AMIやマシンイメージとして9系の状態を保存しておきます。

ロードバランサやDNSの切り替えを伴う構成では、Blue-Greenデプロイの考え方を取り入れると切り戻しが容易になります。Rocky 9の旧サーバをしばらく並行稼働させておき、Rocky 10の検証が完了してから旧サーバを停止するという手順です。DNSのTTLを事前に短縮しておくと、問題発生時の切り戻し速度が上がります。

切り戻し判断の基準もあらかじめ定めておくことが重要です。「移行後X時間以内にエラーレートがY%を超えた場合は即時切り戻す」という数値基準を関係者間で合意しておくと、現場での判断が迷わずに済みます。

2026年現行環境での追加確認事項

2026年8月時点での現行環境では、Rocky Linux 10の登場によってコンテナイメージの管理方針を見直すチームも増えています。Podman 5系がRocky 10に標準搭載されており、Compose V2の動作やネットワークプラグイン（Netavark）の挙動がRocky 9上のPodman 4系と異なるケースがあります。Kubernetes上でのコンテナイメージをRocky 10ベースに切り替える場合は、ベースイメージを変えたうえでCI上でのビルドテストを必ず通すようにします。

SELinuxポリシーについても変更があります。Rocky 10では一部のサービスに対する新しいポリシーモジュールが導入されており、9系でAudit2allowで生成したカスタムポリシーがそのまま適用できないケースがあります。移行後にausearch -m avcでAVCデナイアルが発生していないかを確認します。

サードパーティリポジトリ（EPEL・RPM Fusionなど）のRocky 10対応状況は、2026年時点で概ね整ってきていますが、特定のニッチなパッケージは依然として9系のみ対応という場合があります。本番環境で使用しているサードパーティパッケージをリストアップし、10系対応版があるかをdnf searchで確認するステップを移行チェックリストに含めることを推奨します。

Rocky Linux 10への移行は、Rocky 9のEOLが2032年5月であることを踏まえると、必ずしも今すぐ急ぐ必要はありません。ただし、新規構築するサーバについては10系を選択することで、長期的なサポート期間を確保できます。既存のRocky 9環境については、本記事で整理した手順を参考に検証環境での十分な確認を経たうえで、計画的に移行を進めることが現実的なアプローチです。