DaoCloud镜像加速完整指南Docker镜像加速如何快速上手附避坑清单【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror拉海外镜像仓库的镜像总是超时。public-image-mirror 是 DaoCloud 的开源镜像站项目服务通常被叫做 DaoCloud镜像加速在镜像地址前加一个前缀Docker镜像加速、镜像拉取加速都能分钟级完成且完全不需要改动现有部署流程。先说清它为什么快很多镜像如 gcr.io、quay.io的源仓库都托管在国外跨境链路质量差拉取时就表现为长时间卡住甚至中断。这个项目做的是把源镜像仓库Registry在国内镜像一份——采用懒加载机制你第一次请求某个镜像时它按需从源仓库同步过来并缓存之后再拉就直接命中缓存。类似从国内 CDN 下载国内资源而不是每次都自己跑去国外源站。所有镜像的 sha256 与源仓库保持一致完整性没有折扣。一次凌晨部署的超时先判断镜像能不能加速 想象一个典型场景凌晨扩容节点上docker pull一个国外仓库的大镜像进度条转了半小时没动任务超时被平台回收。换成m.daocloud.io的加速地址后同样的镜像通常几分钟就能拉完。但要注意它不是什么镜像都能加速白名单制只有登记在 allows.txt 里的镜像才会被同步文件里有 1300 多行规则支持通配写法如docker.io/prom/*、gcr.io/**。缓存有寿命缓存内容只保留 30 天过期后需要重新同步Manifest 有 1 小时内存缓存源上 tag 更新后最长 1 小时才会在镜像侧生效。服务有节奏项目每天自动检查同步情况官方建议把大批量拉取任务安排在闲时——北京时间凌晨 01:00–07:00其他时段流量非常拥挤。判断能不能加速只要 30 秒后面有现成脚本这里先记住先看白名单再谈配置。一步替换镜像地址加个前缀就完事 最快、也最推荐的方式是在原地址前面加m.daocloud.io/前缀一行命令就能验证效果# 原地址 docker.io/prom/node-exporter:v1.8.2 # 加前缀后 m.daocloud.io/docker.io/prom/node-exporter:v1.8.2 docker run -d -P m.daocloud.io/docker.io/library/nginx第二种方式是前缀替换——直接把源站域名换成对应的专用加速域名源站替换为docker.iodocker.m.daocloud.iogcr.iogcr.m.daocloud.ioghcr.ioghcr.m.daocloud.ioquay.ioquay.m.daocloud.ioregistry.k8s.iok8s.m.daocloud.iomcr.microsoft.commcr.m.daocloud.ionvcr.ionvcr.m.daocloud.iodocker.elastic.coelastic.m.daocloud.io两种方式的差别加前缀是官方推荐做法通用性最好专用域名是人工配置的规则有变动需要提 Issue。另外有一个容易踩的坑——每个源站的内容不同不要把 docker.io 之外的域名塞进 Docker 的 registry-mirrorsDocker 的 mirror 机制只对 docker.io 生效其他源站必须显式写前缀。把 DaoCloud镜像加速接入自己的环境 ⚙️Docker 镜像配置daemon.json 里加一行 registry-mirrors编辑/etc/docker/daemon.json{ registry-mirrors: [ https://docker.m.daocloud.io ] }改完重启 Docker 服务即可。注意这只会加速 docker.io 的拉取gcr、ghcr 这类源站还是要走前缀写法。Podman 用户则改/etc/containers/registries.conf且 Podman 支持为 gcr.io、quay.io 等逐个配 mirror比 Docker 更灵活。k8s 镜像源替换kubeadm 与 kind 都换掉 imageRepository新建集群时把组件镜像仓库指向加速域名kubeadm 的 ClusterConfiguration 里只需改一处imageRepository: k8s.m.daocloud.io本地 kind 集群则是把节点镜像换成加速地址kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1如果集群里已有大量 Pod与其逐条改 yaml社区里有个 repimage 的 Webhook 方案部署后自动改写所有新建 Pod 的 image 字段yaml 和 helm chart 一行都不用动。Containerd hosts.toml 镜像配置用 Containerd 作为运行时的参考其官方 hosts 文档为对应 registry 配置 hosts.toml 即可走 kubespray 装 K8s 的可以直接用现成的containerd_registries_mirrors参数。CI/CD 流水线接入用环境变量统一前缀在流水线里定义一个变量比如MIRRORm.daocloud.io构建脚本统一用${MIRROR}/docker.io/...这种写法拉镜像。好处是换加速源只改一个变量不用翻几十个 job 的配置。30 秒检查镜像同步状态白名单与脚本 ✅把仓库克隆下来里面自带了校验脚本这也是这个项目对新手友好的一点——不用猜git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror # 把镜像地址规范化自动补 docker.io/library 前缀和 :latest ./hack/correct-image.sh prom/node-exporter:v1.8.2 # 检查是否命中白名单第二个参数是不带 tag 的镜像 ./hack/verify-allows.sh allows.txt docker.io/prom/node-exporter有输出/返回成功说明在同步范围内如果不在名单里去对应的 白名单问题反馈 渠道提需求即可新镜像加入白名单走 Issue 流程。理解这几条机制基本能预判一切诡异现象懒加载首次会稍慢它在替你从源仓库同步30 天没拉的镜像缓存会过期latest 这种可变 tag 更新后最长 1 小时才生效。所以官方给出的选型顺序是优先sha256:摘要 明确版本号 tag 最后才是 latest。如果整个团队都在同一个内网还可以再加一层用本地 registry 挂一个 proxyremoteurl 指向m.daocloud.io做二级缓存部署文档见 docs/local-cache/README.md之后内网节点拉镜像就完全不依赖外网了。常见坑自查清单从拉取失败到 404 ️现象、原因和对应做法放在一起排障时对照着看latest 拉到的内容时新时旧。可变 tag Manifest 一小时缓存源更新后镜像侧还在返回旧数据。做法生产环境固定用sha256:摘要或明确版本号。突然报 404。多半是缓存到了 30 天期限被清理清理瞬间的 blob 缓存窗口会让请求短暂落空。做法稍等片刻重新拉取懒加载会自动补同步长期不用的镜像别指望缓存还在。白天拉取明显变慢。不是配置问题是公共带宽在高峰期很拥挤。做法把批量拉取、预拉取调度到北京时间凌晨 01:00–07:00。gcr/ghcr 镜像配了 registry-mirrors 却没加速。Docker 的 mirror 只作用于 docker.io其他源站必须显式写gcr.m.daocloud.io/...这类前缀。加了前缀仍然拉不到。大概率镜像不在 allows.txt 白名单内。做法跑一遍上面的两个脚本确认不在名单就提 Issue 申请加入。用法小结与一个小建议整件事可以浓缩成一句话docker.io 系镜像用m.daocloud.io/前缀或 daemon.json 里配 registry-mirrors其他源站按专用域名替换拉不到先查 allows.txt 白名单。版本上坚持用摘要或明确 tag批量任务挪到凌晨基本就避开了绝大部分坑。最后一个小建议如果你们的机器都集中在同一内网不妨按 docs/local-cache/README.md 搭一层本地 registry 缓存把 DaoCloud 镜像加速从节点各自拉外网升级成内网统一出口稳定性和速度都能再上一档。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考