戻る

2026/10/19

CentOS Linux 7 や CentOS Linux 8 としてインストールされたサーバーを、今も使い続けている組織は少なくありません。どちらのリリースもすでにサポート終了（EOL）を迎えており、CentOS Project からのセキュリティ更新は提供されません。システム自体は動き続けますが、パッチが当たらない期間が長くなるほどリスクは高まり、監査で指摘されることも増えています。

幸い、現在は信頼できる選択肢がいくつもあります。難しいのはその違いを理解することです。違いは技術面よりも、サポート、ガバナンス、ライフサイクルにあるからです。本記事では、執筆時点の情報をもとに中立的な概要をまとめ、判断の材料をご提供します。

要点

  • CentOS Linux 7 と 8 はすでに更新が提供されていません。CentOS Stream は継続していますが、RHEL の少し先を行く開発ストリームという位置付けです。
  • RHEL、Rocky Linux、AlmaLinux、Oracle Linux はいずれも RHEL 向けのソフトウェアを動かすことを目指していますが、サポートモデルと互換性へのアプローチが異なります。
  • パッケージ形式やツールの違いを受け入れられるなら、Ubuntu と Debian も成熟した選択肢です。
  • サポートの必要性、認定要件、ライフサイクルを基準に選び、そのうえでサーバーごとの移行を計画しましょう。

CentOS Linux と CentOS Stream で何が変わったのか

長年にわたり、CentOS Linux は Red Hat Enterprise Linux (RHEL) の無償リビルドでした。RHEL のリリースに密接に追随していたため、サブスクリプションなしで同じソフトウェアを動かすことができました。2020年12月、CentOS Project は今後 CentOS Stream に注力すると発表しました。CentOS Linux 8 は2021年末に、CentOS Linux 7 は2024年6月末にサポート終了を迎えています。

CentOS Stream は現在も活発で有用なディストリビューションですが、その役割は異なります。次の RHEL マイナーリリースの少し先に位置しており、変更が RHEL に入る前に最初に現れる場所です。そのため今後の変更を試す場としては適していますが、固定的でゆっくりとしか変化しない基盤が必要なサーバーには、あまり自然な選択とはいえません。プロジェクト自身による説明は centos.org でご覧いただけます。

RHEL 互換ディストリビューションのアプローチの違い

現在では、かつて CentOS Linux が占めていた位置をいくつかのディストリビューションが担っています。いずれも RHEL 向けにビルド・認定されたソフトウェアを動かすことを目指していますが、それぞれ独自のアプローチをとっています。

  • Red Hat Enterprise Linux (RHEL) は商用のオリジナルです。サポート、認定済みのハードウェア・ソフトウェアのエコシステム、管理やインプレースアップグレードのためのツールを含むサブスクリプションとともに OS を利用します。
  • Rocky Linux は Rocky Enterprise Software Foundation が運営するコミュニティディストリビューションです。RHEL との完全な互換性を目標として掲げています。
  • AlmaLinux は非営利団体 AlmaLinux OS Foundation が運営するコミュニティディストリビューションです。2023年以降は、完全なリビルドではなく RHEL とのアプリケーションバイナリインターフェース（ABI）互換を目指しており、一部の修正を独自のスケジュールで提供できるようになっています。
  • Oracle Linux は無償でダウンロード、利用、更新ができ、Oracle による有償サポートも用意されています。RHEL 互換カーネルと、Oracle 独自の Unbreakable Enterprise Kernel の両方を提供しています。

ほとんどのワークロードでは、これらのいずれかで動くアプリケーションは、ほかのディストリビューションでもほぼ変更なしで動きます。違いが重要になるのは、ベンダーが自社製品を特定のディストリビューションでのみ認定している場合や、特定のカーネル機能に依存している場合です。

サポートモデル：サブスクリプション、コミュニティ、サードパーティサポート

各選択肢の最も実務的な違いは、問題が起きたときに誰に連絡するかです。執筆時点での主なモデルを下の表にまとめました。条件は変わることがあるため、判断の前に必ず公式ページをご確認ください。

ディストリビューション利用コストサポートの提供元
RHEL有償サブスクリプションRed Hat（サブスクリプションに含まれる）
Rocky Linux無償コミュニティ、およびサードパーティ事業者による商用サポート
AlmaLinux無償コミュニティ、およびサードパーティ事業者による商用サポート
Oracle Linux無償Oracle によるオプションの有償サポート
Ubuntu無償Canonical によるオプションの有償 Ubuntu Pro とサポート
Debian無償コミュニティ、およびサードパーティ事業者による商用サポート

無償であることは、サポートがないことを意味しません。多くの組織がコミュニティディストリビューションを本番環境で運用し、確実な応答時間が必要なシステムに限ってサポートを購入しています。大切なのは、障害が起きてから空白に気づくのではなく、意図的にこれを決めておくことです。

ヒント： データベース、ミドルウェア、バックアップエージェントなど、利用しているすべての商用アプリケーションのサポートマトリクスを確認しましょう。ベンダーが RHEL のみをサポートしている場合、ほかの環境ではコミュニティディストリビューションを使っていても、そのサーバーについてはそれで結論が出ることがあります。

ライフサイクルとリリースサイクルの比較

エンタープライズ Linux の魅力は、メジャーリリースが長期間サポートされることです。RHEL のメジャーリリースには10年のライフサイクルがあり、さらに延長するオプションもあります。Rocky Linux、AlmaLinux、Oracle Linux も、対応するリリースについて同様のスケジュールに従っています。各メジャーバージョン内では定期的にマイナーリリースが提供され、最新のマイナーリリースを使い続けることが、更新を受け取り続けるための通常の方法です。詳細は Red Hat の RHEL ライフサイクルのページで公開されています。

Ubuntu は2年ごとに長期サポート（LTS）リリースを公開しており、5年間の標準セキュリティメンテナンスと、Ubuntu Pro によるさらに長い保守が提供されます。詳しくは Ubuntu のリリースサイクルをご覧ください。Debian はおよそ2年ごとに新しい安定版をリリースしており、コミュニティによる Debian LTS の取り組みが古いリリースのセキュリティサポートを延長しています。詳しくは Debian のリリースをご覧ください。

比較する際は、一般的な方針だけでなく、実際に導入する特定のメジャーバージョンのサポート終了日を確認しましょう。今日導入する基盤は、そのサーバーの計画上の使用期間全体にわたってサポートされている必要があります。

選ぶ前に確認したい質問

唯一の正解はありません。次の質問を検討すると、多くの場合判断のポイントが明確になります。

  1. どのアプリケーションを運用していて、そのベンダーはどのディストリビューションを認定しているか？
  2. すべてのサーバー、一部のサーバー、あるいはどのサーバーにもベンダーのサポート契約が必要か？
  3. チームは dnf などの RPM 系ツールと、apt などの Debian 系ツールのどちらに慣れているか？
  4. 新しい基盤はどれくらいの期間サポートされる必要があり、それは導入するリリースのライフサイクルに合っているか？
  5. 多数のサーバーにわたるパッチ適用、構成管理、コンプライアンスをどのように管理したいか？
  6. 非営利の財団か単一の商用ベンダーかといった、ガバナンスモデルは重要か？

CentOS Linux から移行する多くのチームにとって、RHEL 互換ファミリーにとどまることは、スキル、スクリプト、パッケージを最も多くそのまま活かせる方法です。ほかの環境ですでに Ubuntu や Debian を使っている場合はそれらへの移行も理にかなっていますが、変更はより大きく、より多くのテストが必要です。

既存の CentOS サーバーの移行を計画する

まずは棚卸しから始めましょう。見つけていないものは計画できませんし、CentOS のシステムはアプライアンス、検証環境、古い仮想マシンのテンプレートなどに隠れていることがよくあります。各サーバーでは、いくつかのコマンドで現状を把握できます。

cat /etc/os-release
uname -r
rpm -qa --last | head -n 20
yum repolist enabled

次に、サーバーを稼働しているものと重要度でグループ分けします。グループごとに、次の2つの方法のどちらかを選びます。

  • インプレースで変換する。 同じメジャーバージョン内であれば、各プロジェクトが提供する移行スクリプト（Rocky Linux、AlmaLinux、Oracle Linux 向けなど）や Red Hat の Convert2RHEL ツールにより、再インストールせずにパッケージの取得元とブランディングを切り替えられます。CentOS Linux 7 の場合はメジャーバージョンのアップグレードも必要です。Leapp や AlmaLinux の ELevate プロジェクトなどのツールが役立ちますが、入念なテストが必要です。
  • 再構築して再デプロイする。 最新リリースでクリーンなシステムをインストールし、アプリケーションとデータを移します。サーバーごとの手間は増えますが、既知の、文書化されたベースラインが得られ、長年積み重なった変更を一掃できます。

ヒント： どちらの方法を選ぶ場合も、まずフルバックアップまたはスナップショットを取得し、サーバーのコピーでリハーサルを行いましょう。開始前に、サードパーティのリポジトリ、カーネルモジュール、監視エージェントが移行先のリリースで利用できることを確認してください。

最後に、計画を文書にまとめます。どのサーバーをどの順番で移行するか、誰が承認するか、どのように切り戻すかを書き出しましょう。リスクの低いシステムから移行すると自信がつき、残りの移行を定型作業にできます。AlmaLinux プロジェクトは ELevate の手法を AlmaLinux wiki で文書化しており、各ディストリビューションも独自の移行ガイドを公開しています。

LOGIQ がお手伝いできること

LOGIQ は、残っている CentOS システムの洗い出し、自社のアプリケーションやサポート要件に照らした選択肢の比較、スケジュールに合った移行計画づくりをお手伝いしています。エンタープライズ Linux の計画についてセカンドオピニオンが必要な場合は、logiqlinux.com からお気軽にご連絡ください。