【摘要】 本文介紹了Docker Registry服務幾個組件的構成，怎麼規劃定製一個私有鏡像庫，以及鏡像服務pull/push操做性能分析、併發性能分析，幫助你們按照需求你們本身須要的鏡像服務。html
docker-index
- Web UI
- Meta-data 元數據存儲（附註、星級、公共庫清單）
- 訪問認證
- token管理
docker-registry
- 存儲鏡像、以及鏡像層的家族譜系
- 沒有用戶帳戶數據
- 不知道用戶的帳戶和安全性
- 把安全和認證委託給docker-hub來作，用token來保證傳遞安全
- 不須要從新發明輪子，支持多種存儲後端
- 沒有本地數據庫
後端存儲
- 由於鏡像最終是以tar.gz的方式靜態存儲在服務端
- 適用於對象存儲而不是塊存儲
- registry存儲驅動
- 官方支持的驅動有文件、亞馬遜AWS S三、ceph-s三、Google gcs、OpenStack swift，glance
一次docker pull發生的交互
- Client向Index請求，知道從哪裏下載samlba/busybox
- Index回覆：
- samalba/busybox在RegistryA
- samalba/busybox的checksum，全部層的token
- Client向Registry A請求，samalba/busybox的全部層。Registry A負責存儲samalba/busybox，以及它所依賴的層
- Regsitry A向Index發起請求，驗證用戶/token的合法性
- Index返回此次請求是否合法
- Client從registry下載全部的層
- registry從後端存儲中獲取實際的文件數據，返給Client
搭建私有鏡像庫的方案
上面的index，registry，後端存儲3者都是可選的。registry分0.9的python版實現和2.0版的go實現。python
認證和權限
若是鏡像庫不直接提供給用戶使用，僅僅是私有PaaS的一部分，能夠不用index組件，直接上registry就行。index的開源實現包括docker-registry-web，docker-registry-frontend。支持較好的是馬道長的wharf。web
後端存儲
咱們環境使用的是網易的內部的對象存儲NOS，相似於S3。其餘的方案沒用過，若是要本身搭，可能靠譜的是ceph-s3。若是在公網環境或者已經購買了公有云服務，能夠考慮本身實現一個registry-對象存儲的驅動。docker
集羣和分佈式
registry自己是無狀態的，能夠水平擴展，而後在前面作ngix的負載均衡。數據庫
性能分析
v1協議 vs v2協議
| 客戶端swift |
push總時間後端 |
pull總時間緩存 |
| registry-0.9安全 |
388.1服務器 |
80.9 |
| registry-2.0 |
368.4 |
76.1 |
作了性能對比測試，一樣爲docker1.6，v2協議比v1協議快5-6%左右，基本能夠忽略不計。
單次pull和push的性能分析
層|docker push|curl put :-----|:----- layer1|34s|4.3s layer2|325s|44.6s
層|docker pull|curl get :-----|:----- layer1|42s|20.8s layer2|2s|1.4s
通過對比測試，單次docker pull和push的最大耗時在客戶端，也能夠觀察到每次作docker pull和push的時候系統CPU佔用率都在100%。也就是說50%以上的時間花在本地作的壓縮、計算md5等操做。
併發分析
併發測試的結果是在一個2核2G內存的registry-0.9服務器，直接用文件存儲，大約能負載50個docker client的併發。若是換用對象存儲的後端，估計10個docker client的併發就是極限了。在這方面registry-2.0的併發能力更強，但對內存消耗更大。
Q&A
問：2.0的性能也沒什麼變化啊，優點在哪裏？ **答：**客戶端優化有限，在超過100個節點同時pull一個鏡像時，2.0服務端資源佔用少。
問：服務端的併發瓶頸在哪裏？ **答：**服務端的代碼還沒作過更多的分析，從經驗判斷主要仍是IO，python的內存佔用比較多。
問：考慮過多機房image存儲CDN沒？ **答：**這個還真沒考慮過，目前咱們的鏡像服務是個內部PaaS平臺用的，只要保證集羣所在機房能快速訪問就行。
問：那還不如每機房加緩存？ **答：**是的，也能夠考慮registry的mirror機制，用了mirror後能夠一個點push，其餘點pull。
問：大家的調度器是本身開發的嗎？ **答：**咱們底層用的是Kubernetes，調度器作必定的修改，主要是爲了保證多個可用域。
問：內部的PaaS有沒有作資源限制、網絡隔離？ **答：**有，目前咱們的Docker是跑在kvm上。
問：昨天網易好多服務斷片了，聽說是網絡攻擊，那這些服務有跑在Docker上嗎？ **答：**呵呵，斷片是由於BGP的核心交換機問題，我也很好奇是什麼引發的，目前尚未組織和我的聲稱對此事負責。
問：有沒有考慮過nova-docker？ **答：**社區不是很活躍，咱們沒有采用這個方案，但對於中小公司來講這是最快的方案。
問：爲啥不考慮本身實現調度器？ **答：**忙不過來，咱們也想作啊，這個放在後面實現。
問：咱們準備在某公有云上跑Docker集羣。 **答：**先這麼用唄，我以爲Docker的優點就是底層平臺無關，從此換了底層遷移也沒有那麼困難。
若是尚在猶豫，爲何不先行動起來？華爲雲容器，企業級容器應用管理服務，支持Kubernetes社區原生應用和工具，簡化雲上自動化容器運行環境搭建。
https://www.huaweicloud.com/product/cce.html