DockOne技术分享(三):Docker Registry的定制和性能分析



  • 分享人钟成,网易PaaS平台开发者,写过一些开源软件,期望能在未来的云端世界中有一席之地,目前做的项目是在实现一个构建到部署运行的私有PaaS平台,目标用户是网易各种互联网产品。

    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发生的交互

    1733f7272716b74edc0ce03085f751a9.png

    1. Client向Index请求,知道从哪里下载samlba/busybox
    2. Index回复:
    3. samalba/busybox在RegistryA
    4. samalba/busybox的checksum,所有层的token
    5. Client向Registry A请求,samalba/busybox的所有层。Registry A负责存储samalba/busybox,以及它所依赖的层
    6. Regsitry A向Index发起请求,验证用户/token的合法性
    7. Index返回这次请求是否合法
    8. Client从registry下载所有的层
    9. Registry从后端存储中获取实际的文件数据,返给Client

    搭建私有镜像库的方案

    1e111941614512fcc0bdeb2e80ee9384.png

    上面的index、nginx、后端存储3者都是可选的。registry分0.9的python版实现和2.0版的go实现。

    认证和权限

    如果镜像库不直接提供给用户使用,仅仅是私有PaaS的一部分,可以不用index组件,直接上Registry就行。Index的开源实现包括docker-registry-web,docker-registry-frontend。支持较好的是马道长的wharf。

    后端存储

    我们环境使用的是网易的内部的对象存储NOS,类似于S3。其他的方案没用过,如果要自己搭,可能靠谱的是ceph-s3。如果在公网环境或者已经购买了公有云服务,可以考虑自己实现一个registry-对象存储的驱动。

    集群和分布式

    Registry本身是无状态的,可以水平扩展,然后在前面做ngix的负载均衡。

    性能测试

    v1协议 vs v2协议

    d9ed4ab9cc525a11e5aaa6949e8a6d18.png

    做了性能对比测试,同样为docker1.6,v2协议比v1协议快5-6%左右,基本可以忽略不计。

    单次Pull和Push的性能分析

    1c355e3ad29798084f340c4d988d1eb7.png

    b378fbb7c2a9f8d51356268905f6aefe.png

    经过对比测试,单次docker pull和push的最大耗时在客户端,也可以观察到每次做docker pull和push的时候系统CPU占用率都在100%。也就是说50%以上的时间花在本地做的压缩、计算md5等操作。

    并发分析

    1c718afa559d221008b3d137ca9f47c5.png

    并发测试的结果是在一个2核2G内存的registry-0.9服务器,直接用文件存储,大约能负载50个docker client的并发。如果换用对象存储的后端,估计10个docker client的并发就是极限了。

    registry-2.0的并发性能很奇特,一方面,同样的镜像下载的比registry-1.0要慢,另一方面,只有一个进程,占了20%左右的CPU和内存,对系统资源消耗很少,不像python版的占用了所有的CPU核和内存。

    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的优势就是底层平台无关,今后换了底层迁移也没有那么困难。

    原文链接: http://dockone.io/article/375


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待