Harbor复制策略是CI/CD中实现多云镜像自动同步与备份的核心机制，通过事件驱动模式将一次推送自动分发至阿里云ACR、华为云SWR等目标仓库，并配合skopeo备份、API校验、动态凭证注入及失败降级，确保同步可审计、可验证、可回滚。
在CI/CD中实现Docker镜像的多云仓库自动同步与备份，核心不是“推完再手动同步”，而是把同步动作嵌入构建流水线，让一次推送触发多地分发+本地归档，全程无人值守、可验证、可回滚。
用Harbor复制策略接管同步主干
这是最稳定、可审计的企业级做法。不要在CI脚本里写一堆docker tag + docker push，而是让CI只推一次到内部Harbor主库，其余由Harbor自动完成：
- 在CI最后一步执行：docker push harbor.internal/myapp/backend:v1.5.0（目标仅为你的中心Harbor）
- 提前在Harbor中配置好复制规则：源项目为
myapp/backend，目标分别为阿里云ACR、华为云SWR、AWS ECR等，每条规则启用event_based触发 - 设置过滤器，例如只同步
v[0-9]+\.[0-9]+\.[0-9]+格式的语义化版本标签，排除dev-*或debug类临时镜像 - 关闭“覆盖已存在镜像”选项，强制使用带哈希的tag（如
v1.5.0-sha256-9f3a），确保不可篡改
CI阶段同步+备份双落盘
同步给公有云是分发，备份是兜底。二者应在同一CI任务中完成，避免割裂：
- 在CI的
build-and-push阶段后，新增backup-and-verify作业： - 用
skopeo copy将刚推上去的镜像导出为tar包并上传至对象存储（如阿里云OSS）：skopeo copy docker://harbor.internal/myapp/backend:v1.5.0 oci-archive:/tmp/backend-v1.5.0.tarossutil cp /tmp/backend-v1.5.0.tar oss://myorg-backup/images/ - 同时调用Harbor API校验该镜像是否已在所有目标仓库就绪：
curl -s "https://harbor.internal/api/v2.0/projects/myapp/repositories/backend/artifacts?v1.5.0" | jq '.registry_status[].status' - 任一目标未同步成功，立即失败并告警，不进入部署阶段
用CI变量动态注入云平台凭证
不同云厂商的访问密钥不能硬编码，必须通过CI平台的密钥管理能力安全注入：
- 在GitLab CI中定义
ALIYUN_ACR_TOKEN、HUAWEI_SWR_PASSWORD等受保护变量，并绑定到对应环境分支 - Harbor目标仓库配置时，认证方式选“Token”，并在创建复制规则的API请求体中引用这些变量：
"access_key": "$ALIYUN_ACR_TOKEN" - 对于AWS ECR，可在CI中先运行
aws ecr get-login-password获取临时token，再传给Harbor目标配置
同步失败时自动降级与通知
网络抖动或临时限流可能导致某次同步延迟，但不能卡住整个发布流程：
- Harbor复制任务默认重试3次，超时时间设为600秒；失败后触发Webhook，向企业微信/钉钉发送含镜像名、目标地址、错误码的告警
- 同步失败不中断CI，但自动标记该版本为“待人工确认”，K8s Helm Chart中
image.pullPolicy设为IfNotPresent，优先拉取本地缓存层 - 每日凌晨跑补漏脚本：
find /backups -name "*v1.5.0*.tar" -mmin +1440 -exec skopeo copy {} docker://harbor-bj.myorg.com/... \;，覆盖弱网时段遗漏
