docker 镜像层次管理

Question

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

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

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

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

每个容器都有自己的 Dockerfile。

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

但是，如果app3出现时，使用类似frameworks2与差异较小的容器框架，然后我们与其它图像最终framework2。

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

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

有人有其他想法吗？

Answer 1

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n