public-image-mirror：给国内开发者的一条镜像加速捷径，以及它的边界
GC.R. Ollama Ollama Docker Deepseek-R1 ollama DeepSeek Ollama [ ] 使用 contrib.rocks 制作。
秒懂
- 它是什么？
- DaoCloud 的 public-image-mirror 用加前缀或替换前缀的方式，把 gcr、quay、docker.io 等海外镜像转成国内可直连的地址。懒加载、30 天缓存、白名单限流，这些机制决定了它适合什么场景，也划出了它的使用边界。
- 适合谁用？
- 适合在国内网络环境下需要拉取 gcr、quay、ghcr 等海外镜像的开发者，尤其是使用 kubeadm、kind 或 containerd 的 Kubernetes 用户。不适合对镜像可用性有严格 SLA 的生产环境，因为 30 天缓存过期、1 小时 manifest 延迟、白名单限流都可能造成拉取失败。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是国内拉取海外镜像的痛点
很多镜像托管在 gcr.io、quay.io、ghcr.io 这类国外 registry 上，国内直连速度慢，甚至超时。public-image-mirror 做的事情很直接：给这些镜像地址加一个前缀 m.daocloud.io，或者把源站域名替换成对应的 m.daocloud.io 子域名，让请求走 DaoCloud 的国内节点。这个项目本身不是一个软件，而是一份公开的镜像仓库配置和配套文档。它面向的是需要在国内网络环境下频繁拉取镜像的开发者、运维人员，尤其是使用 Kubernetes 相关组件的场景。README 里明确说，很多镜像在国外，国内下载很慢，需要加速。这个项目就是提供一个简洁有效的加速方法。
懒加载与缓存策略：加速的代价是什么
这个服务不是提前把所有镜像同步到国内，而是采用懒加载机制。当你请求一个镜像时，它才从源站拉取，然后缓存。所有 sha256 摘要和源保持一致，所以镜像内容不会被动过。但缓存只保留 30 天，过期后需要重新同步。manifest 在内存里缓存 1 小时，也就是说，如果源站的 tag 更新了，最多 1 小时后镜像服务才会同步到新版本。blob 缓存只有 1 分钟，如果某个 blob 刚好在 30 天期限到达时被删除，这 1 分钟内请求会报 404。这些机制决定了它不是一个实时同步的镜像仓库，而是一个带过期时间的缓存代理。如果你依赖某个 tag 的最新内容，需要接受最多 1 小时的延迟。
两种用法：加前缀与替换前缀，规则不同
推荐的方式是加前缀。比如 docker.io/library/busybox 变成 m.daocloud.io/docker.io/library/busybox，这在任何支持自定义 registry 地址的容器运行时里都通用。另一种是替换前缀，比如 docker.io 换成 docker.m.daocloud.io，gcr.io 换成 gcr.m.daocloud.io。替换前缀是人工配置的映射表，每个源站对应一个固定的子域名。README 特别提醒，不要把 docker.io 之外的站点配置给 Docker 的 registry-mirrors，因为 registry-mirrors 只适用于 docker.io，其他源站内容不同，配置了反而出错。前缀替换的规则是人工维护的，如果要新增源站，需要提 Issue。
实际配置：Docker、containerd、Podman 三种方式
Docker 的配置最简单，在 /etc/docker/daemon.json 里加 registry-mirrors 一项，指向 https://docker.m.daocloud.io。containerd 需要参考官方 hosts.md 文档，或者在使用 kubespray 时配置 containerd_registries_mirrors 变量。Podman 的配置在 /etc/containers/registries.conf，它比 Docker 灵活，可以为 gcr.io、ghcr.io、quay.io 等每个源站分别配置 mirror。例如，gcr.io 对应 gcr.m.daocloud.io，ghcr.io 对应 ghcr.m.daocloud.io。rootless 模式下可以写到 ~/.config/containers/registries.conf。这三种配置方式覆盖了最常见的容器运行时，但 README 没有提供 containerd 的具体配置示例，只给了官方文档链接，实际配置时还是得去翻 containerd 的文档。
Kubernetes 场景：kubeadm、kind 与 Webhook 注入
这个项目对 Kubernetes 用户特别友好。安装 kubeadm 时，可以把 imageRepository 设为 k8s.m.daocloud.io，coredns 的镜像仓库也对应改掉。kind 创建集群时，用 --image 参数指定 m.daocloud.io/docker.io/kindest/node:v1.22.1。更省事的方式是使用 repimage 这个 Webhook 项目，它通过 kubectl create -f 一条命令部署，自动修改所有新建 Pod 的镜像地址，不需要改动原有的 yaml 或 helm 模板。这个方案对已有集群的镜像加速很有价值，但引入 Webhook 也意味着集群里多了一个关键组件，如果它挂了，新建 Pod 可能会受影响。README 没有提 repimage 的故障处理方式，这点需要自己评估。
Ollama 与 DeepSeek 加速：实验功能，别抱太高期望
项目把 Ollama 和 DeepSeek 的加速单独列了一节。Ollama 的 Docker 镜像可以通过 docker.m.daocloud.io/ollama/ollama 拉取，有 CPU 和 GPU 两种启动方式。DeepSeek 模型则通过 ollama.m.daocloud.io 这个实验性前缀来加速，例如 docker exec -it ollama ollama run ollama.m.daocloud.io/library/deepseek-r1:1.5b。但 README 自己都承认，Ollama 官方源的下载速度已经很快，可以直接用官方源。这个实验功能处于内测阶段，稳定性没有保证。如果你只是想跑 DeepSeek，直接 ollama run deepseek-r1:1.5b 可能更省事。
限制与失败模式：白名单、限流、30 天过期
这个服务有明确的使用限制。白名单和限流是公开信息，但不是所有镜像都在白名单内，不在白名单的镜像无法加速。限流意味着高峰期可能拉取失败。README 建议把拉取任务放在北京时间凌晨 01 到 07 点，其他时间段非常拥挤。这意味着白天使用可能会遇到速度慢或超时。另一个限制是 30 天缓存过期，如果某个镜像超过 30 天没人拉取，再次拉取时需要重新同步，这会增加耗时。manifest 缓存 1 小时，所以 tag 更新后不会立即同步，如果你依赖最新 tag，可能拿到旧版本。这些限制决定了它不适合作为生产环境的唯一镜像源，更适合开发测试或 CI 场景。
替代方案与维护成本
替代方案有两种思路。一是自建本地缓存仓库，项目文档里有专门说明，在内网部署一个 registry，缓存常用镜像，减少对外网的依赖。这需要额外维护一个服务，但可以完全控制缓存策略和可用性。二是使用云厂商的镜像加速服务，比如阿里云或腾讯云的容器镜像服务，它们也有国内加速节点，但通常需要注册账号，且只覆盖 docker.io 的加速，不一定支持 gcr 或 quay。public-image-mirror 的优势在于覆盖源站多，配置简单，缺点是依赖 DaoCloud 的公共基础设施，白名单和限流不受你控制。维护成本方面，这个项目本身是 Apache-2.0 许可证，你可以自由使用，但服务端代码在 OpenCIDN/ocimirror，同步队列状态和监控状态都有公开页面。如果你要自己部署一套，需要维护 OpenCIDN 那套系统，成本不低。
编辑结论
适合在国内网络环境下需要拉取 gcr、quay、ghcr 等海外镜像的开发者，尤其是使用 kubeadm、kind 或 containerd 的 Kubernetes 用户。不适合对镜像可用性有严格 SLA 的生产环境，因为 30 天缓存过期、1 小时 manifest 延迟、白名单限流都可能造成拉取失败。使用前先确认目标镜像在 whitelist 中，并优先用 @sha256 固定镜像摘要，避开北京时间 01 到 07 点之外的高峰时段。如果你接受这些约束，它比自建代理简单得多，但如果你需要稳定的私有镜像源，还是应该部署自己的 registry 或使用云厂商的镜像仓库。
社区笔记