Rocky LinuxとAlmaLinux、VPSにはどちらが最適ですか？

Rocky Linux と AlmaLinux の比較：簡潔な回答

ほとんどすべてのサーバーでは、Rocky Linux と AlmaLinux のどちらを選んでも間違いにはなりません。どちらのプロジェクトも Red Hat Enterprise Linux (RHEL) と同じソースコードを再構築しているため、同じパッケージを、10 年の同じサポートライフサイクルでリリースします。違いはありますが、日常的なサーバー運用ではなく、ガバナンスと一部の例外的なケースに現れます。

単純に好みで決められない場合は、2 つの点で判断できます。AlmaLinux 10 は Intel Haswell より古いプロセッサー向けのビルドも引き続き提供しますが、Rocky Linux 10 は提供しません。これは、安価な VPS (virtual private server) のハードウェアや古い VPS ハードウェアを使用する場合に重要です。また、AlmaLinux は完全に同一の動作ではなく ABI 互換性を保証します。厳格なサポート対象表を持つベンダー製品を運用する場合は、この点が重要です。

両方のディストリビューションの成り立ち

2020 年 12 月 8 日、CentOS プロジェクトは、RHEL 8 のリビルドである CentOS Linux 8 を 2021 年末で終了すると発表しました。当初は 2029 年まで提供される予定でした。今後の中心となるのは CentOS Stream です。同じ発表では、CentOS Stream は現行の RHEL リリースより少し先を追跡し、RHEL のアップストリーム開発ブランチとして機能すると説明されました。CentOS Linux 7 は当初の予定を維持し、2024 年 6 月 30 日にサポート終了を迎えました。

問題は CentOS Stream そのものではありませんでした。すでに導入済みのマシンで、2029 年まで続くはずだったライフサイクルが、約 1 年前の告知で 8 年短縮されたことが問題でした。Rocky Linux と AlmaLinux は、そのために生まれました。両方とも 2021 年に登場し、同じ目的を掲げていました。つまり、運用担当者が導入した後、10 年間そのまま運用できる RHEL の無償リビルドです。

Rocky Linux と AlmaLinux に共通する点

まず、共通する部分から確認します。全体の大部分を占めるのがこの共通部分です。どちらも同じ上流の RHEL ソースから再ビルドされるため、パッケージのバージョン、dnf パッケージマネージャー、SELinux（security enhanced Linux）ポリシー、firewalld フロントエンド、systemd unit レイアウトが共通しています。設定ファイルのパスも同じです。一方を対象にしたガイドは、名前を変更するだけで他方でも使用できます。

どちらも RHEL のマイナーリリースをほぼ同じタイミングで追従します。AlmaLinux 10.2 は 26 May 2026 にリリースされ、Rocky Linux 10.2 は 28 May 2026 にリリースされました。9 シリーズも同じ週にリリースされ、AlmaLinux 9.8 は 26 May 2026、Rocky Linux 9.8 は 27 May 2026 でした。以前は差が大きく、AlmaLinux 10.0 は 27 May 2025、Rocky Linux 10.0 は 11 June 2025 にリリースされました。

この差はマイナーリリースのメディアに関するものであり、セキュリティに関するものではありません。両プロジェクトは、マイナーリリースの間も、それぞれの errata サービスから継続的に errata を公開しています。.2 イメージの公開時期が 2 週間異なっていても、その 2 週間にわたってパッチが提供されなかったという意味ではありません。

どちらも、RHEL から引き継いだ 10 年間のライフサイクルモデルを採用しています。おおむね 5 年間はアクティブサポートを提供し、その後の 5 年間はセキュリティのみのメンテナンスを提供します。両方の 10 シリーズは 2035 年まで続きます。

各プロジェクトを支える組織

Rocky Linuxは、CentOSの共同創設者であるGregory Kurtzerが設立した、Delaware州の公益法人Rocky Enterprise Software Foundation（RESF）が管理しています。2022年11月、RESFは付属定款と憲章を承認し、創設者の手から管理権限を移して、これらの文書に基づく運営体制へ移行しました。Kurtzerが設立した企業CIQは設立スポンサーであり、Rocky Linux向けの商用サポートを販売しています。

AlmaLinuxは、2021年3月に設立された、Delaware州で法人化された501(c)(6)の非営利団体AlmaLinux OS Foundationが管理しています。理事会は財団の会員によって4年のずれた任期で選出され、議事録は14日以内に公開されます。また、付属定款により、スポンサー金額にかかわらず、1つの雇用主が議決権を持つ理事席を2つ以上占めることは禁止されています。CloudLinuxがこのプロジェクトを開始し、2024年10月には年間100万ドル相当のプラチナスポンサー契約を更新しました。同社のTuxCare部門が商用サポートを販売しています。

両方の組織構造は、CentOS Linux 8で起きたことを単一の企業が再び起こせないように設計されています。どちらが明らかに安全というわけでもありません。実際に両方で確認できる点は同じです。付属定款を読み、資金を提供している組織を特定できます。

2023 年に何が変わり、現在も重要なのでしょうか？

2023 年 6 月 21 日、Red Hat は CentOS Stream が公開される RHEL 関連ソースコードリリースの唯一のリポジトリになると発表しました。それ以前は、RHEL のパッケージソースが git.centos.org に掲載されており、各再構築プロジェクトはそこからソースを取得していました。このフィードを削除しても、再構築自体は止まりませんでした。ただし、各プロジェクトはソースをどのように取得するのかを公開の場で説明する必要が生じました。

Rocky は 2023 年 6 月 29 日に回答しました。Universal Base Image (UBI) のコンテナーイメージと、従量課金のパブリッククラウドインスタンスから RHEL のソースを取得します。その根拠は、「GPL ソフトウェアの再配布を誰も阻止できない」というものです。2023 年 8 月には、CIQ、Oracle、SUSE が Open Enterprise Linux Association (OpenELA) を設立しました。同組織は、Enterprise Linux とバグ単位で互換性のある再構築に必要なソースを公開しています。AlmaLinux は加盟していません。

AlmaLinux は 2023 年 7 月 13 日に回答しました。その回答は、目標の変更でした。同プロジェクトは 1:1 のバグ単位の互換性を取りやめ、ABI 互換性を採用しました。プロジェクト自身の説明によると、「今後は Red Hat とのバグ単位の互換性に拘束されなくなります。つまり、Red Hat のリリースサイクル外のバグ修正も受け入れられます」。同じ投稿では、日常的な利用における「変更は非常に少ない」とユーザーに説明しています。

3 年が経過した現在、ソースの取得方法に関する問題は、実運用上は決着しています。両プロジェクトはそれ以降、RHEL のすべてのマイナーリリースを、ほぼ同じスケジュールでリリースしてきました。議論の結果として残ったのは、それぞれが何を保証するのかという違いです。

バグ単位の互換性と ABI 互換性の違い

Rocky Linux のホームページでは現在も、このディストリビューションを RHEL と「100% バグ単位で互換」にすることを目指して設計していると説明しています。バグ単位の互換性とは、再構築版が不具合を含めて RHEL の挙動を再現することです。RHEL のパッケージにバグがあれば、Rocky Linux の同じパッケージにもそのバグが含まれます。そのため、Red Hat のナレッジベース記事に記載された回避策を、そのまま適用できます。

ABI 互換性は、より狭く、より正確な概念です。ABI、つまりアプリケーションバイナリーインターフェースは、コンパイル済みプログラムが依存するバイナリーの契約です。シンボル名、構造体のレイアウト、呼び出し規約、ライブラリーのバージョンなどが含まれます。この契約を維持すれば、RHEL 向けにビルドしたバイナリーをロードして実行できます。この保証は、RHEL のバグまで一致させることを意味しません。

この違いによる結果は明確です。AlmaLinux は、Red Hat が修正する前にバグを修正できます。また、Red Hat が削除したドライバーを維持することもできます。どちらも、意図的に RHEL とは異なる挙動にする変更です。Rocky Linux は設計上、そのどちらも行いません。そのため、認証で重視される点において、正確に予測可能な状態を維持します。

必要な保証がどちらなのかを判断する必要があります。サーバーに RHEL とまったく同じ挙動を求めていますか。それとも、RHEL 向けにビルドされたソフトウェアを実行できればよいですか。ほとんどの場合、必要なのは後者です。

RHEL 向けにビルドされたベンダーパッケージは、両方にインストールできますか？

はい。RHEL 9 または RHEL 10 向けにビルドされた RPM は、ABI が一致しており、両ディストリビューションがツールに対して Red Hat 系システムとして認識されるように情報を提示するため、どちらにもインストールして実行できます。その情報を提示するファイルが /etc/os-release です。

NAME="AlmaLinux"
ID="almalinux"
ID_LIKE="rhel centos fedora"

Rocky Linux のコピーも NAME="Rocky Linux" と ID="rocky" を含む同じ形式で、ID_LIKE には rhel も記載されています。ID_LIKE を読み取り、rhel を見つけて Red Hat 用の処理を選択するインストーラースクリプトは、どちらでも動作します。一方、ID と、ハードコードされた rhel、centos、fedora のリストだけを比較するスクリプトは、どちらでも失敗します。両方で同じく、未対応のディストリビューションであるというメッセージが表示されます。これはスクリプトのバグであり、2 つのシステムの違いではありません。

本当の例外は、技術的なものではなく商業上のものです。サポート対象の一覧は、ビジネス上の文書です。ベンダーのパッケージが、その一覧に記載されていないディストリビューションでも問題なくインストールして実行できる場合があります。それでも、問題が発生したときにベンダーがサポートを拒否することはあります。そのサポートに料金を支払っている場合は、一覧を確認し、その内容に従って選択してください。これが、判断を自分で行わなくてよい唯一のケースです。

古い CPU でも動作するのはどれですか？

RHEL 10 では、x86-64 のマイクロアーキテクチャレベルの基準が x86-64-v3 に引き上げられました。このレベルは Intel の Haswell 世代と AMD の Excavator に相当し、AVX2 などの命令セット拡張が必要です。Rocky Linux 10 もこの点で RHEL に従っています。ドキュメントには、x86-64-v3 が基準であり、v2 以前のレベルはサポートされないと記載されています。

AlmaLinux 10 は v3 ビルドをデフォルトで提供し、別途 x86-64-v2 ビルドも追加しています。AlmaLinux の説明では、これは古いハードウェアを使用するユーザーが、さらに 10 年間セキュリティ更新を受けられるようにするためです。AlmaLinux はそのアーキテクチャ向けに EPEL パッケージも再ビルドしています。サードパーティの RHEL 10 パッケージは v3 を対象としているためです。利用前に知っておくべき注意点はここです。v2 ビルドに適しているのは、標準のパッケージセットと AlmaLinux 独自の v2 EPEL です。それ以外のパッケージは、自分で v2 向けに再ビルドする必要があります。

これは、自分で所有するハードウェアよりも VPS で重要です。VPS ではホストのプロセッサを選べないためです。古いホストや低価格のホストでは、ハイパーバイザーがゲストに保守的な CPU モデルを提示することがあります。その場合、物理チップが AVX2 に対応していても、仮想マシンから AVX2 が利用できないことがあります。すると、v3 向けにビルドされたパッケージが、プロセッサにない命令を使用しようとして失敗します。10 系へフリートを移行する前に、実際にインスタンスから利用できる命令を確認してください。両ディストリビューションの 9 系は、引き続き v2 レベルで動作します。x86 インスタンスではなく ARM インスタンスを使用する場合、この問題は発生しません。マイクロアーキテクチャレベルは x86-64 の概念だからです。

同じ柔軟性は AlmaLinux 10 の別の部分にも表れています。プロジェクトは、upstream が削除した 150 以上のデバイスのサポートを再有効化しました。これには、古い RAID および iSCSI コントローラーの PCI ID が含まれます。また、サーバーとクライアントの両方で SPICE のサポートも再有効化しました。フレームポインターはデフォルトで有効です。これにより、システム全体のプロファイリングが可能になります。バグ単位での互換性を保証する方針では、これらの変更を1つも許可できません。そのため、2023 年の方針変更によって、これらの対応を行う余地が生まれました。

既存の CentOS または RHEL サーバーを移行するにはどうすればよいですか？

Rocky Linux は rocky-tools リポジトリで変換スクリプトを公開しています。migrate2rocky.sh は Enterprise Linux 8 システムを Rocky Linux 8 に変換し、migrate2rocky9.sh は 9 系列に対して同じ処理を行います。いずれも同一のメジャーバージョン内でのみ動作します。2026 年 8 月時点で、リポジトリには Enterprise Linux 10 用の同等スクリプトがありません。そのため、Rocky Linux 10 へ移行するには再インストールが必要です。

AlmaLinux は almalinux-deploy.sh を公開しています。Enterprise Linux 8、9、10 に対応し、CentOS Stream、Oracle Linux、RHEL、Rocky Linux、MiracleLinux、Virtuozzo Linux から変換できます。対応アーキテクチャは x86_64、aarch64、ppc64le、s390x です。開始前に、ドキュメントに記載された制限を確認してください。ブートローダーが必要なシステムでは、GRUB2 のみがサポートされます。また、Oracle の UEK（Unbreakable Enterprise Kernel）などのカスタムカーネルは自動的に削除されません。そのため、Secure Boot 有効時にマシンが起動できなくなることがあります。

メジャーバージョンをまたぐ移行には、AlmaLinux が Red Hat の leapp フレームワークを基盤とする ELevate を提供しています。ドキュメントに記載されている移行経路は、CentOS 7 から EL8、AlmaLinux 8 または CentOS Stream 8 から EL9、AlmaLinux 9 または CentOS Stream 9 から EL10 です。移行先を特定のディストリビューション名ではなく EL8、EL9、EL10 と表記しているのは、移行先となる Enterprise Linux ディストリビューションを選択できるためです。

これらの方法では、リリースパッケージを書き換え、システムの大部分を再インストールします。最初にプロバイダーのスナップショットを取得してください。AlmaLinux のドキュメントが推奨しているとおり、screen または tmux 内で変換を実行してください。途中で SSH 接続が切断されると、レスキューコンソールから原因を調査したくない状態でマシンが停止する可能性があります。

では、どちらを選ぶべきでしょうか？

一般的な VPS の用途であれば、どちらでも問題ありません。インストールされるパッケージは同じで、サポート終了年も同じです。どちらか一方を選び、運用するすべてのサーバーで使い、以後は気にしないことを推奨します。両者の違いよりも、一貫性のほうが重要です。混在したサーバー群では、追跡するイメージと errata feed の数が 2 倍になるためです。複数の Linux サーバーを同時に管理するようになると、この負担は急速に増えます。

例外は限定的であり、いずれも好み以外の要因で決まります。

• ホストのプロセッサが Haswell より古い場合、またはハイパーバイザーがゲストから AVX2 を隠している場合。AlmaLinux 10 には x86-64-v2 ビルドがあります。Rocky Linux 10 にはありません。
• 契約しているベンダーが、サポート対象の組み合わせで一方のディストリビューションを指定している場合。そのディストリビューションを使います。
• 認証または監査のために RHEL と完全に同じ動作が必要な場合。Rocky Linux はバグ単位での互換性を目標に掲げていますが、AlmaLinux の目標は明確に異なります。
• 新しいサーバーを構築するのではなく、稼働中のサーバーを変換する場合。AlmaLinux のツールは現在、Enterprise Linux 10 を含め、より多くの移行元ディストリビューションとメジャーバージョンに対応しています。

本当の問題が Enterprise Linux と別の選択肢の比較であるなら、選ぶべきなのはライフサイクルモデルです。Enterprise Linux ディストリビューションでは、1 つのパッケージセットをバージョンジャンプなしで 10 年間使えるため、計画的な大規模アップグレードが不要です。Ubuntu の long term support リリースでは、標準サポートが 5 年間提供され、2 年ごとにサポート対象のアップグレードパスがあります。これは異なる選択肢であり、Ubuntu LTS と interim リリースの比較で詳しく説明しています。どちらをインストールしても、マシンで最初に行う作業は同じです。そのため、何かを配置する前に新しい VPS で最初の 10 分間に行う作業を進めてください。

FAQ

Rocky Linux と AlmaLinux では、どちらが Red Hat Enterprise Linux に近いですか？

Rocky Linux です。Rocky Linux は、RHEL と 100% bug for bug compatible になることを目標に掲げています。これは、RHEL の不具合を含む動作の再現を目指すという意味です。AlmaLinux は 2023年7月13日、代わりに ABI（application binary interface）互換性を目標にすると発表しました。そのため、RHEL 用にビルドされたソフトウェアは AlmaLinux で動作しますが、基盤のコードには RHEL がまだリリースしていない修正が含まれる場合があります。通常のサーバーソフトウェアを実行する場合、両者に実用上の違いはありません。RHEL の動作を指定する認定を取得する場合は、この違いが重要になります。

再インストールせずに Rocky Linux から AlmaLinux へ移行できますか？

はい、その方向であれば可能です。AlmaLinux の almalinux-deploy.sh には、CentOS Stream、Oracle Linux、RHEL、MiracleLinux とともに、Rocky Linux 8、9、10 が対応する移行元として記載されています。逆方向の移行には制限があります。Rocky Linux の rocky-tools repository には Enterprise Linux 8 と 9 用の変換スクリプトしか含まれていないため、2026年8月時点では Rocky Linux 10 へインプレースで移行する方法はありません。変換の前に snapshot を取得してください。また、接続が切れても維持される session から実行してください。この処理では release package が置き換えられ、システムの大部分が再インストールされるためです。

RHEL 用にビルドされた package は、両方で動作しますか？

はい、通常の RPM package と third party repository であれば動作します。両方の distribution は RHEL の application binary interface を維持しています。また、両方とも /etc/os-release 内で ID_LIKE="rhel centos fedora" により自らを識別します。そのため、Red Hat family system を確認する package や installer script は適切な処理を選択します。例外は技術面ではなく、commercial support に関するものです。vendor は、package が両方にインストールされて動作する場合でも、support matrix に記載した distribution だけをサポートすることがあります。そのサポートに料金を支払っている場合は、support matrix を基準にしてください。

古い CPU を搭載した低価格 VPS では、どちらを使用すべきですか？

10 series を使用したい場合は AlmaLinux です。RHEL 10 では x86-64 の基準が v3 microarchitecture level に引き上げられました。これは Intel Haswell または AMD Excavator 相当の processor を必要とします。Rocky Linux 10 もこの基準に従います。AlmaLinux 10 には、古い hardware 向けに追加の x86-64-v2 build が用意されており、10年間の security update が提供されます。導入を決める前に、instance から利用できる機能を確認してください。virtual machine から見えるのは hypervisor が提供する CPU model であり、host の instruction set 全体が常に利用できるとは限らないためです。両 distribution の 9 series は、引き続き v2 hardware で動作します。