码头图像层次管理

Question

在我的IT团队通过码头部署许多应用程序的一种情况下。我们有我们自己的码头图片，以及来自互联网注册表的其他图片。

一（基地）图像可能是一个操作系统图像，而另一个可能是一个运行时框架（用于Java，红宝石，等...），还有一个可能是一些专用工具（如git，一些库）。然后，最后，我们有我们的应用程序的图像。

这意味着我们的容器层次结构是这样的：

1. 应用FROM工具和(ADD . /app)
2. 工具FROM框架
3. 框架FROM OS
4. OS为基础容器

每容器有它自己的D ockerfile。

然后如果我们需要创建另一个app2，我们可以重新使用我们的框架容器。好。

但如果app3走来，用很少的差异相似frameworks2容器从框架，那么我们就结束了与其它图像framework2。

这使得使用版本图像及其基础来控制应用程序的版本变得非常困难。

最后，我只选择了一个Dockerfile。从操作系统的应用程序，它使一切，它的Dockerfile与应用版本。

任何人有其他想法？

Answer 1

我们使用最像您的码头工具，但我们并没有将每个应用程序构建到图像上。

我们有一个基本的os镜像，还有很多框架镜像，比如php52，php53，Python2.7，nodejs等等。

尽我们所能，使每个框架图像包含我们的开发人员需要他的开发语言的所有依赖项。

当开发人员需要激活一个应用程序时，他只需将他的代码推送到我们的git中，并从他的开发语言的框架图像中启动容器。因为在我们使用docker之前，我们已经使用kvm很长时间了，并且几乎收集了所有依赖项，我们的开发人员需要在不同的kvm映像中进行打包。所以我们在docker中这样做，他们只需要关注他们的代码。

我认为将每个应用程序构建为一个图像太过沉重，而且几乎没有版本控制。如果您构建了一些基础框架映像，并且他们需要更新依赖项时，则只能更新基础框架映像，并且从新映像重新启动容器比传统虚拟化（例如kvm）更快。尽管这可能会导致图像变大，但我认为它比拥有太多图像并且难以控制它们要好。

我的英文不好，我希望我能准确解释我的想法并做一些帮助。