共計 2318 個字符，預計需要花費 6 分鐘才能閱讀完成。
本篇內容主要講解“docker-registry 的定制和性能是怎樣的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“docker-registry 的定制和性能是怎樣的”吧!
docker-index
Web UI
Meta-data 元數據存儲（附注、星級、公共庫清單）
訪問認證
token 管理
docker-registry
存儲鏡像、以及鏡像層的家族譜系
沒有用戶賬戶數據
不知道用戶的賬戶和安全性
把安全和認證委托給 docker-hub 來做，用 token 來保證傳遞安全
不需要重新發明輪子，支持多種存儲后端
沒有本地數據庫
后端存儲
因為鏡像最終是以 tar.gz 的方式靜態存儲在服務端
適用于對象存儲而不是塊存儲
registry 存儲驅動
官方支持的驅動有文件、亞馬遜 AWS S3、ceph-s3、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 實現。
認證和權限
如果鏡像庫不直接提供給用戶使用，僅僅是私有 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.9388.180.9registry-2.0368.476.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 的優勢就是底層平臺無關，今后換了底層遷移也沒有那么困難。
到此，相信大家對“docker-registry 的定制和性能是怎樣的”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
