Docker鏡像倉庫要分庫分權(quán)限的原因是什么

Docker鏡像倉庫要分庫分權(quán)限的原因是什么？針對這個問題，今天小編總結(jié)這篇有關(guān)Docker鏡像的文章，希望能幫助更多想解決這個問題的朋友找到更加簡單易行的辦法。

先說一個事故案例：

場景：某大型互聯(lián)網(wǎng)電商公司，使用一個鏡像倉庫管理所有Docker鏡像。開發(fā)者打出的鏡像上傳到唯一的鏡像庫，測試通過后，運維環(huán)境的 Kubernetes 直接從這個庫里拉取鏡像，所有人對鏡像庫都有 CRUD 的權(quán)限。
事故：由于鏡像存儲容量過大，開發(fā)者打算清理下Snapshot 的鏡像，在鏡像清理的時候，誤將生產(chǎn)環(huán)境的鏡像進行了刪除，導致上線出現(xiàn)問題。本質(zhì)是鏡像缺乏成熟度的區(qū)分管理，
解決辦法：為通一個項目的鏡像通過升級，放在3個鏡像倉庫內(nèi)，開發(fā)庫，測試庫，生產(chǎn)庫。不同的鏡像庫對應(yīng)管理不同成熟度的鏡像。

從上圖可以看到，Michael Huttermann 在2012年展示的流水線質(zhì)量關(guān)卡的概念。上圖的意思，是每個流水線必須具備一定的質(zhì)量關(guān)卡，特別是在測試環(huán)境，也就是說，未經(jīng)自動化測試的 Docker 鏡像，是不能被放到線上環(huán)境運行的。為了區(qū)分不同成熟度的制品，需要為不同成熟度階段的制品建立不同的制品倉庫，也就是開發(fā)庫，測試庫，生產(chǎn)庫。

根據(jù)鏡像成熟度區(qū)分的原則，我推薦上圖的鏡像存儲方式。我們?yōu)殚_發(fā)者提供鏡像的開發(fā)庫，供他們將打好的鏡像 Push 到開發(fā)庫，推送到鏡像庫之后，即開始開發(fā)者自我驗證功能。自我驗證通過后，鏡像倉庫會復制（也叫Promote升級）到測試庫，隨后調(diào)用測試環(huán)境的 Jenkins 流水線，執(zhí)行自動化測試案例，當測試完成后，記錄測試結(jié)果的關(guān)鍵信息到該鏡像的元數(shù)據(jù)上。同時通知測試人員進行 UAT 測試，待所有的測試（人工+自動化）完成之后，邊將該鏡像升級到發(fā)布庫，也叫生產(chǎn)庫。
現(xiàn)在我們?yōu)槊總€項目建立了三個鏡像倉庫，那么你可能會問，難道我需要配置3個鏡像倉庫地址嗎？這里我們推薦下面的鏡像倉庫工作模型。

來看看上述模型的工作原理：
?   首先需要有一個虛擬倉庫（Virtual Repository）來聚合三個本地倉庫（Local）和遠程倉庫（Remote）。目前JFrog Artifactory支持了虛擬倉庫，為研發(fā)團隊提供唯一的 Docker 鏡像中心訪問地址，而不需要在多個鏡像中心之間切換。
?   開發(fā)者通過遠程倉庫用于代理和緩存 DockerHub 的官方鏡像源。
?   鏡像通過 Jenkins流水線，在三個本地倉庫之間進行升級。
?   終端用戶，例如生產(chǎn)環(huán)境的 Docker 客戶端，訪問 Docker 生產(chǎn)環(huán)境的虛擬倉庫，該倉庫提供對外的服務(wù)。
好的，了解了鏡像升級，虛擬倉庫的概念之后，你可能會問，如何做這些倉庫的權(quán)限配置呢？
我畫了下面的表格，來幫助你理解不同團隊對不同成熟度的鏡像倉庫應(yīng)該基本什么樣的權(quán)限。

開發(fā)只對開發(fā)庫有CRUD權(quán)限，對生產(chǎn)庫無權(quán)限，這樣就能避免開發(fā)對生產(chǎn)庫的誤操作。測試團隊只接受通過開發(fā)自測，升級到測試庫的鏡像，這樣降低測試團隊的無效測試率。運維對生產(chǎn)庫有CRUD 的權(quán)限。那么這里你可能注意到了 CI 服務(wù)器對三個倉庫都有權(quán)限，那是應(yīng)為鏡像的跨倉庫復制，打標簽，都是通過CI 服務(wù)器自動化完成的。

看完上述內(nèi)容，你們對Docker鏡像倉庫要分庫分權(quán)限的原因大概了解了嗎？如果想了解更多相關(guān)文章內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！