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 对源系统的要求比较多建议对照下面的表格逐项确认而不是直接复制命令。检查项最低要求说明系统版本CentOS 7.9内核 3.10.0-1160 及以上老内核版本过低会导致 Leapp 直接拒绝升级根分区剩余空间建议 15GB 以上Leapp 需要下载并解包大量 RPM 包/var/tmp 剩余空间建议 5GB 以上升级工具会把 payload 释放到这个目录外网访问能访问 AlmaLinux 仓库和镜像源下载升级包和数据文件软件仓库清理无关的第三方仓库某些第三方仓库会让预检报告出现大量错误服务状态记录当前开机自启服务列表升级后需要对比服务差异磁盘挂载检查 /etc/fstab 是否有临时挂载项升级后内核变化可能影响挂载磁盘空间是最容易低估的坑。我记得第一次升级时只留了 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.confirmTrue第二报告提示安装了不兼容的第三方内核模块或旧版软件包。这种情况按照报告里的建议用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_64dnf 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-servicessh firewall-cmd --reload4.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 的存量机器我建议先找一台测试实例按这个流程完整走一遍跑通了再往生产环境推心里会踏实很多。