先說一個事故案例：
場景：某大型互聯網電商公司，使用一個鏡像倉庫管理所有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 服務器能上傳，運維只接受生產庫裏的鏡像，進行鏡像漏洞掃描，部署到生產環境。有什麼問題歡迎留言討論。