1. 2025年还在用 CentOS7 镜像的人，到底在图什么
CentOS7 现在是个挺尴尬的存在：官方源在 2024 年 6 月底正式停止更新，mirrorlist.centos.org这个域名也随之下线，但你手上那批老项目、老编译链、老中间件还牢牢压在这个底座上。更微妙的是，docker pull centos:7依然能顺畅拉下来，镜像也在，docker images里显示得好好的 204MB，可你进容器随手敲一句yum install -y vim，大概率直接甩给你一串Could not resolve host: mirrorlist.centos.org。镜像还在、源没了，这就是当下最真实的现状，也是很多人在 Docker 环境里反复折腾 CentOS7 镜像的原因。
这篇内容想聊的，就是把 CentOS7 系镜像在 Docker 里的几种常见做法捋清楚：官方centos:7到底还能不能用、社区重建版镜像和兼容发行版镜像各自是什么脾气、yum 报错了该怎么一步步排查、自己怎么焊一个能长期复用的基础镜像、离线内网怎么搬运、以及真要搬家时该从哪里下手。不管你是刚接触 Docker 想跑个 CentOS7 环境做实验，还是手上有存量业务必须继续用 7 这个版本号，下面这些内容都能直接抄去用。
1.1 官方源停摆之后，centos:7 这个镜像变成了"半成品"
理解现在的处境，得先把时间线理清楚。CentOS 8 在 2021 年底提前结束生命周期，官方把重心挪到了 Stream 版本上；CentOS 7 则按原计划一路维护到 2024 年 6 月 30 日。停止维护之后，原本负责分发软件包的mirror.centos.org和mirrorlist.centos.org逐步下线，旧版本的所有包被归档到了vault.centos.org这个地址上。归档的意思是：东西还在，只是不会再更新，也不再有镜像列表服务，你得自己知道确切的路径去取。
问题就出在这里。Docker Hub 上的centos:7镜像最后一次构建大概是在 2020 年底，也就是说镜像内部/etc/yum.repos.d/CentOS-Base.repo里写的还是当年那套mirrorlist=http://mirrorlist.centos.org/?release=$releasever&...的配置。这个域名现在解析不了，yum 第一步去拿镜像列表就挂了，后面的下载、安装自然全都无从谈起。所以你会看到一个反直觉的现象：镜像本身是完好的、能启动、能进 bash，但包管理器彻底瘫了。
这就意味着centos:7现在更像一个"裸壳"而不是一个可用的操作系统环境。你可以拿它跑静态编译好的二进制程序，可以拿它当文件系统底座，但只要涉及到装包、编译、拉起依赖，就必须先动手把源修好。很多人第一次遇到这个报错会怀疑是 Docker 网络问题、DNS 问题、公司防火墙问题，折腾半天才发现根本不是网络的事，是那个域名已经不存在了。
1.2 三类真实的存量场景：老编译链、老旧中间件、内网交付
为什么大家不干脆换个新底座？因为现实里的约束往往不在技术选型上。我在实际工作中碰到的场景，基本能归成三类。
第一类是编译环境锁定。有些 C/C++ 项目依赖的第三方库只提供了针对 CentOS7 时代的预编译包，或者构建脚本里写死了/usr/lib64/libssl.so.10这类路径。CentOS7 用的是 glibc 2.17、OpenSSL 1.0.2，这些版本号在今天看来很老，但偏偏就是某些商业软件、某些老 SDK 的硬性要求。
第二类是老旧中间件和私有软件。一些企业内部部署的中间件、监控 Agent、加密设备驱动，官方给的安装包就是.rpm，而且明确只支持 RHEL7/CentOS7 系。你想在 Rocky Linux 9 上装，人家连依赖都过不去。
第三类是内网离线交付。这个场景特别典型：生产环境完全不通外网，所有镜像必须先在外网环境准备好，导出成 tar 包，再拷进内网加载。这种情况下，"在线源能不能用"根本不重要，重要的是镜像里该装的包是不是已经装齐了，版本是不是钉死了。这也是为什么我后面会专门花一节讲docker save和离线分发，因为对这批用户来说，这才是真正的日常。
提醒一句：如果你的项目已经在往新版本迁移的路上，那就不要在新环境里继续铺 CentOS7 了。给自己留一个"只读"的 CentOS7 环境用于复现历史问题就够了，新东西一律上新底座。
2. 手上能拿到的四类 CentOS7 系镜像，脾气各不相同
要选镜像，第一步是先搞清楚市面上到底有哪些选择。我说的"CentOS7 镜像"其实包含四类完全不同的东西：官方归档镜像、社区重建镜像、兼容发行版镜像、以及极简替代底座。它们都能给你一个"像 CentOS7 一样"的环境，但来源、可信度、维护状态、体积、坑点全都不一样，混着用是要出事的。
先给一个总的原则：能用官方就用官方，官方源挂了就修源，不要为了省事去用来源不明的第三方镜像。我见过不少人在网上随便搜一个centos7-vault之类的镜像名就docker pull，拉下来发现里面塞了不知道什么东西，甚至带了不该带的东西。基础镜像这种要长期复用的东西，来源必须可追溯。
2.1 官方 centos:7 与 centos:7.9.2009：同一个镜像，两个标签
先澄清一个高频疑问：centos:7和centos:7.9.2009是不是两个不同的镜像？不是。CentOS 7 的最后一个版本号就是 7.9.2009（2020 年 9 月发布），所以7这个滚动标签最终指向的就是7.9.2009这个具体版本。你在 Docker Hub 上看到这两个 tag，拉下来docker images显示的 image ID 是一样的。
那为什么还要区分？因为可复现性。如果你在 Dockerfile 里写FROM centos:7，理论上今天和三年后拉到的应该是同一个东西（毕竟已经冻结了），但依赖一个"滚动标签"始终不如直接钉版本号来得踏实。我的习惯是：开发调试阶段用centos:7图省事，一旦进了生产 Dockerfile，一律写FROM centos:7.9.2009，条件允许的话再进一步钉到 digest。
关于这个镜像本身有几个特点值得记一下。它大约 204MB，内置了 yum、rpm、bash、coreutils 这些基础工具，但没有 systemd、没有 sshd、没有 vim、没有 curl（部分版本有精简过的 curl）。python命令指向的是 Python 2.7.5，这是 CentOS7 的系统 Python，动它之前先想清楚。/etc/yum.repos.d/下有CentOS-Base.repo、CentOS-Sources.repo、CentOS-Vault.repo这几个文件，修源的时候要盯准CentOS-Base.repo，别用通配符一把梭。
2.2 社区重建版镜像：把 vault 源提前焊死在镜像里
所谓的"社区重建版"，本质上就是有人把官方centos:7拉下来，改好/etc/yum.repos.d/里的地址，指向vault.centos.org或者某个镜像站的归档路径，然后重新推成一个新镜像。这类镜像的价值在于省事：拉下来直接yum install就能用，不用每次自己改 repo 文件。
但这里的风险也很明确。第一，你无法确认对方在重建过程中有没有动过别的东西；第二，这类镜像的 tag 命名往往很随意，latest、v7、7-fixed什么都有，没有版本概念，下次拉可能就不是同一个东西了；第三，官方镜像已经是"最后一次构建"，不存在过期概念，但社区镜像如果哪天作者删库了，你的构建链就断了。
我的建议是：把社区重建版当作参考实现，而不是直接用。看到哪个镜像的修源思路不错，抄过来，自己写进 Dockerfile，构建成自己仓库里的镜像，打上自己的标签。这样既拿到了便利，又把控制权攥在手里。我在实际项目里就是这么干的，公司私有仓库里那个base/centos7:7.9.2009-v3就是自己维护的，谁改了什么、什么时候改的，清清楚楚。
2.3 兼容发行版镜像：rockylinux、almalinux、oraclelinux 怎么挑
如果你的目的只是"要一个 yum/dnf 系、接近 RHEL 7 风格的环境"，而不是严格复现 CentOS7 的每一个包版本，那兼容发行版其实更值得考虑。
oraclelinux:7-slim是我个人比较喜欢的一个选择。它和 CentOS7 同源，glibc 同样是 2.17，OpenSSL 同样是 1.0.2，几乎所有针对 CentOS7 编译的二进制都能直接跑，但体积比官方 centos:7 小一截，而且 Oracle 那边对 7 系的支持周期拉得更长一些。用它替换centos:7，绝大多数场景下是"换汤不换药"。
rockylinux:8和almalinux:8属于下一代底座，glibc 2.28、OpenSSL 1.1.1、包管理器换成了 dnf，体积也更小。它们适合作为迁移目标而不是 CentOS7 的替代品——因为 ABI 层面确实变了，下面第 6 节我会专门讲这里面的坑。
至于 Alpine、Debian slim 这类极简镜像，只有在你跑的是静态编译的二进制（比如 Go 程序、Rust 程序）时才划算。Alpine 用的是 musl libc，跟 glibc 是两个世界，任何动态链接了 glibc 的东西搬过去都会炸。
2.4 一张对照表：什么场景用哪个底座
把上面的信息整理成一张表，选型的时候直接对照着看：
| 底座 | 版本 | glibc | 包管理 | 体积（大致） | 最适合的场景 |
|---|---|---|---|---|---|
centos:7.9.2009 | 7.9 | 2.17 | yum | ~204MB | 严格复现历史环境、跑老 RPM 包 |
自建centos7-vault | 7.9 | 2.17 | yum | ~230MB | 日常开发、CI 构建、内网交付 |
oraclelinux:7-slim | 7.9 | 2.17 | yum | ~130MB | 想要 7 系兼容又要瘦身 |
rockylinux:8 | 8.x | 2.28 | dnf | ~190MB | 迁移过渡期的新环境 |
rockylinux:9 | 9.x | 2.34 | dnf | ~180MB | 全新项目 |
debian:bullseye-slim | 11 | 2.31 | apt | ~80MB | 只跑静态二进制或自带运行时的程序 |
体积这几个数字不用太较真，不同时间点、不同架构会有浮动，看相对关系就行。真正决定选型的是中间那两列：glibc 版本和你程序对它的依赖，以及包管理器的生态。这两条一确定，剩下的基本就没什么可纠结的了。
3. 拉下来就报错：yum 不可用问题的完整排查链路
现在进入最实用的部分。假设你已经docker run -it --rm centos:7 bash进了容器，敲yum install -y vim，得到的是：
Loaded plugins: fastestmirror, ovl Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"碰到这个不要慌，也不要急着去改 Docker 的 DNS 设置或者重启 Docker 服务，先按下面这条链路一步步走。我之所以强调"链路"，是因为很多人一看报错就跳到结论去改 repo 文件，结果改错了地方，反而把本来能用的状态搞坏。
3.1 第一步：确认是网络、DNS 还是源本身没了
排查要从最外层往里剥。先确认容器里到底能不能上网：
# 容器内执行 cat /etc/resolv.conf getent hosts vault.centos.org如果getent hosts vault.centos.org能返回 IP，说明 DNS 没问题，网络出口也通，那问题就锁定在mirrorlist.centos.org这个域名本身——对，就是它下线了。这种情况下你改 DNS、改 Docker 配置、改 hosts，全都是白费功夫。
如果连vault.centos.org都解析不出来，那才轮到排查网络：宿主机能不能解析？是不是公司内网环境需要配置代理？Docker 的 DNS 是不是继承错了？这几步分开查，别混在一起。
还有个小技巧：curl -I http://mirrorlist.centos.org和nslookup mirrorlist.centos.org在最小化的 centos:7 容器里可能根本没装。这时候别急着装工具——装 curl 本身也需要能用的源，这就是典型的鸡生蛋问题，下面会专门讲。
3.2 第二步：把 mirrorlist 换成 vault 的 baseurl
确认是源的问题之后，直接手工改/etc/yum.repos.d/CentOS-Base.repo。动手之前先 cat 看一眼，因为不同时间从不同渠道拿到的centos:7镜像，repo 文件内容可能略有差异，盲改容易出错：
cat /etc/yum.repos.d/CentOS-Base.repo典型的原始内容长这样（以 base 段为例）：
[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7改造思路就两步：把mirrorlist那行注释掉，把baseurl那行启用并换成 vault 地址。这两件事可以用一条 sed 搞定：
sed -i \ -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Base.repo yum clean all yum makecache这里有三个坑必须提前说清楚，每一个我都亲自踩过。
第一个坑是别用通配符。/etc/yum.repos.d/CentOS-*.repo会把CentOS-Vault.repo和CentOS-Sources.repo一起改掉，而CentOS-Vault.repo里本来就已经是 vault 地址了，被 sed 再处理一遍可能产生重复或畸形配置，yum 直接报文件解析错误。老老实实只改CentOS-Base.repo。
第二个坑是**$releasever变量在 vault 路径下的行为**。用http://vault.centos.org/centos/$releasever/os/$basearch/这种写法，最终会展开成vault.centos.org/centos/7/os/x86_64/，这个是能用的。但如果你换成某些第三方镜像站的归档路径，人家的目录结构里可能只保留了7.9.2009这种精确版本号，没有7这一层。这种时候就要把变量写死：
sed -i 's|\$releasever|7.9.2009|g' /etc/yum.repos.d/CentOS-Base.repo写死版本号其实还有个额外好处：构建结果确定。今天构建和半年后构建拉到的是同一批包，这在做 CI 的时候特别重要。
第三个坑是GPG key 不用动。gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7指向的是镜像里自带的那把公钥，vault 归档里的包还是用同一把 key 签的，所以校验不会有问题。反倒是如果你从别处下载了一份 vendor 提供的 repo 文件覆盖过去，那份文件里的 gpgkey 可能指向一个网络地址，在不通外网的环境里就会校验失败。所以我的做法是：只改 server 地址，保留本地 gpgkey 路径。
3.3 第三步：GPG Key 与 TLS 握手这类"第二层坑"
源改好了，yum makecache也过了，结果yum install -y git的时候又跳出新的错误，这种"修好一个冒出一个"的体验特别消耗耐心。常见的第二层坑有两个。
一个是NSS error -5961。CentOS7 里的 curl 是基于 NSS 库的，版本比较老，遇到只支持较新 TLS 协议版本、或者证书链用了新算法的站点时，握手会直接失败，报出来的就是curl#58 - "SSL connect error"或者NSS error -5961。解决办法是先更新基础库：
yum install -y ca-certificates nss curl这个命令的前提是源已经修好了。顺序不能反。
另一个是容器时间不对导致 HTTPS 校验失败。基础镜像里没有 NTP，容器时间继承宿主机，一般没问题；但如果你的宿主机本身时间漂了，或者在某些虚拟化环境里时间同步没做好，证书的有效期校验就会失败，报certificate is not yet valid之类的错。进容器先敲一句date -u看一眼，能省掉很多无谓的排查。
3.4 第四步：验证源是否真的可用，别只看 makecache 成功
yum clean all yum makecache只跑完yum clean all看到"已清理"是不算数的。真正的验证是装一个包试试，而且要挑一个带依赖的包，比如：
yum install -y --setopt=tsflags=nodocs tzdata openssl或者更彻底一点，直接把 yum 的仓库列表和执行路径都打出来看：
yum repolist -vrepolist会列出每个仓库的 ID、名称、状态、包数量。如果某个仓库显示0 packages或者状态是disabled，说明配置还有问题。另外一个值得养成的习惯是加--setopt=tsflags=nodocs，它会让 yum 跳过安装 man 手册和文档文件，对一个基础镜像来说能省下十几兆到几十兆的空间，而且完全不影响功能。这个参数你也可以直接写进/etc/yum.conf里，一次配置长期生效。
一个纯经验性的判断：如果
yum makecache在 30 秒内完成，说明源速度不错；如果超过两分钟还在转，多半是fastestmirror插件在逐个测速。容器环境里这个插件纯属累赘，直接/etc/yum/pluginconf.d/fastestmirror.conf里把enabled=1改成0，能明显提速。
4. 自己焊一个能长期用的 CentOS7 基础镜像
把上面的排查过程固化成 Dockerfile，就得到了一个可复用、可版本管理、可内网分发的基础镜像。这一步的价值在于：所有的修复动作都被记录在代码里，而不是散落在某个人的终端历史里。以后新同事接手，docker build一下就能得到完全一样的环境，不用再去问"你当时是怎么改的"。
4.1 Dockerfile 的骨架：从源改造到清理缓存的顺序问题
先给一个我实际在用的骨架，然后再解释每一行的用意：
FROM centos:7.9.2009 ENV LANG=en_US.UTF-8 \ LC_ALL=en_US.UTF-8 \ TZ=Asia/Shanghai \ container=docker RUN set -eux; \ sed -i \ -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Base.repo; \ sed -i 's|\$releasever|7.9.2009|g' /etc/yum.repos.d/CentOS-Base.repo; \ echo 'tsflags=nodocs' >> /etc/yum.conf; \ yum clean all; \ yum makecache; \ localedef -i en_US -f UTF-8 en_US.UTF-8; \ ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime; \ yum clean all; \ rm -rf /var/cache/yum /tmp/* CMD ["/bin/bash"]几个地方值得展开说。第一，set -eux这三个开关几乎是写 Dockerfile 的必备：-e让任何一条命令失败就整体退出，避免构建出"看起来成功实际残缺"的镜像；-u让引用未定义变量时报错；-x把每条执行的命令打印出来，方便看构建日志定位问题。
第二，两次yum clean all不是冗余。第一次在makecache之前，是为了清掉旧源残留的缓存元数据；第二次在最后，是为了清掉刚刚重新生成的缓存。缓存目录/var/cache/yum里躺着的是几个 G 的元数据和下载的 rpm 包，不清掉的话，你装 10MB 的软件能长出 200MB 的镜像层。
第三，顺序很关键。所有yum相关的操作必须放在同一个RUN里，因为 Docker 的每一层都是叠加的。如果你写两个 RUN，第一个装包、第二个清理缓存，最终镜像里那层缓存依然存在，只是被"覆盖"了，体积一点没减。这是新手最常犯的错误之一。
第四，localedef这行经常被忽略，但它的缺失会导致一堆奇怪的中文乱码问题，下面单独说。
4.2 时区、locale、字符集：三个最容易被忽略的配置
这三个东西平时不出问题，一出问题就很难查，因为它们影响的往往是"显示"而不是"功能"。
先说时区。centos:7镜像默认是 UTC。你的 Java 应用、Python 脚本、日志时间戳全都按 UTC 走，而你在本地看日志时按北京时间理解，中间就差了 8 小时。这种错位在小团队里能潜伏好几个月，直到某个跨时区的线上问题排查时才暴露出来。解决办法就是那行软链接：
ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime前提是镜像里得有/usr/share/zoneinfo/Asia/Shanghai这个文件，也就是tzdata包。如果镜像里没有，就先yum install -y tzdata再软链。
再说locale。centos:7镜像里/etc/locale.conf写着LANG=en_US.UTF-8，但en_US.UTF-8这个 locale 实际上并没有被生成。你敲locale命令，会看到一堆Cannot set LC_CTYPE to default locale: No such file or directory的警告。这东西本身不影响程序运行，但影响sort、grep -P这类和字符集相关的工具的排序和匹配行为，某些依赖 locale 的第三方库也可能因此行为异常。修复方法就是构建时补一句：
localedef -i en_US -f UTF-8 en_US.UTF-8需要中文 locale 的话，再加一句localedef -i zh_CN -f UTF-8 zh_CN.UTF-8并安装glibc-common。不过说实话，我很少在容器里生成中文 locale——容器里的中文显示需求本来就少，而且会让镜像变大。绝大多数情况下en_US.UTF-8就够了。
最后是字符集。这是一个更隐蔽的坑：即使把 locale 都设对了，如果你的应用读写的文件本身是 GBK 编码，而环境变量强制 UTF-8，读出来照样是乱码。这类问题的根源不在镜像，在数据本身，但排查的时候很容易被"是不是镜像没配好"带偏。记住一个判断方法：如果同一个文件在宿主机上看是正常的，进容器就乱码，那多半是容器的 locale 问题；如果两边都乱码，那是文件本身的问题。
4.3 systemd 容器化：CentOS7 在 cgroup v2 主机上的真实表现
很多老应用、老中间件是用 systemd 管理服务的，把这种环境搬进容器时，第一个问题是systemctl直接报Failed to get D-Bus connection: Operation not permitted。CentOS7 用的是 systemd 219，这个版本对容器化支持的成熟度远不如后来的 239、249。
让它跑起来需要一套固定的配置。Dockerfile 层面大致是：
FROM centos:7.9.2009 ENV container=docker STOPSIGNAL SIGRTMIN+3 RUN yum install -y systemd; \ yum clean all; \ (cd /lib/systemd/system/sysinit.target.wants/; \ for i in *; do [ "$i" = systemd-tmpfiles-setup.service ] || rm -f "$i"; done); \ rm -f /lib/systemd/system/multi-user.target.wants/*; \ rm -f /etc/systemd/system/*.wants/*; \ rm -f /lib/systemd/system/local-fs.target.wants/*; \ rm -f /lib/systemd/system/sockets.target.wants/*udev*; \ rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \ rm -f /lib/systemd/system/basic.target.wants/*; \ rm -f /lib/systemd/system/anaconda.target.wants/* VOLUME ["/sys/fs/cgroup"] CMD ["/usr/sbin/init"]那一长串rm -f的逻辑是：清掉所有会在容器里失败的启动单元，只保留最小可用的部分。因为容器里没有 udev、没有 anaconda、没有多用户登录这些概念，这些 unit 留着只会在启动时刷一屏报错。这一步做不做，直接决定了你的 systemd 容器是"能用"还是"能用但日志里全是红字"。
运行时的参数也不能少：
docker run -d --name c7-sysd \ --privileged \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ --tmpfs /run --tmpfs /tmp \ c7-systemd:7.9.2009--privileged在很多人看来是"危险信号"，但在 systemd 容器这个场景下，它确实是绕不开的。如果你不想开 privileged，可以退一步，只给必要的 capabilities 并手动挂载 cgroup，但折腾成本很高，效果还不一定稳定。我的建议是：如果只是做测试环境，用--privileged就别纠结；如果要上生产，认真考虑一下是不是真的需要 systemd，能不能改成前台进程启动。
这里还有一个真正的硬坑：新版宿主机大多启用了 cgroup v2，也就是统一的 cgroup 层级结构，而 CentOS7 的 systemd 219 只认 cgroup v1。你会在容器日志里看到Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted之类的错误。在 Docker Desktop（macOS/Windows）环境下这个问题尤其常见，因为它的 Linux 虚拟机默认就是 cgroup v2。
解决办法有两种。一是让宿主机内核回退到 cgroup v1 混合模式，在 GRUB 启动参数里加systemd.unified_cgroup_hierarchy=0然后重启——但这么做会影响宿主机上的所有容器，代价不小。二是干脆放弃在容器里跑 systemd，把老应用改成直接前台启动，或者用虚拟机跑这个特殊环境。我个人更倾向于后者，因为把一个需要 systemd 的 CentOS7 塞进容器，本身就是在跟设计意图较劲，长期维护成本会一直存在。
4.4 镜像瘦身与分层：哪些能合，哪些必须拆
关于镜像瘦身，有一条原则比所有技巧都重要：不要无缘无故地yum update。我见过不少人出于"保持最新"的好习惯，在 Dockerfile 里写RUN yum update -y，结果镜像从 204MB 直接膨胀到 500MB 以上，构建时间从一分钟变成十分钟，而且还可能因为某个包的更新引入行为变化，把原本跑得好好的程序搞崩。基础镜像这东西，要的是稳定，不是新。
具体能做的瘦身动作有这么几个。tsflags=nodocs跳过文档安装，前面说过了，能省几十兆。合并 RUN 层，前面也说过了。把编译工具和运行时分开，用多阶段构建：
FROM centos7-vault:7.9.2009 AS builder RUN yum install -y gcc make openssl-devel && yum clean all COPY src/ /src/ RUN cd /src && make FROM centos7-vault:7.9.2009 COPY --from=builder /src/server /usr/local/bin/server CMD ["/usr/local/bin/server"]这样最终的运行镜像里就不会有 gcc、make、kernel-headers 这一堆几百兆的编译工具链。注意这里两段用的是同一个底座，只是最终镜像不含编译工具，这跟"跨发行版多阶段构建"是两回事——如果 builder 用 Debian、运行用 CentOS7，那编译出来的二进制能不能跑得看具体语言，动态链接的情况下大概率不行。
还有一点要提醒：别把/var/log或者数据目录写进镜像层。镜像层是只读的，运行时写进去的数据会在容器销毁时丢失，而且会让镜像越滚越大。需要持久化的东西一律用 volume 或者挂载目录。
5. 离线与多架构环境下的镜像搬运
内网交付这个场景，值得单独拿出来讲，因为它和在线环境完全是两套玩法。在线的时候你可以随时docker pull，离线的时候你手上有多少 tar 包就是多少资源。而且这个场景下犯错成本很高——镜像拷到内网发现缺东西，再想从外网补，中间可能要走上好几天的流程。
5.1 docker save / load 的完整流程与校验习惯
标准的搬运流程是这样的：
docker pull centos:7.9.2009 docker tag centos:7.9.2009 registry.internal/base/centos7:7.9.2009 docker save registry.internal/base/centos7:7.9.2009 | gzip -9 > centos7-7.9.2009-amd64.tar.gz sha256sum centos7-7.9.2009-amd64.tar.gz > centos7-7.9.2009-amd64.tar.gz.sha256内网这边：
sha256sum -c centos7-7.9.2009-amd64.tar.gz.sha256 docker load -i centos7-7.9.2009-amd64.tar.gz docker images --digests几个细节值得注意。docker save会保留镜像的所有 tag 和层历史，docker export不会。export 出来的是一个扁平的文件系统快照，import 回去之后没有层、没有历史、没有环境变量和入口点，完全不是一回事。搬运镜像一律用 save/load，别用 export/import。
校验这一步不要省。大文件在跨网络、跨介质拷贝的过程中出问题是常有的事，一个大几 G 的 tar 包坏掉一个字节，docker load可能报出完全看不懂的解压错误。带一个 sha256 文件，几秒钟的事，能省掉半天的排查。
还有一个容易被忽略的点：docker save出来的包是"多镜像"的。如果你 save 的是几个 tag 指向同一个镜像，tar 里可能只有一份层数据，load 之后 tags 都在，这是正常的，不是坏了。
5.2 amd64 与 arm64：exec format error 的来龙去脉
现在越来越多人用 Apple Silicon 的电脑开发，或者用 ARM 架构的服务器，这里有个绕不开的坑。
centos:7这个官方镜像是多架构的，包含 amd64 和 arm64v8 两种。你在 M 系列 Mac 上直接docker pull centos:7，Docker 会根据当前平台自动拉 arm64 版本。这本来没问题，但如果你要跑的是别人在 amd64 环境下编译好的二进制，或者导入的是从 x86 服务器上导出的 tar 包，那就会看到：
standard_init_linux.go:228: exec user process caused "exec format error"这个报错的字面意思是"执行格式错误"，实际含义是"CPU 架构对不上"。解决办法有两个方向。
第一个方向是显式指定平台：
docker pull --platform linux/amd64 centos:7 docker run --platform linux/amd64 -it --rm centos:7 bashDockerfile 里也可以指定：
FROM --platform=linux/amd64 centos:7.9.2009这会让 Docker 在 arm64 主机上拉取 amd64 的镜像，然后通过 QEMU 模拟层运行。能跑，但性能会打折扣，而且某些涉及底层系统调用的程序模拟起来可能不稳定。
第二个方向是按架构分别构建、分别分发。用 buildx 一次性出两个平台的镜像：
docker buildx build \ --platform linux/amd64,linux/arm64 \ -t registry.internal/base/centos7:7.9.2009 \ --push .前提是你在 Dockerfile 里没有写死架构相关的路径和包名——yum install装*.x86_64.rpm这种行为在 arm64 平台上会直接失败。
搬运镜像前养成一个习惯：
docker inspect --format='{{.Architecture}}' 镜像名先看一眼架构。离线环境下拷错架构的包，是最让人抓狂的一类事故，因为它往往在内网部署到最后一步才暴露。
5.3 私有仓库分发时的标签与版本命名约定
最后聊一个管理层面的问题。当团队里不止你一个人用这个基础镜像时，命名规范就不是小事了。
我推荐的结构是仓库地址/项目名/镜像名:基础版本-修订号-日期，比如：
registry.internal/base/centos7:7.9.2009-r3-20250601 registry.internal/base/centos7:7.9.2009-r3 registry.internal/base/centos7:latest其中带日期的 tag 是不可变的，一旦推上去就不许覆盖；不带日期的r3是浮动 tag，随最新修订移动；latest只是个给新手用的便利入口，任何生产 Dockerfile 都不应该写它。
这套规则的意义在于：出问题的时候能精确回滚。比如某次基础镜像修订引入了新的依赖冲突，你可以立刻把业务镜像的 FROM 改回上一个带日期的 tag，几分钟就恢复了，而不是去猜"三天前那版到底是什么内容"。
另外，如果团队规模大一些，建议配一个私有 registry。官方那个registry:2镜像部署起来很简单，配合内网的存储和访问控制就够用了。它的价值不只是"存镜像"，更在于镜像的流转有了唯一可信来源，避免每个人本地都有一份不知道什么版本的 tar 包。
6. 从 CentOS7 底座上搬家的现实路径
说了这么多关于"怎么继续用 CentOS7"的内容，还是得聊聊"怎么离开"。CentOS7 停在 7.9.2009 这个版本上已经好几年了，安全补丁不会再有了。短期靠内网隔离和边界防护应付得过去，但长期看，迁移是必须要做的事，只是节奏由你控制，而不是被某个突发问题逼着做。
6.1 先盘点：glibc、openssl、python 三件套卡住了谁
迁移之前最不该做的事，就是直接改一下FROM然后就docker build。九成会失败，而且失败信息五花八门。正确的做法是先做一轮依赖盘点。
基础信息先收一遍：
rpm -qa | sort > pkgs-before.txt ldd --version | head -1 rpm -q openssl glibc python python -V然后是最关键的一步——看你的二进制到底要求多高的 glibc：
objdump -T /usr/local/bin/yourserver | grep -o 'GLIBC_[0-9.]*' | sort -uV | tail -3输出一般长这样：
GLIBC_2.14 GLIBC_2.17这里最高那个版本号，就是你程序的"最低要求"。CentOS7 提供 2.17，Rocky Linux 8 提供 2.28，Rocky Linux 9 提供 2.34。因为 glibc 是向后兼容的——在低版本上编译的程序能在高版本上跑，反过来不行——所以从 CentOS7 往上走，glibc 这一关通常不会卡人。真正会卡人的是下面两个。
OpenSSL 的 soname 变了。CentOS7 是 OpenSSL 1.0.2，动态库叫libssl.so.10和libcrypto.so.10；Rocky 8 是 1.1.1，叫libssl.so.1.1。如果你的程序是动态链接 OpenSSL 的，搬到 Rocky 8 上会直接报error while loading shared libraries: libssl.so.10: cannot open shared object file。这时候要么重新编译，要么在 Rocky 8 上装compat-openssl10兼容包——但兼容包是个过渡方案，别长期依赖。
Python 版本从 2.7 跳到了 3.x。CentOS7 系统 Python 是 2.7.5，Rocky 8 是 3.6，Rocky 9 是 3.9。所有依赖python命令的运维脚本、构建脚本、工具链接口，全都要过一遍。这一块的工作量往往被严重低估，因为"改语法"看起来简单，实际上print语句、dict.iteritems()、字符串与字节串的隐式转换这些地方，散落在几百个脚本里能改到你怀疑人生。
6.2 同架构平移：换底座重编译的实操顺序
盘完点之后，迁移的实操顺序我推荐这样排。
第一步，在同架构的前提下先换底座，也就是从 CentOS7 换到 Rocky Linux 8，两个都是 x86_64 或者是 arm64，架构不变，只是发行版版本变了。这一步能显著缩小问题范围——如果连架构一起换，出问题时你分不清是架构的问题还是版本的问题。
第二步，在新底座上重建构建环境，重新编译。不要试图把 CentOS7 上编译好的二进制直接拷过去（除了纯静态的 Go 程序那种），哪怕它能跑起来，也留下了不确定的隐患。重新编译一遍的成本远低于日后排查诡异行为的成本。
第三步，平滑切换。这时候最实用的技巧是双轨并行：新老两套镜像同时存在，用流量切分或者灰度发布的方式逐步验证。业务镜像的 Dockerfile 里只改一行FROM，回滚的时候也只改一行，风险可控。
第四步，清理遗留。老底座镜像在私有仓库里先别删，保留半年以上。你永远不知道什么时候需要它来回溯一个历史问题或者复现一个线上 bug。等确定不再需要了再清理，也可以顺手把对应的 tar 包归档到冷存储里。
6.3 迁移路上最容易翻车的四个点
最后分享几个我在实际迁移中踩过的、比较有代表性的坑，希望能帮你少走点弯路。
第一个坑是FROM改完之后构建"成功"了，但运行时报依赖缺失。原因通常是某个包在 Rocky 8 里改了名或者被拆分了，比如某些-devel包的依赖关系调整，或者某个提供命令行工具的包被归到了dnf-plugins-core这类新位置。解决办法是构建完之后真的进容器里跑一遍应用，别只看构建日志是绿色的就当成功了。
第二个坑是字符集和排序行为的细微变化。glibc 2.28 相比 2.17，在 locale 处理上有一些修正，某些对字符串排序敏感的业务逻辑（比如用sort处理过的名单、按名字排序的报表）可能会给出和以前不同的结果。这种东西不会报错，只会让数据"看起来有点不对"。迁移后如果有涉及排序的业务，建议专门验证一遍。
第三个坑是时区数据库的更新。新底座自带的 tzdata 版本更新，如果你的业务逻辑里有涉及历史时间点的时区换算，可能会有细微差异。这个太偏门了，但如果你的业务确实跟时区强相关，值得留个心眼。
第四个坑是构建缓存带来的假象。迁移过程中你会反复改 Dockerfile 反复构建，Docker 的层缓存会让某些步骤被跳过。有时候你以为某个包重装了，其实用的是缓存里的旧结果。关键时刻加--no-cache重新构建一次，能避免很多"本地好的、CI 上坏的"这类问题。这个习惯我一直在用，虽然每次构建慢几分钟，但换来的是"构建结果可信"。
写到这儿，关于 CentOS7 镜像这件事想说的基本都说了。我自己的做法是：存量环境继续用自建的centos7-vault镜像，把源改造、locale、时区这些全部固化进 Dockerfile，版本钉死到 7.9.2009 加日期 tag，归档 tar 包存一份；同时新项目一律从 Rocky Linux 起步，中间用oraclelinux:7-slim做过渡的场景就过渡，但不再新增任何以 CentOS7 为底座的新服务。这个节奏不快，但每一步都是自己可控的，比起被一个意外的依赖缺失逼着加班，我更喜欢这种主动安排的从容。
