先說一個事故案例：

場景 ：某大型網際網路電商公司，使用一個映象倉庫管理所有 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 生產環境的虛擬倉庫，該倉庫提供對外的服務。

好的，瞭解了映象升級，虛擬倉庫的概念之後，你可能會問，如何做這些倉庫的許可權配置呢？

我畫了下面的表格，來幫助你理解不同團隊對不同成熟度的映象倉庫應該基本什麼樣的許可權。

對應許可權	開發庫	測試庫	生產庫
開發	上傳，下載，修改，標籤	無	無
測試	無	上傳，下載，修改，標籤	無
運維	無	無	上傳，下載，修改，標籤
CI   伺服器	上傳，下載，修改，標籤	上傳，下載，修改，標籤	上傳，下載，修改，標籤

開發只對開發庫有 CRUD 許可權，對生產庫無許可權，這樣就能避免開發對生產庫的誤操作。測試團隊只接受透過開發自測，升級到測試庫的映象，這樣降低測試團隊的無效測試率。運維對生產庫有 CRUD 的許可權。那麼這裡你可能注意到了 CI 伺服器對三個倉庫都有許可權，那是應為映象的跨倉庫複製，打標籤，都是透過 CI 伺服器自動化完成的。

總結

透過開發，測試，生產的三庫分離設定，來存放不同成熟度的 Docker 映象，這樣方便做映象倉庫的清理，只清理開發庫的映象，同時，生產庫只有 CI 伺服器能上傳，運維只接受生產庫裡的映象，進行映象漏洞掃描，部署到生產環境。有什麼問題歡迎留言討論。