搞容器的人一定都有过盯着docker pull进度条发呆的经历。我印象最深的一次是在一台配置不差的服务器上拉一个大概 1GB 的系统镜像进度条卡在某个 layer 上持续了十几分钟中途还断了一次最后只能半夜重试才勉强拉完。这种体验实在太常见以至于很多人默认“镜像拉得慢”是一件正常的事。但把问题拆开看慢的原因往往不止一个而是镜像源、传输并发、镜像体积、构建缓存这几个环节凑在一起。所谓“Docker 镜像加速”并不是某个开关或者某条命令而是把拉取链路里能优化的地方全部过一遍形成一套组合操作。这篇文章就是把我这些年折腾镜像加速踩过的坑和验证过的方法摊开讲清楚既能帮刚被 pull 速度劝退的新手少走弯路也能给优化 CI 构建时长的开发者和运维一些可以直接落地的参考。1. 镜像加速到底在加速什么1.1 先拆开 docker pull 的完整过程想加速就得先搞清楚docker pull到底在做什么。这个命令不是简简单单下载一个大文件而是分几个阶段客户端先请求目标镜像的 manifest拿到镜像的层列表和元信息。根据 manifest 里的地址逐个去拉取 layer 数据。每一个 layer 下载完成后还需要校验 digest确定数据没有被篡改。校验通过后layer 内容会被解压并落到本地镜像存储目录。也就是说一次拉取 网络传输 校验 解压落盘。任何一个环节出现瓶颈整体速度都会被拖住。早些年我看进程输出只注意到“正在等待”和“下载完成”这两种状态后来才发现 manifest 请求慢、单个 layer 体积大、并发下载层数不够、本地磁盘 IO 跟不上这类问题才会出现进度条长时间不动的情况。明白了这一点“加速”的思路就很清楚了要么让传输的数据量更少要么让传输路径更快要么让并发的效率更高要么让本地存储不要成为新的瓶颈。1.2 加速的三个层面如果把解决方案归类其实跑不出这三个层面镜像源层面给 Docker 配置更近的镜像加速器或者在网络环境里架设一个带缓存的镜像仓库缩短拉取的物理路径。传输与仓库层面调整 Docker 引擎的并发下载参数合理设计镜像缓存和离线分发方式把带宽用足。镜像本身层面选择更小的基础镜像优化 Dockerfile 指令顺序尽量让构建缓存命中最终产出的镜像越小拉取耗时自然越短。这三个层面用一张表可以看得很清楚优化方向常见手段见效速度成本镜像源配置 registry mirror、自建缓存仓库立竿见影低传输能力调并发、优化连接复用、离线压缩传输中等低镜像体积轻量基础镜像、多阶段构建慢但持久需要改构建文件我个人的习惯是先做镜像源优化因为改动最小、收益最直观然后再处理构建层面的问题因为那部分改动需要回归测试急不来。2. 第一板斧配置 registry mirror 加速器2.1 加速器是怎么介入拉取流程的Docker 引擎原生支持registry-mirrors配置。你可以把它理解为一个“中转仓库”当你执行docker pull的时候Docker 不会直接闷头去连原始镜像仓库而是先去你配置好的 mirror 地址拉取镜像层。如果 mirror 本地已经有缓存它会直接把数据交给你如果 mirror 也没有它会替你向上游仓库请求拿到后一方面转交给你另一方面在自己的存储里留一份缓存下一次再有人拉同一个镜像速度就会快很多。这个机制的优点是几乎不改变任何使用习惯镜像名不用改命令不用变只需要在 Docker 守护进程配置里写上几行之后所有拉取动作都会自动走加速通道。早期不理解的时候我总以为加速器是把镜像重新打包实际上它更像一个带有缓存的 HTTP 代理只是协议层针对镜像仓库做了适配。2.2 完整配置步骤配置 registry mirror 非常快具体步骤如下编辑或新建/etc/docker/daemon.json。如果这个文件不存在直接创建即可。在文件里写入如下内容{ registry-mirrors: [ https://mirror-a.example.com, https://mirror-b.example.org ] }重启 Docker 守护进程让配置生效systemctl daemon-reload systemctl restart docker验证配置是否被正确加载docker info在输出里找到Registry Mirrors这一项它下面会列出你配置的地址。如果能看到说明镜像加速器已经生效。实际拉一个镜像测试速度docker pull some-application:latest这里我用的是占位镜像名实际使用中替换成你自己需要的镜像即可。为什么一定要写在daemon.json里因为 Docker 的拉取动作发生在守护进程内部不是客户端进程里。如果你只是在本机设置 HTTP 代理有一些 Docker 版本并不完全走代理通道配置反而会对不上。整个过程中最容易翻车的地方是 JSON 格式。daemon.json是严格的 JSON不能带注释、不能多逗号很多人为了图省事把多个配置项堆在一起结果少写了一个逗号或者多写了一个逗号Docker 服务直接起不来。我有一个习惯改完先执行一次docker info如果服务还活着且能看到 Registry Mirrors再接下去做其他操作。2.3 如何确认加速器真的生效配置完成不等于万事大吉还得确认 Docker 真的在走加速通道。一个比较有效的办法是用time看拉取耗时time docker pull another-image:latest但这里有个“坑”如果你测的镜像在本地已经存在Docker 会直接复用耗时几乎是 0根本测不出加速效果。所以要测就选一个本地没拉过的镜像或者先在别的机器上确认镜像标签存在。更严谨一点可以在 mirror 服务侧查看访问日志。如果你能看到来自你本机 IP 的请求那就说明拉取请求确实到了 mirror。这一点在自建镜像缓存仓库时尤其好用。还有一个细节docker pull的默认输出是进度条显示的是 layer 的下载状态。如果配置正确拉取过程中经常能看到多个 layer 同时在下载这是正常的说明并发在起作用。2.4 给镜像加速器选型的安全底线镜像加速器本质上是在替你“代收”镜像数据你能拉到的内容完全取决于它给你的内容。虽然 Docker 有 digest 校验但如果你拉取的镜像本身没有锁定 digest那加速器能提供的区域就有很大的操作空间。所以在选择镜像加速服务时我的底线是这样几条必须使用 HTTPS明文 HTTP 在公网环境里很容易被中间人动手脚。优先选长期稳定、更新及时的地址主动维护的加速服务比孤立的私人地址可靠得多。不要盲目信任来源不明的加速器尤其不要在生产环境使用陌生镜像源。如果条件允许尽量在镜像交付链路里用 digest 锁定版本也就是在FROM指令后用sha256:...这样的形式固定镜像内容。这些看起来和“加速”没什么关系但镜像源被污染带来的风险远比速度慢大得多这是这条链路里最不能忽视的一条原则。3. 第二板斧向并发参数和本地缓存要速度3.1 调整 Docker 引擎的并发参数很多人配好加速器之后发现速度有提升但并没有完全跑满带宽这时候就要检查 Docker 引擎的默认并发限制了。早期 Docker 的默认并发下载层数是 3后来的版本稍有调整但总体来说如果你跑在一个带宽比较充足的机器上默认值往往偏保守。镜像通常由十几个甚至几十个 layer 组成如果并发只有 3等于每次只有 3 个下载线程在跑带宽占用率上不去整体耗时自然拉长。可以在daemon.json里把并发数调大{ registry-mirrors: [ https://mirror-a.example.com ], max-concurrent-downloads: 10, max-concurrent-uploads: 5, max-download-attempts: 5 }这里max-concurrent-downloads控制拉取并发层数max-concurrent-uploads控制推送并发层数max-download-attempts控制单个 layer 下载失败后的重试次数。建议从 6 到 8 开始试不要一步直接调到 20。我自己试过一个极端值结果小带宽机器上多个并发请求互相抢带宽反而出现了大量重试最终时间比默认还长。这个参数跟网络环境强相关不存在一个通吃的数值只有实测下来最舒服的数值。另外提醒一句并发参数是守护进程级别的会影响这台机器上所有镜像拉取操作如果你正在跑生产服务尽量在低峰期调整并观察。3.2 内网自建镜像缓存仓库如果镜像加速服务解决了单机问题那多台机器、多环境同时拉镜像的场景怎么办当集群里有十台甚至几十台服务器每一台都单独去外网仓库拉取带宽浪费是非常明显的。这种情况我会建议做一层“内网镜像缓存仓库”原理和加速器一样但部署在你自己掌控的网络里。比较常见的做法是运行一个 registry 服务并开启它的 pull-through cache 模式也就是让这个仓库本身变成上游仓库的一个缓存代理。启动一个缓存仓库的大致命令如下docker run -d -p 5000:5000 --restartalways \ -v /data/registry:/var/lib/registry \ -e REGISTRY_PROXY_REMOTEURLhttps://registry-1.docker.io \ --name registry-cache registry:2然后让内网服务器的 Docker 配置都指向这个仓库地址{ registry-mirrors: [ http://registry-cache.internal:5000 ], insecure-registries: [ registry-cache.internal:5000 ] }先说结论这个方案在内网规模越大时收益越明显。第一台机器拉取某个镜像时速度不快因为它需要穿透到上游拿数据但从第二台机器开始数据直接走内网速度会非常稳定。需要注意一个问题上面示例用了 HTTP 地址Docker 会把这类地址当作不安全仓库所以要同时把它写进insecure-registries。这只是为了演示生产环境我更建议在镜像缓存仓库前面加一层 HTTPS 终结或者至少用认证和网络访问控制把它限制在内网不要裸奔到公网。镜像内容有时候包含敏感代码或私有配置一旦缓存仓库被外人访问等于把压测数据主动送了出去。3.3 离线镜像传输的细节还有一种很常见的场景是离线环境或跨机房迁移目标机器网络受限只能通过内部通道拷贝文件。这时候最直接的办法是docker save导出、docker load导入。我以前也这么干后来发现直接导出 tar 包有几个问题镜像层没有做额外压缩传输体量偏大大量小文件对传输工具的吞吐也不友好。所以现在跨机房同步大镜像时我会在导出和导入之间加一道压缩docker save some-application:latest | zstd -T0 -q -o image.tar.zst目标机器上再解压导入zstd -d -c image.tar.zst | docker load为什么用 zstd 而不是 gzipzstd 的压缩速度更快压缩率在同级别工具里表现不错而且能用多线程压大数据量镜像整体体感会明显好于 gzip。压缩率当然看镜像内容但压缩 20% 到 40% 是很常见的。这个方案的意义不只在省磁盘对带宽敏感的区域传输压缩之后能明显减少耗时也算是一种“加速”。3.4 缓存到底该不该清理镜像缓存不是越多越好。我在一台长期跑 CI 的服务器上遇到过这种情况镜像一个接一个地拉从不清理结果本地存储被占满每次docker pull在解压阶段都慢得离谱进度条停在“Extracting”状态大半天。排查之后才明白拉镜像不是只下载还要解压落盘。当磁盘空间不足、磁盘 IO 被打满无论网络多快最终都会卡在本地存储这一环。所以镜像加速的最后一公里其实是磁盘。常规做法是定期执行docker system df docker image prune -f docker builder prune -fdocker system df能看到镜像、容器、构建缓存各自占了多少空间。image prune会清理掉无用的悬空镜像builder prune会清理构建缓存。这套组合拳基本能解决大部分“越跑越慢”的问题。4. 第三板斧从镜像本身把体积做小4.1 轻量基础镜像怎么选配置层面能做的优化都做完了剩下的空间就在镜像本身。一个 1GB 的镜像和一个 200MB 的镜像哪怕网络再快拉取耗时差距也摆在那里。最直接的减负手段是换更小的基础镜像。以系统类镜像为例同一个应用场景标准版镜像体积大里面带了完整工具链和文档带slim标记的镜像体积明显更小适合运行期使用基于alpine的镜像是另一个重度优化方向把很多可选组件拆掉体积压得非常低从零开始的scratch镜像则适合极少数静态编译产物体积几乎可以忽略。实际的体积数值不同版本差异很大但通常可以理解为标准版到 slim 的差距可能有好几百 MBslim 到 alpine 的差距也有上百 MB。可以做一个简单的换算一个镜像每小 100MB在 10MB/s 的拉取链路里就能省下 10 秒。如果 CI 里每天拉几十次这节省下来的时间就很可观了。但不要无脑追小。alpine 用了 musl 作为 C 库跟很多依赖一起跑时可能需要额外做兼容处理比如某些 Python 扩展包要重新编译。我的建议是先把跑得通当成第一目标再把体积当作持续优化项不要为了体积牺牲稳定性。4.2 Dockerfile 指令顺序与缓存命中镜像体积只是一个静态指标构建过程中还有一个更容易被忽略的加速点构建缓存。Docker 构建时每一条指令都会生成一个 layer。如果某条指令的执行环境没有变化Docker 会直接复用上一次构建产生的缓存层跳过执行。这个机制意味着如果你能把变动频率不同的内容分开让“容易变”的东西尽量排在后面缓存命中率就会大幅提升。一个典型的反例是把COPY . .放在 Dockerfile 最前面。项目里任何一个文件内容变化都会让这一层缓存失效随后所有步骤全部重跑相当于每次构建都是从零开始。更合理的思路是这样FROM some-runtime:latest WORKDIR /app # 先装依赖依赖清单相对稳定 COPY requirements.txt . RUN pip install -r requirements.txt # 再复制源码源码变动不会影响前面的缓存 COPY src/ ./src CMD [python, src/main.py]这种做法我用了很久效果非常明显。尤其是依赖安装耗时很长的项目只要依赖清单不变后续每次构建都能直接命中依赖层缓存省掉大块时间。配套的还有一个.dockerignore文件。它和.gitignore的作用类似把日志、临时文件、本地缓存目录排除在镜像上下文之外。如果不排除这些文件虽然没有被最终复制进镜像但它们的变动可能导致COPY . .的上下文校验发生变化从而让缓存失效。4.3 多阶段构建解决“大而全”的镜像很多镜像体积大是因为构建工具和运行环境混在一起为了编译一个程序把编译器、依赖库、头文件全装进最终镜像运行的时候这些其实都不需要。多阶段构建就是解决这个问题的标准手段。它允许你在一份 Dockerfile 里定义多个阶段前一阶段负责编译和打包后一阶段只负责运行。一个常见的结构是这样的# 第一阶段构建产物 FROM build-tools:latest AS build WORKDIR /src COPY . . RUN make build # 第二阶段只拷贝产物 FROM runtime-base:latest WORKDIR /app COPY --frombuild /src/output /app/output ENTRYPOINT [/app/output/run]关键点在COPY --frombuild它能把第一个阶段里的文件直接拷贝到第二个阶段而第一个阶段的其他系统文件、工具链都不会进到最终镜像里。我第一次把项目改成多阶段构建之后镜像体积直接从接近 1GB 掉到 200MB 以内拉取速度肉眼可见地提升。而且这事还能顺手降低磁盘占用属于投入产出比很高的改动。4.4 别忘了 layer 里的“隐形大文件”还有一个新手很容易踩的坑在 Dockerfile 里下载一个大文件然后在下一条指令里把它rm掉以为最终镜像就不会包含这个文件了。实际上不是这样。Docker 的每个 layer 都是有状态的即使后一层把文件删了前一层里仍然保留了这个文件的数据。最终镜像打包时这个被删掉的大文件仍然会占用传输空间。所以正确做法是在同一条RUN指令里完成“下载、使用、清理”全过程比如RUN curl -o /tmp/pkg.tar.gz http://example.com/pkg.tar.gz \ tar -xf /tmp/pkg.tar.gz -C /opt \ rm -f /tmp/pkg.tar.gz这样临时文件只存在于构建过程中的临时层里不会被最终镜像保存。排查这类问题的工具是docker history能看到每个层的大小变化如果发现某一层突然出现一个很大的体积基本可以确定是有大文件留在了层里。这种情况用docker-squash之类的工具可以重新压平层历史但更推荐在构建层面就拦住它。5. 加速效果验证和问题排查5.1 用最简单的方式量化速度变化优化完成之后一定要量化验证不然你无法知道哪一步起了作用。我的基线做法是这样的选一个固定镜像、固定网络环境记录完成拉取的时间。优化一项之后换另一个大小差不多的镜像再测一次。不要用同一个镜像连续测两次因为如果第一次拉取已经把 layer 缓存到本地第二次测得再快也不算数。time docker pull some-image-a:latest # 换一个镜像再测 time docker pull some-image-b:latest对比两次耗时再结合镜像总大小可以估算出实际吞吐率。这个数字比单纯的“感觉变快了”可靠得多。如果你怀疑是镜像源的问题可以分别在配置 mirror 前后各测一组数据。注意保持镜像名一致并且每次都用本地没存过的版本排除缓存干扰。5.2 常见“提速失败”的原因对照表优化的过程里经常出现“明明配了却没用”的情况我这里整理一个速查表都是实际遇到过的问题现象可能原因处理办法docker info看不到 Registry Mirrorsdaemon.json 格式错误或 Docker 未重启用 json 校验工具检查格式重启后重新验证能看到 Mirror但拉取依然很慢mirror 地址本身网络质量差或者 mirror 没有缓存且上游取数慢换一个更快更稳定的镜像源只有部分镜像走 mirror镜像本身来自其他仓库mirror 只服务特定上游仓库确认镜像来源或在 mirror 配置里覆盖对应上游拉取时卡在“正在等待”一段时间并发参数过高导致连接拥塞或 mirror 限流降低并发数临时去掉 mirror 试试拉取完成但解压极慢本地磁盘空间不足或 IO 打满清理镜像缓存检查磁盘占用拉取同一镜像偶尔失败网络波动或者 mirror 不稳定重试or 调整 max-download-attempts这套对照表不是万能的但它能帮你快速定位方向省去反复试错的时间。5.3 那些看起来是镜像慢、其实是磁盘慢的情况镜像拉取到差不多结束的时候输出经常会显示Extracting或Loading layers这个过程不是在下载而是在解压、写入磁盘。如果你的机器磁盘是机械盘或者剩余空间非常少这里就会出现明显的等待。常见现象是进度条已经到了 100%但状态迟迟不变最后又等了好几分钟才完成。排查起来很简单在卡住的同时打开另一个终端执行iostat或df -h能看到磁盘 IO 被打满或者分区空间告急。处理办法也很直接把 Docker 的>