基于 Harbor 和 Registry 的镜像管理分发方案

1. Harbor 跨区带来的挑战

如果只是简单的存放镜像数据， Registry 作为镜像仓库会是一个很好的选择。Registry 不仅支持多种存储后端，还可以配置 HTTPS 证书，访问凭证。值得一题的是，Harbor 也是使用 Registry 存储镜像数据。

如果团队需要进行角色管理，存储控制，对接 LDAP 认证等功能，可以使用 Harbor。只需要一台 4C8GB 的机器，外置高可用 PGSQL、对象存储，就足够支撑数十个 Kubernetes 集群、数百个 VM 节点，打通 CI、CD 镜像交付流程。

通过堆砌内存、CPU 等资源，单实例的 Harbor 也足够支撑上百集群、数千节点。另一个重要的优化点是，当后端采用 Obs 等对象存储时，上传和下载镜像层数据将会直接请求对象存储桶，而不会给 Harbor 造成过大的流量负担。受益于对象存储的全球加速，上下行速度很容易达到 200+ Mbps，甚至 1Gbps 的带宽。

但也仅限于此，Harbor 只适合单区，而不能满足跨区场景下的镜像管理。如下图，当服务需要部署在多个区域，区域与区域之间通过公网互联，一旦区域网络被所在国家管制、处于不稳定状态，Harbor 在这种场景下就会束手无策。

同时，低效的 Harbor 任务队列，让多 Harbor 同步方案失去了实效性。一个区域推送完，另外一个区域需要等待十几个小时才可能同步完成，应用才允许更新。这是无法容忍的，参考: harbor-的一些问题。

在多区域场景下，单实例 Harbor 不能够支撑全区的镜像流量需求。一方面是跨区的网络不够稳定、流量费用高，另一方面还在于扩展性，IT 基础设施不支持不停地增加区域，所有负载拉取同一个 Harbor 不可靠。

2. 为什么不采用 Dragonfly 等分发方案

2.1 Dragonfly 简介

Dragonfly 是很多人所推荐的镜像分发工具，但是我没有找到符合场景的案例。

Dragonfly 的文档结构并不算很清晰，我理解的 Dragonfly 可以分成两部分:

Dfdaemon

Dfdaemon 与 Docker 官方 Registry 的 Mirror 功能类似，用来代理镜像层流量。这一部分是可以单独使用的，并不依赖于其他组件。

分发网络

分发网络是 Dragonfly 的核心功能，V1 版的组件是 Supernode，V2 版的组件是 Scheduler、Manager 等。类似于我们使用 P2P 工具下载大文件，Dragonfly 构建了一个专门给镜像加速的内部网络。而这个分发网络的下载客户端就是 Dfclient，也叫 Dfdaemon 。

2.2 使用 Mirror 加速镜像的原理

由于 Dragonfly V1 和绝大多数网上的文章都是通过配置 Mirror 加速镜像下载。在聊 Dragonfly 的问题之前，我们先说下 Docker Mirror 加速的原理。

通过查阅源码，可以得到如下片段：

func (s *DefaultService) lookupV2Endpoints(hostname string) (endpoints []APIEndpoint, err error) {
	tlsConfig := tlsconfig.ServerDefault()
	if hostname == DefaultNamespace || hostname == IndexHostname {
		for _, mirror := range s.config.Mirrors {
			endpoints = append(endpoints, APIEndpoint{
				URL:          mirrorURL,
				Version:      APIVersion2,
				Mirror:       true,
				TrimHostname: true,
				TLSConfig:    mirrorTLSConfig,
			})
		}
		endpoints = append(endpoints, APIEndpoint{
			URL:          DefaultV2Registry,
			Version:      APIVersion2,
			Official:     true,
			TrimHostname: true,
			TLSConfig:    tlsConfig,
		})
	}

地址: https://github.com/docker/docker-ce/blob/8bb27fc680463da975f386e3a325fe4d52b05f8e/components/engine/registry/service_v2.go

这里的 DefaultNamespace = "docker.io"、IndexHostname = "index.docker.io"，意味着 Mirror 实际上只对 Docker 官方提供的镜像生效。

而这种特性在 Docker 官方文档中，也给出了明确说明 It’s currently not possible to mirror another private registry. Only the central Hub can be mirrored.，参考: https://docs.docker.com/registry/recipes/mirror/ 。

在 https://github.com/distribution/distribution/issues/1483 中，开发者对这一特性进行了补充说明，私有仓库不能使用 Mirror 的原因在于: 私有仓库源将导致本地命名空间冲突、镜像管理上的混乱，因此仅限于单一的官方 docker.io 仓库镜像，不能对私有仓库进行加速。

2.3 配置代理才能利用 Dragonfly V2 加速私有镜像

加速的困境

由于 Mirror 只能加速 Docker 官方镜像，这与私有镜像仓库的场景不符。让人困惑的是，为什么网上那么多文章都是通过 Mirror 这种方式进行加速，竟然还能配合 Harbor 私有仓库使用。

如果仅仅只是加速 Docker 官方镜像层数据，那么加速的效果就会大打折扣。由于采用分阶段构建，业务的运行时采用 docker.io 上的 alpine 基础镜像，通常只有几到几十 MB。而业务相关的依赖包、二进制、图片、JS、CSS、Jar、WASM 包占整个镜像数据很大比例。

正确的加速方式是配置代理

在 Dragonfly V2 官方文档针对不同的运行时，给出了加速方案，但针对私有仓库时，并不是通过配置 Mirror，而是给 Docker 配置 HTTP_PROXY、HTTPS_PROXY。

除非在安装 Containerd 时就已经配置好 HTTPS_PROXY，我想没人愿意冒着风险直接线上修改。何况还不一定开启了 Live Restore 特性，而这一特性对 Containerd 版本也有要求。

3. 其实也能通过 Mirror 加速私有镜像

前面说过不能通过配置 Mirror 加速私有镜像。但经过思考，我还是找到了一种可行的方案。虽然并没有被真实采用，还是写下来以供大家参考。

3.1 思路

无论是 docker.io 还是 Harbor 搭建的私有镜像仓库，都遵循同一套接口规范。这给我们通过修改 DNS 记录，将私有镜像仓库的流量切换到 docker.io 域名下提供了可能。

3.2 具体步骤

假设内网的镜像仓库名为 private.chenshaowen.com，IP 地址为 1.2.3.4。

第一步，在业务所在内网，添加 DNS 记录将 docker.io 指向 1.2.3.4

第二步，切换镜像服务指向为 docker.io。

完整的镜像名是 private.chenshaowen.com/project/biz:v1 ，实际上如果添加了等价域名之后，我们还可以使用 private-peer-a.chenshaowen.com/project/biz:v1、private-peer-b.chenshaowen.com/project/biz:v1 拉取。镜像格式中的域名只是指示服务，服务的域名是可以随意更换的，只需要重新认证鉴权，并不会影响镜像的推送和拉取。

由于 private.chenshaowen.com 和 docker.io 指向的都是 1.2.3.4，因此我们可以使用 docker.io/project/biz:v1 替换 private.chenshaowen.com/project/biz:v1。

如上图，部署业务应用时，虽然使用的是 docker.io 镜像，但是却是向私有仓库请求镜像数据。但这并没有加速的效果，因此需要使用 Dragonfly 等服务进行加速分发才会起作用。

3.3 Insecure Registry 问题

由于没有 docker.io 的 HTTPS 证书，在内网，我们并不能简单的通过修改 docker.io 的 DNS 记录实现无缝切换。这里提供两个思路，在此不详细展开:

添加 docker.io 到 Insecure Registry 列表
添加根证书到主机，然后利用根证书自签 docker.io 域名的 HTTPS 证书。

3.4 要不要劫持 docker.io 加速镜像拉取

得看是否具备实施条件。

如果具备对基础设施，包括根证书、容器配置具有很强控制力，还是可以考虑的。原因在于，镜像服务也是基础服务，劫持 docker.io 也能增强对基础设施的管控水平，有助于提供镜像周边的增值服务。

否则，为了镜像加速破坏了开发、运维人员对 docker.io 的认知，会得不偿失。

这也引出了下面对其他方案的探索。

4. 使用 Registry 进行镜像分发

4.1 Registry 不为人知的功能

一般程序员可能只是知道 Registry 可以作为镜像仓库，实际上 Registry 有三种用法：

镜像仓库
Mirror 加速 docker.io 上的镜像
Proxy 转发拉取镜像请求，与 Mirror 类似，但使用方式完全不同。

下面简单介绍一下 Proxy 功能：

搭建的方式和 Mirror 一样，参考: 如何搭建一个私有的镜像仓库 mirror

但在使用时，并不是配置 "registry-mirrors": ["http://registry_ip:5000"]，而是 "insecure-registries": ["http://registry_ip:5000"]。

此时，我们可以通过 docker pull registry_ip:5000/shaowenchen/docker-robotframework:latest 拉取 docker.io/shaowenchen/docker-robotframework:latest 镜像。

经过我的测试，这里有几个关键点给出：

如果 docker.io 上的镜像更新了，拉取 Registry 时也会得到最新的镜像
连不上 docker.io，不影响 Registry 提供已经缓存的镜像拉取功能
支持拉取 docker.io 上的私有镜像
支持拉取 registry_ip:5000 认证鉴权
本地会缓存镜像，重复拉取会加速

4.2 镜像加速架构

业务的服务分布在国内、新加坡、日本、印度等很多区域，但是研发在国内，我们的镜像管理平面在国内 Harbor 上，对其他区域主要是对镜像进行分发。

如上图，核心组件包括两部分：

Harbor，部署在国内。开发人员利用 CICD 平台将镜像推送到 Harbor 统一管理
Registry，每个业务服务所在的区域都需要部署。当 Kubernetes 运行第一个 Pod 副本时，Registry 会通过公网拉取国内 Harbor 的镜像，缓存到当前区域的 Registry。当运行第二个副本时，将直接从 Registry 通过区域 VPC 内网直接拉取镜像，以达到加速的目的。

4.3 关于 DNS 的配置

如果能直接修改每个区域的 DNS 记录当然最好，否则需要通过添加 /etc/hosts 记录的方式实现。

研发环境下，镜像仓库指向的是 Harbor
部署环境下，镜像仓库指向的是 Registry

4.4 关于凭证

由于 Registry 并不能代理鉴权，这里会有两套凭证体系。

研发环境下，使用 Harbor 凭证，可以根据角色自定义
部署环境下，使用 Registry 凭证，全局拉取，不能推送

4.5 快速新增 Registry Proxy

这里简单贴一些配置，以便大家测试。

生成凭证

mkdir auth
docker run \
  --entrypoint htpasswd \
  httpd:2 -Bbn global-read xxxxxx > auth/htpasswd

创建配置文件

这里以本地磁盘存储作为实例，但采用对象存储的后端能提供更快的网络访问，特别是跨区域场景下。

version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
proxy:
  remoteurl: https://private.chenshaowen.com
  username: [username]
  password: [password]

运行代理

mkdir /proxy
docker run -d -p 8001:5000 --restart=always --name proxy \
             --add-host=private.chenshaowen.com:1.2.3.4 \
             -v `pwd`/auth:/auth \
             -e "REGISTRY_AUTH=htpasswd" \
             -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
             -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
             -v `pwd`/config.yml:/etc/docker/registry/config.yml \
             -v /proxy:/var/lib/registry \
             registry:2

5. 总结

本文主要思考的是在弱互联环境下，多区域业务如何管理和分发镜像。

否定了多 Harbor 同步方案，否定了 Dragonfly 分发方案，最终借助于不为人知的 Registry 代理模式，配合 DNS 解析，解决了镜像分发问题。

如果分发不是问题，那么单一的 Harbor 管理平面足够。

虽然 Registry 实现的代理满足目前的功能，但其不能转发鉴权、不支持多后端多点传输、不能级联组网，依然具有很大优化空间。

另一个好处是能水平扩展，可以在新的区域迅速提供镜像服务，支持业务快速开区。

推荐订阅源

陈少文的网站