本文讲的是DockOne微信分享（七十七）：用Harbor实现容器镜像仓库的管理和运维【编者的话】本次分享主要讲述了在开发运维中的管理容器镜像方法。为了便于说明原理，较多地使用Harbor作为例子。
内容主要包括：
- 开发和生产环境中镜像仓库的权限控制；
- 镜像远程同步（复制）的原理；
- 大规模应用镜像发布方式；
- 镜像删除和空间回收；
- Registry高可用性设计。
首先简单介绍一下Harbor项目。Harbor是由VMware中国研发团队负责开发的开源企业级Registry，可帮助用户迅速搭建企业级的Registry服务。该项目发布5多个月以来，深受用户喜爱，在GitHub获得了近1000个点赞星星和200多个Forks。有兴趣的朋友可以使用：
https://github.com/vmware/harbor
容器应用的使用越来越普遍，容器最大优点就是开发运维一体化，通过容器镜像打包应用，使得开发、测试和发布都具有相同的运行环境，带来极大的便利。那么镜像在实际运维中处于怎样的地位呢？
我们先看看下面这张经典的Docker容器的生命周期图：
从图中可以看到，容器镜像的关联箭头最多，不言而喻，镜像技术就是容器的核心所在。概括地说，容器包含一静一动两部分：静态存放的镜像(images)和动态运行的containers。相应地，容器的开发运维主要涉及镜像管理和运行时(Runtime)管理两部分。本文主要和大家分享的是容器镜像管理的部分。
开发和生产环境中镜像仓库的权限控制
在企业中，通常有不同的开发团队来负责不同的应用项目，和源代码分项目管理一样，镜像也需要按照项目来存放和管理。由于团队中有不同的成员，如项目经理、产品经理、开发、测试和运维等人员，每人使用镜像的需求不同，因此可以根据角色分配相应的权限。
例如，测试人员通常只需要镜像的读权限（pull），开发人员需要读写权限(push/pull)，项目经理除了拥有开发人员的权限之外，还可以增加和删除项目成员，设定他们的角色。
在Harbor Registry中，每个项目可有三种角色：项目管理员（project admin）、开发者（developer）和客人（guest）。某些项目，如放在Library中的公共镜像, 可以允许匿名访问，即用户不同Docker Login也可以访问，这样可以方便使用。在整个系统中，还设有系统管理员，具有维护镜像同步策略、用户增删等权限。
需要指出的是，在不同的环境中，某个成员的角色可以不同。例如，在开发环境的Registry中，运维人员一般不需要权限（或需要只读权限）；而在生产环境中的Registry，运维人员就需要有读写权限。下图是Harbor的权限管理界面：
镜像远程同步（复制）的原理
很多用户在开发、测试和运维中都使用同一个Registry，这样“简单粗暴”的方式比较适合小团队或简单的项目，其他情况最好使用多个Registry以区分不同的用途。如下图，容器镜像管理的参考流程。
开发环境的Registry：主要由开发人员使用，镜像变化频繁。当开发完成后，通过CI系统生成稳定镜像，同步到测试Registry；
测试环境的Registry：主要由测试人员使用，镜像保持不变。当测试通过后，同步到准生产环境的Registry；
准生产环境的Registry：主要由测试和运维人员使用，镜像保持不变。当准生产环境试运行后，最后再同步生产环境的Registry；
生产环境的Registry：发布镜像到生产环境运行。
从开发到生产的整个过程中，实现容器镜像的Build-Ship-Run过程。Harbor可以提供Registry之间的镜像自动同步和复制功能，简化了管理。
大规模应用镜像发布方式
在实际生产运维的中，往往需要把镜像发布到几十或上百台集群节点上。这时，单个Registry已经无法满足大量节点的下载需求，因此要配置多个Registry实例做负载均衡。手工维护多个Registry实例上的镜像，将是十分繁琐的事情。Harbor可以支持一主多从的镜像发布模式，可以解决大规模镜像发布的难题。
只要往一台Registry上发布，镜像就像“仙女散花”般地同步到多个Registry中，高效可靠。
如果是地域分布较广的集群，还可以采用层次型发布方式，如从集团总部同步到省公司，从省公司再同步到市公司：
在同步过程中，如果源镜像已删除，Harbor会自动同步删除远端的镜像。在镜像同步复制的过程中，Harbor会监控整个复制过程，遇到网络等错误，会自动重试。
这是同步复制的监控画面：
镜像删除和空间回收
Docker命令没有提供Registry镜像删除功能，日积月累，将会产生许多无用的镜像，占用大量存储空间。若要删除镜像并回收空间，需要调用docker registry API来完成，比较麻烦。Harbor提供了可视化的镜像删除界面，可以逻辑删除镜像。在维护状态下可以回收垃圾镜像的空间。
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的GitHub地址：
https://github.com/vmware/harbor
。
Q&A
Q：Master-Slave的镜像架构中,如果Slave Registy中的镜像被删除了，会不会再次自动从Master Reg里面自动同步？
A：如果停止后再重新启动复制策略，可以同步被删除的镜像。
Q：对于多个投产地，多个仓库，哪种方式的高可用方案好么？第一种，共享存储存储可能会出现单点故障么？
A：共享存储只适合同一数据中心，多个产地延时太大，不适合共享存储。
Q：Registry之间同步是如何实现的？
A：Registry API。
Q：在存储这块考虑过提供插件方式可以调用外部模块，比如以插件方式支持s3这种对象存储？
A：Harbor支持其他存储方式，参见
Harbor文档。
以上内容根据2016年8月18日晚微信群分享内容整理。分享人张海宁（Henry Zhang），VMware中国研发中心云原生应用首席架构师，Harbor开源企业级容器Registry项目负责人，Cloud Foundry中国社区最早的技术布道师之一。在VMware中国研发中心先后负责开源平台Cloud Foundry、大数据虚拟化、软件定义存储等领域的技术布道和解决方案推广。目前着重关注云原生应用的研发工作，内容包括Container、PaaS、IaaS等方面。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2016-08-21
本文作者：张海宁
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享（七十七）：用Harbor实现容器镜像仓库的管理和运维
