CentOS 7停服后如何原地升级到AlmaLinux 8全流程

1. 为什么建议走“原地升级”这条路

1.1 CentOS 7 停服后的现实问题

CentOS 7 的官方维护周期在 2024 年年中就正式画上句号了，这意味着它不再有免费的安全更新、关键补丁和官方漏洞修复。别看很多服务器还能正常跑，实际上系统里已经积累了大量已经公开披露、但永远不会被官方修复的漏洞。如果你的业务还暴露在公网，这就是在赌运气，而不是在运维。

更麻烦的是，CentOS 7 的默认软件源也被整体移入了 vautl 归档仓库。虽然还能手动把源切到归档地址继续安装老包，但仓库不再更新，新装软件时依赖解析也会经常出问题。我见过不少团队拖到这时候才着急，一问原因，基本都是“还能跑就先不动了”“怕升级搞挂生产环境”。

这里要说清楚一件事：CentOS 7 停服不等于你的机器立刻蓝屏死机，而是一个慢慢“腐烂”的过程。今天少一个安全补丁，明天少一个兼容更新，后天某个第三方软件因为依赖库版本太老装不上。等到真出问题时，往往是故障已经发生了，你连补救的窗口期都没有。

1.2 为什么落点是 AlmaLinux 8 而不是其他系统

CentOS 7 用户迁移的常见去处有几个：CentOS Stream、Rocky Linux、AlmaLinux，以及直接换到 Debian 或 Ubuntu。我先说结论：如果目标是“最小代价、最低风险地把现有系统平移到新平台”，AlmaLinux 8 是目前最顺的选择。

AlmaLinux 8 与 RHEL 8 保持二进制兼容，也就是说你在 CentOS 7 上用的 Nginx、PHP、MySQL 等软件包，在 AlmaLinux 8 上都有对应的 RHEL 8 兼容版本，配置路径和启动方式基本一致。对于运维同学来说，这意味着不需要重新学一套体系。

更重要的是，AlmaLinux 官方专门维护了一个叫 ELevate 的项目，目的就是解决 EL7 到 EL8、EL8 到 EL9 这种大版本原地升级问题。它基于 Red Hat 开源的 Leapp 框架，额外补充了非 RHEL 发行版的数据包和脚本。目前 Rocky Linux 虽然也能迁移，但工具链上 AlmaLinux 的 ELevate 更成熟，社区案例也更多。CentOS Stream 则更偏向滚动更新，生产环境追求稳定的话我不太推荐。

另外从生命周期看，AlmaLinux 8 的支持周期到 2029 年，还有充足的服务时间。你现在迁过去，不算“刚迁移就要再迁一次”，至少未来五六年不用再为操作系统大版本发愁。

1.3 为什么不直接重装系统

很多人第一反应是“重装一台新机器再把数据搬过去”。这种方式在某些场景下确实更干净，但放在生产环境里，代价往往比想象中大得多。

一台跑了三年的业务服务器上，可能藏着几十个配置文件、系统级环境变量、计划任务、自编译的扩展、内网依赖的认证关系。重装意味着这些全都得重新梳理一遍。哪怕你有自动化部署脚本，也需要花时间验证新环境里的行为是否和老环境一致。更别提数据库、文件存储这类有状态数据的迁移，几十 GB 甚至几 TB 的数据拷贝，时间成本和出错概率都很可观。

原地升级的核心价值是：数据和配置留在原地，系统包从 EL7 替换成 EL8，应用和服务的配置绝大多数不需要改动。停机窗口主要是重启和升级包替换的时间，相对可控。当然，如果你的系统已经乱到没人知道里面装过什么，那重装一次可能比迁移更合适。原地升级适合的是“管理还算规范、数据有价值、不想承担重装成本”的场景。

2. 动手前必须做好的体检和资源评估

2.1 云平台快照：这是最后的保命手段

无论你在哪家云平台，升级前第一件事一定是创建磁盘快照，这是比任何步骤都重要的操作。我见过有人跳过备份直接跑升级，结果中间一次意外断电导致升级环境崩溃，最后只能回滚，但回滚用的快照因为没建完整，数据库只恢复到前一天凌晨的状态，平白丢了大半天的写入数据。

在云平台控制台创建快照时，建议做到几点：

• 如果磁盘支持在线快照，先在业务低峰期触发一次数据库的一致性检查，再创建快照。
• 有条件的话，除了当前地域的快照，再导出一份到对象存储或另一个地域，防止单点故障。
• 快照创建完成后，确认状态是“已完成”再开始升级，不要看着它“创建中”就去跑命令。

快照不是用来“以防万一”的，而是“必须要有”。有了快照，后续哪怕升级失败，也能在十分钟内把磁盘恢复到升级前状态。

2.2 升级条件检查清单

Leapp 对源系统的要求比较多，建议对照下面的表格逐项确认，而不是直接复制命令。

磁盘空间是最容易低估的坑。我记得第一次升级时只留了 6GB 空间，结果 Leapp 下载完数据包就报“空间不足”，整个预检都无法继续。后来我把根分区临时扩容到 20GB，整个过程就顺畅多了。宁可多留，不要卡在这种低级问题上。

2.3 Leapp + ELevate 的升级原理

很多朋友听到“原地升级”第一反应是“这玩意儿靠谱吗？”，其实原理并不神秘。Leapp 本质上是一个升级框架，它做两件事：先分析系统现状，生成一份详细的升级报告；再基于报告执行包替换和配置迁移。ELevate 项目则提供了 CentOS 7 到 AlmaLinux 8 的专属数据，告诉 Leapp 哪些包要换、哪些配置要改。

整个过程可以这么理解：Leapp 先给系统做一次全面体检，列出所有需要处理的问题，你修完问题后，它再打包一个升级环境。重启后系统会进入这个临时升级环境，在后台把 EL7 的软件包替换成 EL8 的软件包。替换完成后再次重启，就进入了 AlmaLinux 8。

这个机制的好处是，升级环境本身是独立的，不依赖正在运行的系统。坏处是，升级过程中系统会处于不可用状态，时间取决于机器性能和包数量，一般二十分钟到一小时。所以升级一定要安排在业务低峰期，并且通过控制台 VNC 关注进度，而不是傻等 SSH 重连。

3. 实操：CentOS 7.9 原地升级到 AlmaLinux 8 全流程

3.1 升级前的系统更新与组件安装

在跑任何升级工具之前，先把 CentOS 7 系统更新到最新的补丁状态，这一步能减少大量兼容性问题。

yum update -y

更新完成后重启一次，确认系统正常。接下来安装 ELevate 的仓库和升级组件：

yum install -y https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm yum install -y leapp leapp-upgrade

安装完成后可以用leapp --version确认版本号。正常情况下会输出版本信息，说明 Leapp 已经就绪。这里要注意，elevate-release 包会向 yum 源里添加 ELevate 专属仓库，后期升级完成后建议移除这个仓库，避免它干扰后续的 dnf 操作。

3.2 预检：leapp preupgrade 一定要跑

接下来执行预检，模拟整个升级过程，但不会真正修改系统：

leapp preupgrade

这个命令会在 /var/log/leapp/ 目录下生成报告文件，最重要的是 leapp-report.txt，里面列出了所有检测到的问题、警告和建议。

grep -E "Error|High" /var/log/leapp/leapp-report.txt

先只看 Error 和 High 级别的项目，Info 级别的基本可以忽略。最常见的两个问题：

第一，系统检测到 pam_pkcs11 模块需要移除，这是 EL7 老配置在新系统里已经不再兼容的典型情况。处理方法是让 Leapp 自动确认变更：

leapp answer --section remove_pam_pkcs11_module.confirm=True

第二，报告提示安装了不兼容的第三方内核模块或旧版软件包。这种情况按照报告里的建议，用yum remove把对应包卸载掉即可。只要你没有装什么冷门驱动，这类问题一般不多。

预检报告就像一份“手术前评估单”，它存在的意义就是让你在真正动手前把所有风险点暴露出来。我强烈建议这时候多花十分钟逐条看报告，而不是直接跳过。

3.3 执行 leapp upgrade 并重启

预检报告处理完之后，终于可以执行真正的升级：

leapp upgrade

命令执行后会再次分析系统并准备升级环境，这个过程大概需要几分钟到十几分钟。期间会出现大量日志输出，主要是在生成 initramfs 镜像和处理升级数据。如果一切正常，最后会提示你重启系统。

到这里，SSH 很有可能会断开，或者即使没断也无法再正常执行命令。不用担心，这是正常现象。此时你需要打开云平台控制台的 VNC 窗口，然后手动执行：

reboot

为什么要用 VNC？因为升级过程是在专用环境里进行的，SSH 服务在这个阶段可能没有启动。如果你只是傻等 SSH 重连，可能会误以为升级失败了。在 VNC 里你能看到真实的升级日志和进度。

3.4 等待系统完成包替换

重启之后，系统不会直接进入 AlmaLinux 8，而是先进 Leapp 准备的升级环境，开始大规模的 RPM 替换。VNC 屏幕上会滚动大量安装日志，比如正在安装 el8 版本的 glibc、systemd、kernel 等。

这个过程是整台机器最脆弱的阶段，属于“系统正在手术中”。你不需要做任何操作，只需要确保两件事：一是电源和网络稳定，二是有足够的耐心。正常情况下二十分钟到一小时左右，机器会自动再次重启。

第二次重启后，如果 VNC 上能看到 AlmaLinux 的欢迎信息，或者 SSH 能重新连上，说明升级已经完成。

3.5 升级后验证

用以下命令验证系统状态：

cat /etc/redhat-release uname -r dnf repolist systemctl list-units --failed

我的实测输出一般是这样：

AlmaLinux release 8.10 (Cerulean Sage) 4.18.0-553.el8.x86_64

dnf repolist应显示 AlmaLinux 8 的仓库列表，而不是原来的 CentOS 仓库。如果仓库还是老的，需要手动更新。同时检查有没有失败的 systemd 服务，如果有，要看具体是哪个服务。

还有一个很容易忽略的点：升级完成后旧内核还挂在系统里。不要急着删，先保留它作为回退手段，观察一两天业务稳定后再清理不迟。

3.6 配置国内镜像源加速

AlmaLinux 官方源在国内的访问速度可能不太理想，特别是第一次dnf makecache时，等上十分钟都是常有的事。建议把 repo 文件里的 baseurl 换成访问速度更快的国内镜像源。

具体操作大致是：

cd /etc/yum.repos.d/ cp -a almalinux.repo almalinux.repo.bak

然后把 almalinux.repo 中的镜像地址替换为对应镜像站提供的 AlmaLinux 8 仓库地址，保存后执行：

dnf clean all dnf makecache

换源这件事尽量在升级完成后第一时间做，否则后面跑dnf update时的等待时间会让人怀疑人生。

4. 升级过程中我踩过的坑和排查经验

4.1 预检报告出现多个 Error 怎么看

很多朋友第一次看到预检报告里好几个 Error 就慌了，其实没那么吓人。关键是要区分哪些是“必须处理”的阻断性问题，哪些只是“建议处理”的警告。

我的处理原则是：Error 级别一定处理，High 级别尽量处理，Info 级别可以先忽略。比如报告提示某个 EL7 时代的旧配置文件路径发生变化，这种属于正常迁移现象，Leapp 会在升级时自动转移配置，不用手动干预。但报告提示“检测到不支持的第三方内核模块”，这种就需要你手动卸载或替换，否则升级后内核可能无法启动。

有一个反直觉的经验：报告里出现大量 Error 不代表系统就没救了，反而说明预检足够仔细。真正危险的是那些“报告显示全绿，升级后却起不来”的场景。临时升级环境对硬件和驱动的兼容性，跟预检脚本的分析能力并不完全一致。所以在生产环境升级前，强烈建议先用一台配置相同的测试机完整演练一遍。

4.2 升级后 SSH 连不上

这是升级后最常见的现象，但大多数情况下不是 SSH 服务挂了，而是 SSH 主机密钥变了。

因为 OpenSSH 从 EL7 到 EL8 版本跨越较大，升级过程中会重新生成主机密钥，旧的 known_hosts 记录自然就失效了。客户端连接时会看到类似 “REMOTE HOST IDENTIFICATION HAS CHANGED” 的提示，直接删除本机 known_hosts 中对应地址的旧记录即可。

如果删掉密钥记录后依然连不上，再用 VNC 登录检查 sshd 状态：

systemctl status sshd

如果服务没有运行，直接启动它：

systemctl start sshd systemctl enable sshd

另外，升级后防火墙规则可能被重置。确认 ssh 端口在 firewalld 中是放行的：

firewall-cmd --permanent --add-service=ssh firewall-cmd --reload

4.3 重启后进入紧急模式

Leapp 升级完成第二次重启后，如果机器进了 emergency mode，屏幕上通常会显示 Failed to mount 或类似错误。大部分原因是 /etc/fstab 里的某些挂载项在新系统里失效了。

我在测试中遇到过两次这个问题，一次是挂载了一个临时数据盘，升级后设备名变了；另一次是系统里残留了一个已经不存在的数据目录挂载项，升级前没检查。处理方法不复杂：在紧急模式下输入 root 密码进入 shell，然后执行：

mount -o remount,rw / cat /etc/fstab

找到有问题的挂载行，用#注释掉，保存后重启。正常进入系统后再重新配置正确的挂载。

这条经验提醒我，升级前检查/etc/fstab是很有必要的。临时挂载、手工挂载的设备，最好在升级前就清理掉，不要等到升级后让系统替你排查。

4.4 云平台的监控 agent 和其他系统组件异常

升级到 AlmaLinux 8 之后，原来在 CentOS 7 上安装的云监控 agent、安全管理组件这类东西，很可能还是 EL7 版本。系统本身能跑，但 agent 日志里会不断出现版本不匹配或依赖缺失的报错，最直接的影响是监控告警失效。

处理方法很简单：到云平台控制台找到“重置云监控”或“重新安装 agent”的入口，重新执行一次安装命令。或者手动从云平台下载 EL8 对应的 agent 安装包更新。这一步很容易被忽略，因为升级后第一眼看到的是系统正常，谁会想到监控 agent 已经是“半残废”状态？等你真的需要告警时，才发现它一个月前就退出了。

另外别忘了 cloud-init。它是云服务器初始化配置的关键组件，升级后确认版本是否为 EL8 版本，否则后续使用云平台的自定义镜像功能或启动脚本时，可能会碰到兼容问题。

4.5 升级失败后的回滚方案

升级失败的场景虽然少，但必须知道怎么回滚。最快的办法是使用你之前创建的磁盘快照，在云平台控制台执行“回滚磁盘”操作，系统会恢复到快照创建时的状态。

这里有两个细节：

• 回滚会丢失快照之后写入的数据，所以备份和快照都建议在业务低峰期做，尽量缩小数据丢失窗口。
• 回滚完成后，如果你用的是数据盘而不是系统盘快照，要先确认数据盘状态，避免环境污染。

Leapp 在升级前其实也会把原始系统的一些状态保存在 /var/lib/leapp/，理论上可以尝试手动恢复，但过程繁琐，成功率没有快照回滚高。我的建议是，只要预检时发现了重大问题且没有解决，就不要硬冲。反正快照在手，最坏结局也就是回滚，没必要顶着风险上。

5. 升完级之后的收尾和运营建议

5.1 移除 Leapp 组件与临时文件

升级完成后，Leapp 和 ELevate 工具已经完成了历史使命，建议从系统中移除，避免它们继续占用空间或者干扰后续包管理。

dnf remove leapp leapp-upgrade elevate-release dnf autoremove

同时清理升级残留的临时文件。Leapp 会在系统和 /root 下释放升级 payload，位置一般在 /var/log/leapp 和 /root/tmp_leapp_payload 之类的目录：

rm -rf /var/log/leapp rm -rf /root/tmp_leapp_payload*

还要检查原来的 yum 仓库缓存。Leapp 会把旧仓库文件整理到 /etc/yum.repos.d/ 下，升级后确认没有残留的 CentOS 仓库配置，否则 dnf 会尝试访问不存在的源并报错。

5.2 重建系统服务与工具链

系统版本变了，配套工具链也要跟着更新。主要注意这几个方面：

• 把依赖 yum 的定时任务或脚本改成 dnf。很多老脚本里写的是yum update -y，在 EL8 上虽然 yum 命令还存在，但本质是 dnf 的软链接，为了避免后续兼容问题，建议统一改成 dnf。
• 如果升级前的服务里有手动编译的扩展模块，比如 PHP 扩展、Python 的 C extension，升级后需要重新编译一遍，否则可能因为内核或 glibc 版本变化而加载失败。
• 系统里的 SELinux 上下文，在某些第三方软件目录上可能需要重新标记。可以用restorecon -Rv /目录修复。

这些工作虽然不复杂，但是琐碎。我习惯在升级后把所有开机自启服务列一份清单，逐一确认还在运行的服务和对外的端口，避免出现“系统正常但业务端口没人监听”的情况。

5.3 分批切换的落地节奏

如果你管理的服务器不止一台，千万别在同一天把所有机器全部升级。即使测试机验证通过，也不能保证所有机器的个性化配置都一致。我的建议是分四步走：先是测试机，再是非核心业务，然后是核心业务但可以接受短时间停机的系统，最后才轮到那些绝对不能出问题的关键节点。每一批之间至少观察二十四小时，确认监控指标、日志、业务访问量都正常，再推进下一批。

还有一个小习惯：第一批机器升级完成后，不要马上删快照。快照至少保留三到七天，等新系统稳定运行后再清理。不要为了省那点存储费，把回退的余地提前关掉。

实际上我自己的体会是，这类大版本原地升级，本质上不是“点个按钮就完事”的活，而是“预检多花一小时，迁移少踩十个坑”。我第一次独立操作的时候，就是没耐心看预检报告，把一台有 NFS 挂载的机器直接跑了升级，结果重启后等了三十分钟还在转圈，最后只能靠快照回滚。重来一遍的时候，花五分钟看报告、顺手处理了两个高优先级问题，整个升级过程一次通过。后来再做类似迁移，流程熟练了，从检查到完成差不多一个半小时，比重装系统再恢复数据快得多。如果你手上还有 CentOS 7 的存量机器，我建议先找一台测试实例按这个流程完整走一遍，跑通了再往生产环境推，心里会踏实很多。