从CentOS迁移到Anolis OS有哪些注意事项？

从 CentOS 迁移到 Anolis OS（龙蜥操作系统），本质上是从一个“停止维护的社区版”转向一个“企业级、长期支持且深度适配国产硬件/云环境”的系统。这不仅仅是换个名字装系统，更涉及到内核参数、依赖包兼容性以及业务稳定性的重新评估。

作为在一线做过多次系统迁移的技术人员，我总结了以下几个核心注意事项，按优先级排列：

1. 明确你的底层架构与芯片类型

这是最容易踩坑的地方。Anolis OS 分为 x86_64 和 aarch64 (ARM) 两个主要版本。

• 如果你是在阿里云 ECS x86 实例上迁移：直接选择 Anolis OS 8.x 或 9.x 的 x86_64 版本即可，体验最接近 CentOS 7/8。
• 如果你涉及 ARM 架构（如倚天、鲲鹏等）：必须使用 aarch64 版本的 Anolis OS。注意，CentOS 是纯 x86 生态出身，而 Anolis 对 ARM 的支持非常早且深入。不要试图在 ARM 服务器上强行运行 x86 的二进制包，除非你使用了 QEMU 模拟（性能极差，生产环境严禁）。

2. 软件源与包管理器的差异

虽然 Anolis OS 兼容 RPM 包格式，但默认的软件源（Repository）已经变了。

• 清理旧源：迁移前务必清空 /etc/yum.repos.d/ 下所有以 centos 命名的 repo 文件。
• 配置新源：Anolis 官方提供了专门的镜像源。建议在迁移后立即执行 yum makecache 刷新元数据。
• EPEL 兼容性：很多业务依赖 EPEL 扩展包。Anolis OS 通常内置了对部分常用 EPEL 包的兼容，或者提供自己的增强仓库。如果某个特定小工具在 Anolis 官方源找不到，优先去 Anolis 社区寻找替代方案，而不是盲目挂载 CentOS 7 的 EPEL 源，这可能导致依赖冲突（Dependency Hell）。

3. 内核模块与 DKMS 驱动

这是迁移中最具技术含量的部分。

• 内核版本：Anolis OS 8 基于 RHEL 8/CentOS 8 的内核分支，但做了大量优化。如果你的业务依赖特定的内核模块（如某些虚拟化驱动、GPU 驱动、或自研的内核补丁），需要确认这些模块是否已合入 Anolis 的内核主线。
• DKMS（Dynamic Kernel Module Support）：如果你有通过 DKMS 安装的第三方内核模块（例如某些网卡驱动、加密狗驱动），迁移后必须重新编译。因为内核版本可能发生变化（即使主版本号相同，次版本号也可能不同）。
  • 操作建议：迁移完成后，立即检查 dkms status，确保所有模块都标记为 installed。如果有报错，手动运行 dkms autoinstall。

4. 系统服务与初始化脚本

• Systemd 一致性：Anolis OS 全面采用 systemd，这点与 CentOS 7+ 一致，所以大部分 .service 文件可以直接复用。
• SysVinit 脚本：如果你的业务还在使用旧的 /etc/init.d/ 脚本，建议尽快改造为 systemd unit 文件。Anolis 对 systemd 的支持更彻底，老旧的 init 脚本可能会遇到权限或路径问题。
• 防火墙策略：CentOS 7 默认用 iptables，CentOS 8/Anolis 8 默认切换到 firewalld（基于 nftables）。如果你的运维脚本里硬编码了 iptables-save 或 iptables-restore，迁移后大概率会失效或报错。
  • 解决方案：统一使用 firewall-cmd 命令，或者在业务允许的情况下，关闭 firewalld 并使用 iptables-nft 后端过渡。

5. 语言环境与字符集

国内业务常涉及中文显示，这里有个经典陷阱：

• CentOS 7 默认可能是 en_US.UTF-8。
• Anolis OS 为了适应国内用户，安装时往往预置了更好的中文支持，但最小化安装（Minimal Install）仍可能保持英文环境。
• 关键点：检查 /etc/locale.conf 和 /etc/environment。如果你的应用日志中出现了乱码，或者 Java 应用启动时报 Unsupported character encoding，第一时间检查 LANG 和 LC_ALL 变量。建议统一设置为 zh_CN.UTF-8 或 en_US.UTF-8，并在 /etc/profile.d/ 中固化。

6. 安全合规与 SELinux

• SELinux 状态：CentOS 默认开启 SELinux，Anolis 也默认开启。迁移时千万不要为了省事直接 setenforce 0。虽然短期内能解决很多权限报错，但长期来看会带来巨大的安全隐患，且不符合等保要求。
• 审计规则：如果你们有等保测评需求，Anolis OS 内置了一些针对国密算法的支持（如 SM2/SM3/SM4），如果你的业务涉及XX或XX，可以利用这一优势进行合规性加固。同时，检查 /etc/selinux/config 中的策略是否正确加载。

7. 迁移实操步骤建议（非停机迁移 vs 停机迁移）

推荐方案：快照 + 新实例测试

1. 备份：对原 CentOS 服务器做全量快照。
2. 创建新实例：在云平台创建一台同配置的 Anolis OS 实例。
3. 数据同步：使用 rsync 将数据同步到新实例。
4. 应用部署：在新实例上重新部署应用（或使用 Docker/Podman 容器化部署，这样最干净）。
5. 灰度验证：修改本地 hosts 或 DNS，让少量流量指向新实例，观察日志、错误率、性能指标。
6. 切换：确认无误后，正式切换 IP 或域名解析。

不推荐方案：原地升级（In-place Upgrade）
虽然理论上可以通过 leapp 工具从 CentOS 7 升级到 Anolis 8（类似 RHEL 的升级路径），但强烈不建议在生产环境这样做。原因如下：

• 风险极高：任何一步失败都可能导致系统无法启动。
• 残留垃圾多：原地升级会保留大量历史配置、临时文件和过时库，极易引发隐蔽 Bug。
• 时间成本：排查原地升级的问题，远不如新建一台机器快。

8. 特别提示：关于“国产替代”的心理预期

Anolis OS 是由阿里云发起、开放原子开源基金会孵化的项目，其目标是提供一个比 CentOS 更稳定、更安全、更适合中国云环境的操作系统。

• 不要指望它完全等于 CentOS：它在网络栈、存储驱动、虚拟化层做了大量针对云场景的优化，这意味着在某些极端边缘场景下，行为可能与 CentOS 有细微差别。
• 文档资源：遇到问题时，优先查阅 Anolis OS 官方文档 和社区论坛，而不是去 StackOverflow 搜 CentOS 的帖子，因为底层实现可能有差异。

总结一句话：
迁移的核心不是“换系统”，而是“验证兼容性”。做好内核模块重编译、防火墙策略转换、软件源替换这三件事，就能避开 90% 的坑。其余的，交给自动化测试和灰度发布来解决。