为什么Java 11基础Docker映像如此之大?(openjdk:11-jre-slim)


144

宣布Java 11是最新的LTS版本。因此,我们正在尝试基于此Java版本启动新服务。

但是,Java 11的基本Docker映像比Java 8的等效映像大得多:

(我只考虑官方的OpenJDK和每个Java版本的最轻量的映像。)

更深入的挖掘发现了以下“事物”:

  • openjdk:11-jre-slim图像使用基本图像debian:sid-slim。这带来了两个问题:

  • 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映像


1
那么对Java的一个新版本(JDK 9+)的模块化,这也解释了为什么在11个模块VS 8.
扎卡里·克雷格


13
没有JRE 11,所以您拥有的是完整的JDK。您可以创建紧凑的环境,甚至比JRE 8更苗条的环境,但是它需要一个实际的模块化应用程序,因此依赖项是已知的。
Holger

1
除上述内容外,并不是您发现的所有那些由于尺寸增加的模块实际上都是您的应用程序所必需的。但是要找出哪些,您将继续创建模块化应用程序。你可以找到更多关于JLINK(在Java9引入)为缘故。
纳曼

1
有什么更好的时间来在线阅读此书-twitter.com/LogicTheoryIO/status/1064503559071371265
Naman

Answers:


171

为什么alpine不再将其用作Java 11超薄映像的基础映像?

不幸的是,这是因为目前没有针对Alpine的官方稳定的OpenJDK 11构建。

与目前大多数Linux使用的标准glibc相比,Alpine使用musl libc,这意味着JVM必须与musl libc兼容才能支持香草Alpine。在OpenJDK的Portola项目下正在开发Musl OpenJDK端口。

当前状态汇总在OpenJDK 11页面上

自JDK 11 GA起,此页面上先前可用的Alpine Linux构建已删除。它尚未投入生产,因为它尚未经过充分的测试,无法被视为GA版本。请使用可抢先使用的JDK 12 Alpine Linux构建代替它。

目前,Alpine唯一稳定的OpenJDK版本是7和8,由 IcedTea项目。

但是,如果您愿意考虑使用官方OpenJDK之外的其他东西,则Azul的Zulu OpenJDK提供了一种引人注目的替代方案:

  • 它支持Alpine musl上的Java 11(撰写本文时为11.0.2版);
  • 它是经过认证的OpenJDK构建,已使用OpenJDK TCK合规套件进行了验证;
  • 它是免费的,开放源代码的,并且可用于dockerDockerhub)。

有关支持可用性和路线图,请参阅Azul支持路线图

更新,19年3月6日:截至昨天,openjdk11在Alpine存储库中可用!可以使用以下方法在Alpine上进行抓取:

apk --no-cache add openjdk11

该软件包基于jdk11uOpenJDK分支以及项目Portola的移植修补程序,随以下PR一起引入。非常感谢Alpine团队。

为什么不稳定的sid版本用于LTS Java映像?

这是一个公平的问题/要求。实际上有一个开放的票证可以在稳定的Debian版本上提供Java 11:https
//github.com/docker-library/openjdk/issues/237

更新,18年12月26日:问题已解决,现在OpenJDK 11超薄映像基于stretch-backports最近可用的OpenJDK 11(PR链接)。

为什么与类似的OpenJDK 8软件包相比,OpenJDK 11的slim / headless / JRE软件包这么大?这是什么模块在OpenJDK 11中带来135 MB的文件?

Java 9引入了模块系统,与jar文件相比,这是一种对包和资源进行分组的新的改进方法。Oracle的这篇文章对此功能进行了非常详细的介绍:
https //www.oracle.com/corporate/features/understanding-java-9-modules.html

modules文件捆绑了JRE随附的所有模块。完整的模块列表可以用打印java --list-modulesmodules确实是一个非常大的文件,并且正如所注释的那样,它包含所有标准模块,因此非常膨胀。

但是要注意的一件事是,它被替换rt.jar并且tools.jar已被弃用,因此,与modulesOpenJDK 9以前的版本进行比较时,考虑到的大小,应减去rt.jar和的大小tools.jar(它们应占用80MB的总和) 。


9

从2019年7月开始https://adoptopenjdk.net/拥有Alpine对Java 11的官方支持:

但是,模块(jmodsjlink当组装最小的应用程序时仍应考虑)。

注意事项纤细的图像不包含某些模块(例如java.sql)-它们被明确排除在外(https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L233


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.