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 鏡像，這樣方便作鏡像倉庫的清理，只清理開發庫的鏡像，同時，生產庫只有CI 服務器能上傳，運維只接受生產庫裏的鏡像，進行鏡像漏洞掃描，部署到生產環境。有什麼問題歡迎留言討論。