需求

最近因为工作需要，开始研究docker-registry的实现和服务搭建。docker-registry是啥呢？就是目前很火的容器docker的镜像存储服务端。

或者这么说把，docker干的事情就是把整个应用、操作系统、配置打包成一个静态的镜像，这个镜像可以快速的启动关闭为一个动态的运行容器。但这种能力对单个人是没有很大意义的，我们需要有个地方把镜像存下来，然后用一个url或者链接分享给其他人。

如果是你，你会怎么设计？开一个公共的FTP让大家存镜像然后分享？这是个好主意，不过……docker的镜像有这么一个设定，就是一个镜像是由多层组成的，如果每次传输全量文件，对客户端、服务端、用户启动都造成时间和流量的浪费。

于是……

需求一：远程存储服务，上传和下载需要智能的识别对面有没有这层，如果两边的层的uuid一致，已经有的话，就不传了。

简单的根据名字上传下载，对人日常使用来说还不不够方便，还需要一个web界面，让人可以登陆、搜索、区分公共的镜像和私有的镜像，等等，这是人的需求，不是客户端程序的需求。

需求二：web界面，支持搜索

每个镜像层的大小约为几十M到几百M之间，可以想象，当很多人都往一个地方上传时，单个服务器的存储容量是绝对支撑不住的，需要可以水平扩展的集群，但web界面不能分开，客户端程序也不应该很麻烦的自己找去哪里下载。

需求三：支持水平扩展的集群存储

docker-hub和docker-registry的分工如下：

docker-hub

负责保存集中的信息访问，关于

用户账户镜像的效验码公共和私人镜像仓库的区分

docker-hub有几个组件：

Web UIMeta-data 元数据存储（附注、星级、公共库清单）访问认证token管理

dokcer-registry

有这么几个特性

存储镜像、以及镜像层的家族谱系没有用户账户数据不知道用户的账户和安全性把安全和认证委托给docker-hub来做，用token来保证传递安全不需要重新发明轮子，支持多种存储后端没有本地数据库

一次docker pull 或 push背后发生的事情

这两个图里面index就是hub，可以看到每次客户端都要先访问index，决定镜像文件从哪个registry上传或下载，然后去相应的registry操作。从阅读源码中可以看出，在registry上，每个镜像的层都是以tar.gz格式存储的。

自己搭建docker镜像服务的考虑

既然是私服，同样需要考虑用户、安全认证、搜索等问题，可以说，docker的开发者在设计镜像服务时就考虑了这些问题，把Web这块留给每个私服的开发者自己去实现，把后端存储抽象成接口来调用。docker-registry的源代码放在这里 。为了保证后续的正常开发使用，我决定先阅读一下这个源码，不过碰上了不少问题：

docker-registry是用python实现的，我对python的了解仅仅限于简单的脚本，对python的包、模块、类都不大懂，所以我学习了pythondocker-registry使用了egg打包发布，gunicorn作为应用服务器（类似tomcat），flask作为mvc框架（类似spring），后面还有sqlalchemy作为搜索后端。这些技术都需要做简单的了解，在需要的时候深入学习。后端存储，因为镜像最终是以tar.gz的方式静态存储在服务端，不需要实时read或write，所以适用于对象存储而不是块存储，于是问题就转化成找一个或写一个私有的存储驱动，官方支持的驱动有亚马逊AWS S3、ceph-s3、Google gcs、OpenStack swift，glance等等，国内的七牛也写了自己的驱动 ，后面在我的环境需要自己写一个驱动。搜索，这块我还没涉及，后续再看……Web UI的实现，现在github上已经有好几个项目了，例如docker-registry-web ，docker-registry-frontend，后续再看……

最近在研究用Docker实现PaaS，欢迎大家有想法找我交流:-)

原文链接：http://my.oschina.net/HardySimpson/blog/365513