容器镜像命名规范及版本管理规范.docx

《容器镜像命名规范及版本管理规范.docx》由会员分享，可在线阅读，更多相关《容器镜像命名规范及版本管理规范.docx（10页珍藏版）》请在优知文库上搜索。

1、公共镜像仓库主要有quay.io和DOCkerHub,使用过docker或podman的我们已经明白了如何从公共镜像仓库获取镜像，除了获取镜像外,我们也可以将自己构建的镜像存放到公共镜像仓库，这样别人也可以使用我们构建的镜像了。不过要将镜像上传到公共镜像仓库，必须先在公共镜像仓库的网站上注册一个账号,注册好了之后，可以在本地使用login命令登录到公共镜像仓库，在输入账号密码登录到公共镜像仓库之后，便可以使用push命令把镜像推送到公共镜像仓库了.1.2私有镜像仓库在企业级应用环境中，我们不可能将企业的内部容器推送到公共镜像仓库中，如果直接使用导出镜像的方式进行共享又比较麻烦,这时候我们可以自

2、己搭建属于自己的私有镜像仓库服务，用于存储和发布企业使用的镜像.Docker官方提供了registry这个穗像，可以用于搭建私有虢像仓库服务，我们把镜像拉到本地之后，用该镜像的容器便可以搭建一个简易的镜像仓库服务.Quay企业版是一个用于存储和分发Docker镜像的企业级Registry服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了简易的DockerDistribution.作为一个企业级私有Registry服务器，QUay企业版提供了更好的性能和安全。提升用户使用RegiStry构建和运行环境传输穗像的效率.Quay企业版支持安装在多个RegiStry节点的镜像资源复

3、制，镜像全部保存在私有RegiStry中，确保数据和知识产权在公司内部网络中管控。另外，QUay企业版也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等.目前主要的云厂商都提供了租户的镜像仓库的服务，如阿里云、百度云、腾讯云等，在这些云平台上，我们可以创建自己租户的镜像仓库，而且还可以使用到这些镜像仓库的加速服务用于加快我们Pull镜像的速度,如果企业的应用本身就在云上，那么使用云镜像仓库服务是一个很好的选择.2镜像仓库的命名规范2.1 基础镜像仓库和业务镜像仓库的分离首先我们为基他镜像和业务镜像做一个定义.基础镜像：不包含具体业务的镜像.主要是为业务提供运行环境的，或者是一些开源项目

4、的官方镜像.业务镜像：基于基桃镜像构建出来的包含具体业务的镜像，能够在测试或生产环境中部署和运行.我们在进行容器化部署实践过程中，有些通用软件的镜像是会被多个项目的应用经常作为基他镜像使用，这些基础软件不翕要我们进行二次开发，在生产环境、测试环境、试运行环境等使用的均为同一镜像，直接使用稳定版本的镜像跑起来更改配舌就可以提供对外服务了，例如常见的RHE1.OPenJDK、Nginx,Redis、MySQ1.等，这些常用软件我们可以放在基础软件镜像库中.针对我们自身开发或者合作开发的软件，一股以项目为单位建立仓库，一个项目存在一到N个不同的模块的镜像，为了方便我们查找和核实抵像的情况，针对每个项

5、目我们构建相对独立的镜像仓库空间.2.2 规范镜像源管理对于不同仓库的镜像文件，不能由开发或者测试员随意进行上传，针对不同仓库的镜像维护需要明瑞责任方，例如：由配餐管理员负责提供和维护基础镜像，需要确保基础境像的版本的安全性、可靠性和稳定性，一般开发和运维人员不能随意上传镜像到此仓库中；Q流水线：项目持续集成生成的镜像，自动上传到我们的项目仓库中；个人用户：非配置管理员手动用push命令上传的测试镜像到项目仓库中.3饯像命名规则及其格式3.1 镜像名称格式我们日前使用的镜像名称的通用格式为：DOCKER_REGISTRYepo/name:tag,各个字段具体含义如下：DoCKER.REGIST

6、RY:企业统一的DockerRegiStry地址；repo:镜像仓库，用来管理某一类镜像；name:某个镜像的具体名称，一般的命名规则为：系统名称+系统版本+服务名+服务版本（如果公司约定了主要使用的系统名称和版本，则可以省略系统名称+系统版本部分，直接使用服务名作为镜像的名称工例如xentos7.6-nginx-l.47.tag:某个镜像具体的标签.例如：2.0.需要注意的是：镜像的名称需要限制为a-z0-9,其中可以出现的符号为卜.，不能出现中文以及中文符号，包括镜像名称中的：也必须是英文的目号，不然创建容器的时候会失败.3.2 基础镜像命名规则上文我们说到我们采用一个独立的仓库来管理企业

7、的基础镜像例如使用public仓库来管理所有的基础镜像，下面我们来约定基础镜像的命名规则：DOCKER_REGISTRY/repo/name:tag;repo:统一用public仓库来进行管理；name:描述该image中所提供的软件，各软件间通过u-连接；tag:依次顺序描述该image中所提供的软件的版本，各版本间通过连接。注意点：所有Baseimage除了尽量通过name和tag描述该image中所有的软件及其版本信息，还需要通过添加description的label,更加详细地描述image内容.对于非软件版本的更新（例如：更新安全漏洞），Baseimage的tag不会更新.为了追踪B

8、aseimage的版本信息，需要在image中加入构建该image的Dockerfile的commitid.例如：第像名称软件和版本PUbliC/tomcat-7:7.0.78Torat7.0.78public/tomcat-8:8.5.15TOmCat8.5.15publicjava-7-tomcat-81.7.65-8.5.15Java1.7.65,Tomcat8.5.15publicnginx-php-71.13.1-7.1.5Nginx1.13.1,Php7.1.53.3 业务镜像命名规则业务镜像的命名规则以项目为仓库进行隔商，例如在一个支付项目中，我们使用Payment镜像仓库，另一

9、个风控项目使用risk-control镜像仓库，下面是我们约定的镜像命名规范：repo:用项目名作为仓库，来管理该项目下的所有镜像.name:描述该image中所包含的业务.tag:Commitid(前7位)和timestamp(12位，yymmddHHMMSS)组合成唯一标识，中间通过连接。例如：像名祢软件和版本pAymentfrontnd7654321-200801040120支付Iffi口中的frontend蛆件,7654321commitID于2020/08/0104:01:20构建paymentbackerdl2S456728020602S8支付项目中的backend爆件，=f123

10、4567commitID于2020/08/0206:0238构建rislc-control/control:132453-200802132415风控Ifl目中的control组件.于132453commitID于2020/08/0213:24:15构建risk-controlmanagc431423200805010408风控项目中的managor组件,于431423commitID于2020/08/0501:0408构建4镜像的版本管理版本控制规范用于确定软件配置项的命名与版本号管理的规则，以确保清楚地、唯一地标识软件的各个组成部分及其状态，并建立这些部分之间的一致性关系.镜像的版本号我们

11、可以通过直接平移项目的版本号到在镜像上.用来标识开发、测试、交付阶段的不同状态的产品，版本号格式一般为：主版本号.次版本号,小版本号-Build号）主版本号：立项时设置，在整个项目开发过程中不改变次版本号：立项时设置，在整个项目开发过程中不改变小版本号：立项时设置，在整个项目开发过程中不改变Release号：又叫Build号，内部测试开始之前设置，初始值为O,此后每产生一次小的修改.Release+l.版本号的一般形式如：1.0.7-101,2.0.0-9004.1 主版本号设置规则设置时间：产品立项时设置设JS规则：新产品立项，主版本号为1产品构架发生改变，主版本号+1产品主要组件（比如订单

12、处理槌架）进行重大修改，主版本号+1产品对外接口协议发生更改，主版本号+14.2 次版本号设置规则设百时间：产品立项时设置设置规则：新产品立项，次版本号为O为处理产品BUg或改进现有功能/性能，对现有功能模块做大的修改，但不增加新的功能模块，副版本号+1为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构件未做正大修改，并且产品的主体构件之间的接口协议也未做修改，副版本号+1为适应不同用户需求，对产品进行更改，而产品的主体构件未做重大修改，并且产品的主体构件之间的接口协议也未做修改，副版本号+1当主版本号变更时，副版本号同时直O4.3 小版本号设置规则新产品立项，小版本号为O修且Bu

13、g或改进现有功能，但不对现有功能模块做大的修改，不增加新的功能模块，小版本号+1当次版本号变更时，小版本号同时置O4.4 Build号设置规则设置时间：产品开发结束，内部测试开始之前设置规则：Release号初始值为O测试过程中，每进行一次修改，ReIeaSe号+15镜像仓库的权限管理5.1 基础镜像仓库镜像仓库划分基础潢像和项目镜像仓库以后，我们下一步需要做的是规范镜像仓库的权限管理，对于基础镜像仓库而言,应该要对所有人可见，而且他们都能pull,但是只有配置管理员才有push和delete的权限。下表中做了基础的权限角色分配：角色SfiPullPush州除配管理员/开发人员XguestXX

14、5.2 业务镜像仓库项目镜像仓南中的内容应该与项目相关的人员才可以看见和PUIl该项目的所有镜像，与项目无关人员无权限看见和pull,达到保护项目的私密性的目的。下表中做了基他的权限角色分配:角色*PullPushM配置管理员开发人员XguestXXXX6镜像仓库的容金管理DockerRegistry中没有提供命令来完成删除镜像的功能，日积月累，将会产生许多无用的镜像，占用大量存储空间.若要刷除潢像并回收空间，需要调用RestfulAPl来完成.我们在管理自己的镜像仓库时，必须要明确约定每个image最多保雷可配置的tag数量.对于N个的话，按时间排序，优先将老的tag删除,达到将仓库容最维持在一个相对稳定的状态