私有镜像仓库该不该用:先看它解决的问题是不是你的问题
Docker Hub 匿名拉取限制为每 6 小时 100 次,CI 并发一高最先撞上
它擅长的是CI 拉取加速;如果你只是内网离线部署,用现成的东西更省事。
先说结论
私有仓库省的是外网依赖和拉取时间,代价是磁盘和一次 gc 的运维
- 适合:CI 拉取加速
- 不适合:镜像版本管控
- 学习成本:registry 删除 manifest 只是打标记,要跑 garbage-collect 才真正释放磁盘
- 最大收益:garbage-collect 要在只读模式或停服时跑,边写边清可能删掉正在推送的层
- 最大风险:只删 tag 不做 gc,磁盘一个月涨了 80GB
它到底解决什么
Docker Hub 匿名拉取限制为每 6 小时 100 次,CI 并发一高最先撞上。
换句话说,它把「CI 拉取加速」这件事从手工变成可重复的流程。这是它真正的价值,而不是功能列表的长度。
什么时候不该用
下面三种情况,用了反而更累:
只删 tag 不做 gc,磁盘一个月涨了 80GB
gc 时还在推送,正在写的层被清掉,push 报 blob unknown
仓库没配 TLS 就暴露在公网,凭据是明文 Basic Auth
和替代方案比
私有仓库默认走 HTTP,Docker 要把它加进 insecure-registries 才能推。
| 方案 | 上手成本 | 适用规模 | 代价 |
|---|---|---|---|
| 私有镜像仓库 | 中等 | 中大型 | 需要维护 |
| 只用官方 registry | 低 | 小型 | 定制能力弱 |
| Harbor 全家桶 | 低 | 一次性任务 | 不可维护 |

这台工具的关键细节
几个决定长期体验的点:
- registry 删除 manifest 只是打标记,要跑 garbage-collect 才真正释放磁盘
- garbage-collect 要在只读模式或停服时跑,边写边清可能删掉正在推送的层
- Harbor 的漏洞扫描依赖外部 Trivy,首次扫一个 1GB 镜像要 1-2 分钟
我的建议
私有仓库省的是外网依赖和拉取时间,代价是磁盘和一次 gc 的运维。
先用两周,跑一个真实的小任务;两周后你还想用它,再谈长期。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- Docker Hub 匿名拉取限制为每 6 小时 100 次,CI 并发一高最先撞上
- 镜像层是共享的,同一基础镜像的 20 个服务实际只多占差异层
工具是解法,不是身份。
评论 (3)
备份没验证过等于没有,这条我认。
排查顺序那段直接抄进值班手册了。
「先看日志再猜」这句话值一篇文。
发表评论