docker-registry的定制和性能是怎樣的

本篇內(nèi)容主要講解“docker-registry的定制和性能是怎樣的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“docker-registry的定制和性能是怎樣的”吧!

docker-index

• Web UI

• Meta-data 元數(shù)據(jù)存儲（附注、星級、公共庫清單）

• 訪問認(rèn)證

• token管理

docker-registry

• 存儲鏡像、以及鏡像層的家族譜系

• 沒有用戶賬戶數(shù)據(jù)

• 不知道用戶的賬戶和安全性

• 把安全和認(rèn)證委托給docker-hub來做，用token來保證傳遞安全

• 不需要重新發(fā)明輪子，支持多種存儲后端

• 沒有本地數(shù)據(jù)庫

后端存儲

• 因為鏡像最終是以tar.gz的方式靜態(tài)存儲在服務(wù)端

• 適用于對象存儲而不是塊存儲

• registry存儲驅(qū)動

• 官方支持的驅(qū)動有文件、亞馬遜AWS S3、ceph-s3、Google gcs、OpenStack swift，glance

一次docker pull發(fā)生的交互

1. Client向Index請求，知道從哪里下載samlba/busybox

2. Index回復(fù)：

3. samalba/busybox在RegistryA

4. samalba/busybox的checksum，所有層的token

5. Client向Registry A請求，samalba/busybox的所有層。Registry A負(fù)責(zé)存儲samalba/busybox，以及它所依賴的層

6. Regsitry A向Index發(fā)起請求，驗證用戶/token的合法性

7. Index返回這次請求是否合法

8. Client從registry下載所有的層

9. registry從后端存儲中獲取實際的文件數(shù)據(jù)，返給Client

搭建私有鏡像庫的方案

上面的index，registry，后端存儲3者都是可選的。registry分0.9的python版實現(xiàn)和2.0版的go實現(xiàn)。

認(rèn)證和權(quán)限

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

后端存儲

我們環(huán)境使用的是網(wǎng)易的內(nèi)部的對象存儲NOS，類似于S3。其他的方案沒用過，如果要自己搭，可能靠譜的是ceph-s3。如果在公網(wǎng)環(huán)境或者已經(jīng)購買了公有云服務(wù)，可以考慮自己實現(xiàn)一個registry-對象存儲的驅(qū)動。

集群和分布式

registry本身是無狀態(tài)的，可以水平擴展，然后在前面做ngix的負(fù)載均衡。

性能分析

v1協(xié)議 vs v2協(xié)議

做了性能對比測試，同樣為docker1.6，v2協(xié)議比v1協(xié)議快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

經(jīng)過對比測試，單次docker pull和push的最大耗時在客戶端，也可以觀察到每次做docker pull和push的時候系統(tǒng)CPU占用率都在100%。也就是說50%以上的時間花在本地做的壓縮、計算md5等操作。

并發(fā)分析

并發(fā)測試的結(jié)果是在一個2核2G內(nèi)存的registry-0.9服務(wù)器，直接用文件存儲，大約能負(fù)載50個docker client的并發(fā)。如果換用對象存儲的后端，估計10個docker client的并發(fā)就是極限了。在這方面registry-2.0的并發(fā)能力更強，但對內(nèi)存消耗更大。

Q&A

問：2.0的性能也沒什么變化啊，優(yōu)勢在哪里？ **答：**客戶端優(yōu)化有限，在超過100個節(jié)點同時pull一個鏡像時，2.0服務(wù)端資源占用少。

問：服務(wù)端的并發(fā)瓶頸在哪里？ **答：**服務(wù)端的代碼還沒做過更多的分析，從經(jīng)驗判斷主要還是IO，python的內(nèi)存占用比較多。

問：考慮過多機房image存儲CDN沒？ **答：**這個還真沒考慮過，目前我們的鏡像服務(wù)是個內(nèi)部PaaS平臺用的，只要保證集群所在機房能快速訪問就行。

問：那還不如每機房加緩存？ **答：**是的，也可以考慮registry的mirror機制，用了mirror后可以一個點push，其他點pull。

問：你們的調(diào)度器是自己開發(fā)的嗎？ **答：**我們底層用的是Kubernetes，調(diào)度器做一定的修改，主要是為了保證多個可用域。

問：內(nèi)部的PaaS有沒有做資源限制、網(wǎng)絡(luò)隔離？ **答：**有，目前我們的Docker是跑在kvm上。

問：昨天網(wǎng)易好多服務(wù)斷片了，據(jù)說是網(wǎng)絡(luò)攻擊，那這些服務(wù)有跑在Docker上嗎？ **答：**呵呵，斷片是因為BGP的核心交換機問題，我也很好奇是什么引起的，目前還沒有組織和個人聲稱對此事負(fù)責(zé)。

問：有沒有考慮過nova-docker？ **答：**社區(qū)不是很活躍，我們沒有采用這個方案，但對于中小公司來說這是最快的方案。

問：為啥不考慮自己實現(xiàn)調(diào)度器？ **答：**忙不過來，我們也想做啊，這個放在后面實現(xiàn)。

問：我們準(zhǔn)備在某公有云上跑Docker集群。 **答：**先這么用唄，我覺得Docker的優(yōu)勢就是底層平臺無關(guān)，今后換了底層遷移也沒有那么困難。

到此，相信大家對“docker-registry的定制和性能是怎樣的”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！