【编者的话】 本文通过研究Docker Hub和docker-registry的架构,介绍了在服务端Docker镜像的存储、管理、安全的架构设计,并给出了一次简单的Docker客户端服务端交互的过程。对于部署实现一个大规模、企业级的镜像库需要做的工作做了初步的探讨,汇总了需要准备的前期知识等。推荐想要搭建一个私有Docker镜像库的同学阅读。
最近因为工作需要,我开始研究docker-registry的实现和服务搭建。docker-registry是Docker的镜像存储服务端。或者这么说,Docker干的事情就是把整个应用、操作系统、配置打包成一个静态的镜像,这个镜像可以快速的启动和停止。但这种能力对单个人是没有多大意义的,我们需要有个地方把镜像存下来,然后用一个url分享给其他人。
如果是你,你会怎么设计?开一个公共的FTP让大家存镜像然后分享?这是个好主意,不过……Docker的镜像有这么一个设定,就是一个镜像是由多层组成的,如果每次传输全量文件,对客户端、服务端、用户启动都造成时间和流量的浪费。
于是……
需求一:远程存储服务,上传和下载需要智能的识别对面有没有这层,如果两边的层的uuid一致,已经有的话,就不传了。
简单的根据名字上传下载,对日常使用来说还不够方便,我们还需要一个Web界面,以支持登录、搜索、区分公共的镜像和私有的镜像等需求,这是用户的需求,不是客户端程序的需求。
需求二:Web界面,支持搜索
每个镜像层一般都有几十兆到几百兆的大小,可以想象,当很多用户都往一个地方上传时,单个服务器的存储容量是绝对支撑不住的,需要可以水平扩展的集群,但Web界面不能分开,客户端程序也不应该很麻烦的自己找去哪里下载。
需求三:支持水平扩展的集群存储
Docker Hub和docker-registry的分工如下:
Docker Hub负责管理集中的信息访问,包括:
Docker Hub有几个组件:
dokcer-registry有如下几个特性:
这两个图里面的index就是hub,可以看到每次客户端都要先访问index,决定镜像文件从哪个registry上传或下载,然后去相应的registry操作。从阅读源码中可以看出,在registry上,每个镜像的层都是以tar.gz格式存储的。
既然是私服,同样需要考虑用户、安全认证、搜索等问题,可以说,Docker的开发者在设计镜像服务时就考虑了这些问题,把Web这块留给每个私服的开发者自己去实现,并把后端存储抽象成接口来调用。docker-registry的源代码放在 这里 。为了保证后续的正常开发使用,我决定先阅读一下这个源码,不过碰上了不少问题,具体如下:
最近在研究用Docker实现PaaS,欢迎大家有想法找我交流:-)