受问题启发 为什么 Java 11 基础 Docker 映像如此之大? (openjdk:11-jre-slim) 发现Java世界的这个话题还没有定论。
至于 07 Dec 2018
有常见的问题/陷阱(在上面的票中讨论):
JRE 不作为单独的“包”分发。应该使用来自 JDK 的模块
Oracle OpenJDK 11 不支持 Linux Alpine ,因此无法轻松创建 轻量级 映像
- 同时当前稳定的 Debian 版本仍然没有 Java 11 包( Ubuntu 在 openjdk-11 包下安装了 Java 10 ),这就是为什么不稳定的 sid 版本用于基础 docker 镜像
当前可用的 Oracle openjdk-11 映像构建未剥离
libjvm.so
模块,该模块有数百兆字节,必须单独剥离:- 从 openjdk 创建的 jlink 运行时映像大小(特别是 libjvm.so)很大。预计它会小得多。
- 解决方案: https ://github.com/docker-library/openjdk/issues/217#issuecomment-436079779
由于这些问题,即使是 苗条 的 Oracle Java 11 基础镜像也很重并且被认为是不稳定的: https ://hub.docker.com/_/openjdk/
所以问题是:
将 Java 11 应用程序作为 Docker 映像构建和交付的 优化 或 推荐 方法是 什么?
原文由 radistao 发布,翻译遵循 CC BY-SA 4.0 许可协议
从 07.2019 开始更新: https ://stackoverflow.com/a/57145029/907576
以简单的 Spring Boot 应用程序(只有一个 REST 端点)为例,到目前为止,我能够找出以下解决方案(考虑到应用程序 jar 位于
build/libs/spring-boot-demo.jar
在 Docker 构建之前:如果我们想 在稳定的 slim Linux 版本上使用官方的 Oracle OpenJDK 发行版(暂时是
Debian 9 "Stretch"
), _绝地之路_:使用
debian:stretch-slim
(最新稳定版)基础镜像使用 Docker 多阶段构建
第一个 Docker 构建阶段:
Oracle OpenJDK
存档jlink
工具为您的项目(又名 JRE)编译 Java 最小发行版第二个 Docker 构建阶段:
所以,最终
Dockerfile
看起来像这样( 实现 JDK
VERSION
,URL
和HASH
值):注意:
最小 JRE 示例中包含 5 个 java 模块(
java.base,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument
)。我发现他们“手动”运行应用程序并修复ClassNotFoundException
。等待一些进一步的 Spring Boot 开发人员建议/指南,包括哪些 Java 模块以及何时包含,与删除一些冗余依赖项一样,例如java.desktop
,这似乎仅用于PropertyEditorSupport
如果您害怕错过一些模块 - 它们非常轻巧,并且所有模块加起来会增加大约 2 MB 的大小。获取
java.*
和jdk.*
11 个模块的完整列表:java --list-modules | grep -E "^java\.[^@]*" | cut -d @ -f 1
java --list-modules | grep -E "^jdk\.[^@]*" | cut -d @ -f 1
在我的情况下,生成的图像大小为 123 MB ,最少 7 个 Spring Boot 模块, 125 MB ,所有
java.*
模块作为此构建工作流程的可选改进:
与 Oracle Azul 的 Zulu JDK 11 相反,支持 Alpine 端口 并具有各自的基础 Docker 映像。
因此,如果尊重 Zulu JVM/JDK,Docker 构建会简单得多:
结果图像为 73 MB ,与剥离的 Alpine 分布一致。