一、 选型博弈：Rocky Linux vs AlmaLinux vs 其他
在 CentOS 替代品的赛道上，并非只有 Rocky Linux 一个选手。CTO 和技术负责人需要在早期做出审慎的选择。
1. 主流替代方案对比
- Rocky Linux：由 CentOS 创始人发起，社区驱动，与 RHEL 保持高度兼容。其治理模式与 CentOS 最为相似，强调“稳定、社区优先”。
- AlmaLinux：由 CloudLinux 公司发起，同样提供 RHEL 二进制兼容。其商业模式更为明确（由 CloudLinux 的商业业务补贴），提供长期稳定的安全支持。
- Ubuntu LTS：如果团队更熟悉 Debian 系生态，Ubuntu 也是可行的选项。但需要评估的是，从 RHEL 系（yum/dnf/rpm）迁移至 Debian 系（apt/dpkg）的改造成本极大，适用于计划做全面技术栈重构的场景。
2. 为什么 Rocky Linux 成为主流选择？
对于绝大多数存量 CentOS 7/8 用户，迁移成本最低 的选项无疑是 Rocky Linux。因为：
- 二进制兼容：RPM 包、内核模块、系统服务管理方式几乎完全一致。
- 命令习惯不变：
yum/dnf、systemctl、firewall-cmd等日常运维命令无需重新学习。 - 迁移工具成熟：Rocky 官方提供了
migrate2rocky脚本，可实现原地升级。
二、 迁移前哨：硬件兼容性与软件依赖评估
在动手迁移之前，必须完成两项关键的评估工作。跳过这一步，等同于在悬崖边蒙眼奔跑。
1. 硬件兼容性
Rocky Linux 对现代硬件的支持非常良好，但如果你的服务器年代较早（如 2015 年之前的机型），需要检查：
- 网卡驱动是否被 Rocky 的内核（默认 5.x+）识别。
- RAID 卡驱动是否在官方支持列表内。
- UEFI 启动模式与 Legacy BIOS 的差异。
最佳实践：先将一台非核心的边缘服务器进行测试性迁移，验证所有硬件识别正常后再扩大范围。
2. 软件生态兼容性
检查当前 CentOS 上运行的所有关键应用：
- 第三方 RPM 仓库：如 EPEL、Remi、Nginx 官方源等，这些通常都有对应的 Rocky Linux 版本。
- 自研程序：基于 Glibc 2.17（CentOS 7）编译的二进制程序，在 Rocky Linux 的 Glibc 2.28+ 上通常可以向下兼容运行。
- 内核模块：如果使用了闭源驱动或自定义编译的内核模块，必须重新针对新内核进行编译。
三、 迁移实战：两条路径的选择与操作指南
Rocky Linux 官方提供了两种主要的迁移路径，分别适用于不同的业务场景。
路径一：原地迁移（In-Place Migration）—— 适合测试环境与无状态应用
使用 Rocky 官方提供的 migrate2rocky 脚本，直接在现有 CentOS 系统上将软件源替换为 Rocky 源，升级内核并保留所有用户数据。
操作要点：
- 备份
/etc目录和重要业务数据。 - 下载并执行迁移脚本。
- 重启后验证内核版本与系统标识。
（极少代码示例：原地迁移的核心命令流程）
# 1. 下载官方迁移脚本（建议在测试环境先行校验）
curl -O https://raw.githubusercontent.com/rocky-linux/migrate2rocky/main/migrate2rocky.sh
# 2. 添加执行权限并以 root 身份运行
chmod +x migrate2rocky.sh
sudo ./migrate2rocky.sh -r
# 3. 迁移完成后，系统会提示重启
sudo reboot
# 4. 重启后检查系统发行版标识
cat /etc/rocky-release
注意事项：原地迁移虽然便捷，但风险相对较高。如果迁移过程中断，系统可能处于不可用状态。建议将数据挂载为独立分区，以便迁移失败时可以通过重装系统再挂载数据的方式恢复。
路径二：新装迁移（Fresh Install）—— 推荐的生产环境方案
对于核心业务系统，强烈推荐 采用“新服务器安装 Rocky Linux + 服务迁移”的方式。这种方式更符合 “不可变基础设施” 的理念，同时便于测试验证。
操作流程：
- 部署一台全新的 Rocky Linux 服务器，安装同版本的应用软件（Nginx/MySQL/Redis 等）。
- 将 CentOS 生产环境的数据（数据库、静态资源）同步至新机器。
- 配置 Nginx/LVS 进行流量灰度切换（先导流 1% 到新机器验证）。
- 确认无误后，逐步将流量切至新机器，下线旧服务器。
（极少代码示例：使用 rsync 同步静态资源，保障数据一致性）
# 将旧服务器的静态文件目录同步至新服务器，保留权限与软链接
rsync -avz --delete /var/www/html/ root@new-rocky-server:/var/www/html/
四、 迁移后的验证清单
切换完成后，不能简单地“交付收工”。运维团队需要依照清单进行验证：
| 验证项 | 检查方式 | 预期结果 | |
|---|---|---|---|
| 系统版本 | cat /etc/os-release | 显示 Rocky Linux 9.x | |
| 内核版本 | uname -r | 显示 5.x 以上稳定版内核 | |
| 所有服务自启动 | `systemctl list-unit-files | grep enabled` | 关键服务均设为 enabled |
| 防火墙规则 | firewall-cmd --list-all | 与原环境规则一致 | |
| SELinux 状态 | getenforce | 建议保持 Enforcing（若原环境为 Disabled，可暂维持 Disabled） | |
| 日志完整性 | journalctl --since "1 hour ago" | 无异常错误堆栈 |
五、 长期运维：版本升级策略与安全更新
迁移不是终点，而是新的起点。Rocky Linux 遵循 RHEL 的长期支持周期（约 10 年），这为企业的长期规划提供了稳定的预期。
1. 升级策略
Rocky Linux 提供两个主要的版本分支：
- Rocky Linux 8.x：对应 RHEL 8，生命周期至 2029 年。
- Rocky Linux 9.x：对应 RHEL 9，生命周期至 2032 年。
建议：新项目直接选择 Rocky Linux 9.x；已有存量系统如无特殊依赖，建议在规划期内逐步迁移至 9.x，以获得更新的软件包与内核特性。
2. 安全更新自动化
配置系统定时自动检查安全更新：
# 安装 dnf-automatic 实现定时安全更新
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timer
3. 加入社区生态
Rocky Linux 拥有活跃的社区支持（论坛、IRC、邮件列表）。对于企业级用户，也可考虑购买商业支持服务，以获得更快的响应保障。
六、 常见问题与排障（FAQ）
Q1：迁移后某些命令报错 command not found？
A：可能是原系统中的第三方工具没有迁移过来。检查 /usr/local/bin 路径，或使用 which 命令定位原命令位置，复制到新系统。
Q2：迁移后网络无法连接？
A：检查网卡名称是否变化（如 eth0 变为 ens192）。编辑 /etc/sysconfig/network-scripts/ifcfg-* 或使用 nmcli 重新配置。
Q3：能否从 CentOS 6 直接迁移到 Rocky Linux 9？
A：不能。跨度太大，建议备份数据后全新安装。
Q4：迁移后 MySQL/MariaDB 无法启动？
A：检查数据库数据目录的权限和 SELinux 上下文。通常需要执行 restorecon -Rv /var/lib/mysql。
结语
CentOS 的停服是一个时代的结束，但同时也是新生态的开始。Rocky Linux 以“稳定、兼容、开放”的姿态承接了这一历史使命。对于运维团队而言，迁移是一次对基础设施的全面“体检”——盘点资产、梳理依赖、优化配置。与其被动等待系统漏洞暴露，不如主动拥抱 Rocky Linux，在延续 RHEL 生态稳定性的同时，为未来的云原生基础设施打下坚实基础。
迁移不可怕，可怕的是不做规划。愿你的每一次迁移，都让系统更加健壮。
