​在我们使用容器云平台的过程中，公司业务的规模会不断发展、各类软件的镜像版本会不停迭代更新，各种版本的镜像变得越来越多，在管理这些镜像的过程中，由于容器云平台的不同开发和运维人员的能力、工作习惯存在较大的差异，出现各类奇葩的镜像命名，造成问题追溯时需要花费大量的时间在问题的定位和沟通层面，降低了运维的效率。

如何统一规范管理容器镜像的命名和版本成为了我们日常工作中必须要解决的一个问题。规范和标准是工作中重要的指引文件，通过规范标准能统一线上容器镜像的名字，防止出现随心所欲的命名，加快容器镜像的定位。本文旨在于介绍容器镜像的命名规范和版本管理，实现“三个方便”原则。方便使用：统一规范的命名规则，使镜像名称能够清晰的描述该镜像的环境信息和用途，方便维护：能够有效地对所有镜像进行展示和查询，定期对无用镜像进行清理，释放存储空间；方便管理：只有镜像名称满足一定规范,才能精确地对所有镜像进行配额管理和权限控制，最终达到为企业降本增效的目的。

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删除，达到将仓库容量维持在一个相对稳定的状态。​