对许多容器来说什么更好：一个大的自定义基础图像或几个小的自定义图像？
为了在单个主机上部署大量的容器（比如说25），最好是在每个应用程序所需的库都有一个大的自定义基本映像，或者为每个容器在每个容器的自定义映像附近进行开发，而每个容器只需要一个库？
Docker的devise模式是保持轻量级（即只有需求），但也有人认为，如果许多容器使用相同的基本映像，那么可以共享“资源”。
以前关于资源共享和大部分Docker信息的问题说容器不共享任何东西。 这个以前关于多基本映像的问题让人相信，无论是大图像还是许多自定义图像，任何重叠的程序都将被共享。在这种情况下，大的基本图像的开销可能会稍高一些，你可以天真地把所有的东西放在一起（即使它是巨大的，磁盘空间是丰富的）
从技术上说，实现大型基础图像与小型定制图像的优缺点是什么？ 如何从同一个基础图像的容器“共享资源”？
Docker映像最终共享其文件系统的公共层。 请记住，Docker使用图像和容器的分层文件系统 。
Docker容器文件系统基于Docker镜像层的顶层，但是在一个容器中进行的更改不会影响Docker镜像或其他容器的文件系统。
Docker容器唯一共享的是Docker主机的内核。
您最终还可以使用Docker数据卷在Docker容器中共享安装点。
为了在单个主机上部署大量的容器（比如说25），最好是在每个应用程序所需的库都有一个大的自定义基本映像，或者为每个容器在每个容器的自定义映像附近进行开发，而每个容器只需要一个库？
这取决于你有更好的标准。 如果你是在追赶速度，那么一个大的基础图像将使事情变得更快，因为它将被拉动一次，基于这个的所有其他docker图像将只需要拉动额外的层。
你也可以假定大部分的改变都是在子图像上完成的，大的基础图像只需要偶尔更新。
使用不同的图像。 @Thomasleveil是正确的，它也可以节省您升级软件的时间，因为您只需重build较小的映像并重新启动较less数量的容器。
虽然，有些情况下，较大的图像是首选。 例如，如果两个小程序需要运行jdk，而jdk是一个非常大的程序，那么在安装所有三个程序的情况下，build立一个大图像可能是有意义的。 但是你不应该启动两个不同的容器来运行程序，你应该在同一个容器内运行这些程序。 您可以使用容器内的主pipe来pipe理多个小程序。