基础镜像的继承管理和如何处理多个技术栈的应用版本？

你的提的这个问题非常好，这个问题是每个企业中大量使用容器的时候都会遇到的。

第一个问题：针对A镜像修改了，B，C和D去级连更新。
提到容器大家都在提持续集成持续部署CI/CD,每个镜像都是由Dockerfile来定义，最终执行docker build命令来镜像构建。推荐选择1-2台服务器专门用来做应用镜像的构建，避免在运行业务容器的服务器上构建镜像影响业务。

系统架构：gitlab存放dockerfile--jenkins job1（A镜像）---jenkins job2（等A构建完成后构建B）--- jenkins job3（等B构建完成后构建C）依次类推......

第二个问题：由于是继承关系，各层软件的版本不同，导致镜像种类就特别多，例如JDK有3种，jboss有三种，那么镜像C就有九种，技术栈深了，命名又成为了问题。

镜像树是这样：baseos--jdk--jboss\tomcat\weblogic---applications，因为dockerfile在gitlab中进行管理，所以不妨你在增加一个文件IMAGE_VERSION=xx，docker build时可以取这个文件中的值，版本号你可以取jboss的版本号（在dockerfile中增加一个EVN jboss-version=xxx就行）。这样即使后面有再多的镜像命名都很好管理了，提前规划好是非常有必要的。

docker镜像管理我建议是以树状结构方式去处理。
以kolla镜像为例

centos7----base ------openstack-base-----nova--base ---nova-api

无法排版；（

由于镜像是分层管理，层级越深，IO性能会降低，因此最好的办法就是各种环境分别制作不同image，如果有一些类似需求的，比如所有环境都使用java7，那么在base先构建java7，再在此基础上建构更上层的技术，一个原则：越通用的东西越先构建
1.尽量将Dockerfile放在空目录中，如果目录中必须有其他文件，则使用.dockerignore文件。
2.避免安装不必须的包
3.每个容器尽量只关注一个功能点。
4.尽量减少最小化镜像层数