從Docker Hub和docker-registry看優秀的后端服務設計實現

本文通過研究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負責管理集中的信息訪問，包括：

• 用戶賬戶
• 鏡像的效驗碼
• 公共和私人鏡像倉庫的區分
</ul>
Docker Hub有幾個組件：


• Web UI
• Meta-data 元數據存儲（附注、星級、公共庫清單）
• 訪問認證
• token管理
</ul>
dokcer-registry有如下幾個特性：


• 存儲鏡像、以及鏡像層的家族譜系
• 沒有用戶賬戶數據
• 不知道用戶的賬戶和安全性
• 把安全和認證委托給docker-hub來做，用token來保證傳遞安全
• 不需要重新發明輪子，支持多種存儲后端
• 沒有本地數據庫
</ul>


一次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的方式靜態存儲在服務端，不需要實時讀或者寫，所以適用于對象存儲而不是塊存儲，于是問題就轉化成找一個或寫一個私 有的存儲驅動，官方支持的驅動有亞馬遜AWS S3、Ceph-s3、Google gcs、OpenStack swift、Glance等等，國內的七牛也寫了自己的驅動 。
• 搜索，這塊我還沒涉及，后續再看……
• Web UI的實現，現在GitHub上已經有好幾個項目了，例如docker-registry-web 、docker-registry-frontend，后續再看……
</ul>
最近在研究用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掛掉都是可以忍受的，可以被輕易的恢復而沒有副作用。
</ul>

來自：http://dockerone.com/article/142