基于此,我的本地系统需要600 MB,而所有Docker镜像则需要7 GB。
这种方法是否正确?应该在每个图像中添加来自DockerHub的“OpenJDK”吗?
没错。虽然你可能会想知道是否仅使用JRE就足够了。
即使目标计算机可能已经安装了JDK,为什么映像的大小仍然很大?
你比较了不可比较的事物:本地环境(除了生产机器之外)与集成/生产环境。
在集成/生产环境中,您的应用程序负载可能很高,并且通常建议在应用程序之间进行隔离。因此,在此处,您希望通过每台计算机(裸机、VM或容器)托管最少数量的应用程序(UI/服务)以防止应用程序之间出现副作用:共享库不兼容性、软件升级副作用、资源耗尽、应用程序之间的链式故障…
在本地环境中,应用程序的负载相当低,并且应用程序之间的隔离通常不是一个严重的问题。因此,在本地机器上可以托管多个应用程序(ui/services),并且还可以共享操作系统提供的一些公共库/依赖项。
虽然您可以这样做,但将所有内容混合和共享在本地真的是一个好习惯吗?
我认为不是因为:
1)本地机器不是垃圾箱:您整天都在使用它。更加干净,您的开发效率就越高。例如:在本地托管的应用程序之间可能存在JDK/JRE的差异,某些应用程序使用的文件夹可能具有相同的位置,数据库版本可能不同,应用程序可能安装了不同的Java服务器(Tomcat、Netty、Weblogic)和/或不同版本...
通过容器,这不是问题:根据您的要求安装和删除所有内容。
2)环境(从本地到生产)应尽可能接近,以便简化整个集成-部署链,并及早检测问题,而不仅仅是在生产中检测。
顺便说一句,在本地实现这一点需要为开发人员提供真正的机器。
所有事物都有代价,但实际上并不昂贵
除了隔离(硬件和软件资源),容器还带来其他优点,如快速部署/取消部署、可扩展性和故障转移友好(例如:Kubernetes 依赖于容器)。
隔离、快速性、可扩展性和鲁棒性友好都有一个代价:不能在容器之间共享任何资源(操作系统、库、JVM 等)。
这意味着,即使您在应用程序中使用完全相同的操作系统、库、JVM,每个应用程序也必须将它们包含在其镜像中。
这很昂贵吗?
实际上并不是:官方镜像通常依赖于 Alpine(轻量级 Linux 操作系统,具有限制但如果需要可以自定义),那么一个 350 MB 的镜像(您引用的值实际上就是这个)在成本上代表什么?
事实上,这非常便宜。
在集成/生产中,您的所有服务很可能不会托管在同一台机器上,因此将容器的 350 MB 与传统虚拟机中用于集成/生产的资源进行比较,后者包含完整的操作系统以及安装的多个其他程序。您会明白容器的资源消耗并不是问题。这甚至被认为是超越本地环境的优势。
FROM
,因此您可以使用JDK进行构建,然后仅使用JRE进行打包。 - mcfedr