获课：shanxueit.com/12829/

2020年底，Red Hat宣布CentOS 8将于2021年底停止维护、CentOS 7于2024年6月正式EOL（生命周期结束）时，整个开源社区和企业运维圈都经历了一次不小的震动。大量以CentOS为生产基座的企业面临同一个问题：系统不再有安全更新和漏洞修复，继续使用意味着将业务暴露在日益增长的风险之中。在这样的背景下，Rocky Linux凭借其与RHEL的"1：1二进制兼容"特性，以及由CentOS联合创始人Gregory Kurtzer主导的背景，成为了最受关注的替代方案之一。以下是从CentOS迁移至Rocky Linux过程中需要关注的要点与实操思路的梳理。

一、迁移前的全面评估：不打无准备之仗

迁移操作系统不是简单的重装，尤其对于承载着数据库、中间件、微服务集群的生产环境而言，任何疏忽都可能导致业务中断。在动手之前，至少需要完成三项准备工作：

第一项是硬件兼容性与驱动清单核查。Rocky Linux的内核版本与CentOS 7或8存在差异，某些老旧硬件的专有驱动可能在新内核下无法正常工作。建议在测试环境中先用Rocky Linux的Live ISO启动，检查网卡、RAID卡、GPU等关键设备的识别情况。

第二项是应用依赖的深度扫描。很多业务系统在编译安装时依赖了特定版本的glibc、openssl或Python运行时。迁移后系统基础库版本升级，可能导致应用启动失败或运行时异常。使用rpm -qa和ldd命令导出当前系统的所有软件包与二进制依赖清单，与Rocky Linux的默认软件包列表做交叉比对，提前识别潜在冲突。

第三项是数据备份与快照保护。无论后续选择哪种迁移方式，这一步都不可跳过。除了常规的业务数据全量备份外，强烈建议对根分区做LVM快照或使用裸机备份工具（如Clonezilla）生成系统镜像，确保在迁移失败时能够毫秒级回滚。

二、两种迁移路径的权衡与选择

当前业界主流的迁移方式有两种，各有适用场景：

路径一：原地升级转换（使用migrate2rocky脚本）。 这是Rocky官方提供的迁移工具，通过替换yum仓库源和部分核心软件包，将CentOS系统原地转换为Rocky Linux。优点是保留了所有已安装的应用、配置文件和用户数据，迁移成本最低；缺点是由于涉及内核和系统关键库的替换，过程中存在较高的风险，且一旦脚本中途出错，系统可能进入不可恢复状态。该路径适用于开发测试环境，或具备完整回滚能力的场景。

路径二：新服务器部署 + 应用迁移。 在另一台物理机或虚拟机上新装Rocky Linux，然后通过应用自身的集群能力（如数据库主从复制、应用服务的滚动发布）将流量逐步切到新环境。这种方式避免了原地升级的系统级风险，且可以在迁移过程中随时回切流量，但需要额外的硬件资源和更长的实施周期。对于金融、医疗等对可用性要求极高的行业，这是更稳妥的选择。

三、迁移过程中的关键注意事项

如果选择原地升级路径，以下几点是容易踩坑的地方：

注意EPEL和第三方仓库的兼容性。 很多CentOS系统启用了EPEL、REMI等第三方软件源，这些源中的软件包在Rocky Linux上可能没有对应的版本或存在依赖冲突。迁移前建议先清理或禁用非官方仓库，完成核心系统转换后再重新添加和安装第三方软件。

SELinux状态的确认。 许多运维人员为了省事会把SELinux设为permissive或disabled。迁移后如果SELinux被意外启用，可能导致大量服务的文件读写权限异常，表现为"权限不足"的诡异错误。迁移前明确记录SELinux的原始配置，并在迁移后保持一致。

防火墙与网络配置的保留。 firewalld的规则在迁移过程中可能被重置，尤其是自定义的rich规则和端口转发配置。建议在迁移前使用iptables-save或firewall-cmd --list-all导出所有规则快照，迁移后逐条核对。

内核启动参数的继承。 部分业务依赖修改/etc/default/grub中的内核参数（如调整共享内存大小、开启透明大页等）。迁移脚本通常不会自动迁移这些定制参数，需要在迁移完成后手动确认和补充。

四、迁移后的验证与收尾工作

系统成功启动并登入后，迁移并没有结束。建议按以下清单逐项验证：关键系统服务的运行状态（sshd、crond、network）、数据库与中间件的连通性、定时任务是否正确执行、监控Agent是否正常上报数据、应用的业务功能是否完整可用。建议在业务低峰期保持至少24小时的观察窗口，期间持续检查系统日志（/var/log/messages和journalctl）中是否有异常报错。

五、关于长期运维的额外建议

迁移完成后，建议将操作系统版本纳入配置管理数据库，建立定期补丁更新的内部规范。同时关注Rocky Linux的安全公告邮件列表，及时获知高危漏洞的修复状态。最后要提醒的是，迁移是一个项目的终点，却是新运维模式的起点——在RHEL生态的新版图下，制定一套涵盖系统初始化、基线加固、版本升级的标准操作流程，才是避免下一次"迁移焦虑"的根本之道。