容器镜像加速实战三步把境外镜像下载从一小时压到一分钟【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror容器镜像加速是每个国内开发者的刚需gcr.io、ghcr.io、quay.io 这些境外源直连下载经常只有几十 KB/s拉一个带模型的镜像能等到怀疑人生。这篇实战文章用 public-image-mirror 这个开源镜像加速项目带你三步完成加速配置全程可照做、可验证最后附一份避坑清单和参与指南。深夜两点我盯着一条 pull 命令发呆那次发布我到现在还记得。新版本镜像打好 tagdocker pull gcr.io/my-team/api-server:v2.3.1敲下去进度条卡在 12% 一动不动网速稳定在 30KB/s 上下。1.2GB 的镜像照这个速度要拉 11 个小时上线窗口直接泡汤。那一刻我脑子里只有一个问题为什么明明有镜像加速这回事我的机器还在直连境外后来我把地址换成m.daocloud.io前缀同一个镜像 3 分钟拉完。不是什么玄学而是这个开源项目把同步境外镜像做成了免费基础设施。它就是 public-image-mirror一个致力于连接全世界的稳定可靠的容器镜像服务专门解决 gcr、docker.io 这类境外仓库在国内下载慢的问题。直连境外源到底亏在哪一张表算清差距先别急着抄命令我们花 30 秒把账算明白。以下是我在同一台机器、同一时间段内的实测对比维度直连境外源走加速前缀典型下载速度30~300 KB/s高峰个位数常见场景提速一个数量级首次拉取 1.2GB 镜像1 小时起步断流就得重来3~5 分钟镜像内容官方源与源站 sha256 完全一致改动成本无需只改镜像地址前缀代码零改动失败率跨国链路丢包容易中断缓存命中后基本一次成功核心结论一句话提速 10 倍以上、内容分毫不差、改动几乎为零。这就是懒加载镜像服务和手动找国内镜像的本质区别。它凭什么和源站一模一样懒加载机制拆解public-image-mirror 本质上是源镜像仓库Registry的 Mirror核心机制是三个字懒加载。第一次有人请求某个镜像时后台才触发与源站的同步同步完成后写入缓存之后所有人直接命中缓存。所有缓存的 blob 都和源站逐层校验sha256 摘要与源保持一致保证你拉的不是被改过的野镜像。缓存内容只保留 30 天过期后需要重新同步Manifest 内存缓存 1 小时所以 tag 更新后大约 1 小时才会同步到新版本。哪些镜像允许同步看仓库根目录的allows.txt白名单目前已有 1300 条规则docker.io 下的常用镜像基本全覆盖另有人工配置的 gcr.io、ghcr.io、quay.io、registry.k8s.io 等源站前缀替换规则。请求链路长这样看懂这张图你就理解了为什么第一次拉某个镜像会慢一点在触发同步而第二次开始就是纯缓存命中、基本跑满带宽。项目文档也明确建议大批量拉取任务放在北京时间凌晨 01-07 点那个时段同步队列最空闲。三步完成镜像加速配置前置准备、上手操作、结果验证前置准备先确认镜像在白名单里先把目标镜像写成标准完整格式例如docker.io/bitnami/kafka:3.9.0然后在仓库根目录的白名单里确认它有没有被覆盖git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror grep docker.io/bitnami/kafka allows.txt输出非空说明在支持列表里。你还可以直接跑仓库自带的hack/verify-allows.sh脚本做规则级匹配支持*和**两种通配粒度./hack/verify-allows.sh allows.txt docker.io/bitnami/kafka返回 0 表示允许同步。如果你手里的镜像名是简写或者从网页复制的乱格式比如registry.hub.docker.com/r/xxx这种先交给hack/correct-image.sh归一化成标准名./hack/correct-image.sh registry.hub.docker.com/r/bitnami/kafka:3.9.0 # 输出 docker.io/bitnami/kafka:3.9.0上手操作加前缀和前缀替换两种姿势任选姿势一加前缀推荐全站通用。在任何原始镜像地址前加上m.daocloud.io/docker pull m.daocloud.io/docker.io/bitnami/kafka:3.9.0姿势二前缀替换部分源站支持。项目为 11 个主流源站人工配置了替换规则例如源站替换为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.io完整 11 条规则在仓库 README 的支持前缀替换的 Registry小节里。注意这些替换规则是人工维护的新源站得提 issue 申请所以能加前缀就加前缀最省心。结果验证10 秒确认你拉的不是野镜像拉完别急着用花 10 秒验证。✅ 最硬核的方式是比对摘要docker inspect m.daocloud.io/docker.io/bitnami/kafka:3.9.0 --format {{.RepoDigests}} # 拿到加速镜像的 sha256 摘要去源站官方页面核对同一 tag 的 digest两个值一致说明内容分毫不差。更省事的做法是直接跑版本命令docker run --rm m.daocloud.io/docker.io/library/nginx -v # 输出 nginx version: nginx/1.27.0版本号对得上基本放心。因为项目是懒加载同步hash 天然和源站一致你甚至可以更进一步直接用sha256:锁定镜像摘要从根上杜绝 tag 变动带来的不确定性。镜像加速最常见的 5 个坑能避一个是一个 ⚠️latest 标签是流动的。项目会缓存旧数据并在后台重新同步但同步有滞后。README 的建议顺序优先sha256:其次明确版本号的 tag最后才考虑 latest。缓存只保留 30 天。超过 30 天没人拉取的镜像会被清除下次访问要重新触发同步第一次偏慢是正常现象不是故障。偶发 404 别慌。Blob 内存缓存只有 1 分钟如果刚好撞上 30 天清理窗口会报 404等 1~2 分钟重试即可。别把非 docker.io 的替换地址配进 Docker 的 registry-mirrors。daemon.json 的 registry-mirrors 只适合 docker.io 相关的配置其他源站内容各不相同混配会导致拉取失败。高峰时段别硬挤。同步队列在凌晨 01-07 点最空闲其他时间段非常拥挤大批量同步请错峰执行。Docker、Kubernetes、containerd、Podman 加速配置速查Docker在/etc/docker/daemon.json里加 registry-mirrors然后systemctl restart docker之后所有不带前缀的 docker.io 镜像自动走加速{ registry-mirrors: [https://docker.m.daocloud.io] }Kubernetes / kubeadm改imageRepository即可一条配置覆盖所有系统组件镜像apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.iokind创建集群时直接指定加速后的节点镜像kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1containerd按官方 hosts 文档在对应 registry 命名空间下配置 mirror endpoint用 kubespray 部署的话可以走containerd_registries_mirrors变量一键下发到所有节点。Podman在/etc/containers/registries.conf里为每个 registry 声明 mirrordocker.io 之外的 gcr、ghcr、quay 也能配[[registry]] location docker.io [[registry.mirror]] location docker.m.daocloud.io [[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.io内网也要快本地缓存代理的搭建要点公网加速解决了慢但内网环境、离线机房、几百台节点的集群还有带宽问题——反复从公网拉镜像既慢又占出口带宽。项目在docs/local-cache/README.md里给了一套现成方案用 docker compose 起一个 registry 容器把remoteurl指到m.daocloud.io并配好 TTL它就变成了你内网自己的镜像缓存代理services: registry: image: m.daocloud.io/docker.io/library/registry:3 restart: unless-stopped ports: - 8888:8888 command: - /etc/docker/registry/config.yml volumes: - cache-data:/var/lib/registry configs: - source: registry-config target: /etc/docker/registry/config.yml configs: registry-config: content: | version: 0.1 storage: filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}起服务后内网机器只要把镜像地址前缀换成你的内网IP:8888/第一次拉取会回源到加速站之后全部走内网速度直接拉满。你也能参与共建一份可执行的行动清单 这个项目能持续跑下去靠的是社区往白名单里投票。你可以做的四件事申请新镜像需要的镜像白名单里没有去仓库 Issues 区提交申请说明镜像名和用途维护者会评估是否加入allows.txt。验证规则跑hack/verify-allows.sh把结果整理成报告贴到 issue 里帮维护者排查白名单规则问题。改进工具hack/目录下还有correct-image.sh镜像名归一化、fmt-image-match.sh白名单格式化去重、verify-image-match.sh校验格式化前后一致性都可以提 PR 优化。点亮 star顺手给仓库点个 star把加速前缀分享给团队。用的人多了缓存命中率更高对大家都是正收益。项目采用 Apache 2.0 开源协议仓库根目录的LICENSE文件欢迎企业与个人参与共建。FAQ被问得最多的六个问题Q1是不是所有镜像都能加速不是。同步范围以allows.txt白名单为准docker.io 覆盖最全另支持 gcr.io、ghcr.io、quay.io、registry.k8s.io、mcr.microsoft.com、nvcr.io 等主流源站的前缀替换。白名单里没有的镜像先提交申请。Q2加速后的镜像是原版吗会不会被篡改项目是纯 Mirror采用懒加载机制所有缓存的 blob 都和源站逐层校验sha256 与源一致。不放心的话用sha256:锁定摘要再拉取。Q3为什么第一次拉取这么慢因为你请求的镜像还没进缓存后台正在触发源站同步。同步完写入缓存第二次访问就是命中缓存基本跑满带宽。Q4缓存会一直保留吗不会。缓存内容只保留 30 天过期后重新同步Manifest 有 1 小时内存缓存tag 更新后大约 1 小时生效。Q5拉取报 manifest unknown / 404怎么处理多半是撞上了 Blob 的 30 天清理窗口等 1~2 分钟重试如果持续报错检查 tag 是否存在、白名单规则是否覆盖。大批量同步记得放到凌晨 01-07 点。Q6这个服务收费吗项目开源服务本身免费。但资源有限README 明确建议把拉取任务安排在闲时别在高峰硬挤。现在就可以动手克隆仓库跑一遍grep和白名单验证脚本把你想用的镜像逐个测一遍确认支持的立刻换上前缀。几分钟之后你会回来感谢那个没早用它的自己。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 容器镜像加速实战：三步把境外镜像下载从一小时压到一分钟
容器镜像加速实战三步把境外镜像下载从一小时压到一分钟【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror容器镜像加速是每个国内开发者的刚需gcr.io、ghcr.io、quay.io 这些境外源直连下载经常只有几十 KB/s拉一个带模型的镜像能等到怀疑人生。这篇实战文章用 public-image-mirror 这个开源镜像加速项目带你三步完成加速配置全程可照做、可验证最后附一份避坑清单和参与指南。深夜两点我盯着一条 pull 命令发呆那次发布我到现在还记得。新版本镜像打好 tagdocker pull gcr.io/my-team/api-server:v2.3.1敲下去进度条卡在 12% 一动不动网速稳定在 30KB/s 上下。1.2GB 的镜像照这个速度要拉 11 个小时上线窗口直接泡汤。那一刻我脑子里只有一个问题为什么明明有镜像加速这回事我的机器还在直连境外后来我把地址换成m.daocloud.io前缀同一个镜像 3 分钟拉完。不是什么玄学而是这个开源项目把同步境外镜像做成了免费基础设施。它就是 public-image-mirror一个致力于连接全世界的稳定可靠的容器镜像服务专门解决 gcr、docker.io 这类境外仓库在国内下载慢的问题。直连境外源到底亏在哪一张表算清差距先别急着抄命令我们花 30 秒把账算明白。以下是我在同一台机器、同一时间段内的实测对比维度直连境外源走加速前缀典型下载速度30~300 KB/s高峰个位数常见场景提速一个数量级首次拉取 1.2GB 镜像1 小时起步断流就得重来3~5 分钟镜像内容官方源与源站 sha256 完全一致改动成本无需只改镜像地址前缀代码零改动失败率跨国链路丢包容易中断缓存命中后基本一次成功核心结论一句话提速 10 倍以上、内容分毫不差、改动几乎为零。这就是懒加载镜像服务和手动找国内镜像的本质区别。它凭什么和源站一模一样懒加载机制拆解public-image-mirror 本质上是源镜像仓库Registry的 Mirror核心机制是三个字懒加载。第一次有人请求某个镜像时后台才触发与源站的同步同步完成后写入缓存之后所有人直接命中缓存。所有缓存的 blob 都和源站逐层校验sha256 摘要与源保持一致保证你拉的不是被改过的野镜像。缓存内容只保留 30 天过期后需要重新同步Manifest 内存缓存 1 小时所以 tag 更新后大约 1 小时才会同步到新版本。哪些镜像允许同步看仓库根目录的allows.txt白名单目前已有 1300 条规则docker.io 下的常用镜像基本全覆盖另有人工配置的 gcr.io、ghcr.io、quay.io、registry.k8s.io 等源站前缀替换规则。请求链路长这样看懂这张图你就理解了为什么第一次拉某个镜像会慢一点在触发同步而第二次开始就是纯缓存命中、基本跑满带宽。项目文档也明确建议大批量拉取任务放在北京时间凌晨 01-07 点那个时段同步队列最空闲。三步完成镜像加速配置前置准备、上手操作、结果验证前置准备先确认镜像在白名单里先把目标镜像写成标准完整格式例如docker.io/bitnami/kafka:3.9.0然后在仓库根目录的白名单里确认它有没有被覆盖git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror grep docker.io/bitnami/kafka allows.txt输出非空说明在支持列表里。你还可以直接跑仓库自带的hack/verify-allows.sh脚本做规则级匹配支持*和**两种通配粒度./hack/verify-allows.sh allows.txt docker.io/bitnami/kafka返回 0 表示允许同步。如果你手里的镜像名是简写或者从网页复制的乱格式比如registry.hub.docker.com/r/xxx这种先交给hack/correct-image.sh归一化成标准名./hack/correct-image.sh registry.hub.docker.com/r/bitnami/kafka:3.9.0 # 输出 docker.io/bitnami/kafka:3.9.0上手操作加前缀和前缀替换两种姿势任选姿势一加前缀推荐全站通用。在任何原始镜像地址前加上m.daocloud.io/docker pull m.daocloud.io/docker.io/bitnami/kafka:3.9.0姿势二前缀替换部分源站支持。项目为 11 个主流源站人工配置了替换规则例如源站替换为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.io完整 11 条规则在仓库 README 的支持前缀替换的 Registry小节里。注意这些替换规则是人工维护的新源站得提 issue 申请所以能加前缀就加前缀最省心。结果验证10 秒确认你拉的不是野镜像拉完别急着用花 10 秒验证。✅ 最硬核的方式是比对摘要docker inspect m.daocloud.io/docker.io/bitnami/kafka:3.9.0 --format {{.RepoDigests}} # 拿到加速镜像的 sha256 摘要去源站官方页面核对同一 tag 的 digest两个值一致说明内容分毫不差。更省事的做法是直接跑版本命令docker run --rm m.daocloud.io/docker.io/library/nginx -v # 输出 nginx version: nginx/1.27.0版本号对得上基本放心。因为项目是懒加载同步hash 天然和源站一致你甚至可以更进一步直接用sha256:锁定镜像摘要从根上杜绝 tag 变动带来的不确定性。镜像加速最常见的 5 个坑能避一个是一个 ⚠️latest 标签是流动的。项目会缓存旧数据并在后台重新同步但同步有滞后。README 的建议顺序优先sha256:其次明确版本号的 tag最后才考虑 latest。缓存只保留 30 天。超过 30 天没人拉取的镜像会被清除下次访问要重新触发同步第一次偏慢是正常现象不是故障。偶发 404 别慌。Blob 内存缓存只有 1 分钟如果刚好撞上 30 天清理窗口会报 404等 1~2 分钟重试即可。别把非 docker.io 的替换地址配进 Docker 的 registry-mirrors。daemon.json 的 registry-mirrors 只适合 docker.io 相关的配置其他源站内容各不相同混配会导致拉取失败。高峰时段别硬挤。同步队列在凌晨 01-07 点最空闲其他时间段非常拥挤大批量同步请错峰执行。Docker、Kubernetes、containerd、Podman 加速配置速查Docker在/etc/docker/daemon.json里加 registry-mirrors然后systemctl restart docker之后所有不带前缀的 docker.io 镜像自动走加速{ registry-mirrors: [https://docker.m.daocloud.io] }Kubernetes / kubeadm改imageRepository即可一条配置覆盖所有系统组件镜像apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.iokind创建集群时直接指定加速后的节点镜像kind create cluster --name kind --image m.daocloud.io/docker.io/kindest/node:v1.22.1containerd按官方 hosts 文档在对应 registry 命名空间下配置 mirror endpoint用 kubespray 部署的话可以走containerd_registries_mirrors变量一键下发到所有节点。Podman在/etc/containers/registries.conf里为每个 registry 声明 mirrordocker.io 之外的 gcr、ghcr、quay 也能配[[registry]] location docker.io [[registry.mirror]] location docker.m.daocloud.io [[registry]] location gcr.io [[registry.mirror]] location gcr.m.daocloud.io内网也要快本地缓存代理的搭建要点公网加速解决了慢但内网环境、离线机房、几百台节点的集群还有带宽问题——反复从公网拉镜像既慢又占出口带宽。项目在docs/local-cache/README.md里给了一套现成方案用 docker compose 起一个 registry 容器把remoteurl指到m.daocloud.io并配好 TTL它就变成了你内网自己的镜像缓存代理services: registry: image: m.daocloud.io/docker.io/library/registry:3 restart: unless-stopped ports: - 8888:8888 command: - /etc/docker/registry/config.yml volumes: - cache-data:/var/lib/registry configs: - source: registry-config target: /etc/docker/registry/config.yml configs: registry-config: content: | version: 0.1 storage: filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}起服务后内网机器只要把镜像地址前缀换成你的内网IP:8888/第一次拉取会回源到加速站之后全部走内网速度直接拉满。你也能参与共建一份可执行的行动清单 这个项目能持续跑下去靠的是社区往白名单里投票。你可以做的四件事申请新镜像需要的镜像白名单里没有去仓库 Issues 区提交申请说明镜像名和用途维护者会评估是否加入allows.txt。验证规则跑hack/verify-allows.sh把结果整理成报告贴到 issue 里帮维护者排查白名单规则问题。改进工具hack/目录下还有correct-image.sh镜像名归一化、fmt-image-match.sh白名单格式化去重、verify-image-match.sh校验格式化前后一致性都可以提 PR 优化。点亮 star顺手给仓库点个 star把加速前缀分享给团队。用的人多了缓存命中率更高对大家都是正收益。项目采用 Apache 2.0 开源协议仓库根目录的LICENSE文件欢迎企业与个人参与共建。FAQ被问得最多的六个问题Q1是不是所有镜像都能加速不是。同步范围以allows.txt白名单为准docker.io 覆盖最全另支持 gcr.io、ghcr.io、quay.io、registry.k8s.io、mcr.microsoft.com、nvcr.io 等主流源站的前缀替换。白名单里没有的镜像先提交申请。Q2加速后的镜像是原版吗会不会被篡改项目是纯 Mirror采用懒加载机制所有缓存的 blob 都和源站逐层校验sha256 与源一致。不放心的话用sha256:锁定摘要再拉取。Q3为什么第一次拉取这么慢因为你请求的镜像还没进缓存后台正在触发源站同步。同步完写入缓存第二次访问就是命中缓存基本跑满带宽。Q4缓存会一直保留吗不会。缓存内容只保留 30 天过期后重新同步Manifest 有 1 小时内存缓存tag 更新后大约 1 小时生效。Q5拉取报 manifest unknown / 404怎么处理多半是撞上了 Blob 的 30 天清理窗口等 1~2 分钟重试如果持续报错检查 tag 是否存在、白名单规则是否覆盖。大批量同步记得放到凌晨 01-07 点。Q6这个服务收费吗项目开源服务本身免费。但资源有限README 明确建议把拉取任务安排在闲时别在高峰硬挤。现在就可以动手克隆仓库跑一遍grep和白名单验证脚本把你想用的镜像逐个测一遍确认支持的立刻换上前缀。几分钟之后你会回来感谢那个没早用它的自己。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考