宣布Java 11是最新的LTS版本。因此,我们正在尝试基于此Java版本启动新服务。
但是,Java 11的基本Docker映像比Java 8的等效映像大得多:
openjdk:8-jre-alpine
:84 MBopenjdk:11-jre-slim
:283 MB
(我只考虑官方的OpenJDK和每个Java版本的最轻量的映像。)
更深入的挖掘发现了以下“事物”:
该
openjdk:11-jre-slim
图像使用基本图像debian:sid-slim
。这带来了两个问题:比60 MB大
alpine:3.8
在Debian的
sid
版本是不稳定
openjdk-11-jre-headless
镜像中安装的软件包比(运行Docker容器内部)大3倍openjdk8-jre
:openjdk:8-jre-alpine
:/ # du -hs /usr/lib/jvm/java-1.8-openjdk/jre/lib/ 57.5M /usr/lib/jvm/java-1.8-openjdk/jre/lib/
openjdk:11-jre-slim
:# du -sh /usr/lib/jvm/java-11-openjdk-amd64/lib/ 179M /usr/lib/jvm/java-11-openjdk-amd64/lib/
更深入地讲,我发现了这种繁重的“根”-它
modules
是JDK 的文件:# ls -lhG /usr/lib/jvm/java-11-openjdk-amd64/lib/modules 135M /usr/lib/jvm/java-11-openjdk-amd64/lib/modules
因此,现在出现的问题是:
为什么
alpine
不再将其用作Java 11超薄映像的基础映像?为什么不稳定的sid版本用于LTS Java映像?
为什么与类似的OpenJDK 8软件包相比,OpenJDK 11的slim / headless / JRE软件包这么大?
- 在OpenJDK 11中带来135 MB的这个模块文件是什么?
UPD:作为应对这些挑战的解决方案,可以使用以下答案:Java 11应用程序作为docker映像