Docker镜像仓库选型与迁移：从单机registry到Harbor HA

先说一个我上个月实际遇到的场景。晚上九点线上发布窗口刚开群里就有人我“Jenkins 里一堆 Docker 镜像拉取排队卡了两分钟是不是网挂了”我第一反应是查节点带宽发现外网没问题问题出在公司那台跑了两年的单机 Docker 镜像库上——磁盘 IO 冲高并发连接数打满几百个节点同时从同一个仓库拉镜像队列排到天荒地老。那次之后我花了一整个周末把公司的 Docker 镜像库选型从头捋了一遍也把过去几年踩过的坑全翻了出来。今天这篇就把这套评估方法写清楚给 2026 年还在为镜像仓库头疼的人做个参考。这篇内容不是那种堆功能对比表的说明书。我会先讲三个选型前必须想清楚的问题再拆解五大核心评估维度然后把 Docker Hub、Harbor、云厂商托管、轻量自建 registry:2 这几个主流方案挨个过一遍最后附上一次实际从单机 registry 迁移到 Harbor HA 的完整复盘包括迁移过程中踩过的具体坑。无论你是几个人的小团队还是几百人研发线的运维应该都能在里面找到可以直接参考的部分。1. 选型前先回答三个问题才不会被功能表带偏1.1 镜像库在业务链路上到底是什么角色先放下功能对比认真想一个问题镜像仓库在你的交付链路里到底是什么位置。它不是一个单纯的存储而是构建产物交付通道上的中转枢纽同时连接两个世界左侧是 CI 构建完后的 docker push 写入方右侧是 K8s、测试环境、生产节点 docker pull 的读取方。代码提交、构建、推送、拉取、启动整个生命周期里只要仓库慢一点、挂一下、权限错一处影响面就是整条交付链路。很多团队把镜像仓库当文件服务器以为能存能拉就算完成任务。实际镜像仓库的协议是分层的manifest 是内容索引blob 是真实镜像层tag 是一个可变引用。普通浏览器上传一个压缩包坏了顶多重传镜像仓库里这三层中任何一层损坏都会导致节点无法正常 pull甚至 manifest 列表和 blob 对不上连回滚都做不了。理解了这一点再看后面的评估维度思路会清楚很多。1.2 用需求五连问确定自己的选型权重在做维度打分之前先回答五个问题答案直接决定你的权重怎么分配团队规模有多大是三五个人还是几百个研发发布频率多高一天发几次单个镜像多大集群规模多大单次发布会有多少节点同时拉取有没有合规边界是否需要私有化、等保、供应链审计运维上有多少人力能投入在镜像仓库上团队画像吞吐要求高可用要求安全要求成本敏感度个人开发者 / 3-5 人低低低高30-100 人研发团队中中中中百人以上 / 多环境高高高低金融、政企等强合规中高极高低这张表不用做得很精确它只是提醒你一个小团队如果把高可用和安全权重拉到第一往往会选一个运维成本很高的重方案最后被反噬而一个大团队如果只关注存储便宜忽略并发和权限后面事故不断。不同画像对应不同方案具体匹配我放到第三章再展开。1.3 把“跑路成本”放在第一优先级选型时我优先级最高的指标不是功能、也不是速度而是跑路成本。所有方案在纸面上都长得很像真正拉开差距的是你用了一年后想换掉它时迁移有多痛。我会优先看三点是否兼容 OCI Distribution Spec 标准 API数据能否平滑导出迁移工具链是否成熟。只要这三点成立哪怕某个功能当时弱一点后面都能补。反过来如果厂商或自建方案把数据格式绑死等你想迁移时几十 TB 镜像搬不动那才是真正的黑天鹅。这个判断标准帮我避开过不少坑。有的开源项目 UI 做得再漂亮存储格式是私有的迁移只能导出 metadatablob 得重新拉等于白做有的云托管服务镜像存量一多导出按 GB 收费迁移成本远超当初省下的订阅费。所以在看下面五个维度之前建议先确定你想用的方案是不是“来去自由”。2. 五大核心评估维度每一项都是踩过坑换来的每个维度看着都基础但每一项背后都有过事故。下面拆开讲并给出我认为可以落地的评估方式。2.1 吞吐与并发看似最简单的维度最容易出问题先说最常见的场景CI 流水线批量构建推到仓库与此同时 K8s 集群进行滚动更新几十上百个节点同时从仓库拉镜像。这个时候仓库能提供的并发能力和带宽直接决定发布是顺利完成还是卡死。镜像传输的实际数据量和压缩率强相关。一个 Java 应用镜像 1.5GB压缩后通常只有 600MB 左右基础镜像压缩率低可能接近原大小。算一笔账单次发布 200 个节点同时拉 600MB希望 5 分钟内完成理论带宽需求是 200×600MB 除以 300 秒约 400MB/s折合 3.2Gbps这已经超过绝大多数普通服务器的带宽上限。所以镜像仓库慢很多时候根本不是仓库软件的问题而是带宽和并发的物理上限。怎么量化评估我的做法是拿一台 8C16G 的机器做压测用 skopeo copy 或 crane ls 分别测单流和多流下载记录不同并发下的吞吐曲线。注意观察 registry 在并发阈值下是否会返回 429 或 503。很多新手以为是仓库坏了其实是背压机制在保护后端存储。这种机制是正常的但你要知道阈值在哪里、是否能调参、后端存储能不能跟上。Docker 官方 registry:2 的并发上限、Harbor 的 registry 组件参数、云托管服务有没有规格上限都是这个维度要摸清的底细。2.2 高可用与容灾镜像仓库挂了全公司发布就停镜像仓库的故障很隐蔽它不像业务故障那样直接 5xx 刷屏而是表现为 CI 排队、发布卡住、集群扩容失败。我见过最典型的两起事故一是磁盘写满registry 的 GC 一直跑不完blob 删一半留一半仓库只能读不能写二是元数据文件损坏manifest 读不出来所有镜像看起来像消失了一样。这两起都不是什么大型分布式系统才有的问题单机部署也可能碰到。高可用设计分三层。第一层是应用层registry 本身要做到无状态多副本前面挂负载均衡任何一个副本挂了都能自动切换。第二层是数据层镜像数据要放到共享对象存储里比如 S3、MinIO、阿里云 OSS 这类而不是绑死在本地磁盘上。这样多个副本共享同一份数据不需要互相同步。第三层是容灾层跨区域用复制机制同步一份数据到灾备站点比如 Harbor 的 Replication、云厂商的跨区域同步。如果你只有一套环境至少把前两层做了大部分风险就已经被挡住了。另外要说一下备份。很多人以为后端用了对象存储就不用备份对象存储本身也有故障的可能而且误删镜像、恶意删除真发生了光靠版本控制未必够。关键数据定期做异地复制或者导出成本很低但关键时刻能救命。2.3 安全与合规2026 年不能只靠“私有部署”四个字过去一提私有镜像仓库大家的反应是反正在内网别人看不到很安全。这套思路放到 2026 年已经完全不成立了。镜像生产链路上有太多被污染的可能基础镜像本身有漏洞、依赖组件被投毒、tag 被覆盖成恶意版本、离职员工的账号还能访问仓库。所谓的私有部署解决的只是“外网访问权限”问题供应链的完整性没人保证。这个维度重点看四件事。第一CVE 漏洞扫描镜像进入仓库后能自动扫描并阻止高危镜像上线Harbor 集成的 Trivy、Clair 都可以。第二镜像签名与校验用 cosign 或 Notation 对镜像签名拉取端和生产环境校验签名保证镜像从构建到运行没被动过Harbor 3.x 对 cosign 签名校验的支持越来越成熟。第三访问控制与审计要支持 RBAC、机器人账号、细粒度权限、操作审计日志而不是一个账号走天下。第四不可变 tag同一个 tag 一旦推送成功就不允许覆盖从机制上杜绝 tag 漂移带来的安全风险。2026 年的合规评审里SBOM 软件物料清单也正在成为必填项。镜像里到底有哪些组件、哪些版本、有没有高危漏洞能不能一键导出一份可信清单会在选型时产生很大差别。如果你所在行业对供应链安全有硬性要求建议直接把签名和 SBOM 能力列入最低门槛而不是最后再补。2.4 生态与自动化镜像仓库要跟 CI/CD、K8s 长在一起镜像仓库不是独立工具它必须和 CI/CD、K8s 深度嵌在一起。这里看的是 API 兼容性和自动化能力。API 层面主流仓库现在都兼容 OCI Distribution Spec但兼容程度有差异。crane、skopeo、oras 这些工具能不能直接用webhook 能不能触发下游流程配额和保留策略能不能通过 API 管理都会影响接入成本。GitOps 场景下镜像构建完成后往往要自动通知部署平台触发更新这依赖仓库的 webhook 推送能力。多环境场景下每个环境要用不同项目隔离镜像那么项目级别的配额和清理策略就很重要。K8s 拉取凭证的轮换也是实际痛点很多团队 imagePullSecrets 写死凭证明文躺在集群里过期时全集群拉取失败支持机器人账号和临时凭证的方案可以减少这类事故。本地开发环境用 Docker Desktop 怎么登录、CI 里怎么注入凭据也都在这个维度里看起来很小但天天影响效率。还有一个和 Docker 镜像下载慢密切相关的功能代理缓存也叫 pull-through cache。Harbor 从 2.x 开始支持配置 Docker Hub 代理项目节点在内网拉 Docker Hub 镜像时Harbor 会从上游拉一份并缓存到本地后续节点直接从内网拉取。这个功能可以在不改造任何 Dockerfile 的情况下把拉取速度和稳定性提升一大截是很多团队解决 docker 镜像下载慢的最优解。2.5 成本与运维负担最贵的不一定是服务器一提到成本很多人第一反应是服务器价格。镜像仓库真正的成本结构其实有三块资源成本、人力成本、风险成本。资源成本包括服务器、存储、带宽和公网流量。人力成本包括日常升级、备份、修复、处理告警的时间。风险成本是系统故障引发的业务损失这个最难量化但往往最大。比较一下你就明白。自建一套 Harbor HA就算只用两台应用节点加一台 MinIO硬件和带宽成本看起来不高但版本升级、证书过期、存储清理、GC 卡死、权限误配这些坑每个都要有人去处理一年折算下来人工成本很容易超过买云托管的费用。反过来如果团队本身有资深运维已经把 Harbor 跑得很熟练那自建就是最省钱且可控的方案。选型时我会建议做半年或一年的 TCO 分析把所有隐性成本写进去再决定。3. 主流方案横向对比从 Docker Hub 到自建 Harbor3.1 五类方案的真实定位先快速过一遍主流方案每一个都说清楚它擅长什么、不擅长什么。Docker Hub生态最大几乎所有公共镜像都能在这儿找到。但两个老问题一直存在免费额度逐年收紧限流越来越严格国内网络环境下拉取 Docker Hub 经常超时。它适合做公共镜像的获取入口不适合做团队内部生产仓库。我一般只在本地开发时直接拉 Docker Hub在 CI 和生产环境全部走内网镜像源缓存。云厂商托管仓库阿里云 ACR、腾讯云 TCR、华为云 SWR、AWS ECR、Google Artifact Registry 都属于这一类。如果业务和 K8s 都在同一朵云上选同厂商的镜像仓库是最省心的方案内网访问、IAM 统一、按量付费、自带跨区域同步运维负担几乎为零。缺点是一旦上了云镜像数据就粘在厂商生态里跨云或者迁回自建时会比较麻烦。HarborCNCF 毕业项目企业级自建方案的首选。RBAC、机器人账号、复制、代理缓存、漏洞扫描、签名验签、不可变 tag、审计日志都已经是标配对绝大多数自建场景来说功能完全够用。它的问题不是能力而是需要有人维护。团队没有运维人力用它很容易从第一天就开始还技术债。registry:2Docker 官方轻量仓库一个容器就是一套服务。优势是简单、省资源适合个人开发者、测试环境或者作为 Docker Hub 的 pull-through 镜像源使用。劣势很明显没有 UI、没有完整的权限体系、GC 机制容易踩坑、审计基本靠日志。我不建议把它作为公司正式环境的唯一仓库。GHCR 和 Quay.io这两个和代码托管生态深度绑定适合开源项目和个人的 side projectGitHub 仓库的 Release 和镜像可以放在一起管理。企业生产环境用它作为主仓库集成度和私有化能力都不太够。3.2 一张表看清关键差异方案部署方式高可用安全能力性能/分发典型成本适合场景Docker Hub公有 SaaS厂商保障基础扫漏洞、限流公网受网络影响大免费/低公共镜像下载、个人学习云厂商托管仓库公有 SaaS厂商保障、跨区域同步IAM/RBAC、扫描云内网高速按量计费同云生态生产环境Harbor自建多副本共享存储全面可签名审计依赖自建带宽服务器运维人力企业私有化、强合规registry:2自建单机单点需自行扩展弱依赖单机链路极低个人测试、镜像源缓存GHCR/Quay公有 SaaS厂商保障基础安全公网免费/低开源项目、个人项目这张表只是快速筛选真要定方案还是要回到第一章的需求五连问里对号入座。3.3 不同团队画像下的落地建议个人开发者直接用 Docker Hub 加一个顺手点的镜像加速器就行本地环境用 Docker Desktop 拉公共镜像没必要折腾私有仓库。实在有私有镜像存储需求一台小机器跑 registry:2 足够了。十几到几十人的研发团队如果公司预算允许优先用云托管仓库一个项目一个命名空间IAM 管好权限省下的运维时间可以做更有价值的事。如果团队里有懂 Docker 的同事也可以先上一台 Harbor 单节点至少把权限和备份这两个问题先解决掉。100 人以上、多环境、强合规我建议直接规划 Harbor HA 三节点加共享对象存储跨机房或跨区域复制配合 cosign 签名和 SBOM 审计做完之后基本未来三五年不用再折腾。如果已经在云上且没有强制私有化用云厂商企业版加审计能力也是合理选择。很多团队问我自建 Harbor 和云托管到底哪个好。我的回答是如果你已经在一朵云上别犹豫用托管如果你有多云、混合云或私有化部署需求才考虑自建。选型永远先看环境约束再看功能。4. 2026 年哪些变量会改变你的决定4.1 供应链安全从“加分项”变成“必选项”过去镜像仓库选型安全大概属于加分项漏洞扫描有就更好没有也能凑合。现在不一样了供应链攻击的新闻越来越频密镜像从构建到运行要经过代码仓库、CI、镜像仓库、部署平台这么多环节每个环节都可能被动手脚。2026 年在做镜像仓库选型时我会把 CVE 扫描、镜像签名验签、SBOM、不可变 tag、审计日志列为必选项而不是可选项。以镜像签名为例cosign/Sigstore 生态已经比较成熟Harbor 3.x 对 cosign 校验的集成也越来越好。生产环境在部署前校验镜像签名保证只有私钥持有者签过名的镜像才能上线这不是安全团队一个部门的事运维应该在选型阶段就把它考虑进去否则后期补签名方案会非常痛苦。4.2 AI 模型和超大 artifact 会涌进镜像仓库镜像仓库的下一个变量是 AI 模型、数据集这类大体积 artifact。一个模型动不动几 GB 到几百 GB用 docker save 的方式硬塞镜像显然不现实。OCI Artifacts 规范允许在 registry 里存放非容器格式的 artifactORAS 这类客户端可以 push/pull 任意格式Harbor 和主流云厂商仓库都在往这个方向走。这个趋势对选型的影响很直接底层对象存储要能支持大对象、分片上传、断点续传否则模型文件传一半超时就只能从头再来。如果接下来一年你的团队打算把模型纳入版本管理最好现在就把这个需求写进评估维度宁可暂时用不上不要等到要用时发现仓库干不了。4.3 多集群、多区域让“分发”成为新重点当你的 K8s 集群从一个变成三个、五个镜像仓库立刻会变成带宽瓶颈。中心仓库只放在一个机房其他区域的节点每拉一次镜像都要跨机房慢不说流量费还贵。所以 2026 年的分发方案逐渐从“中心仓库各节点硬拉”转向“P2P 分发边缘缓存按区域同步”。选型时重点看方案是否支持 P2P 分发组件比如 Dragonfly 与 Harbor 的集成是否支持按项目做跨区域同步云托管仓库跨区域拉取流量怎么收费。这些指标前期不起眼等节点分布广了每个月光流量费都能超过镜像仓库本身的费用。4.4 托管服务正在变成“研发交付平台”镜像仓库的另一个变化是定位越来越不独立。云厂商正在把镜像仓库和代码托管、CI/CD、部署上料打通比如镜像构建完成自动触发部署、漏洞扫描结果自动阻断发布。Harbor 也在往企业级交付平台方向演进。用户不再只是管理镜像而是要一条从 commit 到 deploy 的可观测、可审计、自动化的交付链路。这意味着选型时不能只看仓库本身的功能还要看它能不能方便地接入现有平台API 是否完善、webhook 是否灵活、账号体系能否和 SSO 打通。一个孤立好用的镜像仓库和整个研发平台融不进去最后也会被换掉。5. 一次真实选型与迁移复盘从单机 registry 到 Harbor HA5.1 旧环境的问题去年底我接手的一个项目公司 20 多人研发团队镜像仓库是一台单机 4T 磁盘的 registry:2跑了两年。问题已经不只是慢所有人都知道 root 密码都能 push/pull 任何项目磁盘经常到 90%每次发版前都要手工删镜像CI 高峰期一次性几十个构建同时 push仓库响应越来越慢docker 镜像下载慢成了高频抱怨没有任何审计日志出问题根本不知道是谁干的。这个状态其实很典型。单机 registry:2 作为起步方案肯定够用但团队到了一定量级之后它缺的不是某一个功能而是权限、审计、高可用、容量管理这些底层能力。我们的目标很明确Harbor HA后端用 MinIO 对象存储前面挂 LB并把保留策略和签名校验都配置好。5.2 迁移路线数据不动 docker data 格式第一步盘点。用 skopeo ls 或 crane ls 把现有的项目、tag、镜像大小列出来确认哪些要保留、哪些可以清理。这一步花了一天实际效果是迁移的时候没有把几百 GB 垃圾镜像一起搬过去。第二步在目标环境搭好 Harbor HA项目结构和旧仓库尽量保持一致省得后面改 CI 脚本。第三步开始同步这里重点提示不要直接把 registry:2 的 data 目录挂给 Harbor 用两者的存储目录结构不兼容正确的做法是写一个循环脚本用 skopeo copy 从旧仓库拉镜像再推到新仓库。同步时先传、再校验 digest、再切流量顺序不能反。流量切换我用的是 DNS 和 LB 先切部分构建机做灰度CI 里验证全流程没问题后再把所有节点切过去。旧仓库保留只读状态不立刻销毁作为回滚保险。5.3 迁移过程中踩过的三个具体坑第一个坑是存储目录结构不兼容。我之前同事以为把 registry:2 的 /var/lib/registry 直接拷贝到 Harbor 后端就行结果 Harbor 起来之后项目列表是空的后来确认两部分结构差异太大白折腾了半天。用 skopeo copy 从旧仓库到新仓库才是正确思路以后遇到类似迁移直接走这一步。第二个坑是构建机凭证。切换前只改了 CI 上的凭证忽略了线下开发机上 Docker Desktop 里保存的还是旧仓库登录态第二天一堆人报 pull 失败。后来我们统一用机器人账号并写了个 credential helper让每台开发机从内部系统动态获取短期凭证这个问题才真正降下来。第三个坑是保留策略。Harbor 里配置清理策略时一开始按“创建时间超过 90 天”清理把一批没人更新但还在用的基础镜像删了后续重新拉取延迟很高内网缓存也失效了。换成“最近拉取时间超过 90 天”并给基础镜像项目加豁免规则之后这个坑才算填平。5.4 验证清单与回滚方案迁移后的验证清单我给四层。第一层 digest 校验抽几组镜像对比旧仓库和新仓库的 digest 是否一致。第二层 CI 全流程回归确认 docker build、docker push、docker compose 编排的集成环境拉起、发布和回滚链路都没问题。第三层并发压测模拟几十个并发拉取确认 Harbor HA 和后端 MinIO 的吞吐达标。第四层权限和审计验证确认不同角色的账号只能访问指定项目操作日志能正常记录。回滚方案一定要提前写出来。我的做法是旧仓库保持只读且不清理LB 和 DNS 随时可以切回旧地址。这里有个细节如果迁移后新仓库已经开始写入新镜像回滚时最好用 tag 匹配而不是盲目把整个域名切回去否则可能出现新镜像在新仓库、旧仓库只有老镜像的割裂状态。迁移期间保留干净的时间窗口能省很多麻烦。最后说点个人体会。我做选型不是找那个功能表上最全的方案而是找一个出了问题最多人能接手的方案。镜像仓库看似只是基础设施里的一颗螺丝但它一旦出问题影响面是整个研发和发布链路。把五大维度做成一张打分表结合团队现阶段的需求去匹配做完决策之后再按上面的迁移复盘来验证基本不会出大错。选型没有标准答案但有标准流程用好流程比纠结某一个指标重要得多。