harbor镜像复制通过同步manifest、image config、tag-to-digest映射和oci index等核心元数据，确保跨仓库版本一致、标签不漂移、多架构镜像可拉取；其geo-replication机制强制校验签名、比对层摘要、全量更新关键元数据并自动验证响应，规避docker tag重打标、漏传manifest、跳过证书验证等导致元数据丢失的风险。
元数据同步不是简单复制镜像层，而是让目标仓库准确理解并复现源仓库中镜像的版本关系、标签指向、摘要绑定和依赖结构。只有元数据对齐，跨域共享才不会出现“能拉到镜像但跑不起来”或“同名标签实际内容不同”的问题。
元数据同步的核心对象
真正需要同步的元数据包括：
- Manifest 文件：描述镜像完整结构（含 layers 列表、配置文件 digest、架构平台信息），是版本一致性的权威依据
- Image Config（config blob）：记录 ENV、CMD、WORKDIR 等运行时元数据，影响容器行为
-
Tag-to-Digest 映射关系：确保
app:v1.2在两地始终指向同一个不可变 digest，防止标签漂移 - OCI Index（多架构镜像）：当镜像支持 arm64/amd64 时，index.json 必须完整同步，否则跨平台拉取失败
用 skopeo 实现带元数据校验的同步
skopeo copy 默认同步完整元数据，且在传输后自动校验 manifest 和 layer digest，比 docker pull+tag+push 更可靠：
skopeo copy \ --src-creds user:pass \ --dest-creds user:pass \ --all \ docker://registry-a.example.com/app:prod-v2.3 \ docker://registry-b.example.com/app:prod-v2.3
关键点：
-
--all确保 multi-arch index 及其所有子 manifest 全量同步 - 跳过本地解压，直接流式传输元数据+层，避免 docker daemon 干预导致的 config 重写
- 目标端收到的 manifest 中
config.digest和layers[n].digest与源端完全一致
Harbor 复制策略如何保障元数据一致性
Harbor 的 Geo-Replication 在元数据层面做了三重保障：
- 同步时强制校验源 manifest 的 signature（如启用 Notary），拒绝篡改过的元数据
- 对每个 layer 比对 size + digest，仅传输缺失或不匹配的层，但 manifest 和 config 总是全量更新
- 复制完成后自动调用
GET /v2/<repo>/manifests/<tag></tag></repo>验证目标端返回的 manifest 是否包含全部预期字段（如mediaType,platform）
规避元数据丢失的常见陷阱
以下操作会破坏元数据完整性，应避免：
- 用
docker tag重新打标后再 push：新 manifest 的created时间、author字段被重写，config digest 变更 - 通过 registry HTTP API 直接上传 layer blob 却漏传 manifest：目标仓库有层无索引，镜像不可用
- 跨 registry 同步时禁用 TLS 或跳过证书验证：中间人可能替换 manifest 内容而不被发现
- 使用不兼容 OCI 的旧版 registry（如 v2.2 以下）：无法正确解析 index.json 或 platform 字段
