Add Java SubstrateVM Base Image

[Jotschi]

It would be nice to see a base image which could be used to generate distroless docker images which contain an app which was build using GraalVM SubstrateVM. SubstrateVM generates static compiled native executables of Java Programs which do not require an additional JVM environment.

I was able to run such images using the gcr.io/distroless/base image by adding the libz.so.1. I saw that the java base image is already containing the lib.

Example docker file:

FROM gcr.io/distroless/base
ADD vertx-graalvm-native-image-test-0.0.1-SNAPSHOT app
ADD libz.so.1 /lib
CMD ["/app"]

I'm not familiar with Bazel but it should be easy to just copy the java build env and remove the JRE from the build.

[dlorenc]

cc @patflynn

[lathama]

Using Docker multistage this is easy.

FROM debian:stable-slim AS build-env

FROM gcr.io/distroless/base
COPY app /app
COPY --from=build-env /lib/x86_64-linux-gnu/libz.so.1 /lib/x86_64-linux-gnu/libz.so.1
CMD ["/app"]

[patflynn]

@dlorenc My first thought is that the distroless/base is the right base-image for this kind of executable. Could we just add libz to it?

[lathama]

Adding items like libz could open the door for adding more and more. The user and the user's build environment can add items like this when and where needed. The tooling is there.

[dlorenc]

We could stick this in cc, which is what the java base uses. That would still keep base clean, and provide a slimmer base for java without the JVM.

[loosebazooka]

@dlorenc this has come up again. Any objections to putting this in the cc image? Looks like the java image pulls in zlib1g.

[loosebazooka]

potential CL: #294

[loosebazooka]

I wonder if this ends up only serving the Java case, and is perhaps a bad way to go about this. Every other language that depends on zlib1g also depends on a bunch of other packages. By moving zlib1g into cc, we've really just made cc -> java-dependencies without adding any value to cc or any of the other images.

Is the actual solution to publish something like java-base ?

[lathama]

would a good example of multistage builds help solve these queries?

[loosebazooka]

@lathama I think your example is fine, it's an effective strategy for users who have docker. In the jib case, it's less obvious how to do this, I'm just trying to find a good way to go about it.

[lathama]

Could creating a solution for JIB benefit more long term?

[loosebazooka]

I think with java11 and tooling around minimizing the JRE, there is a potential for use.

[dlorenc]

I don't have any preferences.

[donmccasland]

We now have multistage build examples in the documentation, closing.

[zifeo]

Note that lib.so.1 might be symlinked (as of today in debian:stable-slim), in case case lathama's solution may be extended with COPY --from=build-env /lib/x86_64-linux-gnu/libz.so* /lib/x86_64-linux-gnu/.

[tisonkun]

I encountered this issue and use ubuntu:jammy instead korandoru/hawkeye#3.

The problem is that even copy libz.so, the glibc version required by GraalVM Native Image can be relatively high. In my case, it's >= 2.34 while debian-11 is associated with 2.31.

ubuntu:jammy takes 69.2MB while distroless/base takes 17.3MB, debian:bookworm-slim which has glibc 2.36 takes 96.4MB, and any jre image takes more than 200MB. Finally, I chose ubuntu:jammy to avoid issues like this one and has a relatively small size.

[dlorenc]

I encountered this issue and use ubuntu:jammy instead korandoru/hawkeye#3.

The problem is that even copy libz.so, the glibc version required by GraalVM Native Image can be relatively high. In my case, it's >= 2.34 while debian-11 is associated with 2.31.

ubuntu:jammy takes 69.2MB while distroless/base takes 17.3MB, debian:bookworm-slim which has glibc 2.36 takes 96.4MB, and any jre image takes more than 200MB. Finally, I chose ubuntu:jammy to avoid issues like this one and has a relatively small size.

Shameless plug - if you get a chance, could you try cgr.dev/chainguard/glibc-dynamic? It's an alternative to distroless/base but with a more modern glibc. I think we use 2.41 now.

[tisonkun]

@dlorenc do we have a better channel to continue this thread? I'm afraid that it's a bit offensive to discuss here.

Anyway, I try the image and it shows that I should still try to install libz.so myself. Copy share lib from another image seems tricky:

docker run -it --rm cgr.dev/chainguard/glibc-dynamic ldconfig -p
18 libs found in cache `/etc/ld.so.cache'
	libutil.so.1 (libc6,AArch64) => /lib/libutil.so.1
	libthread_db.so.1 (libc6,AArch64) => /lib/libthread_db.so.1
	librt.so.1 (libc6,AArch64) => /lib/librt.so.1
	libresolv.so.2 (libc6,AArch64) => /lib/libresolv.so.2
	libpthread.so.0 (libc6,AArch64) => /lib/libpthread.so.0
	libnss_files.so.2 (libc6,AArch64) => /lib/libnss_files.so.2
	libnss_dns.so.2 (libc6,AArch64) => /lib/libnss_dns.so.2
	libnss_compat.so.2 (libc6,AArch64) => /lib/libnss_compat.so.2
	libnsl.so.1 (libc6,AArch64) => /lib/libnsl.so.1
	libmemusage.so (libc6,AArch64) => /lib/libmemusage.so
	libm.so.6 (libc6,AArch64) => /lib/libm.so.6
	libdl.so.2 (libc6,AArch64) => /lib/libdl.so.2
	libcrypt.so.1 (libc6,AArch64) => /lib/libcrypt.so.1
	libc_malloc_debug.so.0 (libc6,AArch64) => /lib/libc_malloc_debug.so.0
	libc.so.6 (libc6,AArch64) => /lib/libc.so.6
	libanl.so.1 (libc6,AArch64) => /lib/libanl.so.1
	libBrokenLocale.so.1 (libc6,AArch64) => /lib/libBrokenLocale.so.1
	ld-linux-aarch64.so.1 (libc6,AArch64) => /lib/ld-linux-aarch64.so.1
Cache generated by: ldconfig (GNU libc) stable release version 2.36

[dlorenc]

I opened an issue and cc'ed you there - chainguard-images/images#171

[dlorenc]

Closing the loop for everyone, there's now a dedicated graal image published here: https://github.com/chainguard-images/images/tree/main/images/graalvm-native-image-base

[pawelprazak]

Thank you @dlorenc for the link.

FYI: the dir was renamed, new link: https://github.com/chainguard-images/images/tree/main/images/graalvm-native