【編者的話】 本文通過研究docker hub和docker-registry的架構，介紹了在服務端docker鏡像的存儲、管理、安全的架構設計，并給出了一次簡單的docker用戶端服務端互動的過程。對于部署實作一個大規模、企業級的鏡像庫需要做的工作做了初步的探讨，彙總了需要準備的前期知識等。推薦想要搭建一個私有docker鏡像庫的同學閱讀。
<a target="_blank"></a>
最近因為工作需要，我開始研究docker-registry的實作和服務搭建。docker-registry是docker的鏡像存儲服務端。或者這麼說，docker幹的事情就是把整個應用、作業系統、配置打包成一個靜态的鏡像，這個鏡像可以快速的啟動和停止。但這種能力對單個人是沒有多大意義的，我們需要有個地方把鏡像存下來，然後用一個url分享給其他人。
如果是你，你會怎麼設計？開一個公共的ftp讓大家存鏡像然後分享？這是個好主意，不過……docker的鏡像有這麼一個設定，就是一個鏡像是由多層組成的，如果每次傳輸全量檔案，對用戶端、服務端、使用者啟動都造成時間和流量的浪費。
095141_pgk8_224285.jpg
于是……
上傳和下載下傳需要智能的識别對面有沒有這層，如果兩邊的層的uuid一緻，已經有的話，就不傳了。
簡單的根據名字上傳下載下傳，對日常使用來說還不夠友善，我們還需要一個web界面，以支援登入、搜尋、區分公共的鏡像和私有的鏡像等需求，這是使用者的需求，不是用戶端程式的需求。
103423_tffg_224285.png
每個鏡像層一般都有幾十兆到幾百兆的大小，可以想象，當很多使用者都往一個地方上傳時，單個伺服器的存儲容量是絕對支撐不住的，需要可以水準擴充的叢集，但web界面不能分開，用戶端程式也不應該很麻煩的自己找去哪裡下載下傳。
113601_lixf_224285.png
docker hub和docker-registry的分工如下：
docker hub負責管理集中的資訊通路，包括：
使用者賬戶
鏡像的效驗碼
公共和私人鏡像倉庫的區分
docker hub有幾個元件：
web ui
meta-data 中繼資料存儲（附注、星級、公共庫清單）
通路認證
token管理
dokcer-registry有如下幾個特性：
存儲鏡像、以及鏡像層的家族譜系
沒有使用者賬戶資料
不知道使用者的賬戶和安全性
把安全和認證委托給docker-hub來做，用token來保證傳遞安全
不需要重新發明輪子，支援多種存儲後端
沒有本地資料庫
這兩個圖裡面的index就是hub，可以看到每次用戶端都要先通路index，決定鏡像檔案從哪個registry上傳或下載下傳，然後去相應的registry操作。從閱讀源碼中可以看出，在registry上，每個鏡像的層都是以tar.gz格式存儲的。
142853_vfja_224285.png
搜尋，這塊我還沒涉及，後續再看……
最近在研究用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挂掉都是可以忍受的，可以被輕易的恢複而沒有副作用。
原文釋出時間：2015-01-21
本文來自雲栖合作夥伴“linux中國”