Docker基础教程（232）私有仓库之设置反代理：别再让Docker镜像“裸奔”了！手把手教你用反向代理为私有仓库穿上“黄金圣衣”

深度分析Docker私有仓库之设置反代理，并附完整示例

一、 引子：从“深宫后院”到“五星级门童”

如果你已经开始使用Docker私有仓库（Registry），恭喜你，你已经迈出了容器化运维的关键一步。但通常情况下，我们搭建私有仓库的方式简单又粗暴：docker run -d -p 5000:5000 --name registry registry:2。然后，你的宝贵镜像就通过 http://你的服务器IP:5000 这个地址对外服务了。

这像什么？这好比把你公司最核心的技术资产——比如源代码、设计图——放在一个没有任何门牌号、只用粉笔写了“东西在这儿”的破旧仓库里。任何人都可能摸进来，通信内容完全是明文传输（如果没用HTTPS），毫无安全和专业性可言。

而反向代理（Reverse Proxy），就是为你这个“破旧仓库”聘请的一位“五星级门童”。它站在仓库前面，拥有一个尊贵的域名（如 registry.your-company.com），负责接待所有外来请求。它能够：

1. 隐藏真实端口：外部只知门童，不知仓库具体在哪间房。
2. 提供HTTPS加密：为所有通信穿上SSL/TLS的“防窃听铠甲”。
3. 实现负载均衡：一个门童忙不过来？多请几个分担流量。
4. 添加高级认证：在Docker仓库自带的认证之外，再加一道“门禁系统”。
5. 简化客户端配置：客户端再也不需要记丑陋的IP和端口，只需记住优雅的域名。

接下来，我们就来深度剖析如何为这位“门童”进行上岗培训。

二、 核心原理：反向代理如何与Docker仓库“握手”

Docker Registry默认的API是遵循RESTful规范的。反向代理（如Nginx）的核心工作，就是正确地将客户端的请求转发给后端的Registry容器，并把Registry的响应原路返回。

关键点在于理解请求路径。Docker客户端与Registry交互的主要接口是 /v2/。因此，我们的反向代理规则需要清晰地定义：所有指向 registry.your-company.com 且路径以 /v2/ 开头的请求，统统转发给后台真正的Registry服务。

这个过程可以简单概括为：
客户端请求 -> DNS解析至Nginx服务器 -> Nginx根据配置规则匹配 /v2/ -> Nginx将请求转发至 localhost:5000 (Registry容器) -> Registry处理请求并返回响应 -> Nginx将响应返回给客户端。

三、 实战演练：从零搭建一个安全的私有仓库门户

环境准备：