Docker基础教程（226）Docker Registry API介绍：别再用Docker Hub瞎逛了！解锁Registry API：你的私有镜像库「魔法操作手册」

引言：从“用户”到“管理员”的蜕变

想象一下，Docker Registry（镜像仓库）就像一个巨大的、管理严格的超级图书馆。平时，我们作为普通读者（开发者），只需要使用docker pull（借书）和docker push（还书）这两条简单的指令就够了，非常方便。

但有一天，你被任命为这个图书馆的管理员。这时你会发现，光会借书还书远远不够。你需要回答以下问题：

• “我们图书馆里到底有哪些书（镜像）？”
• “《哈利波特》系列（一个镜像的所有标签）具体有哪些版本？”
• “那本最厚的《辞海》（某个镜像的某个标签）详细信息和唯一编号（Manifest摘要）是什么？”
• “有些破旧的老书（过期镜像）需要清理掉以节省空间，怎么安全地销毁？”

docker 命令行工具对这些高级管理问题显得力不从心。这时，我们就需要直接与图书馆的“中央管理系统”——也就是 Docker Registry API —— 进行对话。这本「魔法操作手册」将为你揭示所有秘密。

第一幕：敲门砖——理解认证（Authentication）

直接敲Registry的门，它很可能对你say no。因为大多数私有仓库都需要身份验证。这就像一个需要门禁卡的图书馆。

Registry API采用了一种标准的、基于Bearer Token的认证流程。整个过程有点像去高级俱乐部：

1. 初次尝试（不带请柬）：你直接请求一个受保护的资源（比如列出镜像）。
2. 被保安拦下（401 Unauthorized）：Registry回复：“嘿，小子，你想干啥？出示你的身份证明！”并在响应头里告诉你去哪里认证（WWW-Authenticate header）。
3. 去服务台验明正身（获取Token）：你带着你的用户名和密码（或证书），按照保安指示的地址（认证服务URL）去获取一个临时的“通行证”（Bearer Token）。
4. 持证入场（携带Token请求）：你拿着这个Token，再次向Registry发起最初的请求，这次就能顺利通过了。

示例：我们用cURL来模拟这个过程

假设我们的私有Registry地址是 my-registry.com:5000。

# 1. 尝试直接访问，会被拒绝
curl -i https://my-registry.com:5000/v2/_catalog

# 你会收到一个类似这样的401响应：
# HTTP/1.1 401 Unauthorized
# WWW-Authenticate: Bearer realm="https://my-registry.com:5000/auth",service="my-registry.com:5000"

# 2. 根据realm和service信息，去认证服务器获取Token
# 这里需要你的用户名(username)和密码(password)
TOKEN=$(curl -s -u username:password "https://my-registry.com:5000/auth?service=my-registry.com:5000&scope=registry:catalog:*" | jq -r .token)

# 解释一下参数：
# -u username:password: 你的凭据
# service: 和WWW-Authenticate头里的一样
# scope: 定义Token的权