「AlmaLinux 9に移行したけど、これもいつかはサポートが切れるよね。次はいつ動けばいい?」
CentOS 8が2021年末に突然EOLを迎えたあの混乱を覚えているだろうか。あの出来事以来、サポート期限を事前に把握しておく重要性を多くのエンジニアが身をもって学んだはずだ。AlmaLinuxはRHELと同じライフサイクルに準拠しているため、計画的な移行が可能だ。しかし、バージョンごとの期限を正確に把握していないと、また同じ轍を踏む羽目になる。
この記事では、AlmaLinux 8・9・10のサポート期限一覧と、EOLを迎えた後に取れる選択肢、そして8・9から10への移行判断フローを解説する。RHEL互換ディストリビューションの中でAlmaLinuxが置かれている現状を整理し、計画的な移行の道筋を示す。
この記事のポイント
・AlmaLinux 8のEOLは2029年5月31日、現在はメンテナンスサポート期
・AlmaLinux 9のEOLは2032年5月31日、2027年まではフルサポート継続
・8→9→10の段階的アップグレードにはleappコマンドを使う(8から10へのダイレクトは非対応)
・CentOS 8から移行済みの環境は2029年に向けた計画を今から立て直す
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AlmaLinuxのサポートサイクルとRHELとの関係
AlmaLinuxはRHEL(Red Hat Enterprise Linux)のバイナリ互換ディストリビューションであり、サポートライフサイクルもRHELに準拠している。RHELのライフサイクルは大まかに3つのフェーズに分かれる。・フルサポート(Full Support):バグ修正・セキュリティパッチ・ハードウェアサポートが全て提供される期間
・メンテナンスサポート2(Maintenance Support 2):重要なセキュリティパッチのみ提供される期間。新機能追加やハードウェア追加は原則なし
・延長ライフサイクルサポート(ELS):有償オプション。Maintenance期間終了後も一定期間のセキュリティパッチを受けられる(Red Hat契約者向け)
AlmaLinuxはRHELのソースコードを元にビルドされるため、RHELと同じタイムラインでサポート期間が設定される。EOL(End of Life)はRHELの「Maintenance Support 2」終了日と同一だ。なお、AlmaLinux独自の有償延長サポートは提供されていない(2026年時点)ため、EOL後はアップグレードまたは移行が必須となる。
バージョン別サポート期限一覧
AlmaLinux 8のサポート期限
AlmaLinux 8はRHEL 8と同じライフサイクルに従う。RHEL 8のフルサポートは2024年5月31日に終了しており、2026年時点ではメンテナンスサポート期にある。| フェーズ | 終了日 | 提供内容 |
|---|---|---|
| フルサポート | 2024年5月31日(終了済み) | バグ修正・セキュリティ・ハードウェア対応 |
| メンテナンスサポート2 | 2029年5月31日 | 重要なセキュリティパッチのみ |
AlmaLinux 8のEOLは2029年5月31日だ。CentOS 8の突然のEOLを受けてAlmaLinux 8へ移行した環境が多いことを考えると、2029年はその次の節目になる。フルサポートはすでに終了しているため、新機能やハードウェアドライバの追加は基本的に期待できない。現在AlmaLinux 8を使っているサーバーは、セキュリティパッチは継続して当たるものの、EOLまで約3年という認識で計画を立てるべきだ。
AlmaLinux 9のサポート期限
AlmaLinux 9はRHEL 9ベース。2026年現在、まだフルサポート期間内にある。| フェーズ | 終了日 | 提供内容 |
|---|---|---|
| フルサポート | 2027年5月31日 | バグ修正・セキュリティ・ハードウェア対応 |
| メンテナンスサポート2 | 2032年5月31日 | 重要なセキュリティパッチのみ |
AlmaLinux 9のEOLは2032年5月31日。2027年以降はメンテナンス期に入るが、EOLまでは6年以上の余裕がある。AlmaLinux 8から9へ移行した環境は、次のEOLに向けた準備は2030年頃から始めれば十分だ。ただし、2027年のフルサポート終了後は新しいパッケージや最新カーネル機能が必要なシステムへの適用が制限されてくるため、その点は留意しておくこと。
AlmaLinux 10のサポート期限(予定)
AlmaLinux 10はRHEL 10(2025年GA)をベースに構築されている。RHEL 10のライフサイクルはまだ全て公式確定していないが、従来の10年サポートのパターンから以下のように推計できる。| フェーズ | 予定終了日 | 備考 |
|---|---|---|
| フルサポート | 2030年5月31日(予定) | RHEL 10 GA:2025年 |
| メンテナンスサポート2 | 2035年5月31日(予定) | 確定次第Red Hat公式で要確認 |
AlmaLinux 10へ移行すれば、EOL問題を約10年先送りにできる。ただし、AlmaLinux 10はまだリリース直後であり、本番環境での安定稼働実績の蓄積が途上にある。本番移行の前には十分な検証期間を設けること。特に、Python・OpenSSL・glibc等の主要ライブラリのメジャーバージョンが変わっているため、自社アプリやスクリプトの互換性確認が必須だ。
現在使用中のAlmaLinuxバージョンの確認方法
移行計画の前に、まず自分のサーバーで何のバージョンが動いているかを確認しよう。# /etc/almalinux-release でバージョンを確認する # cat /etc/almalinux-release AlmaLinux release 9.4 (Seafoam Ocelot) # rpm コマンドでも確認できる # rpm -q almalinux-release almalinux-release-9.4-1.el9.x86_64
マイナーバージョン(9.4の「4」の部分)はセキュリティパッチの累積適用状況を表す。EOL管理はメジャーバージョン(8・9・10)単位で行われるため、マイナーバージョンの古さはEOL判断には直接影響しない。ただし、既知の脆弱性対策として最新マイナーバージョンへのアップデートは常に適用しておくこと。
# 最新マイナーバージョンへのアップデート # dnf update -y # アップデート後にバージョン再確認 # cat /etc/almalinux-release AlmaLinux release 9.5 (Teal Serval)
EOL後の選択肢
AlmaLinuxのEOLを迎えた後、主に3つの選択肢がある。1. leappコマンドでインプレースアップグレード(推奨)
最も現実的な選択肢は、leappコマンドを使ったインプレースアップグレードだ。サーバーを再インストールせずに、稼働中のシステムをメジャーバージョンアップできる。AlmaLinuxが公式サポートするアップグレードパスは以下の通りだ。
・AlmaLinux 8.x → AlmaLinux 9.x:leapp対応(公式サポート済み)
・AlmaLinux 9.x → AlmaLinux 10.x:leapp対応(RHEL 10 GA以降、順次対応)
【重要】AlmaLinux 8から10へのダイレクトアップグレードは非対応。8→9→10と段階的に実施する必要がある。
leappの実行前には必ず
leapp preupgrade でアップグレード可否チェックを行い、阻害要因(inhibitor)がないことを確認すること。本番環境への適用前には、スナップショット取得またはフルバックアップを必ず完了させてから進めること。# leappコマンドのインストール(AlmaLinux 8 → 9 の例) # dnf install -y leapp-upgrade # 事前チェック(阻害要因の確認) # leapp preupgrade --target 9.0 # 問題なければ本番アップグレード実行 # leapp upgrade --target 9.0
2. 新規インストールでクリーン移行
leappが使えない環境(独自カーネルモジュールが多い・サードパーティドライバへの依存が深い等)では、新規インストールによるクリーン移行が安全だ。新サーバーにAlmaLinux 10をインストールし、設定・データを移行する手順になる。手間はかかるが、長年蓄積したレガシー設定をリセットする好機でもある。3. 別ディストリビューションへの乗り換え
RHEL互換系以外への移行も選択肢の一つだ。・Rocky Linux 9/10:AlmaLinuxと同じくRHEL互換。コマンド体系・設定ファイルの互換性が高く、最も移行コストが低い
・Ubuntu Server 24.04/26.04 LTS:RHEL系とはパッケージ管理(apt)・ディレクトリ構造が異なるが、クラウド・コンテナ環境では主流。Ubuntu 26.04 LTS の概要も参考にしてほしい
・クラウドマネージドへの移行:AWS/Azure/GCPのマネージドサービスを使う方法。インフラ管理の手間を削減できるが、運用設計の見直しが必要
ただし、RHEL系からUbuntuへの乗り換えは、運用チームのスキル・既存スクリプト・設定ファイルの書き直しコストが大きい。特に理由がない限りRHEL互換系のままアップグレードするのが現実的だ。
8・9から10への移行判断フロー
移行のタイミングは「まだ時間があるから後回し」にしがちだが、EOLが近づいてから動くと選択肢が急に狭まる。以下のフローで自分の環境を判断してほしい。1. 現在のバージョンを確認する:
cat /etc/almalinux-release2. EOLまでの残り期間を計算する:下記まとめテーブルを参照
3. EOLまで2年以内:移行計画の策定を開始する
4. EOLまで1年以内:検証環境でleapp preupgradeを実行し、阻害要因を洗い出す
5. EOLまで6ヶ月以内:本番移行を完了させる(セキュリティパッチ停止に間に合わせる)
特にAlmaLinux 8環境は2026年時点でEOLまで約3年のため、今年中に移行計画を策定しておくのが理想的だ。セミナーや教育システムなど、年度をまたぐ計画が必要な環境では特に早めの準備が求められる。サーバー移行に先立って体系的なスキルを整理しておきたい方には、Linux Master Pro SeminarでAlmaLinux 10対応のサーバー構築スキルを体系的に身につける方法もある。
移行時のトラブルシュートと注意点
leappでのインプレースアップグレードには既知の注意点がある。事前に把握しておくことで、本番でのトラブルを避けられる。・サードパーティリポジトリ(EPEL等)の無効化:アップグレード前にEPELその他のサードパーティリポジトリを無効化しないと、leappがinhibitorを出してブロックされる
# EPELリポジトリを一時無効化してからleapp preupgradeを実行 # dnf config-manager --set-disabled epel epel-modular # leapp preupgrade --target 9.0 # inhibitorが出た場合、原因ごとに1つずつ解消してから再実行する
・SELinuxポリシーの変更:バージョンアップでSELinuxのモジュールが更新され、以前は許可されていたアクセスがブロックされるケースがある。アップグレード後は
ausearch -m avc -ts recent でSELinux拒否ログを確認すること・独自カーネルモジュール:サードパーティのカーネルモジュール(特定のRAIDカードやNICドライバ等)はバージョンアップ後に再インストールが必要なケースがある。leapp preupgradeのinhibitor出力で事前に検出できる
・「This is an inhibitor」が出たら必ず解消する:inhibitorを無視してのアップグレード強行は絶対にしないこと。システムが起動不能になるリスクがある
本記事のまとめ
AlmaLinux 8・9・10のサポート期限と移行の考え方をまとめた。| バージョン | EOL(End of Life) | 2026年時点の状態 | 推奨アクション |
|---|---|---|---|
| AlmaLinux 8 | 2029年5月31日 | メンテナンスサポート期 | 2027年めどに移行計画策定 |
| AlmaLinux 9 | 2032年5月31日 | フルサポート中(2027年まで) | 2030年めどに計画着手 |
| AlmaLinux 10 | 2035年5月31日(予定) | リリース直後・積極サポート中 | 本番移行前に十分な検証を |
AlmaLinuxはRHELと同じライフサイクルに乗るため、少なくとも10年単位のサポートが期待できる。CentOS 8のような突然EOLは起こらない。ただし「まだ時間があるから」と後回しにすると、EOL直前に選択肢が限られた状態で急いで移行する羽目になる。
AlmaLinux 8を使っている環境は今から移行計画を立て、AlmaLinux 9環境は2027年のフルサポート終了を一つの目安に次のロードマップを描いてほしい。現場のエンジニアとして言えるのは、計画的な移行に失敗はないということだ。EOLを迎えてからでは遅い。
20年以上・3,100名以上の指導実績を持つ宮崎 智広が教える「Linux Master Pro Seminar」では、AlmaLinux 10対応のサーバー構築・移行手順を少人数ハンズオンで体系的に習得できます。
>> セミナー詳細・お申し込みはこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:tasksetコマンドでLinuxプロセスをCPUコアに固定する方法|affinityマスクの確認とsystemd永続化
- この記事の属するカテゴリ:Linuxtipsへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます