微信号:greatops

介绍:高效运维公众号由萧田国及朋友们维护,经常发布各种广为传播的优秀原创技术文章,关注运维转型,陪伴您的运维职业生涯,一起愉快滴发展.

跨数据中心Docker镜像复制的开源实现 | Harbor Registry

2016-08-04 07:10 姜坦\/尹文开

欢迎关注“高效运维(微信ID:greatops)”公众号,以抢先赏阅干货满满的各种原创文章。

引言

容器镜像复制和发布一直缺少良好的工具,是实际开发和运维中的一大痛点。开源Harbor Registry提供强大的镜像复制/同步能力,成为众多用户喜爱的杀手级功能。

本文介绍了镜像复制功能的工作原理,作者为Harbor项目核心工程师姜坦、尹文开,编者做了少量调整。

开源项目 Harbor简介

VMware公司3月份开源了企业级Registry项目Harbor,由VMware中国研发的团队负责开发。

Harbor可帮助用户迅速搭建企业级的registry 服务。它提供了管理图形界面, 基于角色的访问控制(Role Based Access Control),镜像远程复制(同步),AD/LDAP集成、以及审计日志等企业用户需求的功能,同时还原生支持中文,深受中国用户的喜爱。

该项目推出4多个月以来,在GitHub 获得了超过900多个star和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

 
高效运维 更多文章 关于分布式存储,这是你应该知道的(图文详解) 运维也得会表达:即兴发言的8种速成套路 《运维知识体系》介绍及研讨会 致运维:感觉身体被掏空?七夕给您补回来 听Linux之父Linus Torvalds谈谈Linux和他的故事
猜您喜欢 不可不知的十大流行Python库 流量都去哪儿了 —— 三板斧搞定Android网络流量测试 Docker命令行详解 以AWS为例,讲给普通人听的分布式数据存储 提高Android代码质量的4个工具