public-image-mirror 内网镜像缓存实战基于 Registry 3 构建本地 Pull-Through Cache【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror本篇基于 docs/local-cache/README.md 展开讲解如何在内网环境部署一套本地镜像缓存借助 Docker Registry 3 的 proxy 模式对接 public-image-mirror即m.daocloud.io把常用镜像缓存到内网降低对外网依赖。读完本文你可以独立完成从 Docker Compose 编排、Registry 配置、Docker 客户端适配到拉取验证的全链路操作并理解 proxy、TTL、存储目录等参数背后的工作机制。为什么需要在内网部署镜像缓存在公网直接使用m.daocloud.io加速镜像拉取时每次拉取最终仍要经过一次内网 → 公网加速节点 → 源 Registry的链路。而内网环境如 VPC 内部集群、生产机房、离线程度较高的机房通常存在两类问题外网带宽不稳定或成本敏感大量节点重复拉取相同镜像时流量会反复穿透公网可用性要求高对外网服务的依赖越多构建/部署链路越脆弱。本地缓存部署的定位正是在内网中架设一个镜像仓库把常用镜像缓存下来。首次拉取仍会回源回源到m.daocloud.io由它再去同步上游源站但之后的拉取直接命中内网缓存从而减少对外网的依赖。这套做法与 README.md 中最佳实践章节的部署内网缓存一节一脉相承——它是官方推荐的把加速能力引入内网的方案本文即是该方案的完整实操展开。工作原理Registry 3 的 proxy 模式内网缓存的核心是一个运行pull-through cache拉取式缓存模式的 Docker Distribution Registry。与普通仓库不同proxy 模式的 Registry 自身不要求你手动docker push当客户端向它拉取某个镜像而本地没有时Registry 会按配置到远端 URL 回源拉取并把结果落盘到本地存储后续相同请求则直接命中本地。这一点可以直接从本文档给出的 Registry 配置中确认见下一节完整docker-compose.ymlproxy: remoteurl: https://m.daocloud.io ttl: 2160hremoteurl指定回源地址。这里回源到m.daocloud.io意味着内网缓存实际是两级缓存的第二级m.daocloud.io是第一级它缓存上游docker.io、gcr.io等源站你的内网 Registry 是第二级ttl为缓存条目的存活时间本文档取值2160h90 天超过 TTL 的缓存条目会被视为过期、重新回源。上游第一级缓存的行为在 README.md 中有明确说明可以作为理解整条链路的背景所有 hashsha256与源保持一致懒加载机制m.daocloud.io缓存的内容只保留 30 天过期后需要重新同步Manifest 内存缓存 1 小时tag 更新后约 1 小时才会同步新的Blob 内存缓存 1 分钟期间若 blob 到达 30 天期限被删除可能报 404。也就是说内网缓存命中时完全走内网流量未命中时请求会依次经过 内网 Registry →m.daocloud.io→ 源站此时延迟主要由公网回源决定。理解这个链路后为什么内网第二次拉取飞快就很好解释了。部署步骤1. 准备环境确保目标机器已安装Docker和Docker Composedocker compose子命令形式Docker 20.10 内置的 Compose v2 均可。2. 配置 Docker Compose 文件创建一个docker-compose.yml内容如下完整继承自 docs/local-cache/README.mdservices: 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: delete: enabled: true filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}逐项说明各配置的作用配置项作用image: m.daocloud.io/docker.io/library/registry:3缓存 Registry 自身的镜像也走加速源拉取避免用镜像加速服务的镜像来部署它自己时的鸡生蛋问题ports: 8888:8888把容器内 Registry 监听端口 8888 映射到宿主机 8888如内网习惯其他端口只需改映射的左侧并同步更新客户端配置command: /etc/docker/registry/config.yml指定 Registry 启动时使用的配置文件路径镜像默认即该路径这里显式写出便于理解volumes: cache-data:/var/lib/registry将缓存数据目录挂载到命名卷Registry 落盘的 manifest/blob 都保存在这里用命名卷而非绑定目录可随容器生命周期管理restart: unless-stopped异常退出自动拉起保证缓存服务持续可用configs: registry-config通过 Compose configs 机制把 Registry 配置以匿名文件形式注入容器避免再维护一个独立配置文件内嵌的 Registry 配置configs部分要点storage.filesystem.rootdirectory: /var/lib/registry缓存数据的根目录与上方卷挂载点一一对应storage.delete.enabled: true开启删除能力。配合 pull-through 场景Registry 在清理过期超过ttl缓存条目时可以真正删除存储内容避免缓存卷无限膨胀http.addr: :8888监听容器内所有网卡的 8888 端口是客户端访问的入口proxy.remoteurl: https://m.daocloud.io回源地址proxy.ttl: 2160h缓存存活 90 天过期后重新回源。3. 启动服务docker compose up -d启动后可用docker compose ps与docker compose logs registry确认服务正常并确认宿主机 8888 端口已监听。4. 配置 Docker 客户端由于内网缓存 Registry 走的是明文 HTTP内网场景下没有额外部署 TLS 证书Docker 客户端需要把它声明为可信的不安全 Registry。编辑/etc/docker/daemon.json添加{ insecure-registries: [your-registry-ip:your-registry-port] }将your-registry-ip、your-registry-port替换为缓存 Registry 实际的内网 IP 与端口按上文示例即宿主机 IP 与8888。然后重启 Docker 服务使配置生效systemctl restart docker说明如果你的内网环境部署了统一 CA 签发的证书也可以走 HTTPS 并去掉insecure-registries但 docs/local-cache/README.md 给出的标准方案就是明文 insecure-registries在内网中是常见且简单的做法。用法像使用 m.daocloud.io 一样加前缀部署完成后your-registry-ip:your-registry-port/就成为m.daocloud.io/的本地缓存代理。使用规则与直接使用m.daocloud.io完全一致在原镜像地址前加前缀即可只是前缀从m.daocloud.io换成了你的内网地址。例如拉取docker.io/library/nginx:latest镜像docker pull your-registry-ip:your-registry-port/docker.io/library/nginx:latest该请求的处理过程客户端向http://your-registry-ip:your-registry-port发起 pull内网 Registry 查本地存储命中则直接返回纯内网流量未命中则回源https://m.daocloud.io由它再按自身缓存/回源逻辑取到镜像同时写入内网本地缓存供后续节点复用。这套前缀规则与 README.md 中增加前缀的推荐方式一致内网 Registry 只是把第一级前缀本地化了。与直接使用 m.daocloud.io 的差异维度直接使用 m.daocloud.io部署内网缓存后前缀m.daocloud.io/...your-registry-ip:your-registry-port/...命中缓存时的网络路径节点 → 公网加速节点节点 → 内网 Registry回源链路加速节点 → 源站懒加载内网 Registry →m.daocloud.io→ 源站对外网依赖每次拉取都依赖外网可达仅首次/过期回源时依赖外网适用场景单点、节点少的公网环境内网集群、机房批量拉取另外结合上游缓存特性见 README.mdm.daocloud.io侧缓存只保留 30 天、Manifest 内存缓存 1 小时因此即使内网侧设置了 90 天 TTL长期不拉的镜像在 30 天后回源也可能需要重新同步——这是懒加载 两级缓存的正常表现属于适用前提与限制。运维与排障要点结合上文配置给出几条与实现直接对应的检查项缓存数据落盘位置docker volume inspect 项目名_cache-data可查看命名卷实际路径镜像内容全部位于/var/lib/registry下。内网盘容量要能容纳目标镜像的累计大小ttl: 2160h决定了过期条目才会被清理容量规划需按常用镜像全集估算端口不通时确认docker compose ps中容器在运行、宿主机 8888 监听正常、内网安全组/防火墙放行了 8888客户端daemon.json中声明的 IP:端口必须与ports映射的宿主机端口一致拉取报 404若上游源站/加速侧的 blob 恰好处于过期清理窗口可能出现瞬时 404对应 README.md 中Blob 内存缓存 1 分钟期间如果 blob 到达 30 天期限被删除导致会报 404的说明重试即可只读使用本方案中内网 Registry 只承担 pull 角色无需为它配置推送认证不要把内网缓存 Registry 当作品号仓库使用镜像白名单背景回源的m.daocloud.io服务于有白名单约束的镜像集合本仓库以 allows.txt 维护允许的镜像前缀含*、**等通配规则其格式可由 hack/verify-allows.sh 中的匹配逻辑印证——逐行判断前缀是否以**任意深度子路径、*仅一级路径或精确镜像名结尾再与请求镜像做前缀比对。因此内网缓存能拉到的范围天然等于m.daocloud.io允许的范围部署本地缓存不会扩大这个范围只会改变流量路径。小结内网缓存 一个 proxy 模式的 Registry 3proxy.remoteurl指向m.daocloud.iottl: 2160h控制缓存过期完整部署仅需一份内嵌configs的docker-compose.yml端口 8888、卷cache-data、回源地址、TTL 四处关键参数客户端在daemon.json中声明insecure-registries后重启 Docker使用方式与m.daocloud.io完全同构把前缀m.daocloud.io/换成your-registry-ip:your-registry-port/即可命中走内网、未命中回源两级缓存容量规划与 404 排查均可从 TTL 与缓存生命周期解释。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 public-image-mirror 内网镜像缓存实战：基于 Registry 3 构建本地 Pull-Through Cache
public-image-mirror 内网镜像缓存实战基于 Registry 3 构建本地 Pull-Through Cache【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror本篇基于 docs/local-cache/README.md 展开讲解如何在内网环境部署一套本地镜像缓存借助 Docker Registry 3 的 proxy 模式对接 public-image-mirror即m.daocloud.io把常用镜像缓存到内网降低对外网依赖。读完本文你可以独立完成从 Docker Compose 编排、Registry 配置、Docker 客户端适配到拉取验证的全链路操作并理解 proxy、TTL、存储目录等参数背后的工作机制。为什么需要在内网部署镜像缓存在公网直接使用m.daocloud.io加速镜像拉取时每次拉取最终仍要经过一次内网 → 公网加速节点 → 源 Registry的链路。而内网环境如 VPC 内部集群、生产机房、离线程度较高的机房通常存在两类问题外网带宽不稳定或成本敏感大量节点重复拉取相同镜像时流量会反复穿透公网可用性要求高对外网服务的依赖越多构建/部署链路越脆弱。本地缓存部署的定位正是在内网中架设一个镜像仓库把常用镜像缓存下来。首次拉取仍会回源回源到m.daocloud.io由它再去同步上游源站但之后的拉取直接命中内网缓存从而减少对外网的依赖。这套做法与 README.md 中最佳实践章节的部署内网缓存一节一脉相承——它是官方推荐的把加速能力引入内网的方案本文即是该方案的完整实操展开。工作原理Registry 3 的 proxy 模式内网缓存的核心是一个运行pull-through cache拉取式缓存模式的 Docker Distribution Registry。与普通仓库不同proxy 模式的 Registry 自身不要求你手动docker push当客户端向它拉取某个镜像而本地没有时Registry 会按配置到远端 URL 回源拉取并把结果落盘到本地存储后续相同请求则直接命中本地。这一点可以直接从本文档给出的 Registry 配置中确认见下一节完整docker-compose.ymlproxy: remoteurl: https://m.daocloud.io ttl: 2160hremoteurl指定回源地址。这里回源到m.daocloud.io意味着内网缓存实际是两级缓存的第二级m.daocloud.io是第一级它缓存上游docker.io、gcr.io等源站你的内网 Registry 是第二级ttl为缓存条目的存活时间本文档取值2160h90 天超过 TTL 的缓存条目会被视为过期、重新回源。上游第一级缓存的行为在 README.md 中有明确说明可以作为理解整条链路的背景所有 hashsha256与源保持一致懒加载机制m.daocloud.io缓存的内容只保留 30 天过期后需要重新同步Manifest 内存缓存 1 小时tag 更新后约 1 小时才会同步新的Blob 内存缓存 1 分钟期间若 blob 到达 30 天期限被删除可能报 404。也就是说内网缓存命中时完全走内网流量未命中时请求会依次经过 内网 Registry →m.daocloud.io→ 源站此时延迟主要由公网回源决定。理解这个链路后为什么内网第二次拉取飞快就很好解释了。部署步骤1. 准备环境确保目标机器已安装Docker和Docker Composedocker compose子命令形式Docker 20.10 内置的 Compose v2 均可。2. 配置 Docker Compose 文件创建一个docker-compose.yml内容如下完整继承自 docs/local-cache/README.mdservices: 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: delete: enabled: true filesystem: rootdirectory: /var/lib/registry http: addr: :8888 proxy: remoteurl: https://m.daocloud.io ttl: 2160h volumes: cache-data: {}逐项说明各配置的作用配置项作用image: m.daocloud.io/docker.io/library/registry:3缓存 Registry 自身的镜像也走加速源拉取避免用镜像加速服务的镜像来部署它自己时的鸡生蛋问题ports: 8888:8888把容器内 Registry 监听端口 8888 映射到宿主机 8888如内网习惯其他端口只需改映射的左侧并同步更新客户端配置command: /etc/docker/registry/config.yml指定 Registry 启动时使用的配置文件路径镜像默认即该路径这里显式写出便于理解volumes: cache-data:/var/lib/registry将缓存数据目录挂载到命名卷Registry 落盘的 manifest/blob 都保存在这里用命名卷而非绑定目录可随容器生命周期管理restart: unless-stopped异常退出自动拉起保证缓存服务持续可用configs: registry-config通过 Compose configs 机制把 Registry 配置以匿名文件形式注入容器避免再维护一个独立配置文件内嵌的 Registry 配置configs部分要点storage.filesystem.rootdirectory: /var/lib/registry缓存数据的根目录与上方卷挂载点一一对应storage.delete.enabled: true开启删除能力。配合 pull-through 场景Registry 在清理过期超过ttl缓存条目时可以真正删除存储内容避免缓存卷无限膨胀http.addr: :8888监听容器内所有网卡的 8888 端口是客户端访问的入口proxy.remoteurl: https://m.daocloud.io回源地址proxy.ttl: 2160h缓存存活 90 天过期后重新回源。3. 启动服务docker compose up -d启动后可用docker compose ps与docker compose logs registry确认服务正常并确认宿主机 8888 端口已监听。4. 配置 Docker 客户端由于内网缓存 Registry 走的是明文 HTTP内网场景下没有额外部署 TLS 证书Docker 客户端需要把它声明为可信的不安全 Registry。编辑/etc/docker/daemon.json添加{ insecure-registries: [your-registry-ip:your-registry-port] }将your-registry-ip、your-registry-port替换为缓存 Registry 实际的内网 IP 与端口按上文示例即宿主机 IP 与8888。然后重启 Docker 服务使配置生效systemctl restart docker说明如果你的内网环境部署了统一 CA 签发的证书也可以走 HTTPS 并去掉insecure-registries但 docs/local-cache/README.md 给出的标准方案就是明文 insecure-registries在内网中是常见且简单的做法。用法像使用 m.daocloud.io 一样加前缀部署完成后your-registry-ip:your-registry-port/就成为m.daocloud.io/的本地缓存代理。使用规则与直接使用m.daocloud.io完全一致在原镜像地址前加前缀即可只是前缀从m.daocloud.io换成了你的内网地址。例如拉取docker.io/library/nginx:latest镜像docker pull your-registry-ip:your-registry-port/docker.io/library/nginx:latest该请求的处理过程客户端向http://your-registry-ip:your-registry-port发起 pull内网 Registry 查本地存储命中则直接返回纯内网流量未命中则回源https://m.daocloud.io由它再按自身缓存/回源逻辑取到镜像同时写入内网本地缓存供后续节点复用。这套前缀规则与 README.md 中增加前缀的推荐方式一致内网 Registry 只是把第一级前缀本地化了。与直接使用 m.daocloud.io 的差异维度直接使用 m.daocloud.io部署内网缓存后前缀m.daocloud.io/...your-registry-ip:your-registry-port/...命中缓存时的网络路径节点 → 公网加速节点节点 → 内网 Registry回源链路加速节点 → 源站懒加载内网 Registry →m.daocloud.io→ 源站对外网依赖每次拉取都依赖外网可达仅首次/过期回源时依赖外网适用场景单点、节点少的公网环境内网集群、机房批量拉取另外结合上游缓存特性见 README.mdm.daocloud.io侧缓存只保留 30 天、Manifest 内存缓存 1 小时因此即使内网侧设置了 90 天 TTL长期不拉的镜像在 30 天后回源也可能需要重新同步——这是懒加载 两级缓存的正常表现属于适用前提与限制。运维与排障要点结合上文配置给出几条与实现直接对应的检查项缓存数据落盘位置docker volume inspect 项目名_cache-data可查看命名卷实际路径镜像内容全部位于/var/lib/registry下。内网盘容量要能容纳目标镜像的累计大小ttl: 2160h决定了过期条目才会被清理容量规划需按常用镜像全集估算端口不通时确认docker compose ps中容器在运行、宿主机 8888 监听正常、内网安全组/防火墙放行了 8888客户端daemon.json中声明的 IP:端口必须与ports映射的宿主机端口一致拉取报 404若上游源站/加速侧的 blob 恰好处于过期清理窗口可能出现瞬时 404对应 README.md 中Blob 内存缓存 1 分钟期间如果 blob 到达 30 天期限被删除导致会报 404的说明重试即可只读使用本方案中内网 Registry 只承担 pull 角色无需为它配置推送认证不要把内网缓存 Registry 当作品号仓库使用镜像白名单背景回源的m.daocloud.io服务于有白名单约束的镜像集合本仓库以 allows.txt 维护允许的镜像前缀含*、**等通配规则其格式可由 hack/verify-allows.sh 中的匹配逻辑印证——逐行判断前缀是否以**任意深度子路径、*仅一级路径或精确镜像名结尾再与请求镜像做前缀比对。因此内网缓存能拉到的范围天然等于m.daocloud.io允许的范围部署本地缓存不会扩大这个范围只会改变流量路径。小结内网缓存 一个 proxy 模式的 Registry 3proxy.remoteurl指向m.daocloud.iottl: 2160h控制缓存过期完整部署仅需一份内嵌configs的docker-compose.yml端口 8888、卷cache-data、回源地址、TTL 四处关键参数客户端在daemon.json中声明insecure-registries后重启 Docker使用方式与m.daocloud.io完全同构把前缀m.daocloud.io/换成your-registry-ip:your-registry-port/即可命中走内网、未命中回源两级缓存容量规划与 404 排查均可从 TTL 与缓存生命周期解释。【免费下载链接】public-image-mirror很多镜像都在国外。比如 gcr 。国内下载很慢需要加速。致力于提供连接全世界的稳定可靠安全的容器镜像服务。项目地址: https://gitcode.com/GitHub_Trending/pu/public-image-mirror创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考