CentOS 7.4 安装 Docker、Nginx，软件版本应该怎么选

CentOS 7.4 装 Docker 或 Nginx 时，下载成功不代表兼容。缺系统库、内核能力不足或启动失败，往往与软件包和主机环境不匹配有关。

没有一组 Docker、Nginx 版本能保证适合所有 CentOS 7.4 项目。要先看软件是否还支持这个系统，再看包依赖，最后验证业务。不能只按“别人装成功过”的版本号选择。

先分清三个条件

软件能下载，说明文件仍然存在；能安装，说明依赖检查暂时通过；厂商支持，才表示这个系统组合在其维护范围内。三者不是一回事。

本文核对时，Docker 当前 CentOS 安装文档列的是仍受维护的 CentOS Stream 9、10；Nginx 当前 RHEL 及衍生发行版软件包支持列表也已从 8 系列起列出。不能把当前安装步骤直接套到 CentOS 7.4。

一些旧 EL7 包仍可能保存在历史目录里，这不表示它们今天仍获得维护。用于复现与用于公网长期运行，选择标准不同。

先把主机环境查完整

cat /etc/redhat-release
uname -r
uname -m
rpm -q glibc openssl libseccomp
yum repolist all

普通用户一般可以查询这些信息，安装和服务管理则需要管理员权限。记录系统是否仍为 7.4，还是已经安装了后续组件；“最初用 7.4 ISO 安装”不能说明它现在仍是原始包集合。

找历史软件包时，架构要匹配，依赖也要能从可信仓库获得。EL8、EL9 包不能因为名字一样就拿到 EL7 上装。

Docker：先确认宿主机能否满足运行条件

Docker 依赖宿主机内核、cgroup、存储驱动和相关系统包。程序装进去以后，还可能在拉取镜像、建立网络或启动容器时失败。

如果只是复现旧 Docker 项目，优先还原原来已经验证的 Engine、CLI、containerd 和 Compose 组合，以及镜像的准确标签或摘要。不要只固定 docker-ce，却让其余组件随意选择最新版本。

在已经核实来源和适用范围的历史仓库中，可以列出可用版本：

yum --disablerepo='*' --enablerepo='已核实的仓库ID' list docker-ce --showduplicates

这里的仓库 ID 需要替换，不能原样执行。列出来以后，先预览完整安装事务，确认依赖来源和组件组合。若无法拿到原来那组包，应在测试副本验证替代方案，不能宣称某个旧版本“必定兼容”。

已有 Docker 主机还应记录：

docker version
docker info
docker ps -a
docker volume ls

保留容器启动参数、Compose 文件和卷数据备份。不要直接卸载旧 Docker 再说，尤其不能把 /var/lib/docker 当作普通缓存删除。

Nginx：除了版本号，还要看模块和构建参数

Nginx 的差别可能来自编译模块、OpenSSL、动态模块或配置语法。版本号相同，构建选项不同，也可能加载不了原来的配置。

已有环境先记录：

nginx -v
nginx -V
nginx -t
rpm -q nginx

nginx -V 可以看到构建参数，nginx -t 用于检查配置。项目如果用了额外模块，要核对模块与 Nginx 二进制的匹配关系。

新装旧环境时，从已确认来源的 EL7 历史仓库查看包版本，先预览事务，在测试机安装后执行配置检查，再测试证书、请求转发、上传限制和业务接口。能返回默认首页，还不足以证明原项目可用。

不要把“缺少新 glibc”理解成需要手动替换系统 glibc。为了单个程序强行升级核心库，很容易把 yum、SSH 和其他服务一并破坏。

源码编译能解决吗？

源码编译有时能绕过发行包限制，但不会自动解决所有兼容问题。新源码可能要求新编译器、系统库或内核能力，还需要有人负责后续漏洞修复、重编译和升级。

如果确实需要自编译，应保留源码版本、补丁、构建参数和可重建脚本，并与系统包目录区分。不能把一次编译成功当成长期维护方案。

怎么选才更稳妥？

复现旧项目，优先使用原来验证过的完整软件组合，在隔离环境保存它。旧生产系统临时补装软件，先判断能否转移到受维护的新主机，别为了多装一个新组件继续扩大旧机职责。

新部署则先确定应用支持的现代发行版，再按软件当前支持范围安装。容器也不能让旧宿主机获得新内核：把新应用装进容器，仍然需要检查宿主机运行条件。

不要把目标定为把某个包强行装进去。主机、依赖、程序和项目配置应共同通过验证，并且能持续维护，版本选择才算有了可靠依据。