镜像拉取慢public-image-mirror 容器镜像加速的完整实战指南【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirrorpublic-image-mirror 是 DaoCloud 运营的公开容器镜像加速服务给镜像地址加上m.daocloud.io前缀即可加速拉取 docker.io、gcr.io、ghcr.io 等国外仓库的镜像无需改造拉取命令和 CI 脚本。它解决的是国内访问境外 Registry 慢、不稳定导致构建部署卡死的问题适合本地开发拉镜像、Kubernetes 集群、CI/CD 流水线三类使用者。一分钟跑通容器镜像加速只加一个前缀public-image-mirror 的用法只有一件事——前缀替换。原始地址前面拼上m.daocloud.io其余不动docker pull m.daocloud.io/docker.io/library/nginx:1.25 docker run -d -P m.daocloud.io/docker.io/library/nginx这是 README 里快速开始的完整内容一条命令就能验证服务是否可用。第二种写法是前缀替换用专用域名顶替原域名docker pull docker.m.daocloud.io/library/nginx:1.25各源站对应的加速域名是人工配置的固定映射完整清单见 README.md源站替换为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注意两点官方明确推荐加前缀方式前缀替换表不保证覆盖所有源站另外这个服务是白名单制镜像必须在名单内才能被同步。你的镜像在白名单吗查 allows.txt 的三种方法服务只同步白名单里的镜像未收录的镜像拉取会直接 404。白名单就是仓库根目录的 allows.txt一行一个镜像仓库路径目前有 1327 行按源站统计前三位是 docker.io997 行、ghcr.io225 行、quay.io58 行。行尾通配符有严格语义docker.io/*只匹配一级命名空间下的镜像docker.elastic.co/**匹配该站点下所有镜像所以查docker.io/apache/kafka命中的是docker.io/apache/*这行规则而不是某个具体镜像名。查询有三种方式从轻到重# 1. 直接 grep注意去掉 tag白名单不含 tag grep docker.io/library/nginx allows.txt # 2. 仓库自带脚本退出码 0 表示命中白名单 ./hack/verify-allows.sh allows.txt docker.io/library/nginx # 3. 镜像名不规范时先归一化补 docker.io/library 前缀、补 :latest ./hack/correct-image.sh nginxhack/ 目录下还有fmt-image-match.sh规整白名单格式和verify-image-match.sh校验白名单规则间是否有冗余维护白名单贡献时需要用到。Docker、Podman、K8s 三种场景如何配置镜像加速运行时全局配置Docker 与 PodmanDocker 只需改/etc/docker/daemon.json的关键两行然后重启{ registry-mirrors: [https://docker.m.daocloud.io] } 这里有一个最多人踩的坑Docker 的registry-mirrors只对 docker.io 生效把 gcr.io 等其他源站的加速域名填进去反而会拖慢 docker.io 的拉取。README 专门强调了这一点。Podman 的registries.conf则支持给每个源站分别配 mirror写法如下rootless 模式放~/.config/containers/registries.conf同样有效[[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.ioContainerd 用户按官方hosts.toml机制配置 registry mirror 即可kubespray 安装时则直接设containerd_registries_mirrors变量。Kubernetes改两行配置覆盖控制面kubeadm 建集群时控制面组件镜像由 ClusterConfiguration 决定改两处即可apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.io dns: imageRepository: k8s.m.daocloud.io/coredns本地用 kind 起测试集群一条命令搞定kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1不想改任何 YAML 的话README 提到可以用 repimage 这类 mutating Webhook在 admission 阶段自动改写新建 Pod 的 image 字段业务清单保持原样。同一个镜像有时拉得到有时拉不到缓存机制决定的这是服务方在 README 里写明的缓存参数直接决定了你会遇到的各种偶发问题镜像的 sha256 与源仓库完全一致服务只做透明转发不改写内容所以可以放心做 digest 校验缓存内容只保留 30 天过期后删除下次拉取触发重新同步这个窗口期可能 404Manifest 内存缓存 1 小时源站 tag 更新后最长 1 小时你才拉到新内容Blob 内存缓存 1 分钟如果某个 blob 恰好在这 1 分钟内到达 30 天期限被删除会报 404官方给出的运营建议是批量拉取任务放在凌晨北京时间 01:00–07:00执行其他时段队列非常拥挤同步队列状态保留一小时的记录出问题时值得去看一眼排队情况。为什么优先用 sha256 而不是 latestREADME 把引用方式分了三档优先级从高到低sha256:显式 digest明确版本号 taglatest这类可变 tag原因在上一节的缓存机制里latest 指向的内容会变化源站更新后服务会先返回旧数据、后台重新同步集群里多台机器在同一分钟拉到的东西可能不一致而 digest 是不可变地址缓存命中稳定也不会触发反复重同步。对生产环境和 CI 流水线这是拉取行为可复现和不可复现的分界线。docker pull m.daocloud.io/docker.io/library/nginxsha256:xxxxxxxx内网二级缓存一份 compose 文件让整队不再依赖外网公网加速只解决了第一跳。如果公司内网机器多、还要防公网服务波动官方文档 docs/local-cache/README.md 给的方案是部署一个 Docker 官方registry:3开启 proxy 指向加速源proxy: remoteurl: https://m.daocloud.io ttl: 2160hdocker compose up -d启动后把节点 Docker 的insecure-registries指向内网IP:8888之后拉镜像就像对 m.daocloud.io 加前缀一样对本地 registry 加前缀docker pull your-registry-ip:8888/docker.io/library/nginx:latest效果是第一台机器把镜像拉进本地缓存后面所有机器走内网30 天内不再出网。同一套 compose 文件换个端口还能给不同团队各挂一份。回到开头那条命令docker pull m.daocloud.io/docker.io/library/nginx就是整个项目的核心交付。它的边界也很清楚——只服务白名单内的公开镜像私有仓库不在此列。把拉取任务放到凌晨、镜像引用锁到 digest、内网再垫一层 registry 缓存这三件事做完基本可以覆盖从个人开发机到生产集群的全部场景。仓库外的姊妹项目 public-binary-files-mirror 提供同类思路的二进制文件加速需要下载 GitHub Release 类资源时值得一并了解。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考