從docker-hub和docker-registry看優秀的後端服務設計實現

##需求

最近由於工做須要，開始研究docker-registry的實現和服務搭建。docker-registry是啥呢？就是目前很火的容器docker的鏡像存儲服務端。

或者這麼說把，docker乾的事情就是把整個應用、操做系統、配置打包成一個靜態的鏡像，這個鏡像能夠快速的啓動關閉爲一個動態的運行容器。但這種能力對單我的是沒有很大意義的，咱們須要有個地方把鏡像存下來，而後用一個url或者連接分享給其餘人。

若是是你，你會怎麼設計？開一個公共的FTP讓你們存鏡像而後分享？這是個好主意，不過……docker的鏡像有這麼一個設定，就是一個鏡像是由多層組成的，若是每次傳輸全量文件，對客戶端、服務端、用戶啓動都形成時間和流量的浪費。

因而……

需求一：遠程存儲服務，上傳和下載須要智能的識別對面有沒有這層，若是兩邊的層的uuid一致，已經有的話，就不傳了。

---

簡單的根據名字上傳下載，對人平常使用來講還不不夠方便，還須要一個web界面，讓人能夠登錄、搜索、區分公共的鏡像和私有的鏡像，等等，這是人的需求，不是客戶端程序的需求。

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

---

每一個鏡像層的大小約爲幾十M到幾百M之間，能夠想象，當不少人都往一個地方上傳時，單個服務器的存儲容量是絕對支撐不住的，須要能夠水平擴展的集羣，但web界面不能分開，客戶端程序也不該該很麻煩的本身找去哪裏下載。

需求三：支持水平擴展的集羣存儲

---

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

##docker-hub

負責保存集中的信息訪問，關於

• 用戶帳戶
• 鏡像的效驗碼
• 公共和私人鏡像倉庫的區分

docker-hub有幾個組件：

• Web UI
• Meta-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的包、模塊、類都不大懂，因此我學習了python

• docker-registry使用了egg打包發佈，gunicorn做爲應用服務器（相似tomcat），flask做爲mvc框架（相似spring），後面還有sqlalchemy做爲搜索後端。這些技術都須要作簡單的瞭解，在須要的時候深刻學習。

• 後端存儲，由於鏡像最終是以tar.gz的方式靜態存儲在服務端，不須要實時read或write，因此適用於對象存儲而不是塊存儲，因而問題就轉化成找一個或寫一個私有的存儲驅動，官方支持的驅動有亞馬遜AWS S三、ceph-s三、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掛掉都是能夠忍受的，能夠被輕易的恢復而沒有反作用。