在我的IT团队通过docker部署许多应用程序的一个场景中。我们有自己的docker镜像，其他来自互联网注册表。
一个（基本）图像可能是操作系统图像，而另一个（基本）图像可能是运行时框架（对于java，ruby等等），仍然另一个可能是一些特定工具（例如git，一些libs）。然后，最后，我们有应用的图片。
这意味着我们的容器层次结构如下：
FROM个工具和(ADD . /app) FROM框架FROM操作系统每个容器都有自己的Dockerfile。
然后，如果我们需要创建另一个app2，我们可以重新使用框架容器。好。
但是如果app3出现，使用类似的 frameworks2 容器与框架几乎没有区别，那么我们最终得到另一个图像 framework2 < /强>
这使得很难用版本映像及其基础来控制应用程序的版本。
最后，我只选择了一个Dockerfile。来自操作系统的APP，它可以生成所有内容，而Dockerfile正在使用应用程序进行版本控制。
任何人都有其他想法吗？
答案 0 :(得分：1)
我们最喜欢使用docker，但我们没有为图像构建每个应用程序。
我们有一个基本的os镜像，以及许多框架图像，如php52，php53，Python2.7，nodejs等。
尽量让每个框架图像都包含我们的开发人员所需的所有依赖项。
当开发人员需要激活应用程序时，他只需要将他的代码推送到我们的git并从他的开发语言的框架图像中启动容器。因为在我们使用docker之前，我们已经使用了很长一段时间的kvm，并且已经收集了我们的开发人员所需的几乎所有家属，并在不同的kvm图像中打包。所以我们在docker中做到了这一点，他们只需要关注他们的代码。
我认为将每个应用程序构建到图像上太过起伏而且很难进行版本控制。如果您构建一些基础框架映像，并且当它们需要更新依赖项时，您只能更新基础框架映像，并且从新映像重新启动容器比传统虚拟化（如kvm）更快。即使这可能导致图像变大，但我认为它比拥有太多图像更难以控制它们。
我的英语不好，我希望我能完全解释我的想法并提供一些帮助。