最新进展 | 才云基于 Harbor 的企业级镜像仓库高可用实践

2018 年 3 月 3 日，Caicloud 在 Kubernetes Meetup 上以《基于 Harbor 的企业级镜像仓库高可用实践》为主题进行演讲，以下是现场回顾。

大家下午好，我来自才云科技，目前主要做的工作是持续集成持续发布，以及镜像仓库这一块。

Agenda

今天分享的主题是基于 Harbor 的企业级镜像仓库高可用实践，这个题目读起来有点绕，那么我们可以来划分一下关键词：

• 第一个关键词是 Harbor，还有企业级镜像仓库，这个是 Harbor 给它自己打的标签，后面就是高可用，简单来说就是我们如何基于 Harbor 搭建一个高可用的镜像仓库。这是今天要讲的主要内容。首先我们要了解一下 Harbor 是什么？可以用它做什么？还有一个就是 Harbor 的实现原理，它的架构是什么样子的？了解清楚架构之后，我们才能基于这个架构去设计出一个高可用的镜像仓库。

• 第二部分，我们会介绍才云自己的镜像仓库是怎么去设计的，在这样的设计基础上是如何实现高可用的。

• 第三部分，我们会介绍一下，在实践的过程中我们踩了哪些坑，是怎样解决的，对于后面大家有高可用需求的话，给出一些建议，以避免出现这些问题。

什么是 Harbor？

首先介绍下 Harbor 是什么？这是 Harbor 官方给自己的一个定义：即一个企业级的镜像仓库。从这个定义上来看的话，我们主要看两个关键词：

• 一个是 Docker images；

• 还有一个就是 Enterprise-class registry，这是企业级的镜像仓库。

Docker images

Docker images 大家应该是比较了解的。Docker 在这么短的时间内能火起来，主要是它为容器技术做了两个比较大的贡献：第一个贡献是 Docker images；第二个贡献是容器引擎。

Docker images 可以简单地认为是一堆文件系统，那么它做的事情就是把这些文件系统按照一定的规律去分层管理。

容器引擎就是把这些分层的 Docker images 启起来。采用 Copy-On-Write 的技术通过一个 image 可能启起来十个容器，底层的一些文件系统都是共用的。只有这个容器对它进行写的时候，它才会再额外地增加一层，这样的话这个容器写的内容就会被写到新的一层里面，那么它底层的一些文件是不受影响的，每一个容器都可以看到一个唯一的视角，而不会受其他容器的影响。

这样的设计理念能够充分复用镜像仓库的 layer 来减少镜像的大小，那么他的启动速度也是非常快的。由于这两个技术，整个 Docker images 相当于传统 VM 的一个 images ，他可能是非常非常小的，一个 images 可能最小的应该是几 K 就可以了吧；那么传统的 VM，你做一个 snapshot 最小可能是几百兆。还有另外一方面就是容器引擎，它启动一个 image 的速度是秒级的，甚至毫秒级的，然而你启一个 VM snapshot 至少是秒级的吧。

企业级镜像仓库

还有一个关键词就是企业级的镜像仓库。为什么 Harbor 是一个企业级的。其实相对来说 Docker images 和容器引擎这两个技术，Docker 还有自己的另外一个产品，就是 Docker registry，目前他更名为 Distribution。其实这个大家知道得比较少，因为它的使用门槛很高。它做的主要事情就是把这些 images 按照 blob 一层一层地存到文件系统里面，每一个 blob 的 name 都是一长串的数字，这数字是根据文件的内容算出来的；甚至它一些描述信息，也是通过 blob 的方式存起来的。然后它提供了一套比较完备的 API 供你去调用，你可以知道这里面有哪些 image 是你可以 pull 或者 push image 的。

真正在企业里面，是不可能什么操作都去调 API 来做这个事情的。那么 Harbor 的话，它做的事情就是说它在原生的一个 Docker registry 的基础上提供了下面这些 features。

Key Features

最大的一个 Feature 就是降低了使用门槛，提供了一个图形化的界面。你可以直接在界面上看有多少 image，有多少 tag，甚至说你可以看它的存储空间还有多少；占用了多少；是不是要对它进行扩充存储。原生的 Docker registry 相对于之前提供的两个功能，像 image 和容器引擎的话，它的使用门槛太高了。Docker image 和容器引擎还是基于底层的 LXC 技术，只是说把这个技术使用门槛降低了，所以才会这么快地普及起来。目前来看，绝大部分的企业或者用户选择的是 Harbor，而不是原生的 Docker registry。

Image Replication

Harbor 的另外一个特性就是 Image replication，这应该是 Harbor 比较早的一个功能。在 2016 年刚出来的时候就应该有这个 feature，这个 feature 的话对于某些用户来说是比较重要的。很常见的一个 case 就是，假设一个大型的互联网电商，他可能在北上广分别有三个 IDC。假设一个支付业务必须要部署在这三个 IDC 里面，才能够实现异地多活。假设广州的 IDC 因为地震或者什么不可抗拒因素垮了，它的业务在北京和上海这两个地方还是可以正常服务的。对于这种应用场景，应用的分发就成问题。一种解决方案就是，发布到一个 Harbor 中，三个地方都从这个 Harbor pull 镜像。这样就存在一个问题：假如这个 Harbor 挂掉了，那么我三个地方的 IDC 都不能正常地运行。

还有另外一个问题就是在 pull 镜像的时候存在一个速度的问题。因为网络延迟等原因，可能速度非常慢。使用 Harbor image replication 的话，我可以说搭建一个中央的 Harbor，然后在每一个 IDC 里面再配一个 Harbor。所有的业务发布到中央 Harbor 里面去，这个 Harbor 通过 image replication，把要发布的镜像同步到每一个 IDC 里面的 Harbor 里面去，那么每一个 IDC 它在部署应用的时候，直接使用自己这个环境里面的一个 Harbor。这样的话中央 Harbor 里面就有一个 image 的备份，然后每个 IDC 里面有自己的备份。如果任何一个地方坏了的话，整个服务是不受影响的，这是它这个特性的一个应用案例。

Access Control

原生的 Docker registry 其实是没有进行权限控制的，它只是提供了一个配置，可以配到你的 auth server 里面去；然后它再进行 pull 和 push 镜像的时候，去给你调这个 auth 的 API，去拿你的权限，决定你是否通过这个操作。但是 Harbor 这边的话，它提供了两种 auth 的机制：一种是它自己有 DB，那么你可以去注册用户和添加用户，也可以给用户去分配权限；第二种就是直接对接企业的 LDAP，所有的用户信息还是在公司原有的 LDAP 里面，它只是在进行一些操作的时候，去访问你 LDAP 里面的一些信息。

Operation Auditing

第四个，就是操作审计。在原生的 Docker registry 里面，你进行的任何操作其实是没有任何记录的。那么这个 image 是谁 push，什么时候 push 的这都不知道。如果说你把一个 base image 给覆盖掉了，里面引入很多问题的话，那么基于这个 base image 的一系列 image 可能都有问题，上线的话，影响是非常大的。这边 Harbor 提供了一个审计功能，你所有的操作都会有一个日志来记录，可以去追踪。

Image Vulnerability Scanning

第五个比较大的功能是 image 的镜像安全扫描，这个在社区呼声非常高。在 2016 年年底的时候，我就已经在做这个事情了，当时在上一家公司，我们做的是基于原生的 Docker registry。我们应该从 2015 年就开始定制 Docker registry，定制了很多丰富的功能，最后把这个也加进去了。那个时候 Harbor 还是零点几的版本，我们当时对比了一下，跟我们的功能差不多，就没有切换。那时我们把这一套做完了之后，第一个给 Harbor 提了集成 Clair 的 proposal。早期的一些原型的验证、设计我也参与了一下。

为什么大家会对 image 的 security 这么关注呢？我们可以对比一下，对于传统的一种运用方式，它部署了很多实例。宿主机上会有一些 security 的问题，在这些宿主机上 run 一些脚本，把这些问题都 fix 掉，下次再重新发布的时候这些问题就没有了，尤其是让一些 OS 或者依赖的 security 问题，那么用这种方式都可以很好解决。

但是对于镜像的话它是完全不一样的，如果说这个镜像里面 CentOS 有个漏洞，那么这个镜像在任何一个地方部署，漏洞也是一直存在的。即使说如果这个跑到镜像的 container 里面去，把这个问题 fix 掉了，但是这个容器一销毁，它的工作就是白做了。在另外一个地方再起来的话，还是存在相同的问题，并没有从源头上解决安全漏洞的问题。

那么如何解决呢？必须要重新打镜像，把这个镜像 security 问题解决了之后，再 push 到镜像仓库，然后基于这个新的 image，再去部署其他的运用。这样的话，其他的应用都不会存在这种安全问题。重新打镜像可能还需要开发或者是运维人员自己做，但是 Harbor 这边能够做的事情就是帮你扫描一遍，能够帮你在应用上线之前告诉你这个镜像是有安全问题的。

相对来说 Harbor 这些重要的 Feature 其实都是针对容器上生产、企业要去使用容器，镜像仓库需要必备的一些功能，那么原生的 Docker registry 是缺这些的。

还有比较重要的一点就是 Harbor 是一个开源项目，它主要是由 VM 中国去开发和维护的，目前已经有 3600 多个 stars，1600 多个 forks，其实这对于两年多的时间来说，已经算是一个不小的成绩，并且它跟其他的一些解决方案相比，是一个比较优秀的方案，后面的迭代速度和开发进展也会加快。我们待会儿会去跟进一下，我们在搭建镜像仓库的过程中，其实一直在换版本，以及为什么会换版本，每个版本里面大概有些什么新的功能进去。

Harbor 的实现原理和架构

Harbor 架构

接下来介绍下 Harbor 的实现原理，它的架构是什么样子的。

我们可以从这张图上看，其实是非常简单的架构：

• 第一，是一个 proxy。proxy 会把一些请求，像 Docker client 的 Docker pull/push 请求直接转发到 Docker registry；

• 第二，对于一些页面的请求它会转发到 Core services 这边，Core services 主要是由 UI 这个模块提供界面，还有就是做权限控制的 token，可以把这个 token 配到 registry 这边；registry 这边进行一个操作的时候，调 token 的接口来判断它的权限。

• 第三，是 webhook，是针对日志审计的。Docker registry 这边的一些 image 的操作它会去调 webhook，会通知说此时有个 image 被 pull 或 push 了，Core services 那边就可以把这些信息记录下来，然后存到 DB 里面去。DB 就是存储一些用户信息或者是镜像的，或者是日志的信息。

• 第四，是 Job services。Job services 之前的功能比较简单，它的作用主要就是镜像的复制。现在它有更多的功能，加了一个镜像安全扫描，还有一个就是内容可信认证。

• 第五，是日志收集。它其实是辅助的，把这些容器里面的日志收集起来然后落盘。从这里看 proxy 是个 Nginx。registry 是原生的，DB 就是 MySQL，那么它做的一个核心的工作主要是 Core services 和 Job services 这两块，这是它大概的一个架构，所以它的实现还是比较简单的。

Harbor 的高可用实践

后面我们会讲一下基于 Harbor 的高可用实践。在说高可用之前，我们先想一想，为什么我们要做高可用，一个 Harbor 为什么不行？

Docker 提出的口号就是 Build、 Ship 和 Run。

• 这里面一个非常关键的因素就是 image，是 image 把这三个阶段给串起来了。一个流水线，它可能 CI/CD 都做了，他最终流转下去了就是 image。那么假设你有一个 Harbor 挂掉了，那么你的 CI 流水线打出来的镜像，无法 push 到那个镜像仓库，流水线失败，后面的流程就不会走了。

• 如果镜像仓库挂掉了的话，也不存在 Ship，因为 image 不能在各个环境里面进行一个很好的流转，它不能从开发环境到测试环境，不能从测试环境到 staging 环境，甚至也不能上生产了，这也是一个问题。

• 还有就是最后的 run 这一步，如果你的镜像仓库挂掉了的话，你也 run 不起来，你可能去创建 container，它会一直尝试 pull image。

所以说基于这样的考虑，我们在使用容器云的时候，Harbor 的功能可以不用很复杂，很完善，但是在高可用这一块，企业的需求还是非常高的。基本上我们的客户，在介绍到这里就会问，你们能做到高可用吗？不能做高可用，我觉得就没有信心了。基于这样一个架构来做到高可用的话，我们应该从哪些方面考虑呢？

其实高可用说白了就是要多副本，避免单实例故障：

• 多副本的话我们可以考虑两个角度：第一个角度，服务的有状态和无状态。有状态的话可能要进行一些持久化，你可以挂 PV 或者一些网络存储进去。还有一个就是，对于一些有状态的服务，像 MySQL 这边，它自己提供了一个集群部署，那这块就不用考虑了，通过这个集群来保证这个组件的高可用。

• 对于无状态，简单的无状态你直接可以给他 scale 到三个或者四个实例；对于一些复杂的运用，像 Job services 这边，它最开始的设计只能起一个实例，如果说你起多个实例的话，那么中间进行同步的时候会出问题。这就是说它在架构设计上没有考虑到这一点，当然在这一块 Harbor 也在进行优化，在 v1.2 里面应该是解决了。但是它在 v1.2 里面引入了 Clair 镜像安全扫描，所以导致这一块只能单实例，但是它在 v1.4 里面就把这个问题解决了，所以这一块是它不能进行高可用的一个短板吧，他们一直在优化这一块。

刚刚我们罗列了一些高可用可以做的一些思路，是不是有状态、无状态。

• 有状态的话要挂盘，或者说用原生的一个集群来保证它的高可用；

• 那无状态的话，你要考虑是不是可以直接伸缩扩容，如果不能的话这个再另想办法。

这个是前面的一些 Harbor 的普及，然后也大概罗列了一下我们在做高可用的时候大致的方向，要考虑哪些因素。

才云：镜像仓库的高可用实践

下面我们讲一下才云在镜像仓库高可用方面，有哪些实践的经验可以参考和借鉴的，是如何去做高可用的。

镜像仓库：Cargo

才云做镜像仓库这一块是比较早的，在 2016 年底，2017 年初的时候就已经做了一个 Cargo v1.0 的版本，这个版本是基于 Harbor v0.4 的版本。当时 Harbor 还不够成熟，我们对它进行一个定制化去集成镜像安全扫描，及一些其他的功能。我们的镜像仓库叫 Cargo，跟原生的是区别开的。在这个演化的过程当中，Cargo 在不同的阶段实现的方式是不一样的。

Compass、 Cargo 与 Harbor

下面 Compass。Compass 就是我们的容器云产品，Cargo 属于我们容器云产品里面的一个组件。

在 2017 年 Q4 的时候，我们就做了一个 Cargo 的 v2.0 版本，当时是基于 Harbor v1.2 的版本做的。后来就有一些新的问题，整个功能趋势的改变。我们打算在今年年底的时候，打算做一个 Cargo 的 v3.0，v3.0 将至少是基于 Harbor v1.4+ 的，因为 Harborv1.4 是前段时间刚刚发布出来的，有比较多的改进，能够很好地解决我们现在 v2.0 里面的一些问题，这个待会儿会详细介绍。

刚刚提到了 Harbor、Cargo 还有 Compass，为了后面介绍方便，我们在介绍前先讲清楚他们之间的关系：

• Harbor 就是原生的 VM 开发的；

• Cargo 就是我们公司自己做的镜像仓库；

• Compass 就是我们的容器云产品，之前叫 CLaaS，后来改叫 Compass。包括这个形状跟 Kubernetes 其实有点类似，它们的作用也差不多：一个是罗盘，一个是舵手，都是去引导方向的。

我们现在介绍下，我们做的 Cargo v1.0。Cargo v1.0 其实就是一个定制化的 Harbor，在上面加了一个给 image 打标签功能。像有的 image 刚出来可能什么标签都没有，如果经过测试他可能会打一个 ready-for-test 标签；基于这样的标签，我们会对它进行过滤；过滤完了之后在可以把这些 ready-for-production 标记 image，然后这些才可以上生产。第二个功能是集成 Clair 做镜像安全扫描。还有一个就是说 Harbor 在初期 v0. 几的版本，在性能上面有很多的问题，我们对它进行比较多的优化。还有其他一些非常小的功能，这个就不详细展开了。

Cargo v1.0

这是我们之前分享过的当时 Cargo HA 的方案，由于它是基于 Harbor 做的，那么它的一个架构就跟之前 Harbor 是类似的。

这个 HA 是放在 Kubernetes 里面，通过 Kubernetes 的 Replication Controller 机制，来保证每个组件都有多副本。像 Nginx*3 有三个；Admin Server*3 有三个；但是 Replication Service 刚刚提到了，因为它设计上的问题导致它只有一个，多个实例的话会有问题。

Docker registry 分两部分。Docker registry 它自身的逻辑是支持高可用的，你可以三个副本是没有问题的，但是他在落盘的时候，需要去 shared storage，不然每一个 image 落的位置可能就不一样，存在数据不一致。当时的一个做法就是挂 PVC，然后通过共享存储。

数据库这一块的话，有人说直接给它起多个实例然后挂 PVC，会存在冲突问题。针对于数据库，它的解决方案跟 registry 不一样，它是不能挂 PVC 的，需要给它布一个 MySQL 的集群。部署方案网上有很多，如果你公司里面有现成的 MySQL 的集群，直接配置一下就可以了。

这下面是一些 references。当时我们公司有位同事把 Kubernetes 的这套部署 yaml 文件提交到 Harbor 中，但这是比较早的。现在社区也一直在维护这一套，当时用的 Replication Controller 已经换成了 deployment，还有对外暴露 IP 的话，现在已经使用 Ingress。有兴趣的同学可以去看一下。

我在 PPT 上还分享了一个 blog，介绍这一套是怎样去部署的。这是比较早的实现 HA 的一种方式。

当然这种方式存在一个问题，就是你要先在 Kubernetes 中利用把 Cargo 部署起来；部署起来之后我们再把一些平台组建的 image 放到这个 Cargo 里面去；然后再部署我们的容器云产品 Compass，这是一个部署的依赖关系，中间是不能打乱的。

Cargo v2.0

下面的话我们来介绍 Cargo v2.0。为什么会有 Cargo v2.0？因为在整个产品的迭代过程中，整个 Harbor 自身也在迭代。这个过程中 Harbor release v1.x，那么它在性能、可用性、功能上它觉得达到了一个非常稳定的版本。

还有就是 Harbor 已经原生支持 Clair，并额外再加 Notary。Clair 的实现原理大概可以介绍一下。镜像是分 layer 的，每次 push 一个 layer 上去，它就会把这 layer 信息记录下来，看你的是什么 OS 版本；装了哪些版本的软件。然后 Clair 那边自己维护了一个漏洞的 DB，这个 DB 会从各网站上实时同步一些漏洞信息来对比一下，看你这个 image 内容。假设你装了一个 Nginx，然后在 DB 里面检查这个版本的 Nginx 有没有漏洞，如果有漏洞会给你报出来；如果没有的话，这个 layer 就是没有问题，它就检测下一个 layer，大概是这样子的一个安全扫描的机制。

Notary 是内容的验证。这是两种 security 的维度，一种是判断 image 有没有安全漏洞；另外一个维度是保证你 pull 下来的 image 是不是官方发布的。就跟 MD5 一样防止有些人进行篡改。但是这个功能对于一些企业来说不是特别特别地重要，因为他们很多时候都是使用内网的，被篡改的概率还是偏小的。

以及，我们刚刚提到的先有 Kubernetes 才能部署 Harbor v1.0 的 HA。后来为了发布和部署方便我们将整个 Kubernetes 的组件也容器化了。我们整个的平台全部是微服务化的，大概有四五十个组件，加上 Kubernetes 和 EFK 等这些杂七杂八的开源组件可能就六七十个了。如果说都统一采用 image 的方式去发布和部署的话，这样就非常简单了。用 image 的方式另外一个考虑就是，它的监控、告警、日志都可以使用平台现有的。如果说你在虚拟机上自己起一个 apiserver，那么你是不是要装一个传统的 Zabbix 判断你这个 apiserver 是不是正常 work 的。所以出于这样的考虑我们就决定将 Kubernetes 的组件容器化了。

那么容器化了之后，就引入到一个哲学问题了，是先有鸡还是先有蛋？容器化之后你首先要有一个镜像仓库去把 image 存起来，再部署 Kubernetes。基于之前的方式，可能就先有 Kubernetes 才能进行镜像仓库的部署，然后才能部署 Compass。图片是这个哲学问题的 Wikipedia 里面截来的，我们可能研究不清楚这个哲学问题，我们的目标就是把这个问题解决掉，那么如何解决呢？

其实就是一个权衡 trade off 的问题。我们认为 Kubernetes 容器化这一套东西会更加重要，那我们就把整个 Harbor 移出来，不再基于 Kubernetes 做 HA 了。这里面我们的 Cargo v2.0 就涉及到了一个 system Harbor 和 user Harbor，就一个 Cargo 里面集成了两个 Harbor， Harbor 的版本是 v1.2。

System Harbor 主要是为 Compass 和 Kubernetes 组件的 image，用户 Harbor 主要是为用户的 image。整体架构大概是这样子的，前面一个 Keepalived，对外暴露一个 VIP，所有访问 Cargo 的话，通过这个 VIP 去访问。下面在几个 VM 上去部署我们的 Cargo，一个 Cargo 就 system Harbor 和用户 Harbor，这里面的内容其实是一样子的。然后 Harbor 前面有个 Nginx，这个 Nginx 被两个 Harbor 是共用的；对一些系统组建的 image 它就会导到 system Harbor；对于用户的 image 它就导到 user Harbor 里去。Keepalived 会去监测这两个 Harbor 是不是一个 health 的状态，如果有问题的话它会把这个 VIP 切换。

这里还有一个 RVIP，就是一个 Redis 的 VIP，这个后面会介绍到，因为现在一个 Harbor 它是不支持直接配一个 Redis 集群的，只能通过 VIP 去解决这个问题。剩下底层的就是在这几台机器上去搭 GlusterFS、MySQL、Redis 和 PostgreSQL 的 cluster。这些可以参考网上现有的一些方案，可能有些公司已经有了这些集群，直接接入就可以了，甚至有的公司可能不是用的 GlusterFS，而是用的 Ceph、NFS 等其它的，这种可能每个公司不太一样。

这是基于 Cargo v2.0 的产品架构。刚刚已经介绍了，就是说里面有两个 Harbor，这边就从 Cargo 中 System Harbor 拉镜像来部署系统组件，然后用户的应用，就会从 Cargo 中 User Harbor 拉镜像（参考黑色线）。控制集群可以部署多个用户集群，它的一个方式也是类似的，这里就简单过一下。

它的部署顺序就是先有 Cargo，然后再有 Kubernetes，再有就是我们的 Compass。

Cargo v3.0

因为 Harbor 那边已经有一些 HA，已经开始尝试着去官方支持了，现在 v1.4 的版本已经有一些相关的文档出来。

然后我们这边的一个需求要做到租户隔离，还有多环境中每个环境要有一个自己的 Cargo，这个是我们 v2.0 版本不支持的。所以这个地方我们要对这个架构进行改进。

改进的 Cargo v3.0 我们会基于 Harbor v1.4+ 以上的版本做，然后要支持去动态地 provision 出一个 Cargo，在产品中用户根据按需去部署。我们认为 Cargo 不再作为一个系统级别的资源被所有的租户共享，它应该是一个租户级别的资源，需要用到这个的话，那么它就动态地去产生一个，需要占用一些租户自己的存储资源什么的。

整个架构是这样子的，一个原生的 Harbor 在外面，剩下的这些 Cargo 都是用户是动态去产生的，跟之前的 Cargo 稍微有点不一样。用户的 applications 是从自己 Cargo 中 pull image。

Cargo V3.0 的 HA 就是外部一个原生 Harbor 的 HA 和集群中 Cargo 的 HA，就是我们之前两套方案结合起来去做这个事情，具体就不再赘述了。

那么它的一个部署顺序是一个原生的 Harbor，然后再把 Kubernetes 部署起来，再部署 Compass；Compass 完了之后用户根据需要去创建一些 Cargos 供自己使用。

遇到的问题

由于时间快到了，我们简单的过一下遇到的问题吧。

不支持直接配 Redis cluster，解决方案是我们已经有了一个 Keepalived，再在上面配一个 VIP 就可以了。因为 Harbor 是基于 Beego 的架构，Beego 这边不支持。所以我们解决方案就是为 Redis 额外加一个 VIP，每个节点去探测一下，自己是不是一个 master；如果不是的话，Keepalived 会把这个 VIP 切换走。

我们这里采用的是 Active/Standby 模式，刚刚已经说过了不能同时存在多个实例，如果同时存在多个实例话就不能支持 Clair 和 Notary，所以我们认为这个功能很重要。所以我们就取舍了一下，采用这种模式。Harbor v1.4 已经 fixed 了 Clair 这边的问题，但是 Notary 这边的问题还存在。

这边的话我们做 health check，这一块主要是去测试 pull image，就是这段代码去 pull 比较小的 image。我们选择这个是因为 Docker pull 和 push 的路径是一样的，而且 pull 的使用频率是最高的。相对于其他的一些 Harbor 的功能，因为它主要是一个镜像的分发和管理。这里就可以看到定时 pull 的一些日志。通过 health check 策略，基本上 Harbor 的绝大部分组件都已经 check 到了。谢谢大家！

本文讲师：Golden

-END-

推荐阅读：