镜像拉不动3分钟上手 public-image-mirror给 Docker 镜像提速【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror深夜十二点运维老陈盯着终端里的进度条gcr.io上的镜像已经下载了三个小时速度稳定在 50KB/s会议室里还坐着等上线的一屋子人。他叹了口气把docker pull重试了一遍——结果进度条比刚才更慢了。这不是段子。只要是国内开发者大概率都经历过类似的镜像焦虑依赖部署在国外仓库网络绕地球一圈慢是一回事更气人的是拉一半断掉、重试又从头开始。今天要讲的public-image-mirror就是专门解决这个问题的项目——它把 gcr.io、ghcr.io、quay.io、docker.io 等主流镜像仓库搬到国内让你不用魔法、不改架构就能以接近本地的速度拉取镜像。一、它到底做了什么先搞懂镜像加速的原理你可能听说过镜像加速器比如配置 Docker 的registry-mirrors。但 public-image-mirror 和传统加速器有个关键区别它不是一个简单的转发代理而是一个镜像仓库的镜像Mirror。翻译成大白话这就像你想买国外才能买到的书。传统加速器是帮你跑腿代购每次下单都要飞一趟国外而 public-image-mirror 是先在国内建了个书店把你常买的书提前搬进来。它的核心机制叫懒加载你第一次请求某个镜像时系统才会去源站同步同步完缓存下来之后所有请求直接命中缓存。同步完成后镜像的 sha256 哈希和源站完全一致你可以放心把它当作原版使用不用担心被偷梁换柱。整个流程可以想象成一个流水线你提交docker pull请求服务端检查本地有没有缓存有缓存直接返回秒级完成没有缓存自动加入同步队列从源站拉取并校验完整性同步完成后后续所有请求都走国内节点。值得一提的是项目里还提供了 4 个维护脚本全部在 hack/ 目录下它们共同保障着这份书单的质量hack/correct-image.sh把五花八门的镜像写法修正成标准格式补全仓库名、tag 等hack/verify-allows.sh校验某个镜像是否在白名单内hack/fmt-image-match.sh格式化并去重白名单hack/verify-image-match.sh检查白名单格式是否规范。二、3 分钟上手照着做就能加速是不是听起来有点复杂其实你根本不需要理解这些内部机制用起来只需要记住一个动作加前缀。第一步确认镜像在白名单里项目维护了一个白名单文件 allows.txt里面列出了所有支持同步的镜像仓库既有docker.io/bitnami/*这种带通配符的批量条目也有精确到单个镜像的条目。你可以用仓库自带的校验脚本快速确认bash hack/verify-allows.sh allows.txt docker.io/bitnami/kafka命令退出码为 0就代表镜像在白名单内可以放心使用。如果返回非 0说明还没收录可以按项目文档的指引提交请求。第二步加前缀替换地址以 Docker Hub 上的bitnami/kafka:3.9.0为例原始地址是docker.io/bitnami/kafka:3.9.0推荐做法是直接在完整地址前加上m.daocloud.io前缀m.daocloud.io/docker.io/bitnami/kafka:3.9.0备选做法是前缀替换把docker.io替换成docker.m.daocloud.iodocker.m.daocloud.io/bitnami/kafka:3.9.0两种方式等价推荐第一种因为它对 gcr.io、quay.io 等所有仓库规则统一不容易记混。第三步拉取并验证docker pull m.daocloud.io/docker.io/bitnami/kafka:3.9.0首次拉取需要等后台同步完成可能会比平时稍慢但一旦缓存命中第二次、第三次拉取就是国内速度从几小时变成几分钟不是夸张。三、进阶玩法不同场景下的正确姿势把前缀替换当成手动挡那下面这些就是自动挡——配置一次全家受益。场景一个人开发者想全局生效如果你不想每次手敲前缀可以直接改 Docker 的守护进程配置写入/etc/docker/daemon.json{ registry-mirrors: [ https://docker.m.daocloud.io ] }重启 Docker 后docker pull bitnami/kafka这类命令就会自动走加速通道命令本身完全不用变。场景二Kubernetes 集群加速所有 Podkubeadm 安装把imageRepository改成k8s.m.daocloud.ioCoreDNS镜像改成k8s.m.daocloud.io/corednskind 创建集群kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1containerd 运行时按 Containerd 官方 hosts 文档配置 registry namespace 的 mirror 指向对应加速域名不想改一堆 yaml项目还推荐了 repimage 方案通过 Webhook 自动改写新建 Pod 的镜像地址一行命令部署改完后业务方零感知。场景三内网团队部署本地缓存如果团队网络环境特殊或者想彻底摆脱外网依赖可以参考 docs/local-cache/README.md用 Docker Compose 起一个带 proxy 的 registry 容器把m.daocloud.io作为远端源内网所有节点都指向这个本地仓库。相当于在公司内部再建了一个分店第一次拉取回源之后全部走内网。场景四AI 开发加速 Ollama项目甚至把 Ollama 模型仓库也纳入了加速范围。启动 Ollama 容器时替换镜像源拉取 DeepSeek 等模型时再叠加一层ollama.m.daocloud.io前缀即可。对本地跑大模型的朋友来说省下的时间相当可观。四、避坑指南新手最容易踩的 4 个坑坑一用latest标签拉镜像latest是可变标签源站更新后你拿到的可能是上一个版本。而且项目缓存有 30 天有效期过期后重新同步期间镜像地址可能短暂 404。正确做法优先用sha256:摘要锁定镜像其次用明确的版本号 tag最后才考虑latest。README 里也明确建议了这个优先级。坑二高峰时段触发同步同步队列是共享的北京时间白天请求量大首次同步会很慢。正确做法把大批量拉取任务安排在凌晨 1 点到 7 点这个时间段队列空闲首次同步速度最快。坑三把非 docker.io 的仓库配到 registry-mirrorsDocker 的registry-mirrors只支持 docker.io 相关的加速。如果你把gcr.m.daocloud.io这种域名也塞进registry-mirrors会直接报错。正确做法docker.io 之外的仓库要么手动加前缀要么用 PodmanPodman 支持为 gcr.io、ghcr.io、quay.io 等分别配置 mirror。坑四以为缓存是永久的缓存内容只保留 30 天Manifest 内存缓存 1 小时Blob 内存缓存 1 分钟。也就是说标签更新后约 1 小时才同步新数据长时间没人拉取的镜像过期后需要重新同步。正确做法重要镜像定期预热别在刚好过期的时间点才去拉。五、高频疑问解答Q加了前缀之后拉下来的镜像和官方的一模一样吗A是的。项目承诺所有 sha256 哈希与源站完全一致并且每天检查同步情况安全上可以放心。Q白名单里没有我要的镜像怎么办A先看看 allows.txt 里的通配符规则很多仓库其实已经整站收录。确实没有的按项目 README 的指引提交 Issue 申请也可以顺手用 hack/verify-allows.sh 确认。Q我只想临时用一次有必要改全局配置吗A没必要。临时用就手动加前缀改动最小、用完即走如果发现每天都要拉再考虑改 daemon.json 或本地缓存。Q想自己维护这个项目从哪里入手A把仓库 clone 下来地址是https://gitcode.com/GitHub_Trending/pu/public-image-mirror先读一遍 README.md再跑跑 hack/ 下的脚本很快就能理解它的工作方式。六、写在最后回顾一下 public-image-mirror 的核心价值它把镜像在海外、拉取靠运气变成了缓存在国内、拉取看速度。对个人开发者它是省时间的利器对运维团队它是保证部署稳定性的基础设施对内网环境它还能作为搭建本地缓存的上游源。如果你正被镜像下载速度折磨或者每次 CI/CD 都在等镜像拉取别犹豫现在就可以把m.daocloud.io前缀用起来。几分钟的配置时间换来的是以后每次部署都少等几十分钟。用完后如果觉得不错记得把项目分享给同样被镜像折磨的同事遇到问题或想要新镜像也可以去项目仓库反馈——这类开源项目正是靠每个使用者的反馈才一点点长大的。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考