题图摄于温哥华港
容器镜像复制和发布一直缺少良好的工具，是实际开发和运维中的一大痛点。开源Harbor Registry提供强大的镜像复制/同步能力，成为众多用户喜爱的杀手级功能。本文介绍了镜像复制功能的工作原理，作者为Harbor项目核心工程师姜坦、尹文开，编者做了少量调整。
VMware公司3月份开源了企业级Registry项目Harbor，由VMware中国研发的团队负责开发。Harbor可帮助用户迅速搭建企业级的registry 服务。它提供了管理图形界面, 基于角色的访问控制RBAC，镜像远程复制（同步），AD/LDAP集成、以及审计日志等企业用户需求的功能，同时还原生支持中文，深受中国用户的喜爱。该项目推出4多个月以来，在GitHub 获得了超过900多个点赞星星和200多个 forks，Github地址：
https://github.com/vmware/harbor
在最近发布的版本中，Harbor新增了基于策略的Docker镜像复制功能，可在不同的数据中心、不同的运行环境之间同步镜像，并提供友好的管理界面，大大简化了实际运维中的镜像管理工作，已经有用户部署了远程镜像双向复制的案例。本文将对该功能的实现原理做详细介绍。
Harbor镜像复制的管理界面
功能简介
在功能设计方面，Harbor仍然以“项目”为中心， 通过对项目配置“复制策略”，标明需要复制的项目以及镜像。管理员在复制策略中指明目标实例，即复制的“目的地”，并对它的地址和连接时使用的用户名密码进行设置。当复制策略被激活时，源项目下的所有镜像，都会被复制到目标实例；此外，当源项目下的镜像被添加或删除（push或delete), 只要策略还在激活状态，镜像的变化都会同步到目标实例上去， 如下图所示：
在较大的容器集群中，往往需要多个Registry服务器做负载均衡，可以采用主从发布模式，镜像只需要发布一次，就可以推送到多个Registry实例中。同时还支持双主复制和层次型的多级镜像发布，如下图所示：
设计与实现
在不同的Registry实例之间复制镜像是十分普遍的需求，过去常见的做法是通过拷贝镜像数据，比如定期通过rsync同步文件系统中镜像的数据，或者，对于部署在IaaS服务上的情况，通过对IaaS存储服务一层进行配置实现对象复制，这些方法往往是根据registry使用的存储而采用不同工具。然而对于Harbor来说，我们希望降低这种依赖，并提高灵活性， 比如用户可能有一个开发用的registry使用文件系统作为存储，并希望把镜像同步到基于S3存储的远端发布用的registry上。考虑到这种情况，我们选择通过调用registry本身的API下载并传输镜像，从而做到了与下层存储无关。
在控制方面，我们引入了一个新的组件，Job Service，用来对镜像复制任务进行管理。当以项目为单位进行复制时，会以镜像为单位生成一系列任务（job)由Job Service 调度管理，Job Service在执行任务的过程中将每个任务的状态更新到数据库中， 以便用户通过UI查看。大体结构如下图所示：
下面介绍一下Job Service 的实现，从外部看它也是通过REST API接收请求调度并执行任务，面临的问题主要有两点，首先，接收到大量复制请求时需要进行限流以免消耗过多IO资源；其次，复制策略有可能在任务执行过程中改变，比如失效，这就需要一种机制能从外界对运行中的任务进行干预。
我们通过任务队列，分发器（dispatcher）和worker pool实现了生产者消费者模型，利用Go语言内置的channel,每个任务会通过scheduler放到channel里，dispatcher 通过channel获得任务，同时，worker在工作结束后会被放入另一个channel, dispatcher 通过这个channel与worker配对，于是，空闲的worker通过dispatcher获得任务id并执行任务，这样可以很方便地通过worker pool中 worker数量来控制并发数：
对于另一个问题，每一个 worker内部是一个抽象的状态机（state machine)，通过给不同状态注册处理器（handler）完成具体工作，同时，状态机可以受到干预，可以中途取消（cancel）任务，或在任务执行发生异常时将任务置为错误（error）状态丢弃或交给调度器（scheduler）重试。 另外由于状态机的状态是可定制的，这样就很方便扩展和调整。对于一个抽象的任务来说，它的状态转移如下图所示：
而对于具体远程同步镜像的任务来说，Running 状态会被进一步细分成多个子状态，如下图所示：
首先, 从源Harbor实例下载相应tag的manifest，分析其所包含的blob，针对每一个blob，检查其在目标实例中是否已经存在，如果不存在，则同步此blob。最后，检查manifest在目标实例中是否已存在，如果不存在，则上传manifest。检查blob的存在性，可以有效减少不必要的网络流量；而由于manifest的上传有可能会触发镜像的同步，所以对manifest存在性的检查，则可以避免当同步的多个Harbor形成环路时进入不断同步的死循环状态。对同一个镜像中的每一个tag重复以上过程，就可以完成整个镜像的同步工作。
总结与展望
本文介绍了Harbor新版本中远程镜像复制功能的设计与实现。今后我们将对此功能进行扩展，比如在策略（policy）中加入更加丰富的控制和过滤条件方便用户选择需要复制的镜像，以及控制复制的发生时间等。也希望读者和用户们在多向我们提供反馈意见。Harbor项目网址：
https://github.com/vmware/harbor
