容器镜像加速完整指南三步解决海外镜像拉取超时【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror一个 AI 团队在部署 Dify 的插件守护进程时第一条 docker pull 命令卡了 30 多分钟没有结果重启容器后又反复出现 ImagePullBackOff。原因很直接dify-plugin-daemon 的官方镜像托管在海外镜像仓库跨境链路不稳定拉大镜像时速度忽高忽低。这篇文章带你用 DaoCloud 的开源项目 public-image-mirror 做容器镜像加速把镜像地址加一个前缀同样的镜像就能从国内加速节点获取避免漫长的等待。原理为什么拉海外镜像会超时容器镜像存放在服务器端的镜像仓库Registry里docker pull 就是按地址通过网络把镜像层逐个下载下来。仓库在海外时每个数据包都要跨境传输链路拥堵时速度极不稳定大镜像很容易长时间卡住。public-image-mirror 的解决方式对用户几乎透明它充当源仓库前面的懒加载镜像。第一次收到请求时它去源站把对应镜像同步过来之后相同请求直接由国内缓存响应。镜像的 sha256 摘要与源站保持一致所以拉到的内容和官方原版完全一样。镜像是否可被同步由白名单控制白名单就存放在仓库里的 allows.txt 文件中目前有 1300 多条记录覆盖 docker.io、gcr.io、ghcr.io、quay.io、mcr.microsoft.com 等主流源站。容器镜像加速三步上手第一步确认镜像在不在白名单。白名单里记录的是镜像仓库路径不包含 tag。你可以把 public-image-mirror 仓库克隆到本地仓库地址https://gitcode.com/GitHub_Trending/pu/public-image-mirror然后在文件里搜一下grep -n langgenius allows.txt能搜到docker.io/langgenius/*这一行就说明 langgenius 组织下的所有镜像都支持同步dify-plugin-daemon 也在其中。如果不想克隆仓库里的 hack/verify-allows.sh 可以直接检查一个完整镜像名是否命中白名单。第二步给镜像地址加前缀。规则只有一个在原始完整地址前加上m.daocloud.io/。比如docker.io/langgenius/dify-plugin-daemon:latest就变成m.daocloud.io/docker.io/langgenius/dify-plugin-daemon:latest。如果你不确定镜像名写全了没有可以试着运行 hack/correct-image.sh它会帮你把缩写形式补全成标准地址。第三步照常执行 docker pull。docker pull m.daocloud.io/docker.io/langgenius/dify-plugin-daemon:latest第一次拉取可能稍慢因为镜像在从源站做首次同步之后再拉就走缓存速度快很多。按场景进阶Docker 全局加速配置不想给每个镜像手动加前缀的话可以给 Docker 配置镜像仓库在/etc/docker/daemon.json的registry-mirrors字段里加入https://docker.m.daocloud.io之后所有拉取 docker.io 镜像的请求都会自动走加速通道部署脚本和 yaml 都不用改。Podman 的配置思路相同而且支持为 gcr.io、ghcr.io、quay.io、registry.k8s.io 等多个源站分别配置加速地址具体文件格式可以参考 README.md 里加速 Docker和加速 Podman两节的说明。锁定版本少用 latest镜像的 Manifest记录 tag 当前指向哪份内容的元数据在镜像端有 1 小时内存缓存发布方更新 tag 后最多一小时才会同步到新内容。更稳妥的做法是固定版本优先用sha256:摘要指定镜像其次是明确的版本号 tag如 v1.2.3最后才考虑 latest。固定版本后部署结果不受上游 tag 变更影响镜像端也不需要为可变 tag 反复重新同步。大镜像同步放在闲时窗口官方建议把拉取任务安排在闲时即北京时间凌晨 1 点到 7 点其他时段同步队列比较拥挤首次同步大镜像容易慢。如果你的 CI 流水线或定时任务里有大批镜像同步试着把这些任务调度到这个时间窗口里。团队内网缓存部署团队里多台机器都从公网加速源拉取时每台机器仍要完整下载一遍镜像。仓库的 docs/local-cache 提供了一套方案用 Docker Compose 部署一个私有镜像仓库配置成代理到 m.daocloud.io再把团队的镜像前缀改成内网地址。这样每个镜像只从外网同步一次之后的分发都走内网高速传输同时减少了对外网的依赖。Kubernetes 场景用 kubeadm 建集群时把配置里的imageRepository换成k8s.m.daocloud.io用 kind 建开发集群时通过--image参数直接指定加速后的节点镜像如果希望集群里所有新建 Pod 自动替换镜像地址而不改 yamlREADME 中加速 Kubernetes一节还介绍了基于 Webhook 的做法可以作为参考。高频坑位现象、原因、处理现象一个镜像很久没拉了突然某天报 404。原因镜像缓存只保留 30 天超期后会被清理下一次拉取触发重新同步这个窗口期内可能出现短暂报错。 处理重新执行一次 pull等重新同步完成即可。长期使用的镜像可以固定版本并加一个定期拉取任务让缓存保持活跃。现象上游明明发布了新版本pull 到的却还是旧镜像。原因Manifest 内存缓存为 1 小时tag 指向变化最多一小时后才会同步。 处理等缓存过期后重拉或者干脆固定到具体版本号避免依赖可变 tag。现象某个镜像地址反复拉取都报 404网络本身没问题。原因该镜像不在白名单内镜像端不会处理白名单之外的请求。 处理先确认镜像的仓库路径是否包含在 allows.txt 里如果确实没有可以到项目方的 issue 区提交申请经维护者确认后加入白名单。实际效果回到开头的场景dify-plugin-daemon 直连海外仓库时 30 分钟拉不完换成 m.daocloud.io 前缀后首次拉取几分钟内完成缓存热了之后后续拉取只要几十秒。再配合固定版本号部署结果不再受上游 tag 变更影响反复重试的次数明显下降。【免费下载链接】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一个 AI 团队在部署 Dify 的插件守护进程时第一条 docker pull 命令卡了 30 多分钟没有结果重启容器后又反复出现 ImagePullBackOff。原因很直接dify-plugin-daemon 的官方镜像托管在海外镜像仓库跨境链路不稳定拉大镜像时速度忽高忽低。这篇文章带你用 DaoCloud 的开源项目 public-image-mirror 做容器镜像加速把镜像地址加一个前缀同样的镜像就能从国内加速节点获取避免漫长的等待。原理为什么拉海外镜像会超时容器镜像存放在服务器端的镜像仓库Registry里docker pull 就是按地址通过网络把镜像层逐个下载下来。仓库在海外时每个数据包都要跨境传输链路拥堵时速度极不稳定大镜像很容易长时间卡住。public-image-mirror 的解决方式对用户几乎透明它充当源仓库前面的懒加载镜像。第一次收到请求时它去源站把对应镜像同步过来之后相同请求直接由国内缓存响应。镜像的 sha256 摘要与源站保持一致所以拉到的内容和官方原版完全一样。镜像是否可被同步由白名单控制白名单就存放在仓库里的 allows.txt 文件中目前有 1300 多条记录覆盖 docker.io、gcr.io、ghcr.io、quay.io、mcr.microsoft.com 等主流源站。容器镜像加速三步上手第一步确认镜像在不在白名单。白名单里记录的是镜像仓库路径不包含 tag。你可以把 public-image-mirror 仓库克隆到本地仓库地址https://gitcode.com/GitHub_Trending/pu/public-image-mirror然后在文件里搜一下grep -n langgenius allows.txt能搜到docker.io/langgenius/*这一行就说明 langgenius 组织下的所有镜像都支持同步dify-plugin-daemon 也在其中。如果不想克隆仓库里的 hack/verify-allows.sh 可以直接检查一个完整镜像名是否命中白名单。第二步给镜像地址加前缀。规则只有一个在原始完整地址前加上m.daocloud.io/。比如docker.io/langgenius/dify-plugin-daemon:latest就变成m.daocloud.io/docker.io/langgenius/dify-plugin-daemon:latest。如果你不确定镜像名写全了没有可以试着运行 hack/correct-image.sh它会帮你把缩写形式补全成标准地址。第三步照常执行 docker pull。docker pull m.daocloud.io/docker.io/langgenius/dify-plugin-daemon:latest第一次拉取可能稍慢因为镜像在从源站做首次同步之后再拉就走缓存速度快很多。按场景进阶Docker 全局加速配置不想给每个镜像手动加前缀的话可以给 Docker 配置镜像仓库在/etc/docker/daemon.json的registry-mirrors字段里加入https://docker.m.daocloud.io之后所有拉取 docker.io 镜像的请求都会自动走加速通道部署脚本和 yaml 都不用改。Podman 的配置思路相同而且支持为 gcr.io、ghcr.io、quay.io、registry.k8s.io 等多个源站分别配置加速地址具体文件格式可以参考 README.md 里加速 Docker和加速 Podman两节的说明。锁定版本少用 latest镜像的 Manifest记录 tag 当前指向哪份内容的元数据在镜像端有 1 小时内存缓存发布方更新 tag 后最多一小时才会同步到新内容。更稳妥的做法是固定版本优先用sha256:摘要指定镜像其次是明确的版本号 tag如 v1.2.3最后才考虑 latest。固定版本后部署结果不受上游 tag 变更影响镜像端也不需要为可变 tag 反复重新同步。大镜像同步放在闲时窗口官方建议把拉取任务安排在闲时即北京时间凌晨 1 点到 7 点其他时段同步队列比较拥挤首次同步大镜像容易慢。如果你的 CI 流水线或定时任务里有大批镜像同步试着把这些任务调度到这个时间窗口里。团队内网缓存部署团队里多台机器都从公网加速源拉取时每台机器仍要完整下载一遍镜像。仓库的 docs/local-cache 提供了一套方案用 Docker Compose 部署一个私有镜像仓库配置成代理到 m.daocloud.io再把团队的镜像前缀改成内网地址。这样每个镜像只从外网同步一次之后的分发都走内网高速传输同时减少了对外网的依赖。Kubernetes 场景用 kubeadm 建集群时把配置里的imageRepository换成k8s.m.daocloud.io用 kind 建开发集群时通过--image参数直接指定加速后的节点镜像如果希望集群里所有新建 Pod 自动替换镜像地址而不改 yamlREADME 中加速 Kubernetes一节还介绍了基于 Webhook 的做法可以作为参考。高频坑位现象、原因、处理现象一个镜像很久没拉了突然某天报 404。原因镜像缓存只保留 30 天超期后会被清理下一次拉取触发重新同步这个窗口期内可能出现短暂报错。 处理重新执行一次 pull等重新同步完成即可。长期使用的镜像可以固定版本并加一个定期拉取任务让缓存保持活跃。现象上游明明发布了新版本pull 到的却还是旧镜像。原因Manifest 内存缓存为 1 小时tag 指向变化最多一小时后才会同步。 处理等缓存过期后重拉或者干脆固定到具体版本号避免依赖可变 tag。现象某个镜像地址反复拉取都报 404网络本身没问题。原因该镜像不在白名单内镜像端不会处理白名单之外的请求。 处理先确认镜像的仓库路径是否包含在 allows.txt 里如果确实没有可以到项目方的 issue 区提交申请经维护者确认后加入白名单。实际效果回到开头的场景dify-plugin-daemon 直连海外仓库时 30 分钟拉不完换成 m.daocloud.io 前缀后首次拉取几分钟内完成缓存热了之后后续拉取只要几十秒。再配合固定版本号部署结果不再受上游 tag 变更影响反复重试的次数明显下降。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考