企业官网建设流程全解析

DaoCloud public-image-mirror 镜像加速指南：3 种用法从单条命令到全局生效

【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢，需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror

晚上十点，你执行docker pull gcr.io/google-containers/pause:3.9，终端停在 "Waiting..." 半天没动静。不少镜像仓库都部署在国外，国内直接拉取又慢又不稳定。DaoCloud 开源的 public-image-mirror 就是干这个的：在原始镜像地址前加一个m.daocloud.io/前缀，拉取就会先经过国内缓存节点完成镜像同步，这一层就叫做镜像加速。

项目定位：它到底做了什么

这个仓库本身不提供后端服务，它做两件事：第一，维护一份白名单 allows.txt，决定哪些源站的镜像允许同步，新镜像想被加速就往这份名单里加；第二，公布一套前缀映射规则，告诉你在每个源站对应的域名前面该贴什么前缀。

和直接拉官方镜像的区别在于"懒加载"。打个比方：它不是提前把仓库里所有镜像搬到国内，而是像按需代购——你第一次拉某个镜像时，后台才去海外源仓库把数据取回来缓存住；之后再拉就是本地直接交付，不用再等跨网传输。⚠️ 注意缓存只保留 30 天，过期后要重新同步；而且 manifest 在内存里有 1 小时的缓存，源站 tag 更新后最多一小时才会生效。

public-image-mirror 镜像加速流程图

上手一：加前缀，单条命令解决

适用场景：临时拉一两个镜像，不想动任何全局配置。

关键命令：在完整镜像地址（含 registry 域名）前面加m.daocloud.io/，原地址里的域名不用删：

# 前缀加在完整地址前，其余什么都不用改 docker pull m.daocloud.io/gcr.io/google-containers/pause:3.9

效果验证：拉取完成后执行docker images能看到本地已存在该镜像；想确认能正常启动，docker run --rm跑一下即可。💡 官方 README 里给的最快示例就是docker run -d -P m.daocloud.io/docker.io/library/nginx，一条命令拉起来就能看到页面。

上手二：换域名，写法更短

适用场景：镜像来自少数几个常用源站（docker.io、gcr.io、ghcr.io 等），希望命令干净一点。

关键命令：这些源站有专门的替换域名，规则见 README 的"支持前缀替换的 Registry"表格。以 docker.io 为例：

# docker.io 的镜像可以换成更短的 docker.m.daocloud.io docker pull docker.m.daocloud.io/library/nginx:alpine # 跑起来验证，-P 会随机映射端口 docker run -d -P --name nginx-test docker.m.daocloud.io/library/nginx:alpine

gcr.io 对应gcr.m.daocloud.io，registry.k8s.io 对应k8s.m.daocloud.io，其余源站在表格里对号入座。

效果验证：docker ps里容器状态是Up，再用curl访问映射出的端口能返回页面，说明镜像本身完整可用。

上手三：改一行配置，全局生效

适用场景：团队机器上不想每次手敲前缀，让 Docker 守护进程自己走镜像源。

关键配置：把下面内容写进/etc/docker/daemon.json，重启 Docker 生效：

{ "registry-mirrors": [ "https://docker.m.daocloud.io" ] }

效果验证：重启后执行docker info | grep -A2 "Registry Mirrors"，输出里出现https://docker.m.daocloud.io即配置成功。⚠️ 这里有个容易踩的点：docker 的 registry-mirrors 只建议配 docker.io 这一站，README 明确提醒不要把 docker.io 之外的源站塞进这个配置，原因见下面的避坑指南。

Kubernetes 场景同理：kubeadm 部署时把配置文件里的imageRepository改成k8s.m.daocloud.io，kind 建集群时把--image换成m.daocloud.io/docker.io/kindest/node:v1.22.1，都是把源仓库地址整体替换掉。

最小演练：本地核对白名单

想确认某个镜像到底能不能被这个服务同步，不用真的拉一次浪费时间。先把仓库克隆下来，然后用它自带的校验脚本核对：

git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror # 传入不带 tag 的镜像路径，退出码 0 表示在白名单内 bash hack/verify-allows.sh allows.txt docker.io/library/nginx; echo $?

跑完你会看到输出0，说明docker.io/library/nginx在 allows.txt 中，放心拉取；如果输出1，代表不在白名单，加速服务不会同步它。这套脚本放在 hack/ 目录下，hack/verify-allows.sh只负责白名单判断，另有hack/correct-image.sh帮你把写歪的镜像名（缺域名、缺 tag）补全成标准格式，提交 Issue 前可以顺手用一下。

避坑指南

报 not found，但海外能直接拉

现象：docker pull m.daocloud.io/xxx/yyy报镜像不存在，同一个镜像在海外源站却能正常拉取。

原因：这个项目是"白名单 + 限流"的公开服务，只同步 allows.txt 里的镜像，不在名单内的直接拒绝。

处理：本地跑bash hack/verify-allows.sh allows.txt <不带tag的镜像路径>，返回 1 就是没在名单里。去项目 Issue 区提交添加申请；另外 README 建议把批量拉取任务放在闲时（北京时间凌晨 01–07 点），其他时段同步队列非常拥挤，会明显变慢。

同一个镜像时快时慢，偶尔 404

现象：昨天还能拉，今天报 404；或者拉下来发现 tag 内容和源站对不上。

原因：懒加载缓存的固有特性——缓存内容只保留 30 天，过期被清理后需要重新同步；manifest 有 1 小时内存缓存，tag 更新后要等缓存过期；blob 有 1 分钟缓存，期间如果底层数据到了 30 天期限被删，就会短暂报 404。

处理：生产环境优先用@sha256:摘要锁定镜像，其次是明确版本号的 tag，最后才考虑latest这种可变 tag（README 原话：latest 变更后会响应旧数据，并且后台会重新同步）。碰到偶发 404，隔几分钟重新拉一次即可。

配了 registry-mirrors，gcr 镜像却没走加速

现象：/etc/docker/daemon.json里配好了docker.m.daocloud.io，但拉 gcr.io、ghcr.io 的镜像速度没变化。

原因：docker 的 registry-mirrors 只会对 docker.io 的请求做替换，每个源站的内容和路由互不相同，README 明确警告不要把 docker.io 之外的站点配置给 registry-mirrors。

处理：gcr.io、ghcr.io 这类源站用加前缀方式m.daocloud.io/gcr.io/...；如果团队用的是 Podman，它支持给每个 registry 单独配 mirror，在/etc/containers/registries.conf里给 gcr.io、quay.io 分别加上对应的*.m.daocloud.io地址就能全覆盖。

收尾

public-image-mirror 用"一份白名单 + 一套前缀规则"把跨网拉镜像的问题收敛成一个加前缀的动作，稳定、透明、无需改代码。想继续深入的话，两个方向值得看：一是按 docs/local-cache/README.md 在机房内网部署一层私有 registry 缓存，减少对外网的依赖；二是研究仓库配套的限流与同步策略（README 顶部列出的公开信息 Issue），理解官方如何平衡加速效果与源站压力。

【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢，需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror