docker pull 在 CI 里卡了 8 分钟?3 步接入 DaoCloud 镜像加速,拉取回到 1 分钟内

docker pull 在 CI 里卡了 8 分钟?3 步接入 DaoCloud 镜像加速,拉取回到 1 分钟内【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirrorCI 里拉docker.io/library/redis:7,卡在 8 分钟后报超时,这是 docker.io 国内拉取超时的典型样子。Docker 镜像拉取慢的根子基本都在一个地方:源仓库在海外。DaoCloud 镜像加速做的就是一件公开镜像加速代理的活:你不用自己搭 mirror 仓库,只在镜像地址前面加一层前缀,它负责中转和缓存,hash 与源仓库保持一致。下面按接上 → 验证 → 兜底三步,把这个服务从接入到排障走一遍。一条凌晨的 CI 日志:拉了 8 分钟的 pull这一节解决的问题:遇到拉取慢,先判断它是不是该用加速。下面是一段压缩过的 CI 日志:14:02:11 pull docker.io/library/redis:7 14:02:14 manifest 2d4c…: digest sha256:9f21… 14:05:47 layer 0123… 9.8% (14.0MiB/142.6MiB) 14:08:10 ERROR: net/http: request canceled (Client.Timeout)拉取分三段:拿 Manifest、逐层下载、落盘。日志里进度停在 9.8% 三分钟不动,说明慢在国际链路上,跟你机器配置没关系——这类慢法几乎都是跨境带宽问题。接入加速后能快多少,实际表现取决于带宽和时段,没有保底数字;挑一个你高频拉的镜像对比一下前后耗时,心里就有数了。另外服务方建议把批量拉取放在凌晨 01:00-07:00(北京时间)的闲时,其他时段比较拥挤。这个服务替你干了什么:一个懒加载的镜像中转站这一节解决的问题:把数据流向搞明白,后面再遇到旧数据或偶发 404 就知道是哪来的。它的思路类似代购:不提前同步整个仓库,而是你拉某个镜像时,它才从源仓库按需同步到镜像侧;热门的镜像别人拉过,你直接命中缓存。整条链路很短:源仓库 → 同步队列 → 加速节点 → 你的客户端,客户端只跟加速域名打交道。两个词:Manifest 和 BlobManifest 就是镜像的目录清单,告诉客户端有哪些层要下载、各自的哈希是什么;Blob 是每一层的实际数据。镜像端对它们的处理就两点:一是所有 hash(sha256)与源仓库保持一致,中途不做任何重打包;二是都带有效期存放,不会永久驻留。三条缓存规则,决定你看到的旧数据从哪来官方写明的有效期规则一共三条:Blob 持久缓存保留 30 天,过期后下次拉取要重新同步Manifest 内存缓存 1 小时,所以上游 tag 更新后,新内容一小时内不可见Blob 内存缓存 1 分钟,这个窗口内如果持久缓存恰好被清掉,可能偶发 404后面排障遇到怪现象,先回来对这三条。最省事的接法:前缀写法和运行时全局配置这一节解决的问题:地址到底改在哪,改动量有多大。改一行镜像地址,立刻生效推荐方式是加前缀:把m.daocloud.io/拼在原地址前面,不改任何配置文件,这是容器镜像加速最通用的入口:# 原地址,国内网络通常很慢 docker pull docker.io/library/redis:7 # 加前缀,只多了一个域名 docker pull m.daocloud.io/docker.io/library/redis:7 # 或者在 yaml 里直接写替换域名的形式 docker.m.daocloud.io/library/redis:7第三行是域名替换写法:docker.io 写成 docker.m.daocloud.io,gcr.io 写成 gcr.m.daocloud.io,quay.io、registry.k8s.io 等十几个源站也各有对应域名。这套映射是人工配置的,新源站要等配置加进来才能用,所以官方 README 明确说推荐前缀方式。如果你连每个 yaml 都不想改,k8s 镜像仓库代理配置也是同一个思路:kubeadm 配置里的imageRepository字段换成加速域名,kind 建集群时--image传前缀地址,都是这一类事。常用接法按场景各一行:你处于的情况写什么例子一次性或少数镜像原地址加前缀m.daocloud.io/docker.io/library/redis:7整台 Docker 机器daemon.json 的registry-mirrorshttps://docker.m.daocloud.iodocker.io 以外的源(gcr、quay 等)对那个源加前缀m.daocloud.io/quay.io/…改 daemon.json 让 Docker 默认走加速想让整台机器的 Docker 都受益,改/etc/docker/daemon.json一处:{ registry-mirrors: [ https://docker.m.daocloud.io ] }重启 Docker 服务生效。注意这个条目只对 docker.io 生效,不要拿它去配置其他源站,否则请求会落到错误的地方。containerd 加速镜像拉取同理,在 registry host 配置里声明 mirror 指向对应加速域名即可;Podman 则在registries.conf里给每个源写 mirror 条目,逻辑相同,都是把原域名指向加速域名。拉取超时先查这个文件这一节解决的问题:拉取报 404 或超时,怎么快速定位原因。这个服务的前提是白名单 限流:只有在白名单里的镜像才会被代理。白名单就是仓库里的 allows.txt 文件,一千三百多行,每行一个源站的命名空间或项目。查白名单:两种通配符,先去掉 tag行尾有两种通配符,含义不一样:docker.io/alpine/*只匹配该命名空间下的直接子项,不进子目录;docker.io/adriansegura99/**则匹配其下所有层级。查询时记得先去掉 tag:grep -F docker.io/library/redis allows.txt。查不到,说明镜像端不会代理,拉取必然 404——这时候换白名单内的镜像或等清单更新,别反复重试。仓库的 hack/ 目录里还带着verify-image-match.sh、verify-allows.sh这类脚本,可以批量核对一份镜像清单和白名单的匹配关系;要用脚本的话,先git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror把源码拉下来。用 digest 验证镜像没被换包接入镜像端之后,内容是否和源仓库一致应该抽查一次。最快的办法是对比同一 tag 两侧的 digest:# 两条 digest 一致,说明内容与源仓库一致 skopeo inspect docker://docker.io/library/redis:7 | grep -i digest skopeo inspect docker://m.daocloud.io/docker.io/library/redis:7 | grep -i digestdigest 对不上时先别急着用,回去对一遍上面三条缓存规则,或者直接改用sha256:显式锁定版本。⚠️ 生产上容易被打脸的四个细节这一节解决的问题:接入生产后哪些行为一定会遇到,提前知道比事后排查便宜。先是 latest 标签。它是可变 tag,上游更新后镜像端后台重新同步,更新和同步完成之间拉到的还是旧内容。官方建议的优先级是:先用sha256:锁定 digest,其次用明确版本号,最后才考虑 latest。CI 里拉基础镜像的,这条一定要做到。其次是 30 天过期。一个基础镜像一个月没拉过,第一次会慢,那是缓存过期重新同步,不是故障,值班时别慌着报障。再是限流。服务侧有限流,CI 多台机器同时打过来可能收到 429,在流水线里加退避重试,别原地硬试。最后是 1 小时延迟。上游刚发新 tag 就立刻从镜像端拉,拿到的还是旧的;时效敏感的场景先直拉源站,或等一小时。兜底:再垫一层内网缓存如果生产网不想经过外部加速域名,可以在内网再垫一层缓存:内网 registry 对镜像端做 pull-through 代理,镜像进内网一次,之后所有机器都从内网拉,对外依赖降到最低。部署步骤在 内网缓存部署文档 里有完整过程,compose 文件加客户端配置,这里不展开。接完之后:现在就能做的三件事这一节不做总结,只列待办。第一,把手头一个服务的镜像地址改成前缀写法拉一遍,顺手跑一次上面的 digest 对比,这个服务就正式进你的流程了。第二,把运行时的 mirror 配置收进配置管理,一次下发全机生效,好过逐台手改 daemon.json。第三,下次遇到拉不到的新 registry 域名,先查白名单,再考虑内网缓存方案。最后数一下:你今天的部署 yaml 里,image:字段还写着 docker.io 原始地址的有几行?那些就是马上可以换成前缀的地方。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考