docker-registry的定製和性能分析

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發生的交互

1. Client向Index請求，知道從哪裏下載samlba/busybox
2. Index回覆：
3. samalba/busybox在RegistryA
4. samalba/busybox的checksum，全部層的token
5. Client向Registry A請求，samalba/busybox的全部層。Registry A負責存儲samalba/busybox，以及它所依賴的層
6. Regsitry A向Index發起請求，驗證用戶/token的合法性
7. Index返回此次請求是否合法
8. Client從registry下載全部的層
9. registry從後端存儲中獲取實際的文件數據，返給Client

搭建私有鏡像庫的方案

上面的index，registry，後端存儲3者都是可選的。registry分0.9的python版實現和2.0版的go實現。

認證和權限

若是鏡像庫不直接提供給用戶使用，僅僅是私有PaaS的一部分，能夠不用index組件，直接上registry就行。index的開源實現包括docker-registry-web，docker-registry-frontend。支持較好的是馬道長的wharf。

後端存儲

咱們環境使用的是網易的內部的對象存儲NOS，相似於S3。其餘的方案沒用過，若是要本身搭，可能靠譜的是ceph-s3。若是在公網環境或者已經購買了公有云服務，能夠考慮本身實現一個registry-對象存儲的驅動。

集羣和分佈式

registry自己是無狀態的，能夠水平擴展，而後在前面作ngix的負載均衡。

性能分析

v1協議 vs v2協議

客戶端	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的優點就是底層平臺無關，從此換了底層遷移也沒有那麼困難。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝