CentOS 7停服后，企业迁移到Rocky Linux或AlmaLinux时应关注哪些兼容性问题？-轻量云Cloud

CentOS 7 于 2024 年 6 月 30 日正式停止维护（EOL），企业向 Rocky Linux 或 AlmaLinux 迁移是延续“二进制兼容 RHEL"生态的主流选择。虽然这两者都宣称与 RHEL 100% 兼容，但在实际生产环境中，从 CentOS 7 到 Rocky/Alma 8/9 的迁移并非简单的版本替换，因为底层架构（如 systemd、glibc、Python 版本）发生了显著变化。

以下是企业在迁移过程中必须重点关注的兼容性挑战及应对策略：

1. 内核与系统基础组件的差异

这是最容易被忽视但风险最高的领域。

内核版本跨度大：CentOS 7 使用 3.10 内核，而 Rocky/Alma 8 默认使用 4.18+，Rocky/Alma 9 使用 5.14+。
- 影响：旧版硬件驱动可能不再支持新内核；某些依赖特定内核参数（sysctl）或内核模块的应用程序可能无法启动。
- 对策：在测试环境验证所有硬件驱动和自定义内核模块的兼容性；检查应用程序是否硬编码了旧内核路径。
glibc 升级：glibc 从 2.17 (CentOS 7) 升级到 2.28+ (RHEL 8) 或 2.34+ (RHEL 9)。
- 影响：编译较老的静态链接二进制文件（特别是 C/C++ 编写的老旧软件）可能会报错 GLIBC_x.xx not found。
- 对策：优先使用源码编译并针对新 glibc 重新编译；对于无法修改的二进制包，考虑使用 Docker 容器隔离运行。

2. Python 版本的重大变更

CentOS 7 默认搭载 Python 2.7，而 Rocky/Alma 8/9 默认搭载 Python 3.6+ 甚至 3.9+，且移除了 Python 2。

影响：
- 大量运维脚本（Ansible playbooks, Shell 中的 Python 调用）、CMS 插件（如旧版 WordPress 插件）、监控工具（旧版 Nagios/Icinga）直接依赖 python 命令或 #!/usr/bin/python 开头，将直接失效。
- /usr/bin/yum 已废弃，改为 /usr/bin/dnf，且 yum 命令在部分配置下可能不可用。
对策：
- 全面审计：扫描全量代码库和脚本，查找 python 和 pip 的使用。
- 安装兼容层：如果必须保留 Python 2，需手动安装 python2 包（Rocky/Alma 8 支持较好，9 中可能需要额外源），但需注意其不再受官方安全更新支持。
- 适配 DNF：将依赖 yum 的脚本迁移至 dnf 或 microdnf。

3. 网络栈与防火墙机制的变化

NetworkManager vs network-scripts：
- CentOS 7 默认使用传统的 network-scripts (ifcfg-*)。
- Rocky/Alma 8/9 默认使用 NetworkManager，network-scripts 被标记为弃用甚至移除。
- 影响：自动生成的网卡配置文件格式不同，可能导致网络接口名称（如 eth0 变为 ens33）或 IP 获取失败。
- 对策：统一迁移至 NetworkManager 管理方式，或使用 nmcli 配置；若必须保留传统风格，需显式安装 network-scripts 包并调整服务优先级。
Firewalld vs iptables：
- CentOS 7 常用 iptables 直接操作，而 RHEL 8+ 强制使用 firewalld 作为前端，底层转为 nftables。
- 影响：旧的 iptables-save 规则可能无法直接导入，或者应用直接调用 iptables 命令的行为在 firewalld 模式下表现不一致。
- 对策：迁移防火墙规则至 firewalld 区域配置；确保应用程序不直接绕过 firewalld 调用底层 netfilter。

4. 存储与文件系统

LVM2 与 XFS：虽然两者都支持 LVM 和 XFS，但元数据格式可能有细微差异。
- 影响：直接从 CentOS 7 磁盘镜像挂载到 Rocky/Alma 时，可能因元数据版本过高导致只读挂载或无法识别。
- 对策：建议采用“全新安装 + 数据迁移”而非“原地升级”。如果必须保留原盘，先备份并在测试机尝试挂载。
Systemd 服务单元：
- 虽然 Systemd 语法大体一致，但新的默认目标（Target）和服务依赖关系有变化。
- 对策：审查自定义的 .service 文件，确保没有引用已移除的系统服务或过时的环境变量。

5. 软件包管理与依赖地狱

仓库结构变化：CentOS 7 的 epel-release 和第三方 RPM 源在 RHEL 8/9 上需要重新配置。
- 影响：许多第三方软件（如 Nginx, MySQL, Node.js）的官方源地址和 GPG 密钥已更新。
- 对策：提前整理所有第三方源的 URL 和 GPG 密钥，编写自动化部署脚本进行批量替换。
模块化（Module）机制：
- RHEL 8/9 引入了强大的 Module Stream 机制（用于控制 PHP, Perl, Python 等版本）。
- 影响：某些软件在安装时可能找不到预期的默认流（Stream），导致安装失败。
- 对策：使用 dnf module list 和 dnf module enable/disable 精确指定所需软件版本流。

6. 迁移策略建议

为了降低上述风险，建议采取以下分步迁移方案：

资产盘点与风险评估：
- 列出所有服务器上的自研应用、第三方软件、定制脚本。
- 重点标记依赖 Python 2、旧版驱动、硬编码路径的服务。
构建测试环境（Sandbox）：
- 搭建与生产环境一致的 Rocky/Alma 测试集群。
- 执行“影子迁移”（Shadow Migration），即在新系统上完整部署应用并比对日志。
选择迁移路径：
- 推荐：全新安装（Clean Install）。将数据备份后，在新系统上重装应用。这是最干净、风险最低的方式。
- 谨慎：In-place Upgrade。虽然存在 leapp 工具，但从 CentOS 7 直接升级到 RHEL 8/9 仍面临较多坑点（尤其是内核和 glibc），仅建议在非核心业务或经过严格验证的场景下尝试。
容器化隔离：
- 对于无法兼容的老旧应用（如必须跑在 Python 2.7 上的遗留系统），强烈建议使用 Docker 或 Podman 将其容器化，宿主系统仅负责提供资源，从而规避 OS 层面的兼容性问题。

总结

从 CentOS 7 迁移到 Rocky Linux 或 AlmaLinux 的核心不在于操作系统本身的替换，而在于适应 RHEL 8/9 的新生态标准。成功的关键在于：彻底清理对 Python 2 和旧内核的依赖，重构网络配置以适配 NetworkManager，以及利用容器技术隔离遗留包袱。