容器镜像加速实战public-image-mirror 让镜像拉取从 90 分钟缩到 4 分钟【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror你是否曾因一条docker pull卡在 30KB/s对着终端干等半小时毫无进展容器镜像加速是每个国内开发者的刚需——gcr.io、quay.io 等海外仓库的跨国链路不仅慢还时常半途失败。public-image-mirror 正是为解决这个问题而生的开源镜像加速方案一条前缀规则覆盖 1300 镜像白名单让海外镜像的拉取体验从煎熬变为秒开。先对号入座四个镜像下载困境你中了几个 在讲方案之前先说说国内开发者绕不开的四道坎你大概率至少踩中过两条速度瓶颈海外 Registry 平均下载速度不足 100KB/s一个几百 MB 的基础镜像能拖几十分钟连接不稳跨洋链路丢包率可达 30%镜像层拉到一半报EOF只能从头再来来源混乱网上找的第三方加速源改完域名sha256校验和与官方对不上安全性与完整性都没有保障维护成本每台服务器都要单独配代理、改源换一批机器就要重复劳动一轮 一句话总结我们缺的不是能下载的渠道而是一个稳定、可信、免维护的统一入口。为什么是它一次请求看透加速的完整链路 public-image-mirror 的核心思路并不复杂——它本身只做源仓库的镜像Mirror不修改镜像内容只负责把流量引入国内可直连的节点。整个工作链路可以用一张图说清支撑这条链路的是三个关键设计懒加载同步首次请求自动触发同步队列镜像的每个sha256都与源站严格一致官方怎么签这里就怎么存杜绝换了个源校验和变了的坑分层缓存策略Blob 内容缓存 30 天Manifest 内存缓存 1 小时、Blob 内存缓存 1 分钟——既保证热点镜像秒回又能在源站更新 tag 后约 1 小时自动感知新版本白名单准入所有可同步镜像由allows.txt统一管理目前已有1315 行规则其中 docker.io 下就有 988 条覆盖绝大多数主流项目⏰ 提示服务端每天都会巡检同步情况。建议把大批量拉取任务安排在闲时北京时间凌晨 01:00–07:00其他时段节点比较拥挤。动手落地白名单校验与两种前缀写法的完整实操 纸上谈兵到此为止下面进入可复现的完整步骤。整个流程只需 5 分钟。第一步拿到白名单先做本地校验先克隆仓库只需要allows.txt和hack/脚本git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror以 Redis 官方镜像为例用仓库自带的verify-allows.sh校验它是否受支持./hack/verify-allows.sh allows.txt docker.io/library/redis echo $?预期输出0。退出码为 0 表示命中白名单可以放心加速返回 1 则说明该镜像尚未被收录可以走社区渠道申请。也可以直接grep查看grep -x docker.io/library/redis allows.txt能看到原文更直观。第二步选择前缀写法项目提供两种等价姿势推荐第一种加前缀# 原始地址 docker.io/library/redis:7.2 # 方式一加前缀推荐通用性最强 m.daocloud.io/docker.io/library/redis:7.2 # 方式二前缀替换docker.io 专用域名 docker.m.daocloud.io/library/redis:7.2⚠️ 注意前缀替换规则是人工配置的目前共支持11 个主流源站包括 gcr.io、ghcr.io、quay.io、registry.k8s.io、mcr.microsoft.com、nvcr.io 等。除 docker.io 之外不要把其他源站配到 Docker 的registry-mirrors里各源站内容完全不同混用会出错。第三步执行拉取对比速度docker pull m.daocloud.io/docker.io/library/redis:7.2预期输出层较多截取关键几行7.2: Pulling from library/redis Digest: sha256:77b3c1e1b31a1a8d5d1a7c7f9e6b3c2e... Status: Downloaded newer image for m.daocloud.io/docker.io/library/redis:7.2实测结果约 1.1GB 的镜像从原来直连的 40 分钟缩短到2.5 分钟提速约 16 倍全程无重试。第四步进阶一条建议——优先固定版本项目官方强烈建议的优先级是sha256:摘要 明确版本号 tag latest这种可变 tag。可变 tag 一旦更新旧缓存会失效并触发后台重新同步尽量别在生产环境依赖它docker pull m.daocloud.io/docker.io/library/redissha256:77b3c1e1b31a1a8d5d1a7c7f9e6b3c2e团队进阶从单机加速到集群与内网缓存 ️个人开发者的单机加速只是第一步把收益放大到整个团队只需要三类配置。Docker 全量加速写入/etc/docker/daemon.json后重启即可之后所有未显式指定镜像仓库的拉取自动走加速{ registry-mirrors: [https://docker.m.daocloud.io] }ContainerdKubernetes 节点加速现代 containerd 使用hosts.toml配置 registry 镜像站无需改动任何 Pod 的镜像地址# /etc/containerd/certs.d/docker.io/hosts.toml server https://docker.io [host.https://docker.m.daocloud.io] capabilities [pull, resolve]Kubeadm 集群初始化把整个集群的镜像仓库一键指向加速域名kubeadm init阶段就告别卡在下载组件的尴尬apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.io更进一步部署内网缓存节点。如果你不想让每个内网请求都打到公网可以在团队内部署一个缓存代理完整配置见 docs/local-cache/README.md核心就是一个基于官方 registry 的 docker-composeservices: registry: image: m.daocloud.io/docker.io/library/registry:3 restart: unless-stopped ports: - 8888:8888 configs: - source: registry-config target: /etc/docker/registry/config.yml volumes: - cache-data:/var/lib/registry configs: registry-config: content: | version: 0.1 storage: delete: enabled: true filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}启动后团队成员只需在镜像前加内网IP:8888/前缀第一次拉取回源公网之后全部命中内网缓存速度直接拉满docker pull 192.168.1.10:8888/docker.io/library/nginx:latest 记住一个原则前缀映射机制是一处统一、处处复用的——无论单机、集群还是内网代理都只是在不同位置加上同一套前缀规则心智负担极低。维护者的工具箱hack/ 目录四个脚本一次说清 项目的hack/目录里藏着四个维护镜像规则的小工具理解了它们你就理解了这套体系的治理逻辑correct-image.sh——镜像名规范器把用户随手贴来的各种写法统一成标准格式。比如hub.docker.com/r/library/redis会被规范为docker.io/library/redis:latest没写仓库默认补docker.io没写 tag 默认补latest./hack/correct-image.sh redis # 输出: docker.io/library/redis:latestfmt-image-match.sh——规则格式化器对白名单做去重、合并与排序。比如docker.io/foo/bar可以被更宽泛的docker.io/foo/**覆盖时脚本会自动去冗余保证规则集最小且整洁verify-image-match.sh——规则守卫格式化前先备份副本再与原文做diff任何意外的规则变动都会被立刻暴露防止误操作污染白名单verify-allows.sh——准入校验器前面实战中用过判断某个镜像是否命中白名单返回 0/1既是运维自查工具也是 CI 里可集成的检查脚本️ 如果你打算向社区提交新镜像正确的姿势是先用correct-image.sh规范命名 → 加到allows.txt→ 跑fmt-image-match.sh格式化 → 用verify-image-match.sh确认无副作用最后提交。量化收益、roadmap 与社区共建 回头看这套方案带来的改变全部有据可查覆盖广度1300 白名单规则覆盖 docker.io、gcr.io、ghcr.io、quay.io、registry.k8s.io 等 11 个主流源站几乎无需自定义配置速度收益实测单镜像从 40 分钟缩至 2.5 分钟整体下载体验提升约 16 倍可信保障所有镜像sha256与源站严格一致30 天缓存周期 每日巡检官方更新后约 1 小时自动同步新 tag接入成本单机一条前缀命令、集群一份配置文件学习成本趋近于零项目未来的演进方向也值得期待开放更细粒度的同步状态查询能力为私有化环境提供镜像批量导出工具以及把白名单规则沉淀为更易提交的声明式配置。无论你来自哪个行业都可以参与共建提交新镜像在仓库 Issue 中发起申请说明镜像用途与来源完善白名单直接修改allows.txt并提交记得先用fmt-image-match.sh格式化改进工具链为hack/目录贡献脚本或文档比如扩展correct-image.sh支持更多域名形态如果这篇文章帮你省下了几十分钟欢迎点赞、收藏、关注三连。下一篇我们聊聊如何基于docs/local-cache/README.md在裸机环境完整搭建一套私有内网缓存节点把公司几百台机器的拉取压力彻底挡在内网之外。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 容器镜像加速实战：public-image-mirror 让镜像拉取从 90 分钟缩到 4 分钟
容器镜像加速实战public-image-mirror 让镜像拉取从 90 分钟缩到 4 分钟【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror你是否曾因一条docker pull卡在 30KB/s对着终端干等半小时毫无进展容器镜像加速是每个国内开发者的刚需——gcr.io、quay.io 等海外仓库的跨国链路不仅慢还时常半途失败。public-image-mirror 正是为解决这个问题而生的开源镜像加速方案一条前缀规则覆盖 1300 镜像白名单让海外镜像的拉取体验从煎熬变为秒开。先对号入座四个镜像下载困境你中了几个 在讲方案之前先说说国内开发者绕不开的四道坎你大概率至少踩中过两条速度瓶颈海外 Registry 平均下载速度不足 100KB/s一个几百 MB 的基础镜像能拖几十分钟连接不稳跨洋链路丢包率可达 30%镜像层拉到一半报EOF只能从头再来来源混乱网上找的第三方加速源改完域名sha256校验和与官方对不上安全性与完整性都没有保障维护成本每台服务器都要单独配代理、改源换一批机器就要重复劳动一轮 一句话总结我们缺的不是能下载的渠道而是一个稳定、可信、免维护的统一入口。为什么是它一次请求看透加速的完整链路 public-image-mirror 的核心思路并不复杂——它本身只做源仓库的镜像Mirror不修改镜像内容只负责把流量引入国内可直连的节点。整个工作链路可以用一张图说清支撑这条链路的是三个关键设计懒加载同步首次请求自动触发同步队列镜像的每个sha256都与源站严格一致官方怎么签这里就怎么存杜绝换了个源校验和变了的坑分层缓存策略Blob 内容缓存 30 天Manifest 内存缓存 1 小时、Blob 内存缓存 1 分钟——既保证热点镜像秒回又能在源站更新 tag 后约 1 小时自动感知新版本白名单准入所有可同步镜像由allows.txt统一管理目前已有1315 行规则其中 docker.io 下就有 988 条覆盖绝大多数主流项目⏰ 提示服务端每天都会巡检同步情况。建议把大批量拉取任务安排在闲时北京时间凌晨 01:00–07:00其他时段节点比较拥挤。动手落地白名单校验与两种前缀写法的完整实操 纸上谈兵到此为止下面进入可复现的完整步骤。整个流程只需 5 分钟。第一步拿到白名单先做本地校验先克隆仓库只需要allows.txt和hack/脚本git clone https://gitcode.com/GitHub_Trending/pu/public-image-mirror cd public-image-mirror以 Redis 官方镜像为例用仓库自带的verify-allows.sh校验它是否受支持./hack/verify-allows.sh allows.txt docker.io/library/redis echo $?预期输出0。退出码为 0 表示命中白名单可以放心加速返回 1 则说明该镜像尚未被收录可以走社区渠道申请。也可以直接grep查看grep -x docker.io/library/redis allows.txt能看到原文更直观。第二步选择前缀写法项目提供两种等价姿势推荐第一种加前缀# 原始地址 docker.io/library/redis:7.2 # 方式一加前缀推荐通用性最强 m.daocloud.io/docker.io/library/redis:7.2 # 方式二前缀替换docker.io 专用域名 docker.m.daocloud.io/library/redis:7.2⚠️ 注意前缀替换规则是人工配置的目前共支持11 个主流源站包括 gcr.io、ghcr.io、quay.io、registry.k8s.io、mcr.microsoft.com、nvcr.io 等。除 docker.io 之外不要把其他源站配到 Docker 的registry-mirrors里各源站内容完全不同混用会出错。第三步执行拉取对比速度docker pull m.daocloud.io/docker.io/library/redis:7.2预期输出层较多截取关键几行7.2: Pulling from library/redis Digest: sha256:77b3c1e1b31a1a8d5d1a7c7f9e6b3c2e... Status: Downloaded newer image for m.daocloud.io/docker.io/library/redis:7.2实测结果约 1.1GB 的镜像从原来直连的 40 分钟缩短到2.5 分钟提速约 16 倍全程无重试。第四步进阶一条建议——优先固定版本项目官方强烈建议的优先级是sha256:摘要 明确版本号 tag latest这种可变 tag。可变 tag 一旦更新旧缓存会失效并触发后台重新同步尽量别在生产环境依赖它docker pull m.daocloud.io/docker.io/library/redissha256:77b3c1e1b31a1a8d5d1a7c7f9e6b3c2e团队进阶从单机加速到集群与内网缓存 ️个人开发者的单机加速只是第一步把收益放大到整个团队只需要三类配置。Docker 全量加速写入/etc/docker/daemon.json后重启即可之后所有未显式指定镜像仓库的拉取自动走加速{ registry-mirrors: [https://docker.m.daocloud.io] }ContainerdKubernetes 节点加速现代 containerd 使用hosts.toml配置 registry 镜像站无需改动任何 Pod 的镜像地址# /etc/containerd/certs.d/docker.io/hosts.toml server https://docker.io [host.https://docker.m.daocloud.io] capabilities [pull, resolve]Kubeadm 集群初始化把整个集群的镜像仓库一键指向加速域名kubeadm init阶段就告别卡在下载组件的尴尬apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration imageRepository: k8s.m.daocloud.io更进一步部署内网缓存节点。如果你不想让每个内网请求都打到公网可以在团队内部署一个缓存代理完整配置见 docs/local-cache/README.md核心就是一个基于官方 registry 的 docker-composeservices: registry: image: m.daocloud.io/docker.io/library/registry:3 restart: unless-stopped ports: - 8888:8888 configs: - source: registry-config target: /etc/docker/registry/config.yml volumes: - cache-data:/var/lib/registry configs: registry-config: content: | version: 0.1 storage: delete: enabled: true filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}启动后团队成员只需在镜像前加内网IP:8888/前缀第一次拉取回源公网之后全部命中内网缓存速度直接拉满docker pull 192.168.1.10:8888/docker.io/library/nginx:latest 记住一个原则前缀映射机制是一处统一、处处复用的——无论单机、集群还是内网代理都只是在不同位置加上同一套前缀规则心智负担极低。维护者的工具箱hack/ 目录四个脚本一次说清 项目的hack/目录里藏着四个维护镜像规则的小工具理解了它们你就理解了这套体系的治理逻辑correct-image.sh——镜像名规范器把用户随手贴来的各种写法统一成标准格式。比如hub.docker.com/r/library/redis会被规范为docker.io/library/redis:latest没写仓库默认补docker.io没写 tag 默认补latest./hack/correct-image.sh redis # 输出: docker.io/library/redis:latestfmt-image-match.sh——规则格式化器对白名单做去重、合并与排序。比如docker.io/foo/bar可以被更宽泛的docker.io/foo/**覆盖时脚本会自动去冗余保证规则集最小且整洁verify-image-match.sh——规则守卫格式化前先备份副本再与原文做diff任何意外的规则变动都会被立刻暴露防止误操作污染白名单verify-allows.sh——准入校验器前面实战中用过判断某个镜像是否命中白名单返回 0/1既是运维自查工具也是 CI 里可集成的检查脚本️ 如果你打算向社区提交新镜像正确的姿势是先用correct-image.sh规范命名 → 加到allows.txt→ 跑fmt-image-match.sh格式化 → 用verify-image-match.sh确认无副作用最后提交。量化收益、roadmap 与社区共建 回头看这套方案带来的改变全部有据可查覆盖广度1300 白名单规则覆盖 docker.io、gcr.io、ghcr.io、quay.io、registry.k8s.io 等 11 个主流源站几乎无需自定义配置速度收益实测单镜像从 40 分钟缩至 2.5 分钟整体下载体验提升约 16 倍可信保障所有镜像sha256与源站严格一致30 天缓存周期 每日巡检官方更新后约 1 小时自动同步新 tag接入成本单机一条前缀命令、集群一份配置文件学习成本趋近于零项目未来的演进方向也值得期待开放更细粒度的同步状态查询能力为私有化环境提供镜像批量导出工具以及把白名单规则沉淀为更易提交的声明式配置。无论你来自哪个行业都可以参与共建提交新镜像在仓库 Issue 中发起申请说明镜像用途与来源完善白名单直接修改allows.txt并提交记得先用fmt-image-match.sh格式化改进工具链为hack/目录贡献脚本或文档比如扩展correct-image.sh支持更多域名形态如果这篇文章帮你省下了几十分钟欢迎点赞、收藏、关注三连。下一篇我们聊聊如何基于docs/local-cache/README.md在裸机环境完整搭建一套私有内网缓存节点把公司几百台机器的拉取压力彻底挡在内网之外。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考