在一个场景中，我的IT团队通过docker部署了许多应用程序。我们有自己的docker图片，其他图片来自互联网注册中心。
一个（基本）映像可以是操作系统映像，而另一个映像可以是运行时框架（用于java、ruby等），还有一个映像可能是一些特定的工具。最后，我们有了应用程序的图像。
这意味着我们的容器层次结构看起来像：
- 应用程序
FROM工具和(ADD . /app) - 工具
FROM框架 - 框架
FROM操作系统 - OS是基本容器
每个容器都有自己的Dockerfile。
然后，如果我们需要创建另一个app2，我们可以重用框架容器。好的。
但是，如果app3出现，使用类似的framework2容器，与框架几乎没有差异，那么我们最终会得到另一个图像framework2。
这使得很难用版本图像及其基础来控制应用程序的版本。
最后，我只选择了一个Dockerfile。应用程序来自操作系统，它制造一切，它Dockerfile正在使用应用程序进行版本控制。
有人有其他想法吗？
我们使用的docker与您的最相似，但我们并没有将每个应用程序都构建到一个映像中。
我们有一个基本的os镜像，还有很多框架镜像，比如php52、php53、Python2.7、nodejs等等
并尽最大努力使每个框架映像包含我们的开发人员需要的开发语言的所有依赖项。
当开发人员需要激活一个应用程序时，他只需要将代码推送到我们的git，并从他的开发语言的框架映像启动容器。因为在使用docker之前，我们已经使用了很长一段时间的kvm，并且已经收集了我们的开发人员所需要的几乎所有依赖项，并打包在不同的kvm映像中。所以我们在docker中做到了这一点，他们只需要专注于他们的代码。
我认为把每个应用程序都构建成一个图像太笨重了，而且很难进行版本控制。如果您构建了一些基本框架映像，并且当它们需要更新从属映像时，您只能更新基本框架映像。从新映像重新启动容器比传统的虚拟化（如kvm）更快。尽管这可能会导致图像变大，但我认为这总比图像太多而难以控制要好。
我的英语不好，我希望我能准确地解释我的想法，并提供一些帮助。