上面的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的负载均衡。
客户端|push总时间|pull总时间
:-----|:-----|:-----
registry-0.9|388.1|80.9
registry-2.0|368.4|76.1
做了性能对比测试,同样为docker1.6,v2协议比v1协议快5-6%左右,基本可以忽略不计。
层|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核和内存。