JLink 不生成可重新分发的图像
JLink does not produce redistributable image
一段时间以来，我一直在处理模块化项目，但由于文件名和自动模块的限制，我从未有机会使用 jlink 工具来生成可再分发的应用程序映像。今天我选择启动一个不导入任何外部依赖项的独立项目，以防止使用兼容模式。该项目由 3 个模块组成，并且在 maven 中，所以我只会发布我正在使用的 jlink 命令片段。
供参考的项目：https://gitlab.com/Dragas/edu-day-demo，检查 modules-full 标签。项目以 package 目标构建，以防止污染您的本地 .m2 存储库。项目已配置为拉取依赖项，因此打包和部署会更容易。
我用来生成jlinked图片的命令如下：
jlink \
--module-path edu-day-runtime/target/dependency/:edu-day-runtime/target/ \
--add-modules ALL-MODULE-PATH \
--output edu-day-jlinked \
--launcher edurun=edu.day.runtime
调用该命令确实会生成一个 jlinked 图像，其中包含 java 项目所需的最少模块、java 库和 JVM 二进制文件。调用构建镜像的机器
edu-day-jlinked/bin/edurun 1 1
执行 运行 项目并输出以下内容
Result of sum is 2
同时，尝试在容器化环境中 运行 相同（这里我使用 bash:5，一个非 java 图像来模拟 java未安装）不会产生类似的结果。相反，shell 似乎没有找到名为 java
的二进制文件
docker run -it -v "$(pwd)/edu-day-jlinked:/app" bash:5
...(in container)
bash-5.0# /app/bin/edurun 1 1
/app/bin/edurun: line 4: /app/bin/java: not found
经检查，该文件夹确实包含名为 java
的二进制文件
bash-5.0# ls -la
total 52
drwxr-xr-x 2 1000 1000 4096 Aug 23 07:53 .
drwxr-xr-x 7 1000 1000 4096 Aug 23 07:53 ..
-rwxr-xr-x 1 1000 1000 116 Aug 23 07:53 edurun
-rwxr-xr-x 1 1000 1000 16688 Aug 23 07:53 java
-rwxr-xr-x 1 1000 1000 16712 Aug 23 07:53 keytool
但即使直接调用它（以显示帮助消息）也不会产生任何结果，除了无法找到二进制文件的相同消息外
(in /app/bin/ folder)
bash-5.0# ./java
bash: ./java: No such file or directory
更有意思的是，连keytool二进制文件returns同样报错
(in /app/bin/ folder)
bash-5.0# ./keytool
bash: ./keytool: No such file or directory
这就提出了一个问题：哪里出了问题？我还没有深入研究 jlink 的工作原理，但我的猜测是它从我自己的 java 安装（来自 arch 存储库的 openjdk 11.0.8+10）复制二进制文件，并认为它是可再分发的。或者我只是错过了一些命令行选项？
您的问题是测试容器 (bash:5) 没有使用与 java 环境相同版本的 run-time 链接器。
如果系统上有兼容的 linux run-time 链接器，jlink 生成的二进制文件只会 运行。
run-time 链接器的目的是配置二进制文件以便在系统上执行 - 在您构建可执行文件时，默认的 run-time 链接器是 hard-coded二进制。您可以使用 readelf -l 或 ldd 等工具检查 run-time 链接器（ldd 仅在它可以找到 run-time 链接器时才有效）
amd64 linux（例如 ubuntu）的默认 run-time 链接器是：/lib64/ld-linux-x86-64.so.2
i386 linux 的默认 run-time 链接器是：/lib/ld-linux.so.2
在 bash:5 容器上，默认的 run-time 链接器是：/lib/ld-musl-x86_64.so.1
这与 jdk
的 run-time 链接器不兼容
错误：/app/bin/java: not found 是因为无法为二进制文件找到 run-time 链接器。 bash:5 容器中的 jlinked VM 的脏测试给出了相同的错误。
当我获得 java 的 run-time 链接器时，我使用了：
$ docker run --rm -it -v (pwd)/edu-day-jlinked64:/app -w /here bash:5 bash
bash-5.0# /app/bin/java
bash: /app/bin/java: No such file or directory
bash-5.0# strings -a /app/bin/java | grep '^/lib'
/lib64/ld-linux-x86-64.so.2
bash-5.0# ls -l /lib64/ld-linux-x86-64.so.2
ls: /lib64/ld-linux-x86-64.so.2: No such file or directory
使用 run-time 链接器进行测试 on-board:
bash-5.0# /lib/ld-musl-x86_64.so.1 --list /app/bin/java
/lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
libjli.so => /app/bin/../lib/libjli.so (0x7fe28528c000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
libz.so.1 => /lib/libz.so.1 (0x7fe285272000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
Error relocating /app/bin/../lib/libjli.so: __snprintf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __vfprintf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __read_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __memmove_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __printf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __fprintf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __sprintf_chk: symbol not found
所以这里肯定不行。
让我们使用一些东西 'standard'。由于我在 ubuntu:focal 容器中构建了 jlinked 应用程序，安装了 java 版本，让我们使用一个没有 java built-in:
的版本
$ docker run --rm -it -v $(pwd)/edu-day-jlinked64:/app -w /here ubuntu:focal bash
root@865c9c12c029:/here# /app/bin/java
Usage: java [options] <mainclass> [args...]
(to execute a class)
or java [options] -jar <jarfile> [args...]
(to execute a jar file)
or java [options] -m <module>[/<mainclass>] [args...]
java [options] --module <module>[/<mainclass>] [args...]
(to execute the main class in a module)
or java [options] <sourcefile> [args]
(to execute a single source-file program)
所以在这种情况下它会起作用。
再现性：
构建使用：
$ docker run --rm -it -v $(pwd):/here -w /here ubuntu:focal bash
# apt-get update
# DEBIAN_FRONTEND=noninteractive apt-get install -y git openjdk-14-jdk maven
# git clone https://gitlab.com/Dragas/edu-day-demo .
# git checkout modules-full
# ./mvnw package
# rm -rf edu-day-runtime/target/classes
# jlink --module-path edu-day-runtime/target/dependency/:edu-day-runtime/target/ --add-modules ALL-MODULE-PATH --output edu-day-jlinked --launcher edurun=edu.day.runtime
# ./edu-day-jlinked/bin/edurun 1 1
Result of sum is 2
在相邻目录中：
$ docker run --rm -it -v $(pwd)/edu-day-jlinked:/app -w /here bash:5 bash
bash-5.0# /app/bin/edurun 1 1
/app/bin/edurun: line 4: /app/bin/java: not found
在另一个目录中：
$ docker run --rm -it -v $(pwd)/edu-day-jlinked:/app -w /here ubuntu:focal bash
root@200b4a98f9ee:/here# /app/bin/edurun 1 1
Result of sum is 2
TL;DR — bash:5 图像使用 C 库与链接到 edu-day-jlinked/bin/java 可执行文件的 C 库二进制不兼容。
长版
„…This raises a question: what went wrong?…“
问题是你的 app/bin/java 二进制文件找不到它最初链接到的 C 库您在本地构建的任何机器上构建了 edu-day-jlinked 可执行文件。
出现这个问题是因为jlink生成的java二进制文件链接到GNU glibc 你的 locally-installed JDK 使用的库…
$ ldd edu-day-demo-modules-full/edu-day-jlinked/bin/java
…
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa61a95b000)
…
而 bash:5 图像 运行 在 Busybox Linux 分布中。而Busybox不使用glibc…
bash-5.0# ldd app/bin/java
…
libjli.so => app/bin/../lib/jli/libjli.so (0x7f572a16d000)
…
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f572a19f000)
Error relocating app/bin/../lib/jli/libjli.so: __snprintf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __vfprintf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __read_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __memmove_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __printf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __fprintf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __sprintf_chk: symbol not found
它使用不同的 C 库：musl…
bash-5.0# find / -name '*musl*'
/lib/libc.musl-x86_64.so.1
/lib/ld-musl-x86_64.so.1
有助于理解Linking process. And it also helps to bear in mind that JLink builds a custom executable for a specific environment。
您在本地机器上的试用版 运行 成功了，因为 jlink 专门构建了可执行文件 适合您的本地环境。
建议的解决方案
„…docker here is intended to simulate an environment which does not have java installed…“
这是一个 Dockerfile，它成功构建了您的应用程序和生成的图像„没有安装 java“……
FROM maven:3.6.1-jdk-13-alpine as build
WORKDIR /app
COPY pom.xml .
COPY edu-day-sum edu-day-sum
COPY edu-day-runtime edu-day-runtime
COPY edu-day-api edu-day-api
RUN mvn package && \
--module-path ${JAVA_HOME}/jmods:edu-day-runtime/target/dependency/:edu-day-runtime/target/edu-day-runtime-1.0-SNAPSHOT.jar \
--add-modules ALL-MODULE-PATH \
--output edu-day-jlinked \
--launcher edurun=edu.day.runtime
FROM alpine:latest
COPY --from=build /app/edu-day-jlinked /app
ENTRYPOINT ["/app/bin/edurun"]
CMD ["1", "1"]
Docker best practice 建议：„使用 multi-stage 构建 “（如上 Dockerfile) 当你的目标是构建“一个没有安装java的环境”时。
FROM maven:3.6.1-jdk-13-alpine multi-stage 构建阶段，使用了一个同时具有 Maven 和 JDK 专为与 alpine 发行版兼容而构建。
FROM alpine:latest 是一个非常小的 linux 发行版， 没有 Java在上面。 maven:3.6.1-jdk-13-alpine 层被丢弃，如 the Docker best practice 文档所说。结果图像中唯一的 java 是 app/bin.
中的那个
一段时间以来，我一直在处理模块化项目，但由于文件名和自动模块的限制，我从未有机会使用 jlink 工具来生成可再分发的应用程序映像。今天我选择启动一个不导入任何外部依赖项的独立项目，以防止使用兼容模式。该项目由 3 个模块组成，并且在 maven 中，所以我只会发布我正在使用的 jlink 命令片段。
供参考的项目：https://gitlab.com/Dragas/edu-day-demo，检查 modules-full 标签。项目以 package 目标构建，以防止污染您的本地 .m2 存储库。项目已配置为拉取依赖项，因此打包和部署会更容易。
我用来生成jlinked图片的命令如下：
jlink \
--module-path edu-day-runtime/target/dependency/:edu-day-runtime/target/ \
--add-modules ALL-MODULE-PATH \
--output edu-day-jlinked \
--launcher edurun=edu.day.runtime
调用该命令确实会生成一个 jlinked 图像，其中包含 java 项目所需的最少模块、java 库和 JVM 二进制文件。调用构建镜像的机器
edu-day-jlinked/bin/edurun 1 1
执行 运行 项目并输出以下内容
Result of sum is 2
同时，尝试在容器化环境中 运行 相同（这里我使用 bash:5，一个非 java 图像来模拟 java未安装）不会产生类似的结果。相反，shell 似乎没有找到名为 java
docker run -it -v "$(pwd)/edu-day-jlinked:/app" bash:5
...(in container)
bash-5.0# /app/bin/edurun 1 1
/app/bin/edurun: line 4: /app/bin/java: not found
经检查，该文件夹确实包含名为 java
的二进制文件bash-5.0# ls -la
total 52
drwxr-xr-x 2 1000 1000 4096 Aug 23 07:53 .
drwxr-xr-x 7 1000 1000 4096 Aug 23 07:53 ..
-rwxr-xr-x 1 1000 1000 116 Aug 23 07:53 edurun
-rwxr-xr-x 1 1000 1000 16688 Aug 23 07:53 java
-rwxr-xr-x 1 1000 1000 16712 Aug 23 07:53 keytool
但即使直接调用它（以显示帮助消息）也不会产生任何结果，除了无法找到二进制文件的相同消息外
(in /app/bin/ folder)
bash-5.0# ./java
bash: ./java: No such file or directory
更有意思的是，连keytool二进制文件returns同样报错
(in /app/bin/ folder)
bash-5.0# ./keytool
bash: ./keytool: No such file or directory
这就提出了一个问题：哪里出了问题？我还没有深入研究 jlink 的工作原理，但我的猜测是它从我自己的 java 安装（来自 arch 存储库的 openjdk 11.0.8+10）复制二进制文件，并认为它是可再分发的。或者我只是错过了一些命令行选项？
您的问题是测试容器 (bash:5) 没有使用与 java 环境相同版本的 run-time 链接器。
如果系统上有兼容的 linux run-time 链接器，jlink 生成的二进制文件只会 运行。
run-time 链接器的目的是配置二进制文件以便在系统上执行 - 在您构建可执行文件时，默认的 run-time 链接器是 hard-coded二进制。您可以使用 readelf -l 或 ldd 等工具检查 run-time 链接器（ldd 仅在它可以找到 run-time 链接器时才有效）
amd64 linux（例如 ubuntu）的默认 run-time 链接器是：/lib64/ld-linux-x86-64.so.2
i386 linux 的默认 run-time 链接器是：/lib/ld-linux.so.2
在 bash:5 容器上，默认的 run-time 链接器是：/lib/ld-musl-x86_64.so.1
这与 jdk
的 run-time 链接器不兼容错误：/app/bin/java: not found 是因为无法为二进制文件找到 run-time 链接器。 bash:5 容器中的 jlinked VM 的脏测试给出了相同的错误。
当我获得 java 的 run-time 链接器时，我使用了：
$ docker run --rm -it -v (pwd)/edu-day-jlinked64:/app -w /here bash:5 bash
bash-5.0# /app/bin/java
bash: /app/bin/java: No such file or directory
bash-5.0# strings -a /app/bin/java | grep '^/lib'
/lib64/ld-linux-x86-64.so.2
bash-5.0# ls -l /lib64/ld-linux-x86-64.so.2
ls: /lib64/ld-linux-x86-64.so.2: No such file or directory
使用 run-time 链接器进行测试 on-board:
bash-5.0# /lib/ld-musl-x86_64.so.1 --list /app/bin/java
/lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
libjli.so => /app/bin/../lib/libjli.so (0x7fe28528c000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
libz.so.1 => /lib/libz.so.1 (0x7fe285272000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fe2852a3000)
Error relocating /app/bin/../lib/libjli.so: __snprintf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __vfprintf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __read_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __memmove_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __printf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __fprintf_chk: symbol not found
Error relocating /app/bin/../lib/libjli.so: __sprintf_chk: symbol not found
所以这里肯定不行。
让我们使用一些东西 'standard'。由于我在 ubuntu:focal 容器中构建了 jlinked 应用程序，安装了 java 版本，让我们使用一个没有 java built-in:
的版本$ docker run --rm -it -v $(pwd)/edu-day-jlinked64:/app -w /here ubuntu:focal bash
root@865c9c12c029:/here# /app/bin/java
Usage: java [options] <mainclass> [args...]
(to execute a class)
or java [options] -jar <jarfile> [args...]
(to execute a jar file)
or java [options] -m <module>[/<mainclass>] [args...]
java [options] --module <module>[/<mainclass>] [args...]
(to execute the main class in a module)
or java [options] <sourcefile> [args]
(to execute a single source-file program)
所以在这种情况下它会起作用。
再现性：
构建使用：
$ docker run --rm -it -v $(pwd):/here -w /here ubuntu:focal bash
# apt-get update
# DEBIAN_FRONTEND=noninteractive apt-get install -y git openjdk-14-jdk maven
# git clone https://gitlab.com/Dragas/edu-day-demo .
# git checkout modules-full
# ./mvnw package
# rm -rf edu-day-runtime/target/classes
# jlink --module-path edu-day-runtime/target/dependency/:edu-day-runtime/target/ --add-modules ALL-MODULE-PATH --output edu-day-jlinked --launcher edurun=edu.day.runtime
# ./edu-day-jlinked/bin/edurun 1 1
Result of sum is 2
在相邻目录中：
$ docker run --rm -it -v $(pwd)/edu-day-jlinked:/app -w /here bash:5 bash
bash-5.0# /app/bin/edurun 1 1
/app/bin/edurun: line 4: /app/bin/java: not found
在另一个目录中：
$ docker run --rm -it -v $(pwd)/edu-day-jlinked:/app -w /here ubuntu:focal bash
root@200b4a98f9ee:/here# /app/bin/edurun 1 1
Result of sum is 2
TL;DR — bash:5 图像使用 C 库与链接到 edu-day-jlinked/bin/java 可执行文件的 C 库二进制不兼容。
长版
„…This raises a question: what went wrong?…“
问题是你的 app/bin/java 二进制文件找不到它最初链接到的 C 库您在本地构建的任何机器上构建了 edu-day-jlinked 可执行文件。
出现这个问题是因为jlink生成的java二进制文件链接到GNU glibc 你的 locally-installed JDK 使用的库…
$ ldd edu-day-demo-modules-full/edu-day-jlinked/bin/java
…
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa61a95b000)
…
而 bash:5 图像 运行 在 Busybox Linux 分布中。而Busybox不使用glibc…
bash-5.0# ldd app/bin/java
…
libjli.so => app/bin/../lib/jli/libjli.so (0x7f572a16d000)
…
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f572a19f000)
Error relocating app/bin/../lib/jli/libjli.so: __snprintf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __vfprintf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __read_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __memmove_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __printf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __fprintf_chk: symbol not found
Error relocating app/bin/../lib/jli/libjli.so: __sprintf_chk: symbol not found
它使用不同的 C 库：musl…
bash-5.0# find / -name '*musl*'
/lib/libc.musl-x86_64.so.1
/lib/ld-musl-x86_64.so.1
有助于理解Linking process. And it also helps to bear in mind that JLink builds a custom executable for a specific environment。
您在本地机器上的试用版 运行 成功了，因为 jlink 专门构建了可执行文件 适合您的本地环境。
建议的解决方案
„…docker here is intended to simulate an environment which does not have java installed…“
这是一个 Dockerfile，它成功构建了您的应用程序和生成的图像„没有安装 java“……
FROM maven:3.6.1-jdk-13-alpine as build
WORKDIR /app
COPY pom.xml .
COPY edu-day-sum edu-day-sum
COPY edu-day-runtime edu-day-runtime
COPY edu-day-api edu-day-api
RUN mvn package && \
--module-path ${JAVA_HOME}/jmods:edu-day-runtime/target/dependency/:edu-day-runtime/target/edu-day-runtime-1.0-SNAPSHOT.jar \
--add-modules ALL-MODULE-PATH \
--output edu-day-jlinked \
--launcher edurun=edu.day.runtime
FROM alpine:latest
COPY --from=build /app/edu-day-jlinked /app
ENTRYPOINT ["/app/bin/edurun"]
CMD ["1", "1"]
Docker best practice 建议：„使用 multi-stage 构建 “（如上 Dockerfile) 当你的目标是构建“一个没有安装java的环境”时。
FROM maven:3.6.1-jdk-13-alpine multi-stage 构建阶段，使用了一个同时具有 Maven 和 JDK 专为与 alpine 发行版兼容而构建。
FROM alpine:latest 是一个非常小的 linux 发行版， 没有 Java在上面。 maven:3.6.1-jdk-13-alpine 层被丢弃，如 the Docker best practice 文档所说。结果图像中唯一的 java 是 app/bin.