您好,登錄后才能下訂單哦!
本篇內容主要講解“docker-registry的定制和性能是怎樣的”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“docker-registry的定制和性能是怎樣的”吧!
Web UI
Meta-data 元數據存儲(附注、星級、公共庫清單)
訪問認證
token管理
存儲鏡像、以及鏡像層的家族譜系
沒有用戶賬戶數據
不知道用戶的賬戶和安全性
把安全和認證委托給docker-hub來做,用token來保證傳遞安全
不需要重新發明輪子,支持多種存儲后端
沒有本地數據庫
因為鏡像最終是以tar.gz的方式靜態存儲在服務端
適用于對象存儲而不是塊存儲
registry存儲驅動
官方支持的驅動有文件、亞馬遜AWS S3、ceph-s3、Google gcs、OpenStack swift,glance
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實現。
如果鏡像庫不直接提供給用戶使用,僅僅是私有PaaS的一部分,可以不用index組件,直接上registry就行。index的開源實現包括docker-registry-web,docker-registry-frontend。支持較好的是馬道長的wharf。
我們環境使用的是網易的內部的對象存儲NOS,類似于S3。其他的方案沒用過,如果要自己搭,可能靠譜的是ceph-s3。如果在公網環境或者已經購買了公有云服務,可以考慮自己實現一個registry-對象存儲的驅動。
registry本身是無狀態的,可以水平擴展,然后在前面做ngix的負載均衡。
客戶端 | push總時間 | pull總時間 |
---|---|---|
registry-0.9 | 388.1 | 80.9 |
registry-2.0 | 368.4 | 76.1 |
做了性能對比測試,同樣為docker1.6,v2協議比v1協議快5-6%左右,基本可以忽略不計。
層|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的并發能力更強,但對內存消耗更大。
問: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的優勢就是底層平臺無關,今后換了底層遷移也沒有那么困難。
到此,相信大家對“docker-registry的定制和性能是怎樣的”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。