deployment - docker 镜像层次管理

Question

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

一个(基本)图像可以是 操作系统 图像，而另一个可能是 运行时框架 (对于 java、ruby 等...)，还有一个可能是一些 专用工具 (例如 git，一些库)。然后，最后，我们有了 的图像应用 .

这意味着我们的容器层次结构如下所示:

应用程序FROM工具和 (ADD . /app)

工具FROM框架

框架FROM操作系统

操作系统是基础容器

每个容器都有自己的 Dockerfile。

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

但如果 app3出现了，使用类似的 框架2 容器与 几乎没有区别框架 ，然后我们得到另一个图像 框架2 .

这使得很难通过版本图像及其基础来控制应用程序的版本。

最后，我只选择了一个 Dockerfile。来自 OS 的 APP，它创造了一切，Dockerfile 使用 app 进行版本控制。

有人有其他想法吗？

Answer 1

我们使用 docker 最像你的，但我们没有将每个应用程序构建到一个图像。

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

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

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

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

我的英语不好，希望我能准确地解释我的想法并提供一些帮助。