Docker鏡像倉庫要分庫分權限的原因是什么

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

先說一個事故案例：

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

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

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

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

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

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