【摘要】 本文介绍了Docker Registry服务几个组件的构成，怎么规划定制一个私有镜像库，以及镜像服务pull/push操做性能分析、并发性能分析，帮助你们按照需求你们本身须要的镜像服务。html
docker-index
- Web UI
- Meta-data 元数据存储（附注、星级、公共库清单）
- 访问认证
- token管理
docker-registry
- 存储镜像、以及镜像层的家族谱系
- 没有用户帐户数据
- 不知道用户的帐户和安全性
- 把安全和认证委托给docker-hub来作，用token来保证传递安全
- 不须要从新发明轮子，支持多种存储后端
- 没有本地数据库
后端存储
- 由于镜像最终是以tar.gz的方式静态存储在服务端
- 适用于对象存储而不是块存储
- registry存储驱动
- 官方支持的驱动有文件、亚马逊AWS S三、ceph-s三、Google gcs、OpenStack swift，glance
一次docker pull发生的交互
- Client向Index请求，知道从哪里下载samlba/busybox
- Index回复：
- samalba/busybox在RegistryA
- samalba/busybox的checksum，全部层的token
- Client向Registry A请求，samalba/busybox的全部层。Registry A负责存储samalba/busybox，以及它所依赖的层
- Regsitry A向Index发起请求，验证用户/token的合法性
- Index返回此次请求是否合法
- Client从registry下载全部的层
- registry从后端存储中获取实际的文件数据，返给Client
搭建私有镜像库的方案
上面的index，registry，后端存储3者都是可选的。registry分0.9的python版实现和2.0版的go实现。python
认证和权限
若是镜像库不直接提供给用户使用，仅仅是私有PaaS的一部分，能够不用index组件，直接上registry就行。index的开源实现包括docker-registry-web，docker-registry-frontend。支持较好的是马道长的wharf。web
后端存储
咱们环境使用的是网易的内部的对象存储NOS，相似于S3。其余的方案没用过，若是要本身搭，可能靠谱的是ceph-s3。若是在公网环境或者已经购买了公有云服务，能够考虑本身实现一个registry-对象存储的驱动。docker
集群和分布式
registry自己是无状态的，能够水平扩展，而后在前面作ngix的负载均衡。数据库
性能分析
v1协议 vs v2协议
| 客户端swift |
push总时间后端 |
pull总时间缓存 |
| registry-0.9安全 |
388.1服务器 |
80.9 |
| registry-2.0 |
368.4 |
76.1 |
作了性能对比测试，一样为docker1.6，v2协议比v1协议快5-6%左右，基本能够忽略不计。
单次pull和push的性能分析
层|docker push|curl put :-----|:----- layer1|34s|4.3s layer2|325s|44.6s
层|docker pull|curl get :-----|:----- layer1|42s|20.8s layer2|2s|1.4s
通过对比测试，单次docker pull和push的最大耗时在客户端，也能够观察到每次作docker pull和push的时候系统CPU占用率都在100%。也就是说50%以上的时间花在本地作的压缩、计算md5等操做。
并发分析
并发测试的结果是在一个2核2G内存的registry-0.9服务器，直接用文件存储，大约能负载50个docker client的并发。若是换用对象存储的后端，估计10个docker client的并发就是极限了。在这方面registry-2.0的并发能力更强，但对内存消耗更大。
Q&A
问：2.0的性能也没什么变化啊，优点在哪里？ **答：**客户端优化有限，在超过100个节点同时pull一个镜像时，2.0服务端资源占用少。
问：服务端的并发瓶颈在哪里？ **答：**服务端的代码还没作过更多的分析，从经验判断主要仍是IO，python的内存占用比较多。
问：考虑过多机房image存储CDN没？ **答：**这个还真没考虑过，目前咱们的镜像服务是个内部PaaS平台用的，只要保证集群所在机房能快速访问就行。
问：那还不如每机房加缓存？ **答：**是的，也能够考虑registry的mirror机制，用了mirror后能够一个点push，其余点pull。
问：大家的调度器是本身开发的吗？ **答：**咱们底层用的是Kubernetes，调度器作必定的修改，主要是为了保证多个可用域。
问：内部的PaaS有没有作资源限制、网络隔离？ **答：**有，目前咱们的Docker是跑在kvm上。
问：昨天网易好多服务断片了，听说是网络攻击，那这些服务有跑在Docker上吗？ **答：**呵呵，断片是由于BGP的核心交换机问题，我也很好奇是什么引发的，目前尚未组织和我的声称对此事负责。
问：有没有考虑过nova-docker？ **答：**社区不是很活跃，咱们没有采用这个方案，但对于中小公司来讲这是最快的方案。
问：为啥不考虑本身实现调度器？ **答：**忙不过来，咱们也想作啊，这个放在后面实现。
问：咱们准备在某公有云上跑Docker集群。 **答：**先这么用呗，我以为Docker的优点就是底层平台无关，从此换了底层迁移也没有那么困难。
若是尚在犹豫，为何不先行动起来？华为云容器，企业级容器应用管理服务，支持Kubernetes社区原生应用和工具，简化云上自动化容器运行环境搭建。
https://www.huaweicloud.com/product/cce.html