自动化迁移需先确认仓库类型：Registry v2用/v2/_catalog分页查询，Docker Hub调单库API，Harbor需catalog全局权限及token；再执行查→拉→推三步链路，并注意证书、权限、凭据安全与超时重试。
通过 Docker 镜像仓库 API 实现自动化迁移，核心是绕过人工操作，用程序批量拉取、重打标签、推送至目标仓库。这不是简单“复制粘贴”，而是一套可复用、可监控的管道流程。
明确目标仓库类型再设计调用逻辑
不同仓库的 API 行为差异很大，必须先确认是标准 Registry v2、Docker Hub 还是 Harbor：
-
标准 Registry v2（如自建 registry）：唯一入口是
/v2/_catalog，但需手动分页（靠last参数）、Basic Auth 认证，并注意Content-Type: application/json； -
Docker Hub：不开放
_catalog，只能通过官方 APIhttps://hub.docker.com/v2/repositories/查单个仓库的 tag 列表，适合已知镜像名的场景；/ /tags/ -
Harbor：路径不是
/v2/_catalog，而是/api/v2.0/projects/{project}/repositories，且需 Harbor 用户 token（非 docker login 的 base64 auth），项目级 read 权限还不够，必须有 catalog 全局权限。
分三步完成自动化迁移链路
跳过中间存储，直接“查→拉→推”，减少磁盘压力和失败点：
-
查：获取源仓库所有镜像+tag 列表
写脚本循环调用 catalog 接口（Registry v2）或 Harbor 项目接口，解析返回的
repositories或name字段，拼出完整镜像名（如library/nginx:alpine）； -
拉：本地拉取并重打标签
对每个镜像执行：
docker pull $SRC_IMAGE && docker tag $SRC_IMAGE $DEST_REGISTRY/$IMAGE_NAME:$TAG； -
推：登录并推送至目标仓库
先
docker login -u $USER -p $PASS $DEST_REGISTRY，再docker push $DEST_REGISTRY/$IMAGE_NAME:$TAG；
关键细节决定是否真正“自动化”
很多脚本跑一半就卡住，往往栽在这些地方：
- 私有 registry 用自签名证书时，
curl或requests必须显式设verify=False，且重定向要打开（allow_redirects=True），否则跳转后丢掉 Authorization 头； - Harbor 返回空数组或 403，大概率是没开
registry: compatibility: schema1: false下的 catalog 开关，或用户缺少system级权限； - 不要把
docker login凭据硬编码进脚本，改用 GitHub Secrets、HashiCorp Vault 或环境变量注入； - 加超时与重试（如 curl -m 30 --retry 3），避免因网络抖动中断整批任务。
推荐用 Python + requests 实现可控流程
比纯 shell 更易处理 JSON、异常、分页和并发：
- 用
requests.Session()复用连接，提升批量请求效率； - 对 Harbor，先调
/service/token?service=harbor-registry&scope=registry%3Acatalog拿 registry token，再带入后续请求头； - 每推一个镜像后，用
curl -I $DEST_REGISTRY/v2/$PATH/manifests/$TAG验证 HTTP 200，才算真正落地。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
