从 CentOS 迁移到 Anolis OS 需要注意哪些问题？-云技术博客

CentOS 8 停服后，国内企业迁移 Anolis OS（龙蜥操作系统）确实是目前最主流的选择之一。毕竟 Anolis 和 CentOS 同宗同源（都基于 RHEL/CentOS 体系），迁移成本相对低，但“看起来一样”不代表“用起来没坑”。

作为在一线做过不少迁移项目的运维/开发，我总结几个最容易踩雷、也最需要提前规划的核心点：

这是最直观的问题。虽然 Anolis 兼容 RPM 包格式，但它的默认仓库结构变了。

BaseOS 与 AppStream 分离：Anolis 8 沿用了 RHEL 8 的仓库划分策略。以前 CentOS 7 时代很多工具直接装在 base 里，现在被拆到了 AppStream。如果你之前写死了 yum install xxx 而没有指定模块或版本，可能会遇到依赖解析失败。
- 建议：迁移前梳理核心依赖包，确认它们在 Anolis 的哪个子仓库中可用。不要盲目复用 CentOS 7 时代的 repo 配置，必须切换到 Anolis 官方源。
EPEL 源适配：很多老项目依赖 EPEL 里的非标准包。你需要确认你使用的 EPEL 版本是否支持 Anolis。目前社区有针对 Anolis 的 EPEL 适配版，但可能存在滞后性。如果某些关键包缺失，可能需要考虑从源码编译或寻找替代方案，而不是死磕 EPEL。

CentOS 7 时代很多人为了省事直接把 SELinux 设为 permissive 甚至 disabled。但在 Anolis 8 上，这往往是故障的重灾区。

策略更严格：Anolis 的安全基线通常比老旧的 CentOS 7 更贴近现代安全规范。如果你的应用涉及复杂的网络端口绑定、文件权限读写，SELinux 的 denials 日志会非常多。
排查成本高：一旦开启 Enforcing 模式，应用起不来，别急着改代码，先查 /var/log/audit/audit.log。使用 ausearch 和 sealert 工具生成修复建议。
- 建议：迁移初期可以先保持 Permissive 模式运行一段时间，收集所有 AVC 拒绝记录，然后针对性地打补丁或调整上下文（Context），最后再切到 Enforcing。千万别一上来就关掉 SELinux，这在合规审计上是过不去的。

如果你跑的是数据库、大数据组件或者特定硬件设备，内核模块是重灾区。

DKMS 支持：Anolis 的内核版本可能与你旧系统不同。对于闭源驱动（如某些网卡、GPU 提速卡），需要确认厂商是否提供了支持 Anolis 内核版本的 DKMS 包或二进制驱动。
内核参数调优：很多性能调优脚本是硬编码了 sysctl.conf 的参数。安诺里斯的内核默认值可能与 CentOS 7 有细微差别，特别是关于网络栈、内存管理（vm.swappiness, vm.vfs_cache_pressure 等）方面。
- 建议：保留原有的 sysctl 配置文件，但在新系统上逐项验证生效情况。特别注意 net.core.somaxconn 和 net.ipv4.tcp_tw_reuse 这类高频修改项，确保没有因为内核版本更新而被废弃或改变语义。

大多数服务器迁移不会重装系统，而是通过 P2V（物理到虚拟）或数据盘挂载的方式。

XFS vs Ext4：Anolis 默认文件系统是 XFS。如果你的旧系统是 Ext4，且使用了大量小文件或特定快照功能，迁移后需注意性能变化。XFS 对大文件友好，但对极大量小文件的元数据操作开销略高。
LVM 卷组导入：如果是整机迁移，注意 UUID 冲突。双机并行测试时，务必断开旧系统的网络连接，并检查 /etc/fstab 中的设备标识（UUID 优于 /dev/sdX），防止启动时挂载错盘。

这部分最容易被忽视，也是导致业务中断的主要原因。

glibc 版本跳跃：从 CentOS 7 (glibc 2.17) 到 Anolis 8 (glibc 2.28+)，库版本升级较大。某些老旧的二进制程序（尤其是用 C/C++ 编译的自研服务）可能会因为符号版本不匹配而报错 version 'GLIBC_X.X' not found。
- 对策：重点排查 Java 以外的原生二进制应用。Java 应用通常自带 JRE/JDK，受影响较小，但仍需关注 JNI 调用的本地库。
Python/Ruby 等解释型语言环境：Anolis 8 默认 Python 版本通常是 3.6 或更高，而 CentOS 7 是 2.7。如果你的脚本硬编码了 #!/usr/bin/python，大概率会挂掉。
- 建议：统一使用 python3 命令，或者利用 alternatives 机制建立软链接。对于遗留的 Python 2 项目，建议使用容器化部署，不要在宿主机上强行维持 Python 2 环境。

别以为换了操作系统，旧的 Agent 就能无缝运行。

Zabbix/Prometheus Node Exporter：这些监控探针通常需要重新安装适配 Anolis 内核版本的 RPM 包。部分老版本 Agent 可能不再维护，需联系供应商获取新版本。
日志路径变更：虽然 /var/log/messages 还在，但 Journald 的日志轮转和存储路径可能在 systemd-journald 的配置下有细微调整。确保你的 Logstash/Filebeat 抓取路径正确，避免日志断流。

镜像准备：去开源之夏或龙蜥官网下载最新稳定版的 ISO，制作最小化安装镜像用于测试。
灰度测试：先拿一台非核心的开发或测试机器做 POC（概念验证）。重点测试：应用启动、核心接口调用、定时任务执行、备份恢复。
依赖清单比对：使用 rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}n' | sort > centos_pkgs.txt 导出旧系统包列表，与新系统对比，找出缺失或版本差异大的包。
回滚预案：迁移前务必做好全量备份（包括系统状态和数据）。如果迁移后发现致命 Bug 无法在短期内解决，要有快速切回旧环境的通道（比如保留旧实例停机但不销毁，或保留冷备数据盘）。

总的来说，从 CentOS 到 Anolis 不是简单的“换个名字”，而是一次向更现代化、更安全、更符合国产信创标准的操作系统演进。前期多花时间在依赖梳理和兼容性测试上，后期能省下一半以上的排障时间。