?在我們使用容器云平臺的過程中，公司業務的規模會不斷發展、各類軟件的鏡像版本會不停迭代更新，各種版本的鏡像變得越來越多，在管理這些鏡像的過程中，由于容器云平臺的不同開發和運維人員的能力、工作習慣存在較大的差異，出現各類奇葩的鏡像命名，造成問題追溯時需要花費大量的時間在問題的定位和溝通層面，降低了運維的效率。

如何統一規范管理容器鏡像的命名和版本成為了我們日常工作中必須要解決的一個問題。規范和標準是工作中重要的指引文件，通過規范標準能統一線上容器鏡像的名字，防止出現隨心所欲的命名，加快容器鏡像的定位。本文旨在于介紹容器鏡像的命名規范和版本管理，實現“三個方便”原則。方便使用：統一規范的命名規則，使鏡像名稱能夠清晰的描述該鏡像的環境信息和用途，方便維護：能夠有效地對所有鏡像進行展示和查詢，定期對無用鏡像進行清理，釋放存儲空間；方便管理：只有鏡像名稱滿足一定規范,才能精確地對所有鏡像進行配額管理和權限控制，最終達到為企業降本增效的目的。

1.鏡像倉庫介紹

鏡像倉庫(Repository)是集中存儲容器鏡像（符合OCI規范）的地方，這里有個概念要稍微做一下區分那就是鏡像倉庫與鏡像倉庫服務器(Registry)是兩回事，一個鏡像倉庫服務器可以創建多個鏡像倉庫的空間，例如，quay.io就是一個開源的公共鏡像倉庫，而Quay企業版則是一個開源的企業級的鏡像倉庫服務器，不過其實有時候我們不太需要太過區分這兩個概念。

1.1 公共鏡像倉庫

公共鏡像倉庫主要有quay.io和Docker Hub，使用過docker或podman的我們已經明白了如何從公共鏡像倉庫獲取鏡像，除了獲取鏡像外，我們也可以將自己構建的鏡像存放到公共鏡像倉庫，這樣別人也可以使用我們構建的鏡像了。不過要將鏡像上傳到公共鏡像倉庫，必須先在公共鏡像倉庫的網站上注冊一個賬號，注冊好了之后，可以在本地使用login命令登錄到公共鏡像倉庫，在輸入賬號密碼登錄到公共鏡像倉庫之后，便可以使用push命令把鏡像推送到公共鏡像倉庫了。

1.2 私有鏡像倉庫

在企業級應用環境中，我們不可能將企業的內部容器推送到公共鏡像倉庫中，如果直接使用導出鏡像的方式進行共享又比較麻煩，這時候我們可以自己搭建屬于自己的私有鏡像倉庫服務，用于存儲和發布企業使用的鏡像。

Docker官方提供了registry這個鏡像，可以用于搭建私有鏡像倉庫服務，我們把鏡像拉到本地之后，用該鏡像的容器便可以搭建一個簡易的鏡像倉庫服務。

Quay企業版是一個用于存儲和分發Docker鏡像的企業級Registry服務器，通過添加一些企業必需的功能特性，例如安全、標識和管理等，擴展了簡易的Docker  Distribution。作為一個企業級私有Registry服務器，Quay企業版提供了更好的性能和安全。提升用戶使用Registry構建和運行環境傳輸鏡像的效率。Quay企業版支持安裝在多個Registry節點的鏡像資源復制，鏡像全部保存在私有Registry中，確保數據和知識產權在公司內部網絡中管控。另外，Quay企業版也提供了高級的安全特性，諸如用戶管理，訪問控制和活動審計等。

1.3 云鏡像倉庫

目前主要的云廠商都提供了租戶的鏡像倉庫的服務，如阿里云、百度云、騰訊云等，在這些云平臺上，我們可以創建自己租戶的鏡像倉庫，而且還可以使用到這些鏡像倉庫的加速服務用于加快我們Pull鏡像的速度，如果企業的應用本身就在云上，那么使用云鏡像倉庫服務是一個很好的選擇。

2.鏡像倉庫的命名規范

2.1 基礎鏡像倉庫和業務鏡像倉庫的分離

首先我們為基礎鏡像和業務鏡像做一個定義。基礎鏡像：不包含具體業務的鏡像。主要是為業務提供運行環境的，或者是一些開源項目的官方鏡像。業務鏡像：基于基礎鏡像構建出來的包含具體業務的鏡像，能夠在測試或生產環境中部署和運行。

我們在進行容器化部署實踐過程中，有些通用軟件的鏡像是會被多個項目的應用經常作為基礎鏡像使用，這些基礎軟件不需要我們進行二次開發，在生產環境、測試環境、試運行環境等使用的均為同一鏡像，直接使用穩定版本的鏡像跑起來更改配置就可以提供對外服務了，例如常見的RHEL、OpenJDK、Nginx、Redis、MySQL等，這些常用軟件我們可以放在基礎軟件鏡像庫中。

針對我們自身開發或者合作開發的軟件，一般以項目為單位建立倉庫，一個項目存在一到N個不同的模塊的鏡像，為了方便我們查找和核實鏡像的情況，針對每個項目我們構建相對獨立的鏡像倉庫空間。

2.2 規范鏡像源管理

對于不同倉庫的鏡像文件，不能由開發或者測試員隨意進行上傳，針對不同倉庫的鏡像維護需要明確責任方，例如：由配置管理員負責提供和維護基礎鏡像，需要確保基礎鏡像的版本的安全性、可靠性和穩定性，一般開發和運維人員不能隨意上傳鏡像到此倉庫中；CI流水線：項目持續集成生成的鏡像，自動上傳到我們的項目倉庫中；個人用戶：非配置管理員手動用push命令上傳的測試鏡像到項目倉庫中。

3.鏡像命名規則及其格式

3.1 鏡像名稱格式

我們日常使用的鏡像名稱的通用格式為：DOCKER_REGISTRY/repo/name:tag，各個字段具體含義如下：

DOCKER_REGISTRY：企業統一的Docker Registry地址；

repo：鏡像倉庫，用來管理某一類鏡像；

name：某個鏡像的具體名稱，一般的命名規則為：系統名稱+系統版本+服務名+服務版本（如果公司約定了主要使用的系統名稱和版本，則可以省略系統名稱+系統版本部分，直接使用服務名作為鏡像的名稱）。例如：centos7.6-nginx-1.47。

tag：某個鏡像具體的標簽。例如：2.0。

需要注意的是：鏡像的名稱需要限制為[a-z0-9],其中可以出現的符號為[-._]，不能出現中文以及中文符號，包括鏡像名稱中的: 也必須是英文的冒號，不然創建容器的時候會失敗。

3.2 基礎鏡像命名規則

上文我們說到，我們采用一個獨立的倉庫來管理企業的基礎鏡像，例如使用public倉庫來管理所有的基礎鏡像，下面我們來約定基礎鏡像的命名規則：DOCKER_REGISTRY/repo/name:tag；

repo：統一用public倉庫來進行管理；

name：描述該image中所提供的軟件，各軟件間通過“-”連接；

tag：依次順序描述該image中所提供的軟件的版本，各版本間通過“-”連接。

注意點：

所有Base image除了盡量通過name和tag描述該image中所有的軟件及其版本信息，還需要通過添加description的label，更加詳細地描述image內容。對于非軟件版本的更新（例如：更新安全漏洞），Base image的tag不會更新。為了追蹤Base image的版本信息，需要在image中加入構建該image的Dockerfile的commit id。

例如：

3.3 業務鏡像命名規則

業務鏡像的命名規則以項目為倉庫進行隔離，例如在一個支付項目中，我們使用payment鏡像倉庫，另一個風控項目使用risk-control鏡像倉庫，下面是我們約定的鏡像命名規范：

repo：用項目名作為倉庫，來管理該項目下的所有鏡像。

name：描述該image中所包含的業務。

tag：commit id（前7位）和timestamp（12位，yymmddHHMMSS）組合成唯一標識，中間通過“-”連接。

例如：

4.鏡像的版本管理

版本控制規范用于確定軟件配置項的命名與版本號管理的規則，以確保清楚地、唯一地標識軟件的各個組成部分及其狀態，并建立這些部分之間的一致性關系。

鏡像的版本號我們可以通過直接平移項目的版本號到在鏡像上。用來標識開發、測試、交付階段的不同狀態的產品，版本號格式一般為：

<主版本號>.<次版本號>.<小版本號>-[Build號]

主版本號：立項時設置，在整個項目開發過程中不改變

次版本號：立項時設置，在整個項目開發過程中不改變

小版本號：立項時設置，在整個項目開發過程中不改變

Release號：又叫Build號，內部測試開始之前設置，初始值為0，此后每產生一次小的修改，Release號+1。版本號的一般形式如：1.0.7-101，2.0.0-900

4.1 主版本號設置規則

設置時間：產品立項時設置

設置規則：

新產品立項，主版本號為1

產品構架發生改變，主版本號+1

產品主要組件（比如訂單處理框架）進行重大修改，主版本號+1

產品對外接口協議發生更改，主版本號+1

4.2 次版本號設置規則

設置時間：產品立項時設置

設置規則：

新產品立項，次版本號為0

為處理產品Bug或改進現有功能/性能，對現有功能模塊做大的修改，但不增加新的功能模塊，副版本號+1

為增加產品功能，在原版本產品上增加新的功能模塊，而產品的主體構件未做重大修改，并且產品的主體構件之間的接口協議也未做修改，副版本號+1

為適應不同用戶需求，對產品進行更改，而產品的主體構件未做重大修改，并且產品的主體構件之間的接口協議也未做修改，副版本號+1

當主版本號變更時，副版本號同時置0

4.3 小版本號設置規則

新產品立項，小版本號為0

修復Bug或改進現有功能，但不對現有功能模塊做大的修改，不增加新的功能模塊，小版本號+1

當次版本號變更時，小版本號同時置0

4.4 Build號設置規則

設置時間：產品開發結束，內部測試開始之前

設置規則：

Release號初始值為0

測試過程中，每進行一次修改，Release號+1

5.鏡像倉庫的權限管理

5.1 基礎鏡像倉庫

鏡像倉庫劃分基礎鏡像和項目鏡像倉庫以后，我們下一步需要做的是規范鏡像倉庫的權限管理，對于基礎鏡像倉庫而言，應該要對所有人可見，而且他們都能pull，但是只有配置管理員才有push和delete的權限。

下表中做了基礎的權限角色分配：

5.2 業務鏡像倉庫

項目鏡像倉庫中的內容應該與項目相關的人員才可以看見和pull該項目的所有鏡像，與項目無關人員無權限看見和pull，達到保護項目的私密性的目的。

下表中做了基礎的權限角色分配：

6.鏡像倉庫的容量管理

Docker Registry中沒有提供命令來完成刪除鏡像的功能，日積月累，將會產生許多無用的鏡像，占用大量存儲空間。若要刪除鏡像并回收空間，需要調用 Restful API來完成。我們在管理自己的鏡像倉庫時，必須要明確約定每個image最多保留可配置的tag數量。對于N個的話，按時間排序，優先將老的tag刪除，達到將倉庫容量維持在一個相對穩定的狀態。?