如何构建Docker镜像仓库的高可用性，避免单点故障导致服务中断？

本文共计546个文字，预计阅读时间需要3分钟。

要防止单点故障导致镜像仓库停服，核心思路是解耦存储、分离服务、多实例负载、统一状态管理。高可用并非简单起多个Registry容器，而是让关键组件（镜像存储、元数据、认证、前端访问）各自具备冗余能力。

一、存储层必须独立且高可用

镜像数据不能存在单台机器的本地目录里，否则节点宕机即丢失数据。 - 推荐使用分布式文件系统：CephFS、NFS HA集群、或云厂商提供的共享存储（如AWS EBS with Multi-Attach、阿里云NAS高可用版） - Harbor部署时，将`/data`挂载点指向共享存储路径，所有Harbor实例读写同一份镜像数据 - 避免用Docker Registry原生的本地文件存储模式（`filesystem` driver），它天生不支持多写

二、服务层部署多实例+反向代理

Registry或Harbor本身无状态（除部分缓存），可横向扩展： - 启动≥2个Harbor实例（core + portal + jobservice等容器组），运行在不同物理机或可用区 - 前置Nginx或HAProxy做七层负载均衡，健康检查端点设为`/api/v2.0/ping`（Harbor）或`/v2/`（Registry） - 所有实例共用同一个外部数据库（PostgreSQL/MySQL主从）和Redis（用于会话与任务队列）

三、关键依赖组件也要高可用

Harbor依赖的后端服务若单点，整个仓库仍会瘫痪： - 数据库：用主从复制+自动故障转移（如Patroni + PostgreSQL，或MySQL Group Replication） - Redis：启用Redis Sentinel或Redis Cluster，避免jobservice任务丢失、登录会话失效 - Notary签名服务（如启用）：同样需多实例+共享MySQL存储，并通过负载均衡暴露4443端口

四、客户端配置容错与自动回退

即使服务端高可用，客户端也要减少对单一入口的强依赖： - 在`/etc/docker/daemon.json`中配置多个`insecure-registries`（仅测试环境）或多个`registry-mirrors`（生产建议用HTTPS） - 使用DNS轮询（如`harbor.example.com`解析为多个VIP）配合keepalived实现VIP漂移 - CI/CD脚本中加入重试逻辑：`docker push`失败后延迟重试，或切换备用仓库地址

不复杂但容易忽略。