嘿，伙计。如果你是从 CentOS 7 那个“红色 hat”时代一路走过来的老用户，或者最近刚发现 CentOS 8 突然“短命”、CentOS Stream 变得有点让人摸不着头脑，那你现在的处境我完全理解：想找个稳如老狗、跟 RHEL 1:1 同步、并且长期支持的原生替代方案，而 AlmaLinux 就是那个站在聚光灯下的选择。
但问题来了：选 AlmaLinux 8 还是 9？如果已经在 8 上，能不能直接跳到 9？跳过去会不会炸？别急，咱们坐下来，像老朋友聊天一样，把这块硬骨头掰开揉碎了讲清楚。
一、先搞清楚：AlmaLinux 8 和 9 到底有啥不一样？
这不是简单的“新版本功能多一点”那么简单。对于从 CentOS 转过来的用户，核心差异主要体现在底层技术栈的代际跨度上。
1. 基础生命周期与支持周期
- AlmaLinux 8：基于 RHEL 8，支持到 2029 年 5 月。
- AlmaLinux 9：基于 RHEL 9，支持到 2032 年 5 月。
关键点：如果你现在部署新系统，且业务没有强烈的遗留依赖，AlmaLinux 9 是更长远、更省心的选择。它的生命周期多出 3 年，这意味着你能少一次痛苦的系统级大升级。
2. 核心组件的版本差异（这是坑最多的地方）
| 组件 | AlmaLinux 8 | AlmaLinux 9 | 影响说明 |
|---|---|---|---|
| Linux 内核 | 4.18 (带长期维护补丁) | 5.14 (带长期维护补丁) | AL9 对硬件支持更好，尤其是新 CPU 和 NVMe。 |
| Nginx | 1.14.1 (官方仓库，较老) | 1.20.1 (官方仓库) | AL9 的 Nginx 性能和安全特性更新。 |
| Apache | 2.4.37 | 2.4.57 | AL9 的 Apache 模块和配置语法更现代。 |
| PHP | 7.2 / 7.3 (默认) | 8.0 / 8.1 / 8.2 | 这是最大的痛点。很多老 CMS（如 WordPress 旧版、Laravel 旧版）不支持 PHP 8+。 |
| Python | 3.6 | 3.9 | 3.6 已停止维护，AL9 的 3.9 是安全基线。 |
| GCC | 8.5 | 11.4 | 编译软件时，AL9 更快，支持 C++17/20。 |
| 文件系统 | XFS (默认) | XFS (默认，但 ext4 更成熟) | AL9 对 XFS 的 Scrub/Repair 工具有优化。 |
| 容器 | Podman 3.x / Docker via EPEL | Podman 4.x / Docker via RPM Fusion | AL9 原生更好支持 rootless 容器。 |
二、选择 AlmaLinux 9 的 5 个硬性理由（为什么说它是未来）
理由 1：安全性是根本
AL8 的很多基础库（如 OpenSSL 1.1.1）虽然仍在更新，但整体攻击面比 AL9 的 OpenSSL 3.x 更大。AL9 强制使用 Hardened Compiler（ hardened build flags），这意味着即使你编译第三方软件，默认也带了更多安全检查。
理由 2：硬件兼容性与性能
如果你是 2020 年以后购买的服务器（Intel 11代+、AMD Ryzen/EPYC Milan+），AL8 的内核 4.18 可能无法充分利用 CPU 调度特性或 NVMe 吞吐能力。AL9 的 5.14 内核经过多年 CVE 修复，性能和安全都更优。
理由 3：Cloud Native 原生支持
AL9 对 Kubernetes、OpenShift 相关工具链支持更好。很多云原生工具（如 Helm、ArgoCD）的官方镜像和依赖链已经向新内核和新 glibc 靠拢。
理由 4：长期维护成本更低
多 3 年支持期。如果你现在建一套系统，到 2026 年 AL8 才 halfway，而 AL9 还有近 6 年。避免未来 3 年内再次面临“CentOS 8 终结”式的心碎。
理由 5：社区与文档活跃度
AlmaLinux 9 是当前社区重点支持的版本，新发布的教程、脚本、Ansible roles 大多默认针对 AL9。AL8 的社区资源逐渐变成“维护模式”。
三、为什么有人仍坚持选 AlmaLinux 8？（现实主义的考量）
别急着骂他们保守。以下情况，AL8 可能是更明智的选择：
情况 1：老旧的 Java 应用
你的企业跑着基于 JDK 8 或 11 的老旧 ERP、OA 系统，且这些应用与底层 glibc 或 OpenSSL 版本有微妙绑定。升级到 AL9 可能引发 SSL 握手失败或类加载错误。
情况 2： proprietary 闭源软件
某些数据库（如旧版 Oracle Database 12c/19c 在某些场景）、监控 agent（如旧版 Zabbix agent、Nagios NRPE）可能只认证到 RHEL 8 / AL8。
情况 3：团队技能断层
如果你的运维团队对 systemd、firewalld、nftables（AL9 默认使用 nftables 替代 iptables）还不熟悉，强行上 AL9 可能导致排障困难。
情况 4：PHP 7.4 依赖
虽然 AL9 支持 PHP 7.4（通过 EPEL 或 IUS 源），但官方源默认是 PHP 8.0+。如果你的 WordPress 插件有大量不兼容 PHP 8 的代码，折腾成本很高。
四、从 CentOS / AlmaLinux 8 迁移到 AlmaLinux 9 的潜在兼容性陷阱
假设你已经决定用 AL9，或者需要从 AL8 迁移。以下是真实发生的问题清单及解决方案。
陷阱 1：Nginx 配置语法变化
现象：在 AL8 上运行的 Nginx 1.14，直接移植到 AL9 的 Nginx 1.20，某些旧的 ssl_protocols 或 ssl_ciphers 配置可能因为 OpenSSL 3.0 的移除策略而报错启动失败。
错误示例：
nginx: [emerg] SSL_CTX_set_ssl_version() failed (SSL: error:03000086:digital envelope routines::initialization error)
解决方案：
编辑 /etc/nginx/nginx.conf，更新 ssl_protocols：
# AL8 常见配置 (可能不兼容 AL9)
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# AL9 推荐配置 (移除不安全的 TLSv1 和 TLSv1.1)
ssl_protocols TLSv1.2 TLSv1.3;
同时，检查 ssl_prefer_server_ciphers on; 是否在 AL9 中仍被推荐（答案是 yes，但需配合更安全的 cipher suite）。
陷阱 2：PHP 扩展缺失
现象：某个老项目依赖 php-mcrypt 或 php-mysqlnd 的特定版本。AL9 中 php-mcrypt 已被移除（因为 mcrypt 本身已废弃），你需要改用 php-libsodium 或其他替代。
解决方案：
- 先安装 EPEL 和 Remi 源（推荐 Remi 源获取多个 PHP 版本）：
sudo dnf install epel-release
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
sudo dnf module reset php
sudo dnf module enable php:remi-8.2
sudo dnf install php php-fpm php-mysqlnd php-gd php-curl php-mbstring
- 对于确实需要的旧扩展，检查
php-mysqlnd是否替代了旧的php-mysql。
陷阱 3：Firewalld 与 nftables
现象：AL8 默认使用 iptables 作为 firewalld 的后端，AL9 默认切换到 nftables。如果你之前用 iptables-save 导出了规则并写入了脚本，直接在 AL9 上 iptables-restore 可能无效或报错。
解决方案：
确保所有防火墙规则通过 firewall-cmd 管理，而不是直接操作 iptables 命令。
# 检查后端
firewall-cmd --get-backend
# 输出应该是 nft
# 如果你必须用 iptables 命令，安装兼容层（不推荐生产环境长期依赖）
sudo dnf install iptables-nft
陷阱 4：Python 3.9 与旧脚本
现象：你的自动化脚本写了 #!/usr/bin/python，在 AL8 指向 3.6，在 AL9 指向 3.9。某些旧语法（如 asyncio 的使用方式）在 3.9 中可能被标记为 deprecated 或移除。
解决方案：
- 使用
alternatives管理 Python 版本，或者明确使用python3.9。 - 在 AL9 上，推荐安装
python3-devel和python3-pip，并考虑使用virtualenv隔离项目依赖。
sudo dnf install python3.9 python3.9-devel python3.9-pip
python3.9 -m venv /opt/myproject/venv
source /opt/myproject/venv/bin/activate
pip install -r requirements.txt
陷阱 5：SELinux 策略变化
现象：某些自定义应用（如部署在 /opt 下的 Java 应用）在 AL8 上 SELinux 宽容模式工作，但在 AL9 上被拒绝访问，因为 AL9 的 SELinux 策略更严格。
解决方案： 不要关闭 SELinux！学习诊断：
# 查看被拒绝的操作
sudo ausearch -m avc -ts recent
# 生成本地策略模块
sudo audit2allow -m myapp < /tmp/myapp.mod
sudo semodule -i myapp.pp
或者，为特定目录设置正确的上下文：
sudo chcon -Rt httpd_sys_content_t /opt/myapp/static
sudo semanage fcontext -a -t httpd_sys_content_t "/opt/myapp/static(/.*)?"
五、实际迁移操作步骤（从 AlmaLinux 8 原地升级）
AlmaLinux 官方推荐使用 leapp 工具进行原地升级。以下是经过验证的流程。
步骤 1：前置检查（非常重要！）
# 1. 确保系统完全更新
sudo dnf upgrade --refresh
# 2. 安装 leapp 和预检查工具
sudo dnf install leapp leapp-upgrade leapp-preupgrade
# 3. 禁用第三方非官方源（如某些自定义 RPM 源），避免冲突
# 编辑 /etc/yum.repos.d/ 下的非官方 repo，将 enabled=1 改为 enabled=0
步骤 2：运行预检查
sudo leapp preupgrade
这会生成一份详细的报告，指出哪些包会导致问题。常见警告：
- NFS 客户端：可能需要重新配置。
- 旧版 MySQL/MariaDB：确保版本在 AL9 支持范围内。
- 自定义内核模块：可能需要重新编译。
步骤 3：查看报告并修复
预检查完成后，检查 /var/log/leapp/leapp-report.txt 和 /var/log/leapp/answers/。
如果报告中有 blocking 级别的问题，必须解决后才能继续。
步骤 4：执行升级
sudo leapp upgrade
这将下载 AL9 的 RPM 包并替换旧包。不要重启！ 继续下一步。
步骤 5：准备 initramfs 和重启
sudo leapp reboot
系统重启后，会自动进入新内核。首次启动可能较慢，因为系统在执行post-upgrade脚本（如更新SELinux策略、重建dracut等）。
步骤 6：验证与清理
# 验证版本
cat /etc/almalinux-release
# 输出应包含 AlmaLinux release 9.x
# 清理旧内核（可选，建议保留一个旧内核以便回滚）
sudo dnf autoremove
六、如果不想原地升级？干净的 AL9 安装建议
对于生产环境，干净安装 + 数据迁移 往往比原地升级更稳定。以下是关键配置差异：
1. 网络配置
AL9 使用 NetworkManager 作为默认网络管理工具，ifcfg-* 脚本仍支持但推荐使用 nmcli。
# 设置静态 IP (推荐)
nmcli con mod "System eth0" ipv4.addresses 192.168.1.100/24
nmcli con mod "System eth0" ipv4.gateway 192.168.1.1
nmcli con mod "System eth0" ipv4.dns "8.8.8.8,1.1.1.1"
nmcli con up "System eth0"
2. 用户与权限
AL9 默认启用 sudoers 组管理，且推荐使用 faillock 替代旧的 pam_tally2 进行登录失败锁定。
# 编辑 /etc/pam.d/password-auth 和 /etc/pam.d/system-auth
# 确保包含：
auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900
3. 时区与NTP
AL9 默认使用 chronyd 作为 NTP 客户端。
sudo timedatectl set-timezone Asia/Shanghai
sudo systemctl enable --now chronyd
七、给小朋友也能听懂的总结
想象一下，你以前住在一栋老房子（CentOS 8）里，房子很稳，但物业说这栋楼 2029 年要拆，让你搬到新小区（AlmaLinux 9）。
搬新小区的好处：
- 新房子更坚固，防火防盗系统（安全性）更好。
- 小区设施更新，快递柜、充电桩（新硬件支持）都配齐了。
- 物业承诺这栋楼至少住到 2032 年，你不用急着再搬家。
搬家的麻烦：
- 你家里的老家具（旧软件）可能放不进门（兼容性问题）。
- 新的水管和电路（系统配置）和以前不一样，你要学习怎么用（nftables, SELinux 策略变化）。
- 你不能把老房子直接“变”成新房子，最好是把值钱的东西（数据）搬出来，重新在新房子里布置（干净安装）；或者小心翼翼地整体搬运（原地升级），但要随时准备应对突发状况。
专家的建议： 如果老家具不多，或者你愿意花时间改造（升级软件版本），直接搬进 AlmaLinux 9 的新房子。如果你有很多不能改的老家具（遗留系统），先在 AL8 里多住几年，等家具都处理好了，再搬家也不迟。
八、最后的忠告
- 永远先备份：无论是原地升级还是干净安装，操作前快照虚拟机或备份
/etc、/var、数据库。 - 测试环境先行：不要在生产线直接做
leapp upgrade。先在测试机上模拟一遍。 - 关注 AlmaLinux 官方论坛：社区非常活跃，遇到问题先搜索，很可能有人已经踩过坑并给出了答案。
- 不要害怕学习新工具：从
iptables到nftables，从system-config-*到nmcli，掌握这些新工具会让你成为更专业的 Linux 管理员。
AlmaLinux 9 是 CentOS 遗民们一个值得投入的未来。它稳定、免费、社区友好。只要做好兼容性评估， migration 的过程可以很平滑。祝你在新的系统上跑得飞快！