CentOS 停更迁移实战：vault 源配置、目标选型与迁移工程清单

CentOS 8 已于 2021-12-31 EOL，CentOS 7 也于 2024-06-30 正式停止维护。大量跑在生产环境上的 CentOS 服务器面临两个直接问题：yum / dnf 源失效装不了软件 ，以及不再有安全补丁 。本文从一线运维角度，把停更后的应急处理（vault 源）、迁移目标选型、迁移工程路线一次讲清，全部可落地。

先说结论：短期用 vault 源应急，中期迁去 Rocky Linux / AlmaLinux（与 RHEL 二进制兼容、应用改动最小）；迁移走"新装目标 + 迁数据 + 并行验证 + 旧机兜底"，别原地升级、别不备份动手、别碰 CentOS Stream。

一、EOL 时间线与真实影响面

版本	EOL 日期	停更后直接后果
CentOS 8	2021-12-31	镜像仓库下线，yum/dnf 报 404
CentOS 7	2024-06-30	同上，且用户基数最大、存量最多

"停止维护"意味着两件事：不再有安全补丁和缺陷修复。新爆出的系统漏洞、openssl 这类基础组件的高危漏洞，官方不会再发补丁。对暴露在公网或跑着业务数据的服务器，这等于把门敞着------不是"还能不能用"的问题，是"安不安全、合不合规"的问题。

需要澄清：停更不等于马上不能用，已有系统短期内业务照跑。纯内网、无等保/审计要求、无新功能新硬件需求的机器，短期继续用是现实选择。但"不更新不代表就没事"：

新爆出的漏洞在这台机器上永久裸奔；
"内网"不是保险箱------U 盘、一台被攻破的边缘设备、一个弱口令远程入口，都可能把风险带进来；
源失效后连排障小工具都可能装不上，真出事时救援本身被拖累。

可以暂不迁，但要知道在承担什么、把迁移排进日程。

二、应急处理：EOL 后 yum/dnf 失效与 vault 源配置

2.1 故障现象

CentOS EOL 后，镜像服务不再为已停更版本返回可用镜像，旧版本被整体移入官方 vault 历史库。典型报错：

复制代码

$ yum install nginx
https://mirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
Error: Cannot find a valid baseurl for repo: base/7/x86_64

2.2 CentOS 7：完整 vault 源配置（yum）

国内阿里云镜像为停更的 CentOS 保留了 centos-vault 目录，2026 年 10 月实测在线（7.9.2009 的 os / updates / extras 均可访问）。操作分四步：

bash 复制代码

# 1. 备份原有源配置
mkdir -p /root/repo-bak && mv /etc/yum.repos.d/CentOS-*.repo /root/repo-bak/

# 2. 写入 vault 源（阿里云镜像）
cat > /etc/yum.repos.d/CentOS-vault.repo <<'EOF'
[base]
name=CentOS-7.9.2009 - Base
baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

[updates]
name=CentOS-7.9.2009 - Updates
baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

[extras]
name=CentOS-7.9.2009 - Extras
baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
EOF

# 3. 清缓存、重建索引
yum clean all && yum makecache

# 4. 试装验证
yum install -y nginx

2.3 CentOS 8：完整 vault 源配置（dnf）

CentOS 8 是 dnf 体系，结构变化：源分为 BaseOS 与 AppStream 两个仓库，必须都配，少一个会有一半包装不上。以 8.5.2111 为例（阿里云 centos-vault 实测在线）：

bash 复制代码

# 1. 备份原有源配置
mkdir -p /root/repo-bak && mv /etc/yum.repos.d/CentOS-*.repo /root/repo-bak/

# 2. 写入 vault 源（BaseOS + AppStream 双源）
cat > /etc/yum.repos.d/CentOS-vault.repo <<'EOF'
[baseos]
name=CentOS-8.5.2111 - BaseOS
baseurl=https://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/$basearch/os/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial

[appstream]
name=CentOS-8.5.2111 - AppStream
baseurl=https://mirrors.aliyun.com/centos-vault/8.5.2111/AppStream/$basearch/os/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
EOF

# 3. 清缓存、重建索引
dnf clean all && dnf makecache

# 4. 试装验证
dnf install -y nginx

2.4 性质界定：vault 源是兜底，不是解药

改源能让存量机器继续装软件、补上该打的最后一批补丁，让"跑不动"的日子来得晚一些。但它不会变出新补丁------EOL 后新爆出的漏洞依然没人修。所以它是迁移前的"止血"，不是"不用迁了"的理由。真到了要改源这一步，通常正是该把迁移正式排上日程的信号。

三、迁移目标选型：四个去向与一个误区

去向	与 RHEL 的关系	适用场景	注意点
Rocky Linux	1:1 兼容，二进制兼容	无感平移，应用/配置改动最小	社区驱动，盯版本发布节奏
AlmaLinux	二进制兼容	同上，另一主流选择	同上
RHEL	本尊	要官方支持与认证	需订阅费
Ubuntu LTS / Debian	deb 系，不同血脉	应用借机重构、团队熟 deb	包/配置差异大，改动多

对"只想把 CentOS 平稳换掉、应用不动"的场景，Rocky / AlmaLinux 是改动最小的一档：与 RHEL 二进制兼容，yum 生态的 Nginx、MySQL、PostgreSQL、Docker 及自研业务系统基本原样承接。

必须挡住的误区：不要升级到 CentOS Stream

CentOS Stream 不是 CentOS Linux 的新版本，它是 RHEL 的上游滚动预览版------变更先进 Stream 验证，再流向下游 RHEL。两者是"上游 → 下游"关系，Stream 定位是开发预览，不是稳定发行版：

没有稳定的支持周期，滚动更新，随时引入未经充分验证的变更；
它天然是"变化"的，而生产服务器要的是"稳"。

2020 年底红帽宣布 CentOS 战略转向后，不少教程把"CentOS 8 → CentOS Stream 8"说成继续获得更新的正道------对生产服务器这是条错路。想要长期稳定就迁 Rocky / AlmaLinux / RHEL；只有想提前验证 RHEL 新特性的开发测试环境才适合碰 Stream。误升上去的，回退路仍是迁移六步。

四、迁移路线：新装迁移 vs 原地转换工具

社区和官方确实提供了原地大版本转换工具，需要客观说明：

leapp：Red Hat 主导的升级框架（预升级检查 + 数据/包迁移），用于 RHEL/CentOS 大版本原地升级（如 CentOS 7 → 8）；
ELevate：AlmaLinux 项目基于 leapp 封装的发行版迁移工具，支持 CentOS 7 → AlmaLinux 8/9 等路径。

工具的存在不代表生产环境该用。三点判断：

官方文档自己就要求：完整备份 + 在测试环境充分验证 + 逐项确认预检报告，失败案例并不少；
原地转换失败时的回退成本极高------现场已被改乱，往往只剩"从备份整机恢复"一条路；
生产环境的稳妥路线是新装目标系统 + 迁应用和数据 + 并行验证后切换：新环境是干净的，旧系统原样保留作兜底，任何一步出问题都能立刻切回，停机可压到分钟级。

结论：leapp / ELevate 适合测试环境评估和特定场景，生产迁移我们走新装路线。

我们摩杰斯自己的核心业务系统从第一天起就整台跑在 Linux 上，CentOS、Rocky、RedHat、Ubuntu、Debian 这些系统的安装、配置、迁移、故障处理，十四年里在几百家制造客户的现场一台台做过------迁 CentOS 这种活，"先备份、搭目标、并行验证、旧机兜底"是我们一贯的路子，每一步都有退路，业务不中断、数据不丢。

五、迁移工程清单（六步）

先备份，再谈迁。 整机备份（系统盘 + 数据 + 配置），留一份能随时回退的兜底盘。铁律，没有备份不动手。
搭目标系统，别原地升级。 新装一台 Rocky / AlmaLinux，而不是在老 CentOS 上转换。看着快，实则最容易把现场搞乱、回不去。
装应用、迁数据，逐项对。 按清单把应用服务、数据库、配置文件、定时任务一项项在新环境重建/迁移，每迁一项验证一项。重点核对：yum 源与 epel 的替代源、依赖包版本、SELinux 策略、防火墙规则、systemd 服务单元。
并行验证。 新环境与旧系统并行跑一段，用真实流量/真实数据核对业务，确认正常再切。
选窗口切换。 挑业务低峰切流量/换入口，切换后密切盯一段时间。
旧机兜底，别急着下线。 切完旧系统保留成回滚预案，新环境真出问题立刻切回旧机。

核心一句：每一步都有退路。迁移不是"赌一把换成功"，是"有备份、有并行、有回滚地换"。

六、常见坑清单

直接原地升级转换：图快，最容易把现有环境搞乱、出了岔子回不去；
不备份就动手：等于没系安全带上高速；
忽视软件源和依赖：yum 源、epel、第三方源停更后可能失效或漂移，要逐项确认新系统的源和依赖版本；
没有回滚预案：只想着"迁成功怎么办"，没想"迁失败怎么退"；
赶在半夜硬切、没并行验证：拿生产业务当试验田；
把 CentOS Stream 当升级路径：RHEL 上游滚动预览版，无稳定支持周期；
以为改了 vault 源就等于有补丁了：源能装 ≠ 安全了，EOL 后新漏洞依然没人修。

常见问题

Q：CentOS 7 EOL 了，现在不迁会怎样？

不会马上出事，短期内照跑。但不再有安全补丁，新漏洞没人修；新硬件新软件兼容性越来越差；过等保或客户审计时"系统已停止支持"是明确扣分项。是"该规划迁移"，不是"今晚不迁就崩"。

Q：yum 报 404 / Cannot find a valid baseurl，改源能解决吗？

能应急：把 repo 的 baseurl 改到阿里云等镜像的 centos-vault 目录（旧版本历史包都还在），就能装软件、打最后一批补丁。但这是兜底不是解药------不会变出新补丁。正确姿势：改源应急，同时把迁移排上日程。

Q：CentOS 8 改源要注意什么？

BaseOS 和 AppStream 两个仓库都要配，少一个会有一半包装不上；用 dnf 而非 yum 命令清缓存重建索引。

Q：内网服务器、也没什么新需求，不迁行不行？

短期可以，但"不更新不代表就没事"：新漏洞没人修，内网不是保险箱（U 盘、被攻破的边缘设备都是入口）；源失效后排障工具都可能装不上，出事救援被拖累。现实做法：继续用着、把迁移排进计划。

Q：leapp / ELeate 这类原地转换工具能用吗？

工具本身是成熟的（Red Hat leapp、AlmaLinux ELevate），但官方要求完整备份 + 测试环境充分验证 + 逐项确认预检报告；生产环境失败回退成本极高，我们走新装路线：新装目标 + 迁数据 + 并行验证 + 旧机兜底。

Q：Rocky Linux 和 AlmaLinux 选哪个？

都与 RHEL 二进制兼容，承接 CentOS 应用配置的省事程度差不多。Rocky 由 CentOS 创始人发起，AlmaLinux 社区根基也深。拿不准看团队更认哪个社区、或哪个版本发布节奏更合你。

Q：迁移一定要停机吗？

不一定。按"搭目标 → 并行验证 → 低峰切换 → 旧机兜底"，停机可压到分钟级甚至更短；只有个别强耦合场景才需要一个可接受的维护窗口。

Q：很多年前的自研应用还能迁吗？

多数能。跑在 CentOS + yum 生态上的应用，迁到二进制兼容的 Rocky / AlmaLinux，依赖和环境基本原样承接；只有绑定很深系统特性的应用才需额外适配。先做现状评估最稳。

结语

CentOS 停更是既定事实，但对绝大多数跑在它上面的业务，这不是"塌方"，是"该换地基了"。vault 源解决眼前，新装迁移解决未来；按"先备份、搭目标、并行验证、旧机兜底"走，业务不中断、数据不丢、随时能回滚是能做到的。真正危险的从来不是迁移本身，而是不备份就动手、原地硬升级、误升 CentOS Stream、没有回滚预案。