docker图像层次pipe理
在我的IT团队通过docker部署许多应用程序的一种情况下。 我们有我们自己的docker图像，与其他来自互联网registry的图像。
一个（基本）图像可能是一个操作系统的图像，而另一个可能是一个运行时框架 （对于Java，ruby等…），另一个可能是一些特定的工具 （如混帐，一些库）。 然后，最后，我们有我们的应用程序的图像。
这意味着我们的容器层次看起来像：
- 应用程序
FROM工具和(ADD . /app) - 工具
FROM框架 - 框架
FROM操作系统 - OS是基本容器
每个容器都有自己的Dockerfile。
那么如果我们需要创build另一个app2 ，我们可以重新使用我们的框架容器。 好。
但是，如果app3出现，使用一个与框架差别不大的类似frameworks2容器，那么我们最终会得到另一个图像框架2 。
这使得使用版本图像及其基础来控制应用程序的版本变得非常困难。
最后，我只select了一个Dockerfile。 从操作系统的应用程序，它使一切，它的Dockerfile是与应用程序版本。
任何人有其他的想法？
我们最喜欢使用docker工具，但是我们没有将每个应用程序都构build到一个图像上。
我们有一个基本的os镜像，以及许多框架镜像，比如php52，php53，Python2.7，nodejs等等。
并尽力使每个框架图像包含我们的开发人员所需的开发人员所需的所有依赖项。
当开发人员需要激活一个应用程序时，他只需要将他的代码推送到我们的git中，并从他的开发语言的框架图像中启动容器。 因为在我们使用docker之前，我们已经使用kvm很长时间了，并且收集了几乎所有的依赖项，我们的开发人员需要在不同的kvm映像中打包。 所以我们在docker中这样做，他们只需要关注他们的代码。
我认为将每个应用程序构build为一个图像太过厚重，而且几乎不能进行版本控制。 如果您构build了一些基础框架映像，并且需要更新依赖项，则只能更新基础框架映像，并且从新映像重新启动容器比传统虚拟化（如kvm）更快。 尽pipe这可能会导致图像变大，但是我觉得这比图像太多，难以控制。
我的英文不好，希望我能正确地解释我的想法并做一些帮助。