CentOS 7 已于 2024 年 6 月 30 日停止支持。对许多团队来说，这个日期悄然而过——没有立即发生的灾难，没有服务器起火——因此仍有相当多的小型工程团队今天仍在运行 CentOS 7，告诉自己他们会很快处理这个问题。”很快”就是现在。在 2026 年运行未经修补的 RHEL 衍生版不是经过计算的风险；这是运营债务，在最糟糕的情况下，你最终将不得不支付其累积的利息。这份面向小型团队的 CentOS 迁移指南旨在让迁移变得具体：实际的选择、诚实的权衡、技术步骤，以及将常规迁移变成周末事件的特定陷阱。
CentOS 实际上发生了什么
这段历史很重要，因为它解释了为什么现在的选择看起来是这样的，也因为许多团队基于对情况的误读做出了决定。简短版本：红帽扼杀了 CentOS 的本质。
CentOS 是一个免费的、社区维护的 Red Hat Enterprise Linux (RHEL) 重建版本。十年来，它是那些想要企业级 Linux 稳定性但又不愿支付 RHEL 许可成本的团队的标准答案，RHEL 的标准订阅每台服务器每年起价约 350 美元。2020 年 12 月，红帽宣布 CentOS 将成为 CentOS Stream——一个滚动发布发行版，它位于 RHEL 的上游而非下游。CentOS Stream 的新包比 RHEL 更早发布，而不是更晚。它是开发领域。这不是运行生产数据库的团队想要的。
后果立竿见影。本应支持到 2029 年的 CentOS 8 在 2021 年底被提前终止——提前了八年。CentOS 7 保持了其原始的 2024 年 6 月停止支持日期。CentOS 9 Stream 存在，但在任何有意义的角度上都不是 CentOS 的替代品；它是一个永久的 RHEL 预发布测试平台，红帽对此是透明的。在生产中使用 CentOS Stream 是一个合理的选择，但它与旧 CentOS 有着根本的不同。你选择了一个滚动发布版本，变化更快，没有长期稳定性保证。
社区的反应是可预测且迅速的。在公告发布后的几个月内，两个分支启动了：Rocky Linux（由 Gregory Kurtzer 领导，他是 CentOS 的原始创始人之一）和 AlmaLinux（由 CloudLinux 支持）。两者都承诺成为 CentOS 曾经的样子：完全兼容 RHEL 的重建版本，永久免费，社区治理。两者在很大程度上都实现了这一承诺。仅从技术角度来说，现在很难回答应该使用哪一个。
2026 年的真实选择
如果你在 2026 年迁移 CentOS 7 或 CentOS 8，你的现实选择分为两类：留在 RHEL 生态系统，或离开它。每种选择都有合理的理由。不合理的是在没有补丁来源的情况下继续使用 CentOS 7。
留在 RHEL 生态系统
AlmaLinux 9是由非营利组织 AlmaLinux OS Foundation 维护的 RHEL 9 重建版本，由 CloudLinux Inc. 提供资金和资源。AlmaLinux 在 2023 年引入了一个细微但重要的变化：不再声称与 RHEL 具有二进制兼容性，而是现在针对 ABI 兼容性。实际上，这意味着绝大多数 RHEL 认证的软件可以正常工作，但 AlmaLinux 不再像最初那样是严格的一对一重建。对于大多数工作负载，这种差异是看不见的。AlmaLinux 9 支持 x86_64、aarch64、ppc64le 和 s390x 架构，如果您拥有混合硬件集群，这一点很重要。AlmaLinux 9 的支持将持续到 2032 年 5 月。
Rocky Linux 9是由公共福利公司 Rocky Enterprise Software Foundation (RESF) 维护的 RHEL 9 重建版本。Rocky 明确针对与 RHEL 的二进制级兼容性，这意味着其 RPM 包是由 Red Hat 发布的相同源代码构建的。Rocky 是 Gregory Kurtzer 构建的，旨在成为 CentOS 承诺的直接继承者。它支持与 AlmaLinux 相同的架构，并且有相同的生命周期结束目标。Rocky 9 的支持将持续到 2032 年 5 月。
RHEL 本身值得一提，因为 Red Hat 现在的免费开发者订阅允许最多 16 台生产服务器免费使用。对于小型团队，这确实值得考虑：您获得完整的 RHEL，在需要时可以获得官方支持，并且可以避开”这是否真正兼容”的问题。缺点是免费层不包括电话支持，并且当您的服务器集群超过 16 台时，许可模式可能会变得复杂。
离开 RHEL 生态系统
Ubuntu Server LTS是离开 RHEL 的团队最常见的选择。Ubuntu 24.04 LTS (Noble Numbat) 标准支持将持续到 2029 年 4 月，通过 Ubuntu Pro 的扩展安全维护将持续到 2034 年 4 月，Ubuntu Pro 对最多五台机器免费。软件包生态系统非常庞大，文档无处不在，用于自动化的服务器工具（cloud-init、netplan、systemd）已经成熟。权衡之处在于 Canonical 的决策并不总是与企业管理员的需求一致 —— snap 包在服务器安装中一直是个持续的困扰，一些软件包版本与 RHEL 差异较大，需要改变工作流程。
Debian 12 (Bookworm)是您在优先考虑稳定性、可预测性和组织独立性时的正确选择。Debian由志愿者社区运营，没有企业所有者来做产品决策。软件包版本相当保守——这是刻意为之。您不会运行任何最新版本的软件，但Debian稳定版中包含的软件都经过了严格测试。Debian 12的支持将持续到2028年6月，长期支持还会进一步延长。如果您的服务器运行的是稳定版、非前沿软件（PostgreSQL、Nginx、标准Python版本），那么Debian是很难被反驳的选择。
AlmaLinux vs. Rocky Linux：诚实对比
大量在线评论将AlmaLinux与Rocky Linux的选择视为具有重大技术意义的事情。对于大多数小型团队来说，情况并非如此。这两者的软件包功能上完全相同。在这两种情况下，内核版本都紧密跟踪RHEL。启动行为、systemd配置、SELinux策略、firewalld默认设置——这些在两个发行版中基本相同。您不会注意到性能差异。
决定应该基于两个因素：治理偏好和您现有的托管关系。
Rocky Linux的治理结构将其定位为一个完全由社区驱动的项目，有企业赞助但由社区控制。如果您对Red Hat接管CentOS并将其转向的记忆仍然清晰，那么Rocky对社区治理的明确承诺就具有重要意义。提供Rocky Linux商业支持的CIQ公司是重要支持者，但RESF结构旨在防止任何单一实体接管控制权。
AlmaLinux在共享托管和VPS行业有更深厚的根基。许多主要提供商——包括CloudLinux本身、cPanel、许多数据中心运营商——已经标准化采用AlmaLinux。如果您正在托管提供商处迁移服务器，或者依赖带有面板专用软件包的控制面板，那么托管环境很可能对AlmaLinux有更好的支持和测试深度。在决定前请检查您的提供商。
实际建议：选择一个，记录选择，然后继续前进。您花在深入评估这两个发行版上的工程时间，最好花在迁移本身上。
为什么许多团队正在转向Ubuntu或Debian
小型工程团队中存在一个真实的迁移模式，RHEL生态系统不会大声谈论这一点：曾经运行CentOS的相当一部分团队最终转向了Ubuntu或Debian。这些原因值得诚实面对。
首先，人才问题。在 Ubuntu 上学习 Linux 的工程师比在 CentOS 上学习的工程师更为常见，随着云计算将 Ubuntu 作为 AWS、GCP 和 Azure 上的默认服务器镜像，这一差距进一步扩大。由两三名工程师组成的小团队在基于 Debian 的系统上操作可能更加流畅。这不是技术层面的争论，而是实际操作中的现实情况。
其次，工具和文档密度。针对 Ubuntu 与基于 RHEL 系统的博客文章、Stack Overflow 回答和供应商文档的密度相差甚远。Ubuntu 在各方面都拥有更多资源。对于没有专职系统工程师的团队来说，在 Ubuntu 上遇到的问题有已记录解决方案的概率要高得多。
第三，RHEL 生态系统近期的历史造成了信任损害，而 AlmaLinux 和 Rocky 尚未完全修复这一问题——这并非它们自身的过错，而是因为”如果这个项目五年后也改变方向会怎样？”现在成了一个合理的问题。Ubuntu 维护长期支持承诺的记录很长，Debian 的记录更长，而 Rocky 和 AlmaLinux 只有四年的记录。
留在 RHEL 生态系统的反论点也是真实的。如果您运行的是经过 RHEL 认证的软件——商业数据库、ERP 系统、供应商支持条款与 RHEL 变体相关的安全工具——留在该生态系统中可以避免重新协商支持协议。如果您的团队已经具备深入的 SELinux 和 RPM 专业知识，迁移到基于 Debian 系统的再培训成本不容小觑。如果您处于变更控制成本高昂的受监管环境中，选择 Rocky 或 AlmaLinux 意味着从 CentOS 迁移的路径要短得多。
迁移指南
无论您是要迁移到 AlmaLinux、Rocky、Ubuntu 还是 Debian，专业迁移的结构都遵循相同的阶段。跳过任何阶段都可能导致迁移变成事故。
阶段 1：迁移前审计
在您进行任何操作之前，记录服务器上实际运行的内容。这听起来很明显，但生产服务器会积累历史，而您自以为了解的服务器几乎肯定与您拥有的任何文档存在差异。运行 rpm -qa 获取完整软件包列表并保存。运行 systemctl list-units --type=service --state=running 清点正在运行的服务。检查 /etc/cron.d、/var/spool/cron 和 /etc/cron.daily 中的定时任务。使用 ss -tlnp 记录所有监听端口。导出当前的 firewalld 规则或 iptables 规则集。
请特别注意从第三方仓库安装的任何软件包：EPEL、Remi、IUS、SCL 以及任何特定于供应商的仓库。这些是迁移后软件包不兼容的最常见来源。为 CentOS 7 构建的第三方仓库将不会自动有 CentOS 替代品等价物，一些软件包可能需要找到新的上游源或从源代码编译。
阶段 2：在快照或克隆中测试
如果您的基础设施允许——在任何现代虚拟化或云环境中都应该允许——在开始之前对服务器进行快照或克隆。如果您无法进行快照，请在目标发行版上启动一个具有相同软件包列表的虚拟机，并针对它测试您的应用程序堆栈。发现特定版本的 Perl 模块或自定义 Apache 模块在目标操作系统上的行为不完全相同，这应该在测试环境中发生，而不是在实时服务器上。
阶段 3：实际转换（RHEL 路径）
对于从 CentOS 7 到 AlmaLinux 8 或 Rocky Linux 8 的就地迁移，这两个项目都提供了迁移脚本，可以交换基础软件包和仓库，而无需重新安装操作系统。AlmaLinux 提供 almalinux-deploy.sh；Rocky Linux 提供 migrate2rocky.sh。这两个脚本都可以从各自的 GitHub 仓库获取，并且已在数十万台服务器上运行。
一般过程是：通过 HTTPS 下载脚本，验证 SHA256 校验和，以 root 身份运行它。脚本交换 GPG 密钥，替换仓库文件，重新安装基础软件包，然后重启。在安装了标准软件包的干净 CentOS 7 系统上，这通常在 30 分钟内完成。在具有大量自定义、第三方软件包或从非标准源安装的软件包的服务器上，预计会出现问题。
一个重要说明：从 CentOS 7 到 AlmaLinux 9 或 Rocky Linux 9 的直接就地迁移不受官方支持。主要版本跳跃（从 7 到 9）需要先经过 8，或者进行全新安装。如果您的目标是版本 9，最干净的方法通常是进行全新安装并手动迁移数据，而不是链接两个就地升级。
阶段 4：实际迁移（Ubuntu/Debian 路径）
没有从 CentOS 到 Ubuntu 或 Debian 的等效就地迁移路径。这些是不同的软件包管理生态系统，不同的文件系统布局约定，不同的 init 系统配置。您将在新服务器（或已擦除的系统）上进行全新安装，并手动迁移您的应用程序和数据。这实际上是一个伪装成限制的功能：它迫使您从一个干净、已知良好的状态重建，这通常比携带多年积累的冗余代码更健康。
此迁移路径的检查清单如下：配置新服务器，安装应用程序依赖项，迁移数据（文件使用 rsync，数据库使用 pg_dump/mysqldump），复制您的 cron 作业和 systemd 单元，更新任何路径或包名差异的配置文件，然后切换 DNS 或更新负载均衡器目标。在切换前测试每个步骤。
容易让人踩坑的问题
迁移 CentOS 服务器的经验揭示了一系列让团队措手不及的常见问题。提前了解这些问题可以将它们从未知事件转变为预期的工作。
SELinux 策略差异
如果您的 CentOS 服务器以强制模式运行 SELinux — 应该如此 — 而您正在迁移到 AlmaLinux 或 Rocky，那么主要版本的 SELinux 策略相似但不完全相同。为 RHEL 7 编写的自定义 SELinux 策略可能无法干净地应用到 RHEL 9 的等效版本。计划在迁移后进行一次 ausearch 和 audit2allow 处理，以捕获您的自定义配置之前处理的任何拒绝。如果您的 CentOS 服务器将 SELinux 设置为宽容模式或已禁用，请在新的安装上修复这个问题 — 不要将宽容设置作为迁移捷径继续使用。
防火墙配置
CentOS 7 默认使用 firewalld。AlmaLinux 9 和 Rocky Linux 9 也使用 firewalld，但区域行为和一些服务定义在版本之间有所变化。更重要的是，如果您要迁移到 Ubuntu，默认防火墙是 ufw，而不是 firewalld — 并且配置语法完全不同。您现有的防火墙规则不会自动转移。明确导出它们，然后在新的系统上从头重新实现它们。这不是复制粘贴的机会；这是审查所有这些规则是否仍然正确的机会。
网络接口名称
较旧的 CentOS 7 服务器，特别是物理机器或旧虚拟机，可能使用传统的网络接口名称，如 eth0，而不是可预测的接口名称，如 enp3s0eth0，除非您考虑到这一点，否则它们在迁移后会静默失效。在开始前清点所有接口引用。
DNS 解析器更改
基于 RHEL 9 的系统（因此也包括 AlmaLinux 9 和 Rocky 9）默认使用 systemd-resolved，并将 /etc/resolv.conf 作为指向 systemd-resolved 存根的符号链接。如果你的 CentOS 7 服务器手动配置了 /etc/resolv.conf 并包含特定的名称服务器条目，那么在迁移后这些条目可能会被静默忽略或覆盖，除非你明确配置了 systemd-resolved。依赖于特定 DNS 解析行为的应用程序——内部 DNS 服务器、分割水平配置、自定义搜索域——在迁移后需要重新验证。Ubuntu 默认也使用 systemd-resolved，具有相同的行为。
Python 和脚本运行时版本
CentOS 7 随 Python 2.7 作为系统 Python 一起发布，尽管 Python 2 在 2020 年 1 月已达到生命周期终点，但仍有大量内部工具从未移植。如果你的操作脚本、自动化或监控代理依赖于 Python 2，这将是你最终处理它的推动因素。AlmaLinux 9 和 Rocky 9 默认不包含 Python 2。Ubuntu 24.04 完全不包含 Python 2。请在迁移前审查你的脚本，而不是在迁移后。
何时应重建而非就地迁移
就地迁移工具确实有效，但并不总是正确的解决方案。有一个明确的启发式方法：如果服务器已运行超过三年未重建，你应该强烈考虑将迁移视为完全重建，而非就地转换。
运行多年的服务器会积累状态：配置漂移、未在任何地方记录的手动更改、为调试安装但从未删除的软件包、由十八个月前离开的承包商添加的 cron 作业、其目的无人记得的文件权限更改。就地迁移会继承所有这些状态。从头开始重建会给你一个你真正理解其状态的服务器。
如果你的服务器配置不在代码中，重建的论点就更加强有力。如果你的当前 CentOS 服务器是其配置的权威真实来源——意味着你无法通过 Ansible playbook、Terraform 模块或类似工具重现它——那么迁移就是修复这一问题的机会。使用基础设施即代码工具重建服务器，并将旧服务器视为你需要复制的内容的文档。
实际测试：你能回答”这个服务器上运行着什么以及为什么？”这个问题吗？对于每个已安装的软件包、每个运行中的服务和每个 cron 作业？如果不能，就地迁移会将这些未知因素带到你的新系统中。重建会迫使你明确回答这些问题。
成本影响：RHEL 许可证与免费替代方案
财务状况相当直接，很少需要详细分析，但团队有时会将其复杂化。
AlmaLinux、Rocky Linux 和 Debian 都是免费的，这是毫无疑问的。有商业支持选项可用 — CloudLinux 和 CIQ 分别为 AlmaLinux 和 Rocky 提供付费支持，Canonical 提供 Ubuntu Advantage（现称为 Ubuntu Pro）并附带正式的服务级别协议（SLA）— 但基础操作系统本身无需任何费用。对于拥有三到十台服务器的小型团队来说，迁移到任何这些系统的实际成本是工程时间，而非许可费用。
Red Hat 标准费率的 RHEL 许可证每台服务器每年大约需要 350 到 500 美元。十台服务器的话，每年就是 3,500 到 5,000 美元。对于小型团队来说，这是一笔不小的开销。覆盖多达 16 台服务器的免费开发者订阅显著缩小了这一差距，但也带来了隐含风险：Red Hat 可能会更改免费层的条款 — 就他们之前对 CentOS 所做的那样。选择 RHEL 的团队应考虑未来成本变化的可能性。
经常被低估的隐藏成本是迁移本身的工程时间。单个生产服务器的谨慎迁移 — 包括审计、测试、执行和迁移后验证 — 对于一个简单的应用程序，应该预算四到八小时的高级工程师时间。具有许多相互依赖关系、自定义内核模块或遗留软件的复杂服务器可能需要长得多的时间。对于拥有十台服务器的团队，如果你在正常工作的同时谨慎进行迁移，预计需要两到四周的日历时间。
常见问题
我还能在 2026 年为 CentOS 7 获取安全补丁吗？
无法从官方 CentOS 项目获取。CentOS 7 的生命周期已于 2024 年 6 月 30 日结束。TuxCare（前身为 CloudLinux 的扩展生命周期服务）和其他一些供应商提供 CentOS 7 的付费扩展生命周期支持，以提供安全补丁。这只是临时解决方案，而非长期解决方案。如果你使用扩展生命周期服务继续使用 CentOS 7，请设定完成迁移的硬性截止日期 — 为已停止支持（EOL）的软件支付补丁费用并不能降低运行老化软件的潜在风险。
CentOS Stream 是可行的生产平台吗？
这取决于你对变化的容忍度和工作负载类型。CentOS Stream 9 是一个滚动发布的 RHEL 预览版，这意味着其包更新频率高于点分发行版。对于开发环境、暂存环境或对软件包次要版本变化不敏感的工作负载，它是合理的。对于需要仔细控制升级时机的生产数据库或应用程序，Stream 的滚动特性是一个缺点。大多数运行生产服务器的团队应该使用 AlmaLinux、Rocky 或基于 Debian 的替代方案，而不是 Stream。
那 Oracle Linux 呢？
Oracle Linux 是一个合法的 RHEL 重建版本，具有良好的兼容性和 Oracle 的支持。对于小型团队来说，其主要缺点在于治理：Oracle 是一家拥有自身商业利益的公司，其历史上做出的与企业利益相冲突的决策记录足够令人担忧。对 RHEL 服务条款风险的同样论点在这里可能适用力度更大。对于优先考虑独立性的团队，AlmaLinux 和 Rocky 拥有更清晰的治理结构。
我需要迁移 CentOS Stream 服务器吗？
CentOS Stream 8 已于 2024 年 5 月结束生命周期。CentOS Stream 9 正在积极维护并将继续接收更新，但它将在 RHEL 9 结束生命周期时停止，目前预计为 2032 年 5 月。如果您使用的是 Stream 9 并且对其滚动发布的特性感到满意，则无需立即采取行动——但您最晚应在 2030 年之前制定迁移计划，并且应该定期测试应用程序对 Stream 更新的兼容性，以避免意外中断。
能够顺利处理 CentOS 迁移的团队，是将它视为基础设施改进项目，而非紧急修复的团队。那些遇到困难的团队，则是等到安全事件发生后才重视起来的团队。
对于小型团队来说，迁移疲劳是真实存在的，在 CentOS 7 超过其 EOL 日期后继续运行的直接后果往往是不可见的——服务器继续工作，没有警报触发，紧迫感逐渐消退。风险是累积且非线性的：在未打补丁的基础设施上每多待一个月，就多一个月暴露在永远不会被修复的漏洞中的风险。迁移是有限的，但暴露不是。选择您的目标发行版，安排维护窗口，然后执行您的迁移计划。
Michael Sun 撰写关于基础设施、安全以及在小规模环境中运行生产系统的实际操作的文章。在过去的十年中，他曾在 RHEL、Debian 和 BSD 环境中处理过服务器迁移工作。