Harbor 2.1发布，工程师的发际线有救了！

开源云原生制品仓库 Harbor 2.1 上周正式发布了！2.1版本增加了好几项新功能，给镜像管理带来很大的便利和提高了效率，可以挽救不少运维工程师的发际线了：

• 镜像的代理和缓存
• 非阻塞的镜像垃圾回收
• P2P镜像分发的预热
• 机器学习模型的管理
• Sysdig镜像扫描器

镜像代理

先说说用户关心已久的镜像代理问题，这个问题可能要追溯到 Docker Registry 刚发布的时候。在很多客户的环境下，机器都不能访问外部互联网，或者访问互联网络的带宽有限，同时有大量的容器镜像需要从外部下载，如果每次开发、测试、部署时都需要从互联网下载容器镜像，则将占用大量的带宽而且效率较低。同时，在某些场景如物联网场景中，需要使用移动网络接入互联网，这时带宽可能是系统部署的瓶颈。更为严重的问题是，有些公有云容器镜像服务（如Docker Hub见下表）对客户端有限流设置，当镜像拉取操作达到一定流量时，会导致服务无法使用。

Docker Hub最新免费服务条款（11月1日生效），付费用户不受此限制：

匿名用户，每 6 小时只允许 pull 100 次

登录用户，每 6 小时只允许 pull 200 次

通过镜像代理服务可以解决上面的问题：当内网客户端需要拉取镜像时，镜像代理可代为到外网拉取镜像（镜像代理服务器需要连通外网），然后返回镜像给内网客户端。同时，代理可以缓存镜像，供后续内部网络拉取时使用。容器镜像代理目前常见的方法有开源项目“docker/distribution”的实现。这种方法需要设置mirror-registry （镜子镜像仓库），并且以proxy的配置启动一个“docker/distribution”的容器，配置好要代理的账户名和密码。这种方案用起来比较复杂，而且只能代理 Docker Hub 的镜像。这个方案还有一个明显的不足，即一旦 docker/distribution 被设置为缓存代理模式，将无法提供其他镜像管理功能，只能是个具有缓存功能的代理。Harbor 项目组一直对此问题“铭记在心”，只是囿于 docker/distribution 的限制，无法提供代理能力。

在 Harbor 2.0 中对架构做了较大重构，绝大部分镜像元数据由 Harbor 直接管理，为解决上述问题带来了曙光。Harbor 2.1 增加了一种项目（project）类型——代理项目，系统管理员可以新建一个代理项目，如 dockerhub_proxy，并且关联到要代理的镜像仓库，如 Docker Hub 的某个镜像库。在代理项目新建好之后，用户只要有权限访问这个代理项目，就可以通过这个代理拉取Docker Hub的容器镜像。配置界面如下：

如果用户需要拉取Docker Hub上面的“myproject/hello-world:latest”镜像，则首先需要登录 Harbor，再运行“docker pull”命令：

$ docker login harbor.example.com

$ docker pull harbor.example.com/dockerhub_proxy/myproject/hello-world:latest

这样就可以通过代理把镜像拉取到本地了。在 Harbor 上缓存了这个镜像，下次同样的请求发到 Harbor 服务时，不通过外部网络就可以直接返回本地缓存的镜像。在 Harbor 上可以看到，“hello-world:latest”镜像被缓存在 dockerhub_proxy 项目的下的“myproject/hello-world:latest”镜像库中。在使用缓存响应请求时，Harbor都会先检查源镜像库是否有更新，如果有更新，则本地缓存镜像失效，需要重新从源镜像库拉取镜像。

Harbor 原有的基于项目的功能，如权限控制、镜像保存策略、配额、CVE白名单，都可以继续使用。如果需要只保存7天内访问过的容器镜像，则只需设置一个镜像保存策略，将超过7天没有访问的缓存镜像删除即可。

总而言之，使用镜像代理功能可以帮助用户节约有限的外网带宽资源，加快镜像获取的速度，同时最小限度地减少对用户既有拉取镜像方法的改动。

P2P镜像预热

接下来说说 P2P 镜像预热功能。在云原生领域，特别是在大规模集群场景中，如何可靠并高效地分发镜像是个需要重点关注的问题。镜像分发在本质上也是文件分发，因此和文件分发一样，随着容器集群规模的增大，从中心化的镜像仓库中拉取镜像会出现镜像分发效率低、镜像仓库负载大等问题，同时网络带宽容量可能成为分发瓶颈，并最终造成分发效率无法提升的结果，进而影响到容器应用或者服务的部署过程。

为了解决上述问题，很多项目在 P2P （点对点）内容分发技术基础之上实现了对镜像分发的加速，即 P2P 镜像分发，这是目前解决镜像分发行之有效的技术之一，也是 P2P 内容分发技术在镜像分发场景中的实际应用。比较有代表性的项目包括阿里巴巴贡献的 CNCF 托管开源项目 Dragonfly（蜻蜓）和 Ube r公司开源的Kraken（海妖）项目。

P2P 镜像分发项目的基本工作机制大致相同。要分发的镜像被分割为固定大小的数据分片来传输，各节点可以从不同的节点（Peer）并发地下载数据分片来组装成完整的镜像内容，这样有效地降低了对上游镜像仓库的请求负载，可就近获取所需内容，大大提升了分发效率。据 Dragonfly 官方文档的介绍，Dragonfly 的镜像分发机制能够提升镜像仓库的吞吐量，同时节省镜像仓库大部分的网络带宽。

Harbor 容器镜像仓库专注于镜像的管理和常规分发，并没有 P2P 相关的功能支持。Harbor 的 P2P 工作组提出了 P2P 镜像预热方案，即通过轻量级松耦合的方式，将 P2P 镜像分发引擎集成到 Harbor 中，并通过策略将满足预设条件的镜像提前下发到 P2P 网络中缓存起来，在节点请求到来时可直接开始 P2P 数据片分发过程，就像 P2P 网络之前已经分发过相同的内容一样，网络已经“热”起来了。

P2P预热的核心思路如下图所示。通过适配器接口将具有预热能力的P2P引擎（目前有 Dragonfly 和 Kraken ）集成到 Harbor 侧并由系统管理员统一管理，项目管理员可以在项目中创建一个或者多个预热策略。每个策略都针对一个目标P2P引擎实例，并通过镜像库（repository）过滤器和 Tag 过滤器确定要预热镜像的范围，同时可叠加更多的预设条件来确保只有满足特定要求的镜像才允许预热。策略可被设定为手动执行、定时周期性执行及基于特定事件的发生执行。

当策略执行时，通过其中的过滤器和预设条件可以得到所有满足条件的镜像列表，如果此列表不为空，则其中所含镜像的相关信息被发送给 P2P 引擎。P2P 引擎会在其 P2P 网络缓存中检查是否存在相关内容，如果不存在，则从Harbor拉取镜像并将其内容缓存到 P2P 网络中。这样 P2P 引擎在之后响应镜像拉取请求时，可直接使用缓存的内容，减少等待延迟，进而提升整体的镜像分发效率。

镜像预热的一个直接使用场景是：在 CI 系统构建出应用镜像后，Harbor能及时地将满足条件的“已就绪”镜像发送到 P2P 网络中，这样应用就可以快速部署出来。

P2P预热功能已经在 Harbor 2.1中推出，主要实现工作由 VMware、腾讯、网易云、灵雀云、阿里巴巴 Dragonfly 及 Uber 的贡献者负责。

Harbor 2.1 还有其他给工程师的“护发”功能，例如，之前文章介绍过的机器学习模型管理，利用 OCI 制品的功能，镜像仓库秒变模型仓库，减少了不必要的组件。另一个运维法宝是非阻塞的镜像垃圾回收功能，在垃圾回收的时候，可以避免 Harbor 进入只读模式，满足生产系统不停机的需要。非阻塞的镜像垃圾回收将在下一期文章在给大家介绍细节。