RHEL7 からRHEL8へのアップグレードより、RHEL9ベースにリプレイスをお勧めした理由

過去2回、「詳細解説 EOL目前　これからの Red Hat Enterprise Linux7 利用についてのウェビナー」を開催した中で寄せられたQ&Aを基に関心の高かった話題に触れてみたいと思います。

こちらの記事はあくまでも一つの見解として参考にして頂けたらと思います。アプリケーションやシステムの特性、運用形態などにより最も良い選択というのは異なるため、いくつかのプランを検討いただきながら最適だと思われるプランを選択いただけらと考えております。

RHEL7の状況

Red Hat Enterprise Linux（RHEL） 7 は2024年6月30日にEnd of Lifecycle（EOL）を迎えるためサポート終了後の運用を検討しなければなりません。

リプレイス計画が完了していない場合、多くのシステムでは当面は塩漬けで運用したい。として、延長サポート契約（ELS）の購入を検討されていると思います。ただし、延長サポートも最大で4年間の提供となるため、いつかはシステムをアップグレードするかリプレイスを行わなけれななりません。

2024年6月以降に取れる主なRHEL7の移行計画を考えると下記の図のようになります。

セミナー内では詳細を触れましたが、延長サポートなしにサブスクリプションのみ更新して利用を続けるという方法もありますが、これは昨今のセキュリティリスクを考えると非常に危険な運用になると考えております。境界防御が突破されてしまった後は内部の脆弱なシステムを検索し侵入を試みる手法が存在しているため、EOLを迎えたまま無防備に運用されているシステムは標的にされる恐れがあります。

上記理由より企業のシステムにおいて「Non ELS RHEL7」の利用は推奨しておりません。

また、アップグレードツール「Leapp」を利用してRHEL8にアップグレードすることも可能ですが、このアップグレードにもいくつかの懸念点がありますので次の項目より詳細を述べたいと思います。

RHEL7からRHEL8のアップグレードの注意点

レッドハットでは、アップグレードツールとして「Leapp」を提供しています。システムによってはアップグレードツールの実行だけでRHEL7で稼働していたものがRHEL8にアップグレードできます。

しかし、多くのシステムではミドルウェアからアプリケーションまで多数の関連パッケージが導入されており、RHELが提供するパッケージだけでもバージョン互換を気にしなければならない数は相当数になる場合があります。

下記URLにてRHEL8に移行する際にRHEL7から変更される主なパッケージの一覧を確認することができます。まずはこちらの一覧より該当するパッケージのバージョンがどのように置き換えられるのか一覧を作成いただき、置き換え後のバージョンがアプリケーションやミドルウェアが対応するのかをご確認頂くのが良いかと考えます。

参考資料：RHEL 8 の導入における検討事項（RHEL7からRHEL8への変更点）
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index

次では一例としてWEBアプリケーションサーバーのよくある構成として Apache HTTP Server、PHP、PostgreSQLの構成を移行する場合のバージョンの相違を見てみましょう。

Apache HTTP Server

Apache HTTP Server は、RHEL 7 のバージョン 2.4.6 から、RHEL 8 のバージョン 2.4.37 に更新されます。外部モジュールの設定および Application Binary Interface (ABI) のレベルでは下位互換が保たれているとされているため、HTTP Serverでの懸念点限定的になりそうです。

新たに追加された機能の他に、削除されたモジュールや機能などもあるためリプレイスの場合はそちらの項目に注意をしてください。既存のHTTPサーバーが利用しているモジュールや設定項目については事前にリストしておくことで確認がスムーズに行えます。

新機能は次のとおりです。

httpd モジュール含まれる mod_http2 パッケージにより、HTTP/2 に対応するようになりました。
systemd ソケットのアクティベーションが対応します。詳細は、man ページの httpd.socket(8) を参照してください。

新しいモジュールが複数追加されています。

mod_proxy_hcheck – プロキシーのヘルスチェックモジュール
mod_proxy_uwsgi – Web Server Gateway Interface (WSGI) プロキシー
mod_proxy_fdpass – クライアントのソケットを別のプロセスに渡す
mod_cache_socache – HTTP キャッシュ (例: memcache バックエンドを使用)
mod_md – ACME プロトコルの SSL/TLS 証明書サービス

以下のモジュールはデフォルトで読み込まれるようになりました。

mod_request
mod_macro
mod_watchdog

新しいサブパッケージ httpd-filesystem が追加されています。これには、Apache HTTP Server の基本的なディレクトリーレイアウト (ディレクトリーの適切な権限を含む) が含まれます。

インスタンス化されたサービスのサポート httpd@.service が導入されました。詳細は、man ページの httpd.service を参照してください。

新しい httpd-init.service が %post script に置き換わり、自己署名の鍵ペア mod_ssl を作成します。
(Let’s Encrypt などの証明書プロバイダーで使用するため) 自動証明書管理環境 (ACME) プロトコルを使用した、TLS 証明書の自動プロビジョニングおよび更新に、mod_md パッケージで対応するようになりました。

Apache HTTP Server が、PKCS#11 モジュールを利用して、ハードウェアのセキュリティートークンから、TLS 証明書および秘密鍵を直接読み込むようになりました。これにより、mod_ssl 設定で、PKCS#11 URL を使用して、SSLCertificateKeyFile ディレクティブおよび SSLCertificateFile ディレクティブに、TLS 秘密鍵と、必要に応じて TLS 証明書をそれぞれ指定できるようになりました。

/etc/httpd/conf/httpd.conf ファイルの新しい ListenFree ディレクティブに対応するようになりました。

Listen ディレクティブと同様、ListenFree は、サーバーがリッスンする IP アドレス、ポート、または IP アドレスとポートの組み合わせに関する情報を提供します。ただし、ListenFree を使用すると、IP_FREEBIND ソケットオプションがデフォルトで有効になります。したがって、httpd は、ローカルではない IP アドレス、または今はまだ存在していない IP アドレスにバインドすることもできます。これにより、httpd がソケットをリッスンできるようになり、httpd がバインドしようとするときに、基になるネットワークインターフェイスまたは指定した動的 IP アドレスを起動する必要がなくなります。

ListenFree ディレクティブは、現在 RHEL 8 でのみ利用できます。

その他の主な変更点は次の通りです。

以下のモジュールが削除されました。削除されたモジュールを利用している場合は別途導入するから代替設定を有効にして頂くなどの対処が必要になります。

mod_file_cache
mod_nss
代わりに mod_ssl を使用します。mod_nss からの移行の詳細は、さまざまな種類のサーバーのデプロイメントのApache Web サーバー設定で秘密鍵と証明書を使用できるように NSS データベースからの証明書のエクスポートを参照してください。
mod_perl

RHEL 8 の Apache HTTP Server が使用するデフォルトの DBM 認証データベースのデフォルトタイプが、SDBM から db5 に変更になりました。

Apache HTTP Server の mod_wsgi モジュールが Python 3 に更新されました。WSGI アプリケーションは Python 3 でしか対応していないため、Python 2 から移行する必要があります。

Apache HTTP Server を使用してデフォルトで設定されたマルチプロセッシングモジュール (MPM) は、マルチプロセスのフォークモデル (prefork として知られています) から、高パフォーマンスのマルチスレッドモデル event に変更しました。

スレッドセーフではないサードパーティーのモジュールは、交換または削除する必要があります。設定した MPM を変更するには、/etc/httpd/conf.modules.d/00-mpm.conf ファイルを編集します。詳細は、man ページの httpd.service(8) を参照してください。

suEXEC によりユーザーに許可される最小 UID および GID はそれぞれ 1000 および 500 です (以前は 100 および 100 でした)。

/etc/sysconfig/httpd ファイルは、httpd サービスへの環境変数の設定に対応するインターフェイスではなくなりました。systemd サービスに、httpd.service(8) の man ページが追加されています。

httpd サービスを停止すると、デフォルトで自動停止が使用されます。

mod_auth_kerb モジュールが、mod_auth_gssapi モジュールに置き換わりました。

PHP

RHEL7 の PHP 5.4 から RHEL8 では PHP 7.2 に更新されます。RHEL 7 で利用できた機能に対する重要な変更が追加されています。アプリケーションソフトをご利用の場合は該当のバージョンへの対応状況をご確認ください。

設定の変更やログ出力の変更による影響が出る場合がありますので、既存のPHPの設定については事前にリストいただき確認頂くことをお勧めいたします。

PHP はデフォルトで FastCGI Process Manager (FPM) を使用します (スレッド化された httpd で安全に使用できます)。
php_value 変数と php-flag 変数が httpd 設定ファイルで使用されなくなり、代わりにプール設定の /etc/php-fpm.d/*.conf で設定する必要があります。
PHP スクリプトのエラーと警告のログは、/var/log/httpd/error.log ではなく /var/log/php-fpm/www-error.log ファイルに記録されます。
PHP の max_execution_time 設定変数を変更する時は、変更した値に合わせて httpd ProxyTimeout 設定を増やす必要があります。
PHP スクリプトを実行するユーザーが、FPM プール設定 (apache ユーザーがデフォルトとなる /etc/php-fpm.d/www.conf ファイル) に設定されるようになりました。
設定を変更した場合、または新しい拡張機能をインストールした場合は、php-fpm サービスを再起動する必要があります。
zip 拡張が、php-common から、別のパッケージ php-pecl-zip に移動しました。

以下の拡張機能が削除されました。

aspell
mysql
(拡張機能の mysqli および pdo_mysql は、php-mysqlnd パッケージで引き続き利用できます)
memcache

PostgreSQL

RHEL 8 では PostgreSQL データベースサーバーのバージョンを2つ利用できます。デフォルトでは PostgreSQL 10 が提供される他、PostgreSQL 9.6 についても提供されます。

RHEL 7 では PostgreSQL 9.2 が提供されていましたのでデータベースのバージョンが上がることでの動作については確認が必要になります。データベースの場合、機能的な要件の他にも性能面への影響についても確認頂くことを推奨いたします。

PostgreSQL 9.6 の主な変更点と機能拡張

一連の動作の並列実行 – scan、join、および aggregate
同期レプリケーションの機能強化
フレーズを検索できるように、フルテキスト検索が改善
postgres_fdw データ連携ドライバーが、リモートの join、sort、UPDATE、および DELETE の操作に対応
(特に、マルチ CPU ソケットサーバーのスケーラビリティーに関する) 重要なパフォーマンスの向上

PostgreSQL 10 の主な変更点と機能拡張

publish キーワードおよび subscribe キーワードを使用した論理レプリケーション
SCRAM-SHA-256 メカニズムを基にした強力なパスワード認証
宣言型テーブルのパーティション
改善されたクエリーの並列処理
重要な一般的なパフォーマンスの向上
改善された監視および制御

以上のように、3つのパッケージでも検討しなければならない項目は多数あげられます。ご利用のRHEL7の現状を把握してRHEL8へアップグレードすることの影響度の事前確認は必須となりますのでご検討の方は「RHEL 8 の導入における検討事項（RHEL7からRHEL8への変更点）」を参考に事前確認を実施ください。

また、机上の確認だけでなく、評価環境を用意いただきまして実際にアプリケーションが動作するところまでをご確認頂くことが確実です。

このような課題があるため、アップグレードはツールで簡単にという状況にはならいため、アップグレードのためにエンジニア工数が多数発生するのであれば、アップグレードよりもリプレイスの方がかかる工数が少なく済む事があります。また昨今のセキュリティインシデントを配慮した設計を再検討頂くことでシステムの安定感なども向上させることができます。

これがセミナーにおいてアップグレードよりもRHEL9向けに再設計をしてリプレイスをした方が良い場合があり、どちらも検討できるのであればリプレイスをお勧めしたいと説明していた背景になります。

のようなシステムであっても現状を把握してどのような移行が可能なのかを検討し、最善と思われる選択肢を選ぶということが重要になります。ぜひ本記事も参考にいただきましてRHEL7の移行についての検討を加速いただけたらありがたいです。

参考URL：RHEL7 から RHEL8 へのアップグレードを実現するツール「Leapp」を試してみる