Docker 镜像拉取加速完整指南3 步接入 DaoCloud 镜像加速【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror先说效果改造前Docker 镜像拉取卡 30 分钟才走到 12%生产部署窗口直接被拖爆改造后同样的docker pull一分钟跑完连从没拉过的新镜像一般一两分钟也能落地。用到的是一套 DaoCloud 维护的公开容器镜像加速服务 public-image-mirror它解决的核心问题很朴素gcr.io、docker.io、ghcr.io 这类源站的镜像都在国外国内拉取又慢又飘而它用加个前缀的方式把这条路走通了——免费、公开、不需要注册任何账号。能力速览这套镜像加速能做什么成本多大能做什么适用场景上手成本一行前缀拉取加速【推荐】Docker / containerd / Podman 拉单个镜像在镜像名前加m.daocloud.io/10 秒Docker 全局加速拉 Docker Hubdocker.io上的镜像daemon.json 加 3 行配置gcr / ghcr / registry.k8s.io / mcr 等源加速K8s 组件、AI 模型镜像换域名或用前缀方式内网缓存代理公司内网、外网受限环境docker compose 起一个 registry镜像白名单自查判断某个镜像能不能被同步跑一次仓库里的 hack 脚本实战第一步一行命令改前缀跑通官方明确推荐增加前缀的方式把m.daocloud.io/放到原始镜像地址前面不用改任何客户端配置也不重启服务。# 改造前卡在 12% 半小时 # 改造后1 分钟内拉完 docker run -d -P m.daocloud.io/docker.io/library/nginx第二种写法是前缀替换把源站域名直接换成加速域名地址更短但官方 README 里标注这种方式不推荐替换规则是人工维护的只在熟悉的源站上使用更稳妥。常见对应关系源站替换为docker.iodocker.m.daocloud.iogcr.iogcr.m.daocloud.ioghcr.ioghcr.m.daocloud.ioregistry.k8s.iok8s.m.daocloud.iok8s.gcr.iok8s-gcr.m.daocloud.iomcr.microsoft.commcr.m.daocloud.ionvcr.ionvcr.m.daocloud.ioquay.ioquay.m.daocloud.io⚡ 新手记住一句话拿不准就用前缀方式替换方式只是让地址变短的备选。实战第二步接入日常工作流单机跑通之后把加速固化到每台机器的默认行为里之后就不用每次手写前缀。Docker 全局加速仅限 Docker Hub编辑/etc/docker/daemon.json重启 Docker 即可{ registry-mirrors: [ https://docker.m.daocloud.io ] }这里有个官方特别强调的边界不要把 docker.io 之外的站点比如 gcr.m.daocloud.io配进 Docker 的 registry-mirrors那些源仍然用前缀方式。Podman 可以一次配多个源Podman 的 registries.conf 支持按源站分别挂镜像gcr、ghcr、quay 一次配齐# /etc/containers/registries.confrootless 模式放 ~/.config/containers/registries.conf [[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.io [[registry]] location quay.io [[registry.mirror]] location quay.m.daocloud.ioKubernetes 安装与本地集群# kubeadm 的 ClusterConfiguration 里改镜像仓库 imageRepository: k8s.m.daocloud.io# kind 建本地集群时节点镜像也走加速 kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1Ollama 与大模型镜像# 拉 Ollama 镜像走加速前缀AI 工具链同样受益 docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama docker.m.daocloud.io/ollama/ollama实战第三步扩到团队与集群规模个人快只是起点团队和内网快才算落地完成。内网缓存代理在公司内部起一个 registryproxy 模式指向m.daocloud.iottl 约 90 天之后节点全部走内网彻底摆脱对外网依赖。完整 compose 配置在 docs/local-cache/README.md。集群级改写不想动 yaml 和 helm 的话可以用 Webhook 工具 repimage自动把新建 Pod 的 image 改写成走本镜像源kubectl部署一次全集群生效。错峰拉取官方建议把拉取任务放在闲时北京时间 01:00–07:00高峰期队列非常拥挤。选镜像的讲究优先sha256:摘要其次明确版本号的 tag最后才是latest这种可变 tag——tag 内容变更后缓存会响应旧数据并在后台重新同步。它凭什么能做到镜像加速原理拆解用起来了再回头看它内部。核心是四个机制懒加载不预先同步全网镜像你第一次拉某个新镜像时才从源站按需同步且所有 sha256 摘要与源仓库保持一致。缓存生命周期缓存内容只保留 30 天过期需重新同步Manifest 内存缓存 1 小时tag 更新最迟 1 小时生效Blob 内存缓存 1 分钟。白名单控制allows.txt 是哪些镜像允许同步的清单目前有 1300 余行规则可用仓库里的校验脚本本地自查。同步队列缓存未命中后会进入同步队列排队队列只保留一小时的同步记录排查问题要趁早。服务后端基于开源项目 ocimirror 构建每天自动检查同步情况不需要人工值守。我踩过的坑3 个排错实录坑一镜像放了一个月突然 404。别慌这是 30 天缓存过期的正常行为重新拉取会自动触发再同步。要长期稳定就用sha256:锁定镜像。坑二新镜像第一次拉特别慢。首次拉取走先同步再拉取的路径慢是机制使然。关键镜像提前放进预热清单并把拉取排在凌晨 1–7 点的闲时窗口。坑三某个镜像死活拉不到。先查白名单。把仓库克隆到本地用 hack/verify-allows.sh 校验# 脚本用法verify-allows.sh 白名单文件 镜像地址 hack/verify-allows.sh allows.txt docker.io/library/nginx不在清单里就到项目里提交申请补充仓库里的 hack/correct-image.sh 还能帮你把各种写法的镜像地址归一成标准格式。一句话收尾与资源清单一句话总结加一个前缀把卡半小时的镜像拉取压到一分钟内全程免费、零注册。想继续深入看这几处入口README.md用法总览与前缀替换域名清单allows.txt可同步镜像白名单docs/local-cache/README.md内网缓存部署完整步骤hack/白名单校验、镜像地址归一化的全套脚本⚡ 觉得有用就收藏 关注团队落地时再遇到新坑也欢迎回来留言。下一篇《内网镜像缓存部署指南从单机 registry 到高可用》敬请期待【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考