harbor高可用docker部署需拆分组件并依赖外部服务：用postgresql集群替代内置db，redis集群替代内置缓存，s3/minio替代本地存储，多实例共用后端且配置一致shared_secret与统一jobservice调度。
使用Docker容器部署Harbor高可用镜像仓库，核心在于避免单点故障，关键不是只跑一个Harbor实例，而是将组件拆分、独立部署，并借助外部服务实现冗余。官方推荐的高可用方案实际基于Kubernetes（如Helm Chart），但若坚持用Docker容器（即Docker Compose方式），需手动解耦并替换默认依赖组件。
拆分Harbor核心组件，脱离内置单体结构
Harbor默认的docker-compose.yml把所有服务（nginx、core、registry、postgresql、redis等）绑在一起，无法横向扩展。高可用第一步是剥离有状态组件，改用外部托管：
- 数据库：不使用内置PostgreSQL容器，换成独立部署的PostgreSQL集群（如主从+Patroni或云数据库RDS），确保元数据持久且可故障转移
- 缓存：不使用内置Redis，接入高可用Redis集群（如Redis Sentinel或Cluster模式），供core和jobservice共享会话与锁
- 镜像存储：不使用本地文件系统，配置为S3、MinIO（多节点部署）、Azure Blob或腾讯云COS等对象存储，天然支持多实例并发读写
- 日志与审计：将harbor-core和harbor-jobservice的日志输出到stdout，并用Filebeat+ELK或Loki收集，避免日志丢失
部署多个Harbor实例，前端用负载均衡分流
每个Harbor实例（docker-compose部署）保持无状态——即不挂载本地config、不运行postgres/redis，只保留nginx、core、registry、portal、jobservice、clair/trivy（按需）。多个实例共用同一套外部数据库、缓存和对象存储：
- 准备两台及以上服务器，各自拉取Harbor离线安装包（如harbor-offline-installer-v2.11.0.tgz），解压后修改harbor.yml
- 在harbor.yml中关闭
database和redis块，填入外部地址；storage设为s3或minio，配置AK/SK和endpoint - 为每个实例分配唯一
hostname（如hub-a.example.com、hub-b.example.com），并在负载均衡器（Nginx、HAProxy或云LB）上做TCP 443/80转发，启用会话保持（基于cookie或IP hash） - 执行
./install.sh --with-notary --with-trivy生成配置，再用docker-compose up -d启动
配置共享会话与任务协调机制
多个Harbor实例必须协同工作，否则会出现UI登录失效、扫描任务重复或失败等问题：
- 确保所有实例的
shared_secret（在harbor.yml中）完全一致，用于JWT token签名验证 - jobservice依赖Redis做分布式锁和任务队列，必须指向同一个Redis集群，并确认
redis://:password@redis-ha:6379/2等地址在各实例配置中统一 - 关闭任一实例的
jobservice自动启停逻辑（通过job_config中设置max_job_workers: 0仅保留core处理轻量任务），集中由指定实例或K8s Job调度器管理重载任务 - 定期检查
core日志中redis connection established和database connected是否稳定，避免因网络抖动导致实例“假死”
验证与日常运维要点
部署完成后不能只测网页能否打开，要覆盖真实协作场景：
- 从不同客户端（机器A推镜像、机器B拉镜像）同时操作，观察是否都命中同一份镜像层（对比
sha256摘要） - 手动停掉一台Harbor宿主机，确认push/pull/scan/login等操作在30秒内自动切到另一台，且Web界面无报错弹窗
- 在PostgreSQL主库执行
SELECT * FROM project;，在Redis执行KEYS "harbor_job_*"，验证数据实时可见性 - 备份策略聚焦外部依赖：每天全量备份PostgreSQL，每小时增量同步MinIO桶，Harbor自身配置目录（
/config）只需保留一份即可
