一次docker pull 或 push背后发生的事情  
这两个图里面index就是hub，可以看到每次客户端都要先访问index，决定镜像文件从哪个registry上传或下载，然后去相应的registry操作。从阅读源码中可以看出，在registry上，每个镜像的层都是以tar.gz格式存储的。
自己搭建docker镜像服务的考虑 既然是私服，同样需要考虑用户、安全认证、搜索等问题，可以说，docker的开发者在设计镜像服务时就考虑了这些问题，把Web这块留给每个私服的开发者自己去实现，把后端存储抽象成接口来调用。docker-registry的源代码放在这里 。为了保证后续的正常开发使用，我决定先阅读一下这个源码，不过碰上了不少问题： docker-registry是用python实现的，我对python的了解仅仅限于简单的脚本，对python的包、模块、类都不大懂，所以我学习了python docker-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，欢迎大家有想法找我交流:-)
最后分析一下这个架构的优点 解耦合
docker-hub是web-ui，用户认证，镜像元数据的集合，在这个方面，不同的组织有不同的做法，所以需要独立出来。
docker-registry是所有组织可以复用的部分，单纯用于镜像存储服务。 不重复造轮子
docker-registry自己去实现一套对象存储了吗？没有，因为在对象存储这个领域，已经有很多优秀的实现。
所以docker-registry是一个http接口的服务，仅仅是在对象存储上包了一层镜像的家族谱系，而且底层支持多种对象存储。 水平扩展性
在简单使用场景下，docker-registry也支持本地文件系统存储，可以说是all-in-one的设计，开箱即用。
而当把这个场景扩展，用于大规模企业级的应用时，docker-hub和docker-registry是1：n的关系，registry本身是一个无状态的服务，可以非常容易的水平扩展。
这也是设计者的狡猾之处，他把有状态的部分都抽离了，把存储这个最大的状态机制做成可以放在其他的对象存储上，这样在大规模使用场景下就不会有性能的问题，也不会有单点问题。
任何一个registry挂掉都是可以忍受的，可以被轻易的恢复而没有副作用。
| 
