この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そう感じている方に向けて、移行パターンの選び方からalmalinux-deployの実行手順、依存破壊と失敗時の復旧までを1ページにまとめます。
CentOS Linux 8は2021年12月、CentOS Linux 7は2024年6月に正式EOLを迎えています。脆弱性パッチが止まったまま放置されているサーバーを抱えたまま、毎月の脆弱性レポートに目を背けて生きるのはそろそろ限界です。AlmaLinuxはalmalinux-deployという公式変換スクリプトを用意しており、CentOSからのin-placeアップグレードを正式にサポートしています。とはいえ「動いているサーバーを止めずに別のディストリへ書き換える」のは、何度やっても緊張する作業です。
この記事ではCentOS 7／8からAlmaLinux 10への移行手順を、3つの移行パターン比較・almalinux-deploy実行・依存破壊への対処・復旧手順までコマンド例つきで解説します。AlmaLinux 10の特徴やサポート期間を先に把握したい方は「AlmaLinux 10とは｜CentOS後継本命の特徴・MIRACLE LINUX統合・サポート期間まとめ」を、移行ではなくクリーンインストールで再構築したい方は「AlmaLinux 10 インストール手順｜USB作成からminimal/server/workstation構成別設定」を先に読むと判断が早まります。
この記事のポイント
・CentOS 7→Alma 10は8経由の2段階、CentOS 8→Alma 10は直行の1段階
・almalinux-deploy実行前のフルバックアップとサードパーティリポジトリ無効化が必須
・依存破壊はdnf history undoとEPEL差分の再導入で大半が片付く
・失敗時はrescue起動からのGRUB修復、最終手段はバックアップからのリストア
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
移行パターンの全体像と選び方
CentOSからAlmaLinux 10へ寄せる方法は、現実的に3パターンあります。本番サーバーを前にしてどれを選ぶかで、所要時間と事故率が大きく変わります。・in-placeアップグレード：稼働中のCentOSにalmalinux-deployを当ててAlmaLinuxへ変換する。停止時間が短く、データ移行不要。dnf依存の絡まりが既存サーバーに残っていると失敗確率が上がる
・クリーン再構築：新しい仮想マシンや別物理機にAlmaLinux 10をクリーンインストールし、設定ファイルとデータを移植する。最も安全だが工数は最大
・並行運用（Blue-Green）：新旧2台を同時稼働させ、ロードバランサで切り替える。Webアプリ系やAPIサーバーで使える贅沢な選択肢
判断軸は3つです。停止許容時間（メンテナンス窓）、新ハードや新インスタンスを用意できる予算、稼働サーバーの「設定の汚れ具合」です。
私の経験では、3年以上稼働しているサーバーは何らかのサードパーティリポジトリ・手動rpm・カスタムカーネルモジュールが入っているケースがほとんどで、in-placeアップグレードはトラブル切り分けに半日以上かかります。一方、新規構築から1年以内のサーバーやKickstartで自動構築した検証機は、almalinux-deployがほぼ無事故で通ります。
# 既存サーバーの状態を簡易診断する3コマンド # 1. 有効リポジトリ一覧（baseos/appstream以外があるか） $ sudo dnf repolist --enabled repo id repo name appstream CentOS Linux 8 - AppStream baseos CentOS Linux 8 - BaseOS docker-ce-stable Docker CE Stable - x86_64 epel Extra Packages for Enterprise Linux 8 extras CentOS Linux 8 - Extras # 2. 過去に手動で入れたrpmの数 $ rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -v 'CentOS\|Red Hat' | wc -l 47 # 3. カスタムカーネルモジュールの有無 $ lsmod | grep -v -E '^(snd|drm|nvidia|btrfs|xfs|ext4|nf_)' | head
判断に迷ったら、検証環境で同じスナップショットを取って先にalmalinux-deployを通してみるのが一番確実です。本番でいきなり走らせるのは事故のもとです。
移行前の事前準備
どの移行パターンを選ぶにせよ、事前準備で結果がほぼ決まります。almalinux-deployを安心して走らせるために、最低限以下を済ませてください。・フルバックアップ：VM環境ならスナップショット、物理機ならtar＋外部ディスクまたはrsyncで別サーバーへ。/etc・/var・/home・/optは必須
・サードパーティリポジトリの無効化：EPEL以外のリポジトリ（Docker・MySQL公式・Remi・PHP公式等）はあらかじめ
--disable しておく・カスタムカーネルの削除：elrepo-kernel-mlやNVIDIAドライバ等、独自カーネルは事前削除して標準カーネルで起動できる状態に戻す
・空き容量の確保：/と/var/cache/dnfに合わせて10GB以上の空きを確保（ダウンロード＋一時展開＋元RPMの保持）
・本番停止のアナウンス：2時間程度の停止窓を確保。in-placeでも30～90分は見ておく
バックアップの取り方は2系統用意しておくと安心です。VM環境のスナップショットだけに依存していると、ハイパーバイザ側のトラブルで一蓮托生になります。
# 設定系ディレクトリの最低限バックアップ $ sudo tar czf /root/backup-etc-$(date +%Y%m%d).tar.gz /etc /var/spool/cron /opt $ ls -lh /root/backup-etc-*.tar.gz -rw-------. 1 root root 89M Apr 25 22:15 /root/backup-etc-20260425.tar.gz # 別サーバーへ転送（rsync over SSH） $ scp /root/backup-etc-20260425.tar.gz backup@192.168.10.20:/srv/backup/ # サードパーティリポジトリを無効化 $ sudo dnf config-manager --disable docker-ce-stable $ sudo dnf config-manager --disable remi-modular $ sudo dnf repolist --enabled # 空き容量確認 $ df -h / /var ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/sda3 50G 18G 32G 36% / /dev/sda4 80G 25G 55G 32% /var
事前準備の段階でDNF／パッケージ管理の基礎を確認しておきたい方は「dnf/yumコマンドの使い方｜パッケージのインストール・更新・削除とリポジトリ管理」に基本構文をまとめています。CentOS 7時代のyumの感覚そのままで、AlmaLinux 10のDNF 5まで通用する内容です。
almalinux-deployの入手と実行手順
almalinux-deployはAlmaLinux OS Foundationが公式提供する変換スクリプトです。CentOS 8系から直接AlmaLinux 8／9／10へ書き換える設計で、CentOS 7からの移行は「いったんAlmaLinux 8経由」というルールになります。公式リポジトリは以下です。
・GitHub：https://github.com/AlmaLinux/almalinux-deploy
・raw URL（直接実行用）：https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
入手手順は単純です。
# スクリプトを取得して実行権を付ける $ sudo curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh $ sudo chmod +x almalinux-deploy.sh # まずは事前チェックモードで実行（実際の変換は行わない） $ sudo ./almalinux-deploy.sh --check-only Check successful. The system can be migrated.
--check-only は事前診断モードです。CPU要件（AlmaLinux 10はx86-64-v3必須）・カーネル整合・dnfの状態をチェックして、移行可能かを返します。Check successful. が返ってこない場合は、メッセージに従って先に修正します。
1. CentOS 8 → AlmaLinux 10の直行パス
CentOS 8からの移行は1段階で済みます。8系の最新ステートに上げてからalmalinux-deployを当てます。# 1. CentOS 8を最新ステートに上げる $ sudo dnf update -y $ sudo reboot # 2. CentOS 8 → AlmaLinux 8への変換（in-place） $ sudo ./almalinux-deploy.sh ... Migration to AlmaLinux is completed $ sudo reboot # 3. 再起動後、AlmaLinux 8として起動していることを確認 $ cat /etc/almalinux-release AlmaLinux release 8.10 (Cerulean Leopard) # 4. AlmaLinux 8 → AlmaLinux 10へのメジャーアップグレード $ sudo dnf install -y leapp-upgrade leapp-data-almalinux $ sudo leapp preupgrade $ sudo leapp upgrade $ sudo reboot # 5. 再起動後にAlmaLinux 10として起動 $ cat /etc/almalinux-release AlmaLinux release 10.0 (Purple Lion)
2. CentOS 7 → AlmaLinux 10の2段階パス
CentOS 7から直接AlmaLinux 10へは飛べません。almalinux-deployの仕様としてCentOS 7はAlmaLinux 8への変換まで対応しており、その先はleappでAlma 8→9、9→10と段階的に上げます。# 1. CentOS 7を最新ステートに上げる $ sudo yum update -y $ sudo reboot # 2. CentOS 7 → AlmaLinux 8（almalinux-deployがleapp相当の処理を内包） $ sudo ./almalinux-deploy.sh $ sudo reboot # 3. AlmaLinux 8として起動を確認 $ cat /etc/almalinux-release AlmaLinux release 8.10 (Cerulean Leopard) # 4. AlmaLinux 8 → 9 → 10へleappで段階アップグレード $ sudo dnf install -y leapp-upgrade leapp-data-almalinux $ sudo leapp preupgrade --target 9.6 $ sudo leapp upgrade --target 9.6 $ sudo reboot $ sudo leapp preupgrade --target 10.0 $ sudo leapp upgrade --target 10.0 $ sudo reboot
cat /etc/almalinux-release・uname -r を確認してから次へ進めてください。2段階の途中で力尽きそうな場合は、ひとまずAlmaLinux 8（2029年5月までサポート）で止めて運用を再開し、後日AlmaLinux 10へ上げる選択も現実的です。CentOS 7のまま運用するよりはるかに安全になります。
移行中に発生しやすい依存破壊と対処
almalinux-deployとleappは「健全な状態のCentOS／AlmaLinuxを別バージョンへ書き換える」設計のため、依存関係の途中破壊や、サードパーティリポジトリ由来のパッケージがほぼ確実に問題を起こします。代表的な3パターンを潰し方付きで紹介します。依存パターン1：EPEL差分での「No package available」
CentOS版EPELとAlma版EPELで微妙にパッケージ構成が違います。almalinux-deploy後にEPELを再有効化してdnf updateすると、一部パッケージが「No package」になります。
# 古いEPELを除去して新しいEPEL 10系へ差し替える $ sudo dnf remove -y epel-release $ sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm # キャッシュを完全クリアしてから更新 $ sudo dnf clean all $ sudo dnf makecache $ sudo dnf update -y
AlmaLinux 8時代に有効化したモジュール（PHP 7.4・Python 3.8等）が10系には存在せず、leapp upgradeが止まります。
# 有効化中のモジュールを一覧 $ sudo dnf module list --enabled Name Stream Profiles Summary php 7.4 [e] common [d] PHP scripting language python38 3.8 [e] common [d] Python programming language # 該当モジュールをリセットして衝突を解消 $ sudo dnf module reset php python38 -y $ sudo dnf module list --enabled （何も表示されなければOK）
何かパッケージ操作で破壊した場合、直前の操作だけ戻せます。万能ではありませんが、傷を浅くするのに使えます。
# 直近のdnfトランザクション履歴を見る $ sudo dnf history list | head ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------ 42 | install httpd | 2026-04-25 22:30 | Install | 8 41 | update | 2026-04-25 22:15 | Upgrade | 124 # 直前のトランザクションを取り消す $ sudo dnf history undo 42 # 取り消し対象のトランザクション内容を事前確認 $ sudo dnf history info 42
移行完了後の動作確認チェックリスト
leapp upgradeが完了して再起動が通ったら、すぐに動作確認を進めます。「動いている」を体感ではなくコマンド出力で確認してください。# 1. ディストリビューションとバージョン $ cat /etc/os-release | head -4 NAME="AlmaLinux" VERSION="10.0 (Purple Lion)" ID="almalinux" PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)" # 2. カーネル $ uname -r 6.12.0-21.el10.x86_64 # 3. 失敗しているサービスがないか $ sudo systemctl --failed 0 loaded units listed. # 4. パッケージDBの整合性チェック $ sudo dnf check （何も出力されなければOK） # 5. SELinuxラベル再付け（移行直後はラベルがズレやすい） $ sudo touch /.autorelabel $ sudo reboot # 6. 再起動後にSELinuxの状態を確認 $ getenforce Enforcing $ sudo sestatus | grep -E 'Current mode|Loaded policy' Current mode: enforcing Loaded policy name: targeted # 7. 主要サービスの起動を個別確認 $ sudo systemctl is-active sshd firewalld chronyd active active active
systemctl --failed に何か出ている場合は、そのサービスのログを journalctl -u サービス名 --no-pager -n 50 で確認します。SELinux関連のdenyならaudit2allowで例外ポリシーを作る方向で対処してください。SELinuxの基本動作確認は「SELinuxを無効化・確認する方法｜enforcing/permissive/disabled切替とgetenforce・sestatus」にまとめています。無効化は最終手段で、まずはpermissiveでログを取りながら原因切り分けが筋です。ファイアウォールの状態確認は「firewall-cmdコマンドでポートを開放・管理する方法｜ゾーン・サービス・永続化の使い分け」を参照してください。CentOS時代に開けていたポートが移行後もそのまま反映されているかを必ず点検します。
動作確認の段階で「ここまで来れば本番投入できる」と判断できれば、移行は成功と言って差し支えありません。移行直後にユーザーアクセスをいきなり戻すのではなく、社内・関係者だけで30分ほど触ってから一般公開するのが安全です。
失敗時の復旧手順
ここまで気をつけても、失敗するときは失敗します。復旧は「軽症」「中症」「重症」の3段階で考えます。軽症：パッケージ起因の問題
特定サービスが起動しない、特定パッケージが入らない、といった局所的な問題です。
dnf history undo でロールバックするか、該当パッケージを再インストールします。本体は動いている状態のまま対処できます。中症：起動はするが致命的な不調
SSHが効かない、SELinuxラベルが大量にズレてサービスが軒並み起動しない、といったケースです。VM環境ならスナップショットへの復元、物理機なら起動可能な状態を保ったまま
setenforce 0 で一時的にpermissiveに落として原因切り分けに入ります。
# 起動はするがSELinuxで詰まっている場合の応急対応 # 1. 一時的にpermissiveへ $ sudo setenforce 0 $ getenforce Permissive # 2. 全ファイルをラベル再付けする $ sudo touch /.autorelabel $ sudo reboot # 3. 再起動後にenforcingに戻す $ sudo setenforce 1
カーネルパニック、GRUBが起動しない、root領域がマウントできない等のケースです。AlmaLinux 10のインストールメディアからrescueモードで起動してGRUBを再構築するか、最終手段としてバックアップからのリストアに進みます。
# rescueモードからGRUBを修復する基本手順 # 1. AlmaLinux 10インストールUSBから起動 → Troubleshooting → Rescue # 2. 既存システムをマウントする sh-5.2# chroot /mnt/sysroot # 3. GRUB設定を再生成 sh-5.2# grub2-mkconfig -o /boot/grub2/grub.cfg # 4. UEFI環境ならEFI側も再インストール sh-5.2# dnf reinstall -y grub2-efi-x64 shim-x64 sh-5.2# grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg # 5. chrootを抜けて再起動 sh-5.2# exit sh-5.2# reboot
20年以上Linuxサーバーを運用してきて言えるのは、「重症の復旧で一番大事なのは復旧スピードではなく判断スピード」ということです。1時間粘ってGRUBを直すより、最初の30分で「これは無理だ」と判断してスナップショットへ戻すほうが、トータルの停止時間は短くなります。経験を積むほど判断が早くなります。
移行を見送るべきケース
ここまで読んだうえで、それでも「今回は移行しないほうがいい」サーバーがあります。3つの典型を整理します。・独自カーネルモジュール依存：NVIDIAドライバ・特殊NIC・古い仮想化基盤等。AlmaLinux 10のカーネル6.12対応版が出ていなければ、出るまで待つか、別系統を選ぶ
・EOL過ぎたサードパーティ依存：CentOS 7用のRPMしか提供されないアプリ・PHP 5系前提のCMS・Python 2系のツール等。アプリ側を先に上げないとAlmaLinux 10では動かない
・本番停止窓が取れない：24時間365日サービス継続が絶対条件で、ロードバランサ前段の冗長化もない場合。in-placeの30～90分すら許されないなら、Blue-Green構成への組み替えが先
それでもCentOS 7／8を放置したくない場合の延命策として、サイバートラスト社のMIRACLE LINUX 10への有償移行サポートや、Red Hatの有償移行ツール（convert2rhel）も選択肢です。商用サポート契約付きで移行作業を伴走してもらえるので、社内に経験者がいない現場では検討の価値があります。
移行が完了した後の運用に進む方は、「AlmaLinux 10 サーバー初期設定10項目｜SELinux・firewalld・dnf・SSH鍵認証」でAlmaLinux 10時代の作法に合わせた初期設定を10項目に整理しています。CentOS時代のクセが残ったまま運用に入ると後々困るので、移行直後に一度目を通しておくのが安全です。
本記事のまとめ
| 工程 | 要点 |
|---|---|
| 移行パターン選定 | in-place／クリーン再構築／並行運用、汚れたサーバーはクリーン推奨 |
| 事前準備 | フルバックアップ2系統・サードパーティリポ無効化・カスタムカーネル削除 |
| CentOS 8→Alma 10 | almalinux-deployでAlma 8へ→leappでAlma 10へ、再起動2回 |
| CentOS 7→Alma 10 | almalinux-deployでAlma 8へ→leappで9→10、再起動3回 |
| 依存破壊対処 | EPEL差し替え・dnf module reset・dnf history undoの3点セット |
| 動作確認 | cat /etc/os-release・systemctl --failed・dnf check・SELinux再ラベル |
| 失敗時復旧 | 軽症=undo／中症=permissive＋再ラベル／重症=rescueでGRUB修復orリストア |
| 見送り判断 | 独自カーネル・EOLサードパーティ・停止窓ゼロは延命策へ |
今回でAlmaLinux 10クラスター3部作（インストール→初期設定→移行）が出揃いました。新規構築は「AlmaLinux 10 インストール手順」、その後の運用準備は「AlmaLinux 10 サーバー初期設定10項目」、ハブ記事は「AlmaLinux 10とは｜CentOS後継本命の特徴・MIRACLE LINUX統合・サポート期間まとめ」です。3本を順に踏めば、選定→構築→移行までを1日で組み立てられる導線になっています。
Ubuntu系のクラスターも別軸で展開しています。RHEL系とDebian系を併用している現場の方は「Ubuntu 26.04 LTS 変更点まとめ｜25.10から何が変わったか現役講師が解説」もあわせて参照してください。
20年以上Linuxサーバーを運用してきた経験から言うと、CentOS／RHELクローンの移行で本当にトラブルになるのは、技術的な難しさよりも「動いているサーバーを触る決断ができない」ことのほうです。バックアップと事前検証を整えたら、あとは一度走らせてしまうのが一番早く、結果的に社内の脆弱性レポートからも解放されます。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxで「なんとなく動いた」経験を積み重ねてきた人が壁にぶつかる理由｜現役講師が教える再現性のある理解の作り方
- 前のページへ：AlmaLinux 10 サーバー初期設定10項目｜SELinux・firewalld・dnf・SSH鍵認証
- この記事の属するカテゴリ：AlmaLinux・Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます