什么是更好的容器：大型自定义基本图像或几个小自定义图像？

Question

为了在单个主机上部署大量容器（比如说25个），最好是拥有一个包含每个应用程序所需的所有库的大型自定义基本映像，或者为每个容器开发自定义映像附近只有必要的库为每个？

Docker的设计模式是保持清晰（即只需要什么），但也有人认为，如果许多容器使用相同的基本图像，那么＆＃34;资源＆＃34;可以分享。

关于Resource Sharing的上一个问题以及大多数Docker信息都表示容器不会共享任何内容。关于Multiple Base Images的上一个问题使人们相信，无论一个大图像还是许多自定义图像，都会共享任何重叠的程序。在这种情况下，大型基础图像的开销可能略高，但开发较少工作，因为你可以天真地把所有东西放在一起（即使它很大，磁盘空间也很丰富）

从技术上讲，实现大型基础图像与小型自定义图像的优缺点是什么？来自同一基本图像的容器如何共享资源＆＃34;？

Answer 1

Docker镜像最终共享其文件系统的公共层。请记住，Docker对图像和容器使用layered filesystem。

Docker容器文件系统基于Docker图像层的顶部，但在一个容器中所做的更改不会影响其Docker镜像或其他容器的文件系统。

Docker容器唯一共享的是内核，它是Docker主机之一。

您最终还可以使用Docker data volumes在Docker容器中共享挂载点。

  

为了在单个主机上部署大量容器（比如说25个），最好是拥有一个包含每个应用程序所需的所有库的大型自定义基本映像，或者为每个容器开发自定义映像附近只有必要的库每个？

这取决于您对更好的标准。如果你追求速度，那么一个大的胖基础图像会使事情变得更快，因为它只被拉一次而所有其他基于这个的 docker图像只需要拉出额外的图层。

您还可以假设大多数更改都是在子图像中完成的，而大胖基础图像只需要偶尔更新。

Answer 2

使用不同的图像。 @Thomasleveil是正确的，它还可以节省您进行软件升级的时间，因为您只需要重建较小的映像并重新启动较少数量的容器。

虽然有些情况下首选较大的图像。例如，如果两个小程序需要运行jdk而jdk是一个非常大的程序，那么在安装了所有三个程序的情况下构建一个大图像可能是有意义的。但是你不应该启动两个不同的容器来运行程序，你应该在同一个容器中运行这些程序。您可以在容器内使用管理程序来管理多个小程序。