docker-registry的定制和性能分析#docker-registry的定制和性能分析
docker-index
- Web UI
- Meta-data 元数据存储（附注、星级、公共库清单）
- 访问认证
- token管理
docker-registry
- 存储镜像、以及镜像层的家族谱系
- 没有用户账户数据
- 不知道用户的账户和安全性
- 把安全和认证委托给docker-hub来做，用token来保证传递安全
- 不需要重新发明轮子，支持多种存储后端
- 没有本地数据库
后端存储
- 因为镜像最终是以tar.gz的方式静态存储在服务端
- 适用于对象存储而不是块存储
- registry存储驱动
- 官方支持的驱动有文件、亚马逊AWS S3、ceph-s3、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实现。
认证和权限
如果镜像库不直接提供给用户使用，仅仅是私有PaaS的一部分，可以不用index组件，直接上re
gistry就行。index的开源实现包括docker-registry-web，docker-registry-frontend。支持较好的是马道长的wharf。
后端存储
我们环境使用的是网易的内部的对象存储NOS，类似于S3。其他的方案没用过，如果要自己搭，可能靠谱的是ceph-s3。如果在公网环境或者已经购买了公有云服务，可以考虑自己实现一个registry-对象存储的驱动。
集群和分布式
registry本身是无状态的，可以水平扩展，然后在前面做ngix的负载均衡。
v1协议 vs v2协议
客户端|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等操作。
并发分析
镜像大小|并发数|单次时间
:-----|:-----|:---
85.1 MB|1|0.5s
85.1 MB|20|11.1s
85.1 MB|50|22s
551.8 MB|1|2.8s
551.8 MB|20|49.5s
551.8 MB|50|140s
并发测试的结果是在一个2核2G内存的registry-0.9服务器，直接用文件存储，大约能负载50个docker client的并发。如果换用对象存储的后端，估计10个docker client的并发就是极限了。
registry-2.0的并发性能很奇特，一方面，同样的镜像下载的比registry-1.0要慢，另一方面，只有一个进程，占了20%左右的CPU和内存，对系统资源消耗很少，不像python版的占用了所有的CPU核和内存。
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
