大規(guī)模容器鏡像管理方案

隨著容器技術(shù)的深入和廣泛應(yīng)用，容器鏡像的管理成為了一個(gè)關(guān)鍵的環(huán)節(jié)，在大規(guī)模并發(fā)訪問(wèn)鏡像中心的時(shí)候，鏡像倉(cāng)庫(kù)的高可用性、性能及安全性都是值得關(guān)注的問(wèn)題。目前市場(chǎng)上存在一些開(kāi)源及商業(yè)的解決方案，旨在滿足特定場(chǎng)景下的需求，本篇文章就針對(duì)容器鏡像管理的一些場(chǎng)景和方案進(jìn)行梳理。

常用的容器鏡像中心

容器鏡像管理中心是云原生應(yīng)用持續(xù)交付體系中的一個(gè)非常底層且關(guān)鍵的部分，目前市場(chǎng)上主流的容器鏡像管理中心主要有開(kāi)源的 Docker Registry，VMWare Harbor, Sonatype Nexus3 及商業(yè)的JFrog Artifactory，這些產(chǎn)品適用于不同的場(chǎng)景，但都支持相同的標(biāo)準(zhǔn)協(xié)議。

Docker Registry

Docker Registry 應(yīng)該是我們認(rèn)識(shí)最早的容器鏡像中心，是由 Docker 公司開(kāi)發(fā)的一款開(kāi)源軟件，采用 Apache License 開(kāi)源協(xié)議。很多小規(guī)模開(kāi)發(fā)團(tuán)隊(duì)喜歡在私有的開(kāi)發(fā)測(cè)試環(huán)境使用它，因?yàn)樗p巧靈便，非常適合在規(guī)模不大的場(chǎng)景下提供鏡像存儲(chǔ)和分發(fā)服務(wù)。

在著名的公有 Docker 鏡像中心 - Docker Hub 上，我們可以查找到創(chuàng)建Docker Registry 的鏡像，因此 Docker 鏡像中心 registry 也可以以容器方式運(yùn)行，特殊點(diǎn)在于其應(yīng)用本身就是管理容器鏡像的。

VMWare Harbor

Harbor 是一個(gè)開(kāi)源的企業(yè)級(jí) Docker 鏡像中心，也是目前唯一原創(chuàng)于中國(guó)的CNCF 項(xiàng)目。Harbor 所做的事情并不是取代 Docker Registry，而是為其增加了諸多企業(yè)級(jí)特性，如 UI, RBAC, Security 及 Replication 等等。

Harbor 主要分5個(gè)大部分：

• 由 Nginx 服務(wù)器構(gòu)成的反向代理
• 由 Docker 官方的開(kāi)源 registry 鏡像構(gòu)成的容器實(shí)例
• 架構(gòu)中的 core services, 此部分是 Harbor 項(xiàng)目的主體
• 由官方 MySql 鏡像構(gòu)成的數(shù)據(jù)庫(kù)容器
• 運(yùn)行著 rsyslogd 的容器，通過(guò) log-driver 的形式收集其他容器的日志
  

Harbor 在業(yè)內(nèi)使用較為廣泛，作為鏡像管理中心，Harbor 還提供了用戶權(quán)限、鏡像安全及復(fù)制分發(fā)等企業(yè)特性，使得更多企業(yè)用戶在研發(fā)測(cè)試環(huán)境中使用。在很多云廠商產(chǎn)品中也有集成 Harbor 作為整體解決方案的一部分，并且在云原生領(lǐng)域已經(jīng)開(kāi)始支持Helm倉(cāng)庫(kù)，使得云原生應(yīng)用的部署更加便捷。

Sonatype Nexus

Sonatype Nexus 是一款優(yōu)秀的Java私服倉(cāng)庫(kù)，集中管理Java語(yǔ)言的制品，后來(lái)加入了其他語(yǔ)言的支持，如Python, NuGet 及 Docker 鏡像。眾多用戶都是使用其開(kāi)源版本，而并未使用帶高可用特性的企業(yè)版本，于此同時(shí)企業(yè)版也將Helm倉(cāng)庫(kù)納入其 RoadMap，不過(guò)是通過(guò)社區(qū)插件的形式來(lái)支持，由于 Sonatype 主要關(guān)注安全領(lǐng)域，未來(lái)在制品倉(cāng)庫(kù)領(lǐng)域的發(fā)展策略尚不明朗。

JFrog Artifactory

JFrog Artifactory 是目前原生支持開(kāi)發(fā)語(yǔ)言類型最多的制品倉(cāng)庫(kù)，除了傳統(tǒng)的Java、.NET、Python、Php等等還支持Docker、Helm等倉(cāng)庫(kù)，甚至還可以支持Debian/RPM倉(cāng)庫(kù)，針對(duì)應(yīng)用配置管理也有其獨(dú)特的解決方案，深受廣大用戶的歡迎。

Artifactory 除了存儲(chǔ)鏡像還可以記錄鏡像整個(gè)生命周期數(shù)據(jù)，為用戶在鏡像復(fù)用、階段交付及上線發(fā)布時(shí)提供數(shù)據(jù)決策支撐。很多企業(yè)都有鏡像安全審計(jì)需求，該制品倉(cāng)庫(kù)可以清晰地展現(xiàn)容器鏡像中的內(nèi)容，如RUN命令的所有指令，可在鏡像上傳時(shí)檢查指令合規(guī)性。于此同時(shí)，針對(duì)企業(yè)關(guān)心的正反向依賴解析也有很好的支持，可快速分析某個(gè)其他語(yǔ)言的制品(比如java語(yǔ)言JAR包)被哪些鏡像層所引用，以及鏡像層被其他哪些鏡像所公用。

容器鏡像中心面臨的挑戰(zhàn)

容器鏡像中心在實(shí)際生產(chǎn)環(huán)境中依然會(huì)遇到一些棘手的問(wèn)題，比如并發(fā)量比較大的場(chǎng)景下的性能問(wèn)題，安全相關(guān)的問(wèn)題及數(shù)據(jù)熱備容災(zāi)等等。

鏡像中心的多活及容災(zāi)熱備

單節(jié)點(diǎn)容器鏡像中心在高并發(fā)下載場(chǎng)景下會(huì)出現(xiàn)性能瓶頸，從而需要多節(jié)點(diǎn)來(lái)共同分擔(dān)下載請(qǐng)求負(fù)載，因此多活節(jié)點(diǎn)是保證性能的必要手段。由于上傳流量相對(duì)于下載流量小很多，因此常常被人忽略，集群模式下寫入必須滿足數(shù)據(jù)一致性，即必須由Leader負(fù)責(zé)與集群其他節(jié)點(diǎn)的數(shù)據(jù)同步。因此由多活節(jié)點(diǎn)保證并行性能及容災(zāi)備份節(jié)點(diǎn)提供冗余機(jī)制的模型就成為大規(guī)模鏡像管理集群的標(biāo)準(zhǔn)架構(gòu)。

鏡像中心的多數(shù)據(jù)中心投送

容器應(yīng)用在本地?cái)?shù)據(jù)中心內(nèi)會(huì)由于升級(jí)、遷移、回滾等動(dòng)作而需要實(shí)時(shí)拉取鏡像，如果此時(shí)鏡像在異地?cái)?shù)據(jù)中心，那么性能肯定會(huì)收到較大影響，最終用提體驗(yàn)較差。因此，在跨地多數(shù)據(jù)中心部署架構(gòu)下，比如能夠?qū)崿F(xiàn)鏡像的多數(shù)據(jù)中心投送，確保應(yīng)用在本地?cái)?shù)據(jù)中心獲取鏡像，這與緩存的基本思想類似。

鏡像的多數(shù)據(jù)中心投送場(chǎng)景不僅僅局限于應(yīng)用部署，在常見(jiàn)的多地域研發(fā)中心協(xié)同的時(shí)候，也會(huì)存在這種跨數(shù)據(jù)中心依賴的情形，需要能夠按需從異地?cái)?shù)據(jù)中心獲取鏡像，然后再本地?cái)?shù)據(jù)中心進(jìn)行緩存，以提升研發(fā)或構(gòu)建時(shí)依賴獲取的效率。

鏡像的核心歷史元信息管理

鏡像本身也是線上運(yùn)行的交付制品，隱含著很多的背景信息，比如構(gòu)建信息、測(cè)試信息及安全信息等等，這些信息對(duì)于線上應(yīng)用的可用性和穩(wěn)定性都有著千絲萬(wàn)縷的聯(lián)系，這些信息如果沒(méi)有集中進(jìn)行管理，會(huì)導(dǎo)致整個(gè)交付信息流中斷，不利于線上問(wèn)題的排查及對(duì)交付流程的評(píng)估分析。

鏡像的動(dòng)態(tài)及靜態(tài)安全管理

鏡像本身由各個(gè)鏡像層組成，每個(gè)鏡像層又由若干二進(jìn)制文件組成，這些文件中絕大多數(shù)都不是由開(kāi)發(fā)者開(kāi)發(fā)的，而是第三方或者開(kāi)源的內(nèi)容，然而開(kāi)源并不等同于安全，這些安全狀態(tài)未知的內(nèi)容的潛在風(fēng)險(xiǎn)非常大，而這些問(wèn)題的影響范圍如何更加不得而知。

其實(shí)安全不僅僅來(lái)自于外部，內(nèi)部開(kāi)發(fā)的組件在被層層引用時(shí)也可能會(huì)造成整個(gè)業(yè)務(wù)組件發(fā)生問(wèn)題，比如存在內(nèi)存溢出等，甚至是老版本的升級(jí)對(duì)受影響的組件的回歸測(cè)試不完整也會(huì)造成不可預(yù)知的問(wèn)題。

鏡像除了靜態(tài)一些安全因素之外，動(dòng)態(tài)安全也應(yīng)該是受到關(guān)注的內(nèi)容，如鏡像中哪些指令是允許執(zhí)行的，而哪些不允許執(zhí)行的，如何動(dòng)態(tài)學(xué)習(xí)一些頻發(fā)執(zhí)行且需要root權(quán)限的系統(tǒng)調(diào)用(syscall)等行為，給管理者進(jìn)行風(fēng)險(xiǎn)告警和快速阻斷，這些都是生產(chǎn)環(huán)境需要解決的重要課題。

容器應(yīng)用編排及配置管理

容器引用發(fā)布其實(shí)不僅僅設(shè)計(jì)鏡像，而且還設(shè)計(jì)很多容器應(yīng)用本身的參數(shù)，比如實(shí)例數(shù)、服務(wù)、config、Volume等等，這些資源要進(jìn)行一個(gè)統(tǒng)一的編排其實(shí)還是有一定的復(fù)雜度的。大型開(kāi)發(fā)項(xiàng)目人員眾多，各自有各自的習(xí)慣和做法，缺乏有效的標(biāo)準(zhǔn)和工具，很容易造成碎片化、難以復(fù)用共享等問(wèn)題。

Helm 是Kubernetes官方的包管理器(Package Manager)，除了提供Chart的倉(cāng)庫(kù)，還能夠?qū)θ萜鲬?yīng)用的生命周期管理，比如部署、升級(jí)、回滾等，配置其生命周期事件的擴(kuò)展(Hook)及插件機(jī)制，可以很方便地實(shí)現(xiàn)灰度、藍(lán)綠等策略支持，這個(gè)對(duì)于容器應(yīng)用編排有著很大的促進(jìn)作用。

容器應(yīng)用的灰度及藍(lán)綠發(fā)布策略需要一些基礎(chǔ)條件，比如應(yīng)用需建立起與配置的關(guān)聯(lián)關(guān)系，配置需要建立與運(yùn)行環(huán)境中配置Key的關(guān)聯(lián)關(guān)系，這樣才能通過(guò)自動(dòng)化的手段實(shí)現(xiàn)在檢測(cè)到異常時(shí)自動(dòng)回滾，并且配置中心還必須保證高可用。這些基礎(chǔ)條件必須與開(kāi)發(fā)工具、語(yǔ)言無(wú)關(guān)，最好是通過(guò)同一個(gè)平臺(tái)進(jìn)行管理。

容器鏡像存儲(chǔ)及分發(fā)優(yōu)化

容器鏡像是分層存儲(chǔ)的，除了最上層是讀寫層之外，其余的全部是只讀層，從存儲(chǔ)優(yōu)化的角度來(lái)說(shuō)，這時(shí)候就需要在多個(gè)鏡像之間來(lái)共享某些層。在物理層如果鏡像層物理文件依然是目錄遞歸查詢的方式，顯然查詢效率會(huì)大大降低，而比較合適的一種設(shè)計(jì)是通過(guò)建立二進(jìn)制文件的SHA2碼的索引，從而實(shí)現(xiàn)快速定位具體二進(jìn)制文件的物理位置，類似存儲(chǔ)虛擬化的設(shè)計(jì)思路。

容器鏡像分發(fā)解決方案

容器鏡像分發(fā)通常有兩種模式，一種是Push模式，即一個(gè)中心節(jié)點(diǎn)向多個(gè)遠(yuǎn)端節(jié)點(diǎn)進(jìn)行推送，另一種是由遠(yuǎn)端節(jié)點(diǎn)進(jìn)行定時(shí)輪詢，發(fā)現(xiàn)有新的內(nèi)容則拉取到本地。對(duì)于觸發(fā)方式，也分為定時(shí)觸發(fā)和事件觸發(fā)兩種。

邊緣節(jié)點(diǎn)CDN加速

通過(guò)CDN形式進(jìn)行分發(fā)是最直觀的加速方式，在邊緣網(wǎng)絡(luò)提供只讀節(jié)點(diǎn)，供用戶就近訪問(wèn)可以減少中心節(jié)點(diǎn)的訪問(wèn)流量，達(dá)到提升鏡像下載速度的目的。在實(shí)際的分發(fā)架構(gòu)中，制品庫(kù)對(duì)接分發(fā)者，分發(fā)者可以控制分發(fā)策略等，分發(fā)者對(duì)接各個(gè)邊緣節(jié)點(diǎn)(Edge Node)，最后用戶可以從多個(gè)邊緣節(jié)點(diǎn)的負(fù)載均衡進(jìn)行下載，進(jìn)一步提升和下載速度，因?yàn)檫吘壒?jié)點(diǎn)支持緩存機(jī)制。

P2P 分發(fā)

目前通過(guò)P2P協(xié)議分發(fā)鏡像也是一種逐漸成為主流的方案，國(guó)內(nèi)的華為、阿里及百度均在此領(lǐng)域有探索，企業(yè)級(jí)開(kāi)源容器鏡像中心VMWare Harbor也有類似方案。例如阿里的Dragonfly已經(jīng)成為正式的CNCF項(xiàng)目，華為容器技術(shù)團(tuán)隊(duì)也發(fā)表了相應(yīng)的技術(shù)方案。整體來(lái)看，P2P分發(fā)協(xié)議是通過(guò)Controller下發(fā)鏡像分發(fā)任務(wù)，由Tracker去跟蹤各個(gè)客戶端下載的二進(jìn)制層的元數(shù)據(jù)信息，最終進(jìn)行匯總決定任務(wù)是否完成。整體架構(gòu)如下:

Docker鏡像是按照Layer存儲(chǔ)的，意味著不同的鏡像可共享Layer，這種機(jī)制不僅減少了物理存儲(chǔ)空間的消耗，也在分發(fā)時(shí)減少了帶寬的損耗。當(dāng)查詢到需要下載Layer時(shí)先通過(guò)export的方式導(dǎo)出和壓縮Layer文件，然后為其制作BT種子，并由控制器分發(fā)下載任務(wù)給各個(gè)客戶端代理，客戶端代理收到任務(wù)會(huì)檢查要下載Layer本地是否已存在，若不存在則根據(jù)任務(wù)中的Layer相關(guān)信息進(jìn)行下載，然后由Docker Daemon進(jìn)行導(dǎo)入，整個(gè)下載的過(guò)程都是并發(fā)執(zhí)行的。

總結(jié)

隨著容器規(guī)模的快速增長(zhǎng)，容器鏡像中心的高可用性保障遇到的挑戰(zhàn)將會(huì)越來(lái)越大，本質(zhì)上來(lái)說(shuō)也是對(duì)分布式文件系統(tǒng)的可靠性的檢驗(yàn)，企業(yè)級(jí)容器鏡像中心將會(huì)是云原生時(shí)代應(yīng)用基礎(chǔ)設(shè)施的關(guān)鍵組成部分，各種管理架構(gòu)和技術(shù)也在不斷深化和發(fā)展中，期望這篇文章對(duì)于關(guān)注相關(guān)技術(shù)的讀者有所幫助。

總結(jié)

以上是生活随笔為你收集整理的大规模容器镜像管理方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。