容器学习：容器镜像命名规范及版本管理规范在管理这些镜像的过程中，由于容器云平台不同开发运维人员的能力和工作习惯存在较大差异，会出现各种奇怪的镜像命名，这跟踪问题时会花费很多钱。大量时间花在问题定位和沟通上，降低运维效率。如何统一管理容器镜像的命名和版本，成为我们日常工作中必须解决的问题。规范标准是工作中的重要指导文件。通过标准化，可以统一线上容器镜像的名称，防止任意命名，加快容器镜像的定位。本文旨在介绍容器镜像的命名规范和版本管理，实现“三便”原则。易用：统一规范的命名规则，使镜像名称能够清晰描述镜像的环境信息和用途，方便维护：可以有效展示和查询所有镜像，定期清理无用镜像，释放存储空间；方便管理：只有镜像名称符合一定规范，才能对所有镜像进行准确的配额管理和权限控制，最终达到为企业降本增效的目的。1.镜像仓库简介镜像仓库（Repository）是集中存放容器镜像（符合OCI规范）的地方。这里有个概念需要稍微区分一下，就是镜像仓库和镜像仓库服务器（Registry）是两个不同的东西，一个镜像仓库服务器可以创建多个镜像仓库空间。比如quay.io是一个开源的公共镜像仓库，QuayEnterpriseEdition是一个开源的企业级镜像仓库服务器。然而，有时我们并不需要区分这两个概念。1.1公共镜像仓库公共镜像仓库主要有quay.io和DockerHub。我们使用过docker或者podman了解过如何从公共镜像仓库获取镜像。除了获取镜像之外，我们还可以将自己构建的镜像存储在公共镜像仓库中，这样其他人也可以使用我们构建的镜像。但是，要将镜像上传到公共镜像仓库，必须先在公共镜像仓库的网站上注册一个账号。注册后，可以在本地使用login命令登录公共镜像仓库。输入账号密码登录公共镜像仓库后，可以使用push命令将镜像推送到公共镜像仓库。1.2私有镜像仓库在企业级应用环境中，我们不可能将企业内部的容器推送到公共镜像仓库中。如果直接导出镜像共享比较麻烦，这时候我们可以搭建自己的私有镜像仓库服务，用于存储和发布企业使用的镜像。Docker官方提供了registry镜像，可以用来搭建私有镜像仓库服务。我们在本地拉取镜像后，就可以使用镜像容器搭建一个简单的镜像仓库服务。QuayEnterpriseEdition是用于存储和分发Docker镜像的企业级注册服务器。它通过添加一些企业需要的功能（例如安全性、识别和管理）来扩展简单的DockerDistribution。作为企业级私有注册服务器，QuayEnterpriseEdition提供了更好的性能和安全性。提高用户在运行环境中使用Registry构建和传输镜像的效率。Quay企业版支持复制安装在多个Registry节点上的镜像资源。所有图像都存储在私有注册表中，以确保数据和知识产权在公司内部网络中得到管理和控制。此外，QuayEnterpriseEdition还提供高级安全功能，例如用户管理、访问控制和活动审计。1.3云镜像仓库目前各大云厂商都为租户提供镜像仓库服务，如阿里云、百度云、腾讯云等，在这些云平台上，我们可以创建自己的租户镜像仓库，我们也可以使用这些镜像仓库的加速服务就是用来加快我们Pull镜像的速度的。如果企业本身的应用在云端，那么使用云镜像仓库服务是一个不错的选择。2.镜像仓库的命名规范2.1基础镜像仓库和业务镜像仓库的分离首先定义基础镜像和业务镜像。基础镜像：不包含特定服务的镜像。主要是为业务提供运行环境，或者是一些开源项目的官方镜像。业务镜像：基于基础镜像构建的包含特定服务的镜像，可以在测试或生产环境中部署运行。在我们容器化部署实践的过程中，一些通用的软件镜像经常被多个项目的应用作为基础镜像使用。这些基础软件不需要我们进行二次开发。在生产环境、测试环境、试运行环境中都使用同一个镜像，可以直接使用稳定版镜像运行和更改配置对外提供服务，比如常见的RHEL、OpenJDK、Nginx、Redis、MySQL等，我们可以把这些常用软件放在基础软件镜像库中间。对于自己开发或者合作开发的软件，我们一般都是以项目为单位建库。一个项目中不同模块有1到N个镜像。为了方便我们查找和验证镜像，我们为每个项目构建了相对独立的模块。镜像仓库空间。2.2规范图片源管理对于不同仓库的图片文件，开发人员或测试人员不能随意上传。对于不同仓库的形象维护，需要明确责任方。例如配置管理员负责提供和维护基础镜像，需要保证基础镜像最新版本的安全性、可靠性和稳定性，一般开发和运维人员无法上传镜像到这个仓库随意；CI管道：项目持续集成生成的镜像自动上传到我们的项目仓库；个人用户：非配置管理员通过push命令手动上传到项目仓库的测试镜像。3.镜像命名规则及其格式3.1镜像名称格式我们日常使用的镜像名称的一般格式为：DOCKER_REGISTRY/repo/name:tag，各字段的具体含义如下：DOCKER_REGISTRY：统一的DockerRegistry地址企业的；repo：镜像仓库，用于管理某类镜像；name：某个镜像的具体名称，一般的命名规则是：系统名称+系统版本+服务名称+服务版本（如果公司对主系统名称和版本有约定，可以省略系统名称+系统版本部分，直接使用服务名称作为镜像名称）。例如：centos7.6-nginx-1.47。tag：某张图片的具体标签。例如：2.0。需要注意的是，图片的名称需要限定为[a-z0-9]，里面可以出现的符号是[-._]，不能出现中文和中文符号，包括:中的:镜像名称也必须是英文冒号，否则创建容器会失败。3.2基础镜像命名规则上面我们提到，我们使用一个独立的仓库来管理企业的基础镜像，比如使用一个公共仓库来管理所有的基础镜像。让我们约定基本镜像的命名规则：DOCKER_REGISTRY/repo/name:tag;repo：使用公共仓库统一管理；名称：描述图中提供的软件，各个软件之间用“-”连接；tag：依次描述图中提供的软件版本，每个版本用“-”连接。注意：所有Base镜像除了要尽量通过名称和标签来描述镜像中的所有软件及其版本信息外，还需要通过添加描述标签的方式对镜像内容进行更详细的描述。对于非软件版本更新（例如：更新安全漏洞），Baseimage的tag不会更新。为了跟踪Base镜像的版本信息，需要在镜像中添加构建镜像的Dockerfile的commitid。例如：3.3业务镜像的命名规则业务镜像的命名规则以项目为仓库进行隔离。比如在一个支付项目中，我们使用支付镜像仓库，另一个风控项目使用风控镜像仓库。以下是我们约定的镜像命名约定：repo：使用项目名作为仓库，管理项目下的所有镜像。名称：描述图像中包含的业务。tag：Commitid（前7位）和timestamp（12位，yymmddHHMMSS）组合成一个唯一标识，用“-”连接。例如：4.镜像的版本管理版本控制规范用于确定软件配置项的命名和版本号管理规则，以保证软件的各个组成部分及其状态得到清晰、唯一的标识，以及它们之间的关系这些部分成立。一致性关系。镜像的版本号我们可以直接将项目的版本号翻译成镜像。用于识别处于不同开发、测试和交付阶段的产品。版本号的格式一般为：<主版本号>.<次版本号>.<次版本号>-[Buildnumber]主版本号：在项目建立时设置，期间不要更改次版本号整个项目开发过程：在项目建立时设置，在整个项目开发过程中不更改次要版本号：在项目建立时设置，在整个项目开发过程中不更改Release号：也称为Buildnumber，内部在测试开始前设置，初始值为0，之后每做一个小的修改，Releasenumber都会+1。版本号的一般形式如下：1.0.7-101,2.0.0-9004.1主版本号设置规则设置时间：设置产品项目建立时的设置规则：新产品项目建立，主版本号为1产品结构发生变化，主版本号+1产品主要组件（如订单处理框架）发生重大改版，主版本号+1产品对外接口协议发生变化,主版本号+14.2次版本号设置规则设置时间:产品立项时设置设置规则:新产品立项,次版本号为0用于处理产品BUG或改进现有功能/性能,以及对现有功能模块进行重大改动，但不增加新的功能模块。小版本号+1是为了增加产品功能，在产品原版本上增加了新的功能模块，但产品的主要组件没有做明显的修改，产品主要组件之间的接口协议有没有被修改。小版本号+1是为了适应不同的用户需求。主组件未进行重大修改，产品主要组件之间的接口协议未修改，次版本号+1主版本号变化时，同时设置次版本号04.3小版本号设置规则新产品项目建立，小版本号为0，用于修复bug或完善现有功能，但不对现有功能模块进行重大改动，不增加新的功能模块，小版本号+1为小版本时版本号变更，次版本号同时设置为04.4Buildnumber规则设置时间：产品开发结束，内测开始前。设定规则：Release编号初始值为0，测试时每修改一次，Release编号+15。镜像仓库的权限管理5.1基础镜像仓库镜像仓库分基础镜像和项目镜像仓库之后，下一步要做的就是规范镜像仓库的权限管理。对于基础镜像仓库，应该是对所有人可见的，可以拉取，但是只有配置管理员可以推送和删除权限。基本权限角色分配如下表：5.2业务镜像仓库项目镜像仓库中的内容只允许与项目相关的人看到和拉取，项目的所有镜像都可以被不相关的人看到和拉取与项目相关，从而达到保护项目隐私的目的。基本权限和角色分配如下表：6.镜像仓库容量管理DockerRegistry没有提供完成删除镜像功能的命令。时间长了，会产生很多无用的镜像，占用大量的存储空间。删除图片回收空间需要调用RestfulAPI来完成。我们在管理自己的镜像仓库时，一定要明确约定每个镜像保留最大数量的可配置标签。对于N，按时间排序，先删除旧的标签，以保持存储容量在一个相对稳定的状态。
