用Harbor实现容器镜像仓库的管理和运维

(本文由8月18日VMware中国研发首席架构师张海宁在Harbor技术群分享内容汇编而成。)

本次分享主要讲述了在开发运维中的管理容器镜像方法。为了便于说明原理，较多地使用Harbor做为例子。

内容主要包括：
1）开发和生产环境中镜像仓库的权限控制
2）镜像远程同步（复制）的原理
3）大规模应用镜像发布方式；
4）镜像删除和空间回收
5）Registry高可用性设计。

首先简单介绍一下Harbor项目。Harbor是由VMware中国研发团队负责开发的开源企业级Registry，可帮助用户迅速搭建企业级的registry 服务。该项目发布5多个月以来，深受用户喜好，在GitHub 得到了近1000个点赞星星和200多个 forks。有兴趣的朋友可使用： https://github.com/vmware/harbor 

容器应用的使用愈来愈广泛，容器最大优势就是开发运维一体化，经过容器镜像打包应用，使得开发、测试和发布都具备相同的运行环境，带来极大的便利。那么镜像在实际运维中处于怎样的地位呢？

咱们先看看下面这张经典的Docker容器的生命周期图：

从图中能够看到，容器镜像的关联箭头最多，不言而喻，镜像技术就是容器的核心所在。归纳地说，容器包含一静一动两部分：静态存放的镜像(images)和动态运行的containers。相应地，容器的开发运维主要涉及镜像管理和运行时(Runtime)管理两部分。本文主要和你们分享的是容器镜像管理的部分。

1）开发和生产环境中镜像仓库的权限控制

在企业中，一般有不一样的开发团队来负责不一样的应用项目，和源代码分项目管理同样，镜像也须要按照项目来存放和管理。因为团队中有不一样的成员，如项目经理、产品经理、开发、测试和运维等人员，每人使用镜像的需求不一样，所以能够根据角色分配相应的权限。

例如，测试人员一般只须要镜像的读权限(pull)，开发人员须要读写权限(push/pull)，项目经理除了拥有开发人员的权限以外，还能够增长和删除项目成员，设定他们的角色。
在Harbor Registry中，每一个项目可有三种角色：项目管理员(project admin)、开发者(developer)和客人(guest)。某些项目，如放在library中的公共镜像, 能够容许匿名访问，即用户不一样docker login也能够访问，这样能够方便使用。在整个系统中，还设有系统管理员，具备维护镜像同步策略、用户增删等权限。

须要指出的是，在不一样的环境中，某个成员的角色能够不一样。例如，在开发环境的registry中，运维人员通常不须要权限（或须要只读权限）；而在生产环境中的Registry，运维人员就须要有读写权限。下图是Harbor的权限管理界面：

2）镜像远程同步（复制）的原理
不少用户在开发、测试和运维中都使用同一个Registry，这样“简单粗暴”的方式比较适合小团队或简单的项目，其余状况最好使用多个Registry以区分不一样的用途。以下图，容器镜像管理的参考流程。

开发环境的Registry: 主要由开发人员使用，镜像变化频繁。当开发完成后，经过CI系统生成稳定镜像，同步到测试Registry;

测试环境的Registry: 主要由测试人员使用，镜像保持不变。当测试经过后，同步到准生产环境的Registry;

准生产环境的Registry: 主要由测试和运维人员使用，镜像保持不变。当准生产环境试运行后，最后再同步生产环境的Registry;

生产环境的Registry: 发布镜像到生产环境运行。

从开发到生产的整个过程当中，实现容器镜像的Build-Ship-Run过程。Harbor能够提供Registry之间的镜像自动同步和复制功能，简化了管理。

3）大规模应用镜像发布方式；

在实际生产运维的中，每每须要把镜像发布到几十或上百台集群节点上。这时，单个Registry已经没法知足大量节点的下载需求，所以要配置多个registry实例作负载均衡。手工维护多个registry实例上的镜像，将是十分繁琐的事情。Harbor能够支持一主多从的镜像发布模式，能够解决大规模镜像发布的难题。

只要往一台registry上发布，镜像就像“仙女散花”般地同步到多个registry中，高效可靠。

若是是地域分布较广的集群，还能够采用层次型发布方式，如从集团总部同步到省公司，从省公司再同步到市公司：

在同步过程当中，若是源镜像已删除，Harbor会自动同步删除远端的镜像。在镜像同步复制的过程当中，Harbor会监控整个复制过程，遇到网络等错误，会自动重试。

这是同步复制的监控画面：

4）镜像删除和空间回收
Docker命令没有提供Registry镜像删除功能，日积月累，将会产生许多无用的镜像，占用大量存储空间。若要删除镜像并回收空间，须要调用docker registry API来完成，比较麻烦。Harbor提供了可视化的镜像删除界面，能够逻辑删除镜像。在维护状态下能够回收垃圾镜像的空间。

5）Registry高可用性设计。
Registry高可用性（HA）是多数生产系统须要关心的问题，基本要求就是没有单点故障。一般须要根据容许服务中断的时间，以及能够承受的成本和损失，来肯定采用的技术。下面介绍3种HA的方案：

一种比较标准的方案，就是多个的Registry实例共享同一个后端存储，任何一个实例持久化到存储的镜像，均可被其余实例中读取。经过前置LB进来的请求，能够分流到不一样的实例中去处理，实现了负载均衡，也避免了单点故障。

应该指出，实际中须要考虑的问题远比上述模型复杂。例如，共享存储的选取，用户session在不一样的实例上共享等等。用户可根据本身业务要求设计出不一样的方案。Harbor将会推出基于swift分布式存储，以及共享session的方案（采用redis）来知足用户的需求。

若是没有共享存储，另外一种方案就是在两个节点间采用双主复制策略，互相复制镜像。即便有一个实例失效，另外一个实例仍然能够提供服务，从而在必定程度上能够知足HA的需求。

第3中方案是利用已有的HA平台，如vSphere HA，配合分布式存储VSAN，能够实现Harbor的HA, 具体架构见下图：

节点出现故障的时候，有vSphere自动切换到好的节点上，镜像数据不丢失。

咱们以开源Harbor为例子，总结了Registry的使用场景和要点，但愿对你们有帮助。

欢迎广大用户使用Harbor项目并反馈意见和建议，也欢迎加入咱们贡献代码。若是您是Harbor的用户或开发者，可申请加入Harbor开源项目微信群，以方便沟通。请先扫描下面二维码关注“亨利笔记”公众号，并在公众号后台发送"入群"信息便可。