docker 镜像层次管理

Question

在一种情况下，我的 IT 团队通过 docker 部署了许多应用程序。我们有自己的 docker 镜像，还有来自互联网注册表的其他镜像。

一个（基本）图像可以是一个操作系统图像，而另一个可以是一个运行时框架（用于 java、ruby 等），并且仍然另一个可能是一些特定工具（例如 git、一些库）。最后，我们有我们的应用程序的图像。

这意味着我们的容器层次结构看起来像：

1. 应用程序FROM 工具和(ADD . /app)
2. 工具FROM 框架
3. 框架FROM操作系统
4. 操作系统是基础容器

每个容器都有自己的 Dockerfile。

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

但是如果出现app3，使用与framework几乎没有区别的类似frameworks2容器，那么我们最终会得到另一个图像framework2.

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

最后，我只选择了一个 Dockerfile。来自 OS 的 APP，它可以制作一切，并且 Dockerfile 正在使用应用程序进行版本控制。

有人有其他想法吗？

Answer 1

我们使用的 docker 最像你的，但我们并没有将每个应用都构建到一个映像中。

我们有一个基础的操作系统镜像，以及多个框架镜像，如php52、php53、Python2.7、nodejs等。

并尽最大努力使每个框架映像都包含我们的开发人员对其开发语言所需的所有依赖项。

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

我认为将每个应用程序都构建到一个图像太繁重，几乎没有进行版本控制。如果你构建了一些基础框架镜像，当他们需要更新依赖时，你只能更新你的基础框架镜像，并且从一个新的镜像重新启动一个容器比传统的虚拟化比如 kvm 更快。尽管这可能会导致图像变大，但我认为这总比图像过多且难以控制要好。

我的英文不好，希望能准确的解释一下我的想法并帮上忙。