如果这篇文章对你有帮助，欢迎关注我的CSDN账号「来福猿」，
有问题可以在评论区留言，我会一一回复。

1. 背景：CentOS 停服，生产环境不能再观望

CentOS 的停服时间表已经非常明确：CentOS 8 在 2021 年底停止维护，CentOS 7 也在 2024 年 6 月 30 日全面停止更新。对于仍然大量运行 CentOS 的生产环境来说，这意味着漏洞不再修复、安全补丁不再发布、社区仓库逐步冻结，系统继续“带病运行”的风险会越来越高。

尤其对于金融、政务、能源、制造等对信息安全和合规要求严格的行业，操作系统停止维护通常会被安全审计直接判定为不合规项。等保测评、行业监管检查、漏洞扫描平台都会把“EOL 操作系统”列为高危问题。因此，CentOS 迁移不是“要不要做”的问题，而是“怎么做、什么时候做、如何把业务影响降到最低”的问题。

本文结合实际生产环境迁移经历，记录从 CentOS 7 迁移到 openEuler 的完整过程，重点梳理迁移方案选择、原地升级操作、常见兼容性问题和最终验收经验，供同样面临信创国产化改造的团队参考。

2. 为什么选择 openEuler

在 CentOS 停服之后，替换方向主要有三类：继续使用 RHEL 商业订阅、切换到 Rocky Linux 等兼容发行版，或者迁移到国产操作系统。结合信创要求和长期支持能力，openEuler 是当前比较稳妥的选择。

对比维度	CentOS 7	openEuler	Rocky Linux
维护状态	已停服	社区活跃，有长期支持版本	社区维护中
信创合规	不满足	满足国产化要求	不满足
生态支持	生态成熟但逐渐收缩	适配国产 CPU、数据库、中间件	与 RHEL 生态接近
迁移工具	无	提供 x2openEuler 原地升级工具	迁移工具相对简单
技术支持	仅社区历史资料	社区与商业发行版支持	以社区为主

openEuler 的核心优势在于：由开放原子开源基金会孵化，社区持续迭代；对鲲鹏、飞腾、海光、兆芯、龙芯等国产处理器适配较好；同时提供了 x2openEuler 迁移工具，可以降低从 CentOS 迁移的门槛。对于已经明确要做信创改造的团队，选择 openEuler 可以少走很多弯路。

3. 迁移前的评估，决定整个项目成败

很多人一上来就想直接跑迁移工具，结果迁移到一半发现存储驱动不兼容、业务依赖缺包、数据库起不来。生产环境迁移的第一原则是：先评估，再动手。

3.1 盘点业务与依赖

迁移前需要形成完整的资产清单，至少包含以下内容：

• 每台服务器的硬件配置、BIOS 版本、RAID 卡型号、HBA 卡型号和网卡型号。
• 操作系统版本、内核版本、已安装的软件包列表。
• 上层的中间件、数据库、消息队列、大数据组件及其版本。
• 第三方 yum 源、自建本地源、pip 源、npm 源等依赖来源。
• 内核模块、自编译驱动、特殊的 systemd 服务或定时任务。

建议在每台服务器上先生成软件包清单，方便迁移后对照。

# 导出已安装的软件包列表
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' > /root/rpm_list_before.txt
导出已启用的 repo 信息
yum repolist all > /root/repolist_before.txt
导出自建 systemd 服务和 crontab
systemctl list-unit-files --state=enabled > /root/services_before.txt
crontab -l > /root/crontab_before.txt 2>/dev/null || true

3.2 识别高风险组件

以下组件在迁移时最容易出问题，需要单独标记并提前制定替代或验证方案：

• 第三方内核模块：RAID 卡驱动、FC 存储多路径驱动、安全代理模块。
• 商业软件：带 license 绑定的备份客户端、监控 Agent、加密客户端。
• 老版本运行时：Python 2、旧版 glibc、32 位兼容库。
• 深度绑定 RHEL 体系的软件：部分数据库和中间件对系统版本有强校验。
• 自编译的二进制和脚本中的绝对路径依赖。

3.3 明确迁移窗口与回退方案

生产迁移必须预留操作窗口，并保证可以快速回退。迁移前至少做一次完整的系统盘和数据盘备份，必要时做整机镜像。对于核心业务，建议先在测试环境和预生产环境完整演练，再进入生产变更窗口。

4. 迁移方案怎么选：重装迁移还是原地升级

从 CentOS 到 openEuler，常见有两种路线：重装迁移和原地升级。

方案	优点	缺点	适用场景
重装迁移	环境干净，没有历史包袱，配置可控	需要重新部署应用、恢复配置，工作量大	应用标准化程度高、可自动部署的环境
原地升级	业务中断时间短，配置和应用基本保留	可能残留不兼容包，依赖问题较多	老业务、配置复杂、无法快速重建的环境

实际项目中通常采用“混合策略”：基础镜像统一、应用可容器化的服务器优先重装迁移；老旧的、配置复杂且难以快速复现的服务器采用 x2openEuler 原地升级。本文重点记录原地升级的实战过程，因为这部分踩坑最多。

如果业务已经容器化，重装迁移通常更省心：先准备好 openEuler 主机，再重新部署容器运行时，应用镜像基本不用改，只需要验证基础镜像的兼容性。对于 Kubernetes 节点，还可以采用“新建节点、驱逐 Pod、逐步下线旧节点”的方式滚动替换。

5. 原地升级实战：x2openEuler 迁移过程

openEuler 官方提供了 x2openEuler 工具，支持从 CentOS 7 等系统原地升级到 openEuler。工具会先对系统进行升级前检查，生成检查报告，再执行升级操作。

5.1 升级前检查

迁移前先安装并运行升级前检查，确认系统是否可以升级。

# 安装 x2openEuler
cd /opt
wget https://repo.oepkgs.net/openEuler/rpm/openEuler-22.03-LTS-SP3/contrib/x2openEuler/noarch/Packages/x2openEuler-20.03-1.noarch.rpm
rpm -ivh x2openEuler-20.03-1.noarch.rpm
执行升级前检查
x2openEuler pre-upgrade
查看检查报告
cat /opt/x2openEuler/upgrade_precheck.json

检查项包括：内核版本、glibc 版本、已安装软件包、第三方 repo、文件系统类型、磁盘空间、内核模块等。检查结果会把问题分为阻断项和警告项。阻断项必须先处理，否则升级会失败。

5.2 常见的升级前阻断项

结合实测经验，检查阶段最常见的阻断项如下：

• 启用了 CentOS 已失效的官方源，需要先切换到 vault 源或禁用。
• 安装了某些与 glibc 强绑定的商业软件，升级后会无法启动。
• 挂载了非标准文件系统，或使用 overlay 等特殊挂载方式。
• 磁盘空间不足，一般建议系统盘至少预留 10GB 以上的可用空间。
• 存在第三方内核模块，需要提前确认是否有 openEuler 对应版本。

5.3 执行升级

处理完阻断项后，可以执行正式升级。升级过程会替换系统包，务必在控制台或带外管理环境中操作，避免 SSH 断连导致升级中断。

# 建议在 screen 或 tmux 中执行
tmux new -s upgrade
执行原地升级
x2openEuler upgrade
升级完成后重启
reboot

升级完成后首次重启，需要重点关注系统能否正常引导、文件系统是否挂载成功、网络是否恢复、ssh 服务是否正常。建议保留控制台访问，防止网络配置异常导致无法远程登录。

6. 生产环境踩坑记录：这些坑几乎都会遇到

升级成功不代表迁移完成。真正的困难一般在升级后的应用验证阶段，以下是实际迁移中遇到的高频问题。

6.1 坑一：第三方 yum 源残留导致依赖冲突

CentOS 上经常配置了 EPEL、ELRepo、Remi 或者公司内部的第三方源。升级到 openEuler 后，这些源的元数据仍然存在，后续 yum 安装时可能出现依赖冲突，甚至把系统关键包替换掉。

# 升级后检查并禁用非 openEuler 源
yum repolist
cd /etc/yum.repos.d/
grep -r "enabled" *.repo

处理方法是禁用全部第三方源，只保留 openEuler 官方源。对于确实需要的软件，再按需求在 openEuler 仓库或软件厂商提供的新源中重新寻找。不要在 openEuler 上继续使用 CentOS 时代的 EPEL 等源。

6.2 坑二：glibc 与老版本软件不兼容

CentOS 7 的 glibc 版本较低，许多老软件是围绕旧版 glibc 构建的。openEuler 的 glibc 版本更高，可能导致部分老二进制无法运行，或者商业软件在启动时提示找不到库文件。

# 查看当前 glibc 版本
ldd --version
查看应用依赖的库
ldd /opt/app/bin/your_app

处理思路是优先由软件厂商提供 openEuler 版本或 arm64/x86_64 新版本包；如果暂时无法更换，可以评估在容器中运行老版本运行时的兼容方案，但不要把 CentOS 的 glibc 包强行混装进 openEuler，会造成系统基础库被破坏。

6.3 坑三：存储多路径与 RAID 卡驱动

在物理服务器上，RAID 卡、HBA 卡和多路径软件的驱动最容易出问题。重装或升级后，可能出现磁盘识别异常、多路径聚合失败、设备名变化等情况。

# 检查多路径配置和聚合状态
multipath -ll
查看块设备
lsblk
查看内核是否加载相应模块
lsmod | grep -E "megaraid|mpt3sas|hpsa|smartpqi"

迁移完成后一定要核对 /etc/fstab 中的设备标识。推荐使用 /dev/disk/by-uuid 或 by-id 方式挂载，避免设备名漂移导致开机无法挂载。同时检查多路径的 wwid 是否与迁移前一致。

6.4 坑四：SELinux 与安全基线适配

CentOS 上的 SELinux 策略和 openEuler 存在差异。部分服务在 CentOS 上是关闭 SELinux 运行的，迁移后如果安全基线要求开启，会出现权限拒绝。反之，如果沿用原来的关闭配置，又可能不满足信创安全要求。

# 查看 SELinux 状态
getenforce
临时切换到 permissive 排查问题
setenforce 0
查看拒绝日志
grep denied /var/log/audit/audit.log | tail -20

建议先按业务最小权限原则配置 SELinux 策略，对确实无法适配的老旧应用使用 permissive，并记录为待整改项，而不是直接一路 setenforce 0 了事。

6.5 坑五：容器运行时兼容问题

已经容器化的业务虽然迁移成本较低，但 Docker、containerd 的版本和依赖也要重新评估。CentOS 7 上的旧版本 Docker 不能直接在 openEuler 上沿用同样的安装源。

# 检查容器运行时版本
docker version
containerd --version
查看当前使用的存储驱动
docker info | grep "Storage Driver"

openEuler 上建议使用仓库中提供的 containerd 或 Docker 版本，并测试 overlay2、cgroup 驱动等配置。Kubernetes 节点迁移时，要特别关注 kubelet 的 cgroup driver 是否与容器运行时一致，避免 Pod 反复重启或节点 NotReady。

6.6 坑六：数据库与中间件的国产化适配

信创改造往往不只是操作系统替换，数据库也可能是从 MySQL、Oracle 迁移到 openGauss、达梦、人大金仓等。操作系统迁移和数据库迁移叠加时，建议分阶段进行：先把系统迁移到 openEuler，再用原有数据库稳定运行一段时间，确认无兼容问题后再考虑数据库替换。

对于暂时保留的 MySQL、Redis、Kafka 等组件，需要到对应官网或 openEuler 仓库确认是否有 openEuler 版本，不要继续使用 CentOS 7 的安装包。部分中间件启动脚本会检查 /etc/redhat-release 或系统版本号，需要根据实际情况调整。

6.7 坑七：时钟同步与监控 Agent

chrony 是 CentOS 7 默认的时间同步工具，openEuler 同样支持，但配置文件路径和默认值可能有差异。迁移后要确认时间同步正常，避免因时间偏差影响日志审计、数据库事务和证书校验。

# 配置 chrony 并检查同步状态
systemctl enable chronyd
systemctl restart chronyd
chronyc sources -v
chronyc tracking

监控 Agent 方面，Zabbix、Prometheus node_exporter、公司自研 Agent 都需要重新安装对应版本。部分商业监控 Agent 会对系统发行版做校验，迁移后可能上报失败，需要在平台侧重新纳管。

6.8 坑八：开机自启和自定义服务丢失

原地升级理论上会保留 systemd 服务，但有些依赖不存在或路径变化的服务会启动失败。迁移后要逐个核对开机自启项：

# 列出所有失败的 unit
systemctl --failed
检查开机自启
systemctl list-unit-files --state=enabled
查看某个服务的状态和日志
systemctl status your_service
journalctl -u your_service -n 50

对于启动脚本里写死 /usr/lib64 下旧库路径的情况，要改成 openEuler 中的实际路径。对于已废弃的服务，及时清理，避免残留影响后续运维。

7. 迁移后的验证清单

迁移完成后，不能只看“系统能开机、ssh 能登录”就结束。建议按照下面的清单逐项验证：

• 系统基础：内核版本、发行版信息、文件系统挂载、磁盘容量、网络连通性。
• 安全基线：防火墙规则、SELinux 状态、SSH 配置、账号权限、审计日志。
• 运行环境：Java、Python、Node.js 等运行时版本，软件包依赖完整性。
• 业务组件：数据库、缓存、消息队列、中间件是否正常启动并保持稳定。
• 监控告警：主机监控、日志采集、告警策略是否恢复。
• 备份恢复：迁移后重新执行一次备份任务，确认备份链路可用。
• 性能基准：对关键应用做简单压测，对比迁移前后的 CPU、内存、IO 指标。

建议以标准化表格记录每台服务器的验证结果，形成迁移验收报告，方便后续审计和问题追溯。

8. 回退与应急策略

无论前期准备多充分，生产变更都必须有回退预案。原地升级前至少做一次完整的系统盘镜像或快照，并将关键业务数据单独备份。升级后如果出现无法快速解决的问题，应果断回退，而不是在故障状态上继续排查。

回退方式取决于迁移方案：重装迁移可以切换回旧主机或旧磁盘；原地升级可以从镜像恢复。无论哪种方式，都建议提前演练一次回退操作，并记录回退耗时。回退本身也是迁移方案的一部分，不能被忽略。

9. 经验总结

从 CentOS 迁移到 openEuler，本质上不只是换一个操作系统，而是对服务器软硬件栈、运维流程、安全策略的一次整体梳理。以下几点是这次项目沉淀下来的经验：

• 迁移不是纯技术操作，前期评估和业务方沟通至少要占一半精力。
• 先迁移测试环境，积累完整的问题清单和解决方案，再进入生产环境。
• 能上容器的业务优先上容器，可以大幅降低操作系统迁移的耦合度。
• 第三方源、商业 Agent、自编译驱动是三大高危点，必须提前识别。
• 迁移后的验证要标准化，留下验收记录，不能靠“感觉没问题”。
• 回退方案必须真实演练过，否则一旦失败会非常被动。

信创国产化是大方向，但落地需要工程化思维。与其纠结某一条命令，不如把评估、演练、验证、回退的流程建立起来。操作系统迁移之后，后续的数据库国产化、中间件替换等改造也会更有底气。