老项目离不开 CentOS 7 怎么办？分阶段过渡和恢复准备

旧项目只能在现有 CentOS 7 服务器运行，却没有把握重新部署，风险不只是系统停止维护。一旦硬件损坏或配置丢失，环境无法重建也会影响恢复。

过渡的第一步应是做出一份能恢复、能验证的副本，再逐步减少旧机职责。在生产机上同时改系统、数据库和应用，一般会让故障更难定位。

先问清“绑定”到底绑定了什么

“只能用 CentOS 7”可能有几种原因：闭源软件只认证这个系统，程序依赖某个旧动态库，设备驱动只支持特定内核，或者安装脚本只是写死了系统名称。

这些情况的处理完全不同。脚本检查可以由维护方调整并测试，二进制依赖需要重新构建或兼容环境，硬件驱动可能要求替换设备，商业认证则需要供应商参与。

先列出应用、运行时、数据库、系统库、驱动和外部接口版本，把“以前就是这么装的”变成能检查的依赖清单。

第一阶段：先证明能恢复

保留系统镜像或经过验证的整机恢复方案，数据库单独做一致性备份，文件和配置另存。备份不要只放在原机，也不要只有一个从未导入过的 SQL 文件。

在隔离网络恢复一台副本，确认系统能启动、应用能登录、数据能读写，定时任务和上传文件也正常。副本中应停用会向真实用户发消息、处理生产队列或修改外部系统的任务。

记录恢复时间。如果恢复一次需要两天，而业务只能停一小时，这份方案即使能成功，也不符合要求，需要继续改进。

第二阶段：收紧旧机的工作范围

列出外部入口和内部依赖，把不再使用的端口、服务和账号停掉。远程管理通过受控入口，数据库只允许必要的应用来源访问。

静态文件、入口 TLS 或其他适合拆出的功能，可以在测试后迁到受维护的新主机。这样可以减少旧机直接接触外部请求的机会，但不等于旧系统漏洞已经被修复。

新入口要限制旧机只接受预期来源，避免原来的公开地址仍然能够绕过新入口。日志里也要保留合理的请求追踪信息，方便故障定位。

第三阶段：固定现有环境，停止随手加东西

把当前软件包、安装介质、源码、配置和部署脚本整理到受控存储，记录版本与校验值。第三方仓库消失后，仍应能在许可允许的范围内重建所需环境。

不要在旧机上不断增加新服务，也不要为了一个新程序手工升级 glibc、OpenSSL 等系统核心组件。新增功能优先放在受维护的新环境，通过已定义接口与旧项目通信。

如果准备从 7.4 更新到最终 7.9 包集合，先在恢复副本中验证。需要延长补丁服务时，确认覆盖范围和修复时效，别把某个组件的补丁当成整机维护。

第四阶段：一次只验证一类变化

可以先在新系统上运行原应用版本，再单独评估数据库升级；也可以先将应用与数据库分离，再迁移应用主机。顺序由依赖决定，但每一步都应有独立的验收和回退办法。

比如，当前数据库已经有受支持的迁移方案，应用只需要调整连接地址，就可以先验证数据库迁移。但如果跨版本会改变 SQL 行为，就必须加入查询和数据一致性测试，不能只测连接成功。

“改得少”不只是少敲命令，而是每次变更影响范围清楚、失败原因容易定位、恢复动作可执行。

容器和虚拟机，各能解决什么？

将旧系统保留成虚拟机，可以帮助摆脱即将损坏的物理硬件，方便复制和测试。但虚拟机内部的 CentOS 7 仍然是旧系统，维护问题没有消失。

把应用放进容器，可以固定一部分用户空间依赖，但普通容器使用宿主机内核。应用依赖特殊内核、驱动、设备或完整系统服务时，未必适合直接容器化。

容器镜像中的旧库也仍然需要修复来源。换成容器格式，并不会让它们自动获得补丁。

给过渡方案设一个完成条件

至少写清旧机剩余职责、每阶段负责人、目标时间、验证项目和回退条件。不要只写“后面再迁”。

可以用一张表跟踪：

不必在过渡第一天重写整个项目。先让环境能够恢复和测试，再逐步替换依赖，才有条件从只靠一台旧机运行，走向可维护的新环境。