企业官网建设流程全解析

容器镜像拉取总超时？DaoCloud 镜像加速的落地手册

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

CI 里一条docker pull卡在 99% 二十分钟，最后报 timeout，这种日子你肯定也经历过。今天讲 DaoCloud 镜像加速：它凭什么能把拉取从「分钟级失败」拉回「秒级成功」，以及从你一个人的笔记本到生产集群，最小改动量怎么接。写给每天要拉 docker.io、gcr.io 这类海外仓库镜像的开发者。

它是怎么加速的：原理讲透但不啰嗦

一句话结论：它就是一个「会缓存的透明代理」，源站不变，走它只是近路。三个机制撑起来——

• 透明代理：你只换拉取地址，镜像内容、tag、digest 一律不动；
• 懒加载：没人拉过的镜像不占空间，第一次拉才从源站同步；
• 分层缓存：Manifest 内存缓存 1 小时（tag 更新最多延迟 1 小时生效）、Blob 内存缓存 1 分钟、落盘缓存保留 30 天，过期后重新回源同步。

docker pull m.daocloud.io/docker.io/library/nginx │ ▼ DaoCloud 加速节点 ──命中缓存──▶ 直接返回 │ 未命中 ▼ 回源 docker.io 拉取 ──▶ 写入缓存 ──▶ 返回给你

⚠️ 关键是：镜像 hash(sha256) 与源仓库完全一致。这意味着你拿到的东西和直连拉的一模一样，信任源站的签名和校验，就不用额外怀疑中间人。

三种接法，对号入座

前缀替换：改一行地址，最省事的接法

在镜像地址前加一个前缀就行，不碰任何配置：

docker pull m.daocloud.io/docker.io/library/nginx:latest

适合：临时验证、脚本里零星几条 pull 命令，谁都能三分钟上手。

域名替换：按源站换前缀，改现有镜像引用

不同源站对应不同加速域名，比如docker.io/library/busybox换成docker.m.daocloud.io/library/busybox，gcr.io 对应gcr.m.daocloud.io、quay.io 对应quay.m.daocloud.io。改法是全局替换镜像地址里的 registry 部分。

适合：镜像引用集中在少数文件、愿意做一次性批量替换的团队。注意：这里每个源站内容独立，别把 docker.io 之外的站配到 Docker 的 registry-mirrors 里。

运行时配置：一次配置，全机器生效

不想改任何镜像地址？改运行时配置即可。Docker 改/etc/docker/daemon.json：

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

Podman 则是改/etc/containers/registries.conf，加两行 mirror 映射（location写源站、mirror里写加速域名）即可，而且它支持给 gcr.io、quay.io 等多个源站分别配 mirror。

适合：希望整机所有拉取透明加速、完全不想动镜像地址的人。

从你一个人的机器，到团队，再到生产集群

思路只有一个：先跑通，再加固，每一级只加一个动作。

• 个人：跑一条docker run -d -P m.daocloud.io/docker.io/library/nginx，确认加速链路在你机器上通。通不了，后面都免谈。
• 团队：把registry-mirrors写进构建机和 CI 的配置模板，让所有人构建走同一套源，不再有人裸连 docker.io。
• 生产集群：集群初始化阶段就把加速源指进去，例如 kubeadm 配置里设imageRepository: k8s.m.daocloud.io，装集群和拉 coredns 都不再卡住；存量 Pod 可以用 Webhook 类方案自动改写新建镜像地址。

每一级都是上一级跑通之后才做的事，别跳级。

拉取提速多少？实测与调优

直连海外仓库，100MB 级别的镜像常见 1~3 分钟甚至超时失败；走加速源后通常 5~15 秒。CI 场景收益更明显：timeout 长尾基本消失，构建不再因为一次网络抖动整体失败。区间因网络环境和镜像大小浮动，但量级差是真实的。

三条立竿见影的调优：

1. 版本锁定：优先用@sha256:指定镜像，其次固定版本 tag，少用latest——可变 tag 源站更新后还会触发后台重新同步，平白慢一次；
2. 时间窗口：批量、大镜像的拉取挪到凌晨（北京时间 01:00–07:00）闲时，白天高峰段同步队列很拥挤；
3. 本地缓存层：内网部署一层 registry 做缓存代理（参考 docs/local-cache/ 的 compose 方案），proxy 指向https://m.daocloud.io，之后内网拉取走内网地址，外网依赖降到最低。

拉不下来？安全与排障兜底

先验信任：怀疑镜像被「动过」时，拿 digest 对一对，30 秒出结果。skopeo 对比源站和加速源的 digest：

skopeo inspect docker://docker.io/library/nginx:latest | grep -i digest skopeo inspect docker://m.daocloud.io/docker.io/library/nginx:latest | grep -i digest

两行输出一致，完整性就没问题。日常拉取失败先对照下表：

拉取卡住时，你第一个该查的永远是：这个镜像到底在不在白名单里。这一步能排掉大多数「加速源 404」的误判。

该不该用：选型与成本

什么情况下不必用：镜像源本来就在国内、拉取速度可接受；或你已有覆盖这些仓库的私有 registry 同步链路；又或者只拉一两个镜像且直连就够快。加速服务是治「慢和不稳」的，不是治「没有仓库」的，别过度依赖单一第三方节点。

收尾：三条判断标准

1. 源站在覆盖列表里就用：目标 registry 在 allows.txt 白名单内，直接上；不在就找替代源或提需求，别硬等。
2. digest 对得上就放心用：按上面的校验方法抽验一次，通过就放心接入；对不上立即停用并反馈。
3. 直连够快就不换：如果你网络环境直连稳定在可接受时长内，保持现状即可；一旦 timeout 成为常态，就按「个人→团队→集群」的顺序逐级接入。

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