Java 21 upgrade #1405
Comments
|
Looks like we need an image based on Debian 13 ( |
|
Why ? There was java17 on debian11 even if it's not the default jre for this version |
|
If there's Java 21 on debian12, we'll add it. Perhaps a question to the debian maintainers? |
|
For me, it will be available. You can follow the package here: openjdk-21. But will need to wait for a few weeks (took one month for JDK 17). Minimum of 5 days between unstable and testing if I read well and then to stable. EDIT: has been migrated to testing the 2023/09/26. Next step: testing->stable. |
|
Hi, Is it going to be released?) |
|
Is it available in debian? |
So we are going to wait till the 2025? What is the problem to base on the debian12 (yes, I know support date of Debian 12 till 2028 and JDK21 till 2031)? |
|
Shameless pointer, the wolfi-based Chainguard images are distroless as well and we just announced support for jdk 21: There's also a jre build: |
|
Fundamentally it's easiest for us to do what debian does. I know we special case nodejs. And maybe we can do the same for Java -- we just don't right now. The wolfi images (or any other vendor) could fill the gap for you here until we find a Java 21 build. |
|
I managed to build Java 21 and Python 3.12 distroless images based off of the debian SID release channel. I created my own debian package fetch script which generates a file similar to Since I maintain a fork of this project at work, I can talk to my manager if I can contribute a part of my work back to this project. If I were to contribute back, we would need to modify the |
|
I think we're just going to use temurin to do this: #1444 |
|
So there should be some java21 images ready for testing. If you are using Java21, we would appreciate some feedback on if these are working for you. gcr.io/distroless/java21-debian12 (amd64, arm64 and ppc64le). They are based on adoptium temurin java21 which does not seem to currently have an s390x build, so if you're using s390x you might be out of luck. |
|
@loosebazooka I'm testing it now, and so far the only hiccup is that I had to upgrade Thanks! |
|
Glad to hear it's working, @swi-jared you probably should've run into that issue a while ago? Since we moved to oci media types (vs old docker media types) a few months ago. |
|
I'm also running tests, looks good so far. 👍 |
This particular service has been using Temurin 17's base image, so we haven't run into this issue yet. |
|
Hi all, I am testing the java 21 distroless image and find some differences compared to Java 17 related to cacerts. I am loading a custom trust store to /etc/ssl/certs/java/cacerts (through a volume) but is looks that it is ignored since the relevant symbolic link is missing. Java 17: /usr/lib/jvm/java-17-openjdk-amd64/lib/security $ ls -la Java 21: /usr/lib/jvm/temurin21_jdk_amd64/lib/security $ ls -la |
|
Yeah looks like temurin ships it's own certs. Probably makes sense to just use those? Or in your script replace those files? |
|
Yes, I can try to mount my trust store to /usr/lib/jvm/temurin21_jdk_amd64/lib/security/cacerts. I think this change should be noted. Using a custom trust store is quite frequent. |
|
Its not clear to me if we should add the symlinks and move the certs over to be consistent with the debian? |
|
IMHO, it would be best to stay compatible with previous releases of |
I believe having the symlinks would be preferable to simplify the upgrade (at least in my case). After all, openjdk 17 has its own cacerts as well and the symlinks were there. |
|
Hey everyone! |
|
Hrmm... Also wondering if we should use temurins shipped trust root or the debian one. Using temurins would simplify our code a bit. |
|
I think that gcr.io/distroless/java17-debian12 used the cacerts shipped with Debian. If that's the case, I believe the same should apply for java 21. |
|
Hr... that is the case, however, the debian java distributions also ship It's looking like we should just use the temurin install as is (easier to maintain, and how temurin generally behaves). Java users will be expected to inject their custom roots directly into the jvm directory as documented in the Java README? |
|
There is another issue that I am facing. I am using the below images:
I mount a custom cacerts to /usr/lib/jvm/temurin21_jdk_amd64/lib/security/cacerts . The application is performing an HTTPS request to a service that its certificated is loaded to the custom cacerts. The results for each image are the following:
The issue is resolved by running the app with the following parameter: -Djavax.net.ssl.trustStore=/usr/lib/jvm/temurin21_jdk_amd64/lib/security/cacerts However, adding the parameter should not be required as this is the default cacerts location. Additionally, there is a mismatch in the behavior between nonroot and debug-nonroot images. I find no other difference apart from the image tag. Any ideas? |
|
I'm still working on open sourcing the code. I'll submit PR once it is approved and you guys can decide which version to keep. The builds are based off of debian sid channel so it would be similar to the current java 17 builds. @apostoliska, debug image contain java jdk whereas non-debug image does not. I was wondering if we could make a jdk image without busybox. We would have the following:
The debug tag will only container busybox. |
|
@apostoliska I think @ding-ma answered your questions, but the detail is that regular images are jres, not jdks. So you need to use the jre path: |
|
I'll add myself as being in support of having separate images with the JDK versus the JRE. I had previously been operating under the assumption that the only difference between the debug and non-debug images was busybox being installed, so was surprised when I learned that the java debug image also used a JDK install instead of a JRE install.
My hope would be to also have a JRE image with busybox. |
|
#1459 was merged, any chance you could try your old workflows again and see if everything is working as expected (write your custom certs into |
|
Verified from my side. Thank you for your efforts. |
|
Tested successfully here too. Thx Nevertheless, I notice a different behavior between java21-debian12:(latest|nonroot) images, and all others java images. docker run --rm -v "$(pwd)"/test/CheckCerts.java:/app/CheckCerts.java --entrypoint="java" gcr.io/distroless/java17-debian11:nonroot /app/CheckCerts.javaor even with java21 debug image: docker run --rm -v "$(pwd)"/test/CheckCerts.java:/app/CheckCerts.java --entrypoint="java" gcr.io/distroless/java21-debian12:debug-nonroot /app/CheckCerts.javaBut with gcr.io/distroless/java21-debian12:(latest|nonroot) image, I get the following error: Do you have any clue of what's going on ? |
|
@Booyaabes from @ding-ma
from @loosebazooka
|
|
Hrmm.. I think the implication was that the java17 jre images were able to do this? |
|
Distroless Java 11 & Java 17 images were able to do this, exactly. |
|
In the spirit of distroless, I would prefer a smaller footprint and only include the jre. However, if history says it includes the full jdk that's not a deal-breaker. Perhaps there's room for image tags like Just a thought. |
|
I don't think we'll publish a non debug jdk image. Although at some point you should be able to just build them yourself using rules distroless. |
|
An issue that I've run into that caused a huge headache is that # bad
> docker run -it --rm --entrypoint ls gcr.io/distroless/java21-debian12:debug -l /usr/lib/jvm/temurin21_jdk_arm64/lib/jspawnhelper
-rw-r--r-- 1 root root 72448 Jan 1 2000 /usr/lib/jvm/temurin21_jdk_arm64/lib/jspawnhelper
# good
> docker run -it --rm --entrypoint ls gcr.io/distroless/java17-debian12:debug -l /usr/lib/jvm/java-17-openjdk-arm64/lib/jspawnhelper
-rwxr-xr-x 1 root root 67488 Oct 31 23:39 /usr/lib/jvm/java-17-openjdk-arm64/lib/jspawnhelperto reproduce:
import java.lang.ProcessBuilder;
class HelloLs {
public static void main(String[] args) throws Exception {
new ProcessBuilder("ls").inheritIO().start().waitFor();
}
}
> docker run --rm -it -v "$PWD/HelloLs.class:/HelloLs.class" --entrypoint java gcr.io/distroless/java17-debian12:debug HelloLs
HelloLs.class boot dev home proc run sys usr
bin busybox etc lib root sbin tmp var
> docker run --rm -it -v "$PWD/HelloLs.class:/HelloLs.class" --entrypoint java gcr.io/distroless/java21-debian12:debug HelloLs
Exception in thread "main" java.io.IOException: Cannot run program "ls": error=13, Permission denied
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1170)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1089)
at HelloLs.main(hello-ls.java:5)
Caused by: java.io.IOException: error=13, Permission denied
at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:295)
at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:225)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1126)
... 2 more
> docker run --rm -it -v "$PWD/HelloLs.class:/HelloLs.class" --entrypoint sh gcr.io/distroless/java21-debian12:debug
/ # chmod +x /usr/lib/jvm/temurin21_jdk_arm64/lib/jspawnhelper
/ # java HelloLs
HelloLs.class boot dev home proc run sys usr
bin busybox etc lib root sbin tmp var
> docker run --rm -it -v "$PWD/HelloLs.class:/HelloLs.class" --entrypoint java gcr.io/distroless/java21-debian12:debug -Djdk.lang.Process.launchMechanism=vfork HelloLs
HelloLs.class boot dev home proc run sys usr
bin busybox etc lib root sbin tmp var |
|
We can make jspawnhelper executable |
|
I haven't had a chance to figure out why @Booyaabes issue is popping up though |
|
hey, are there any updates on this? |
|
I think I might need to use something different than the bazel pkg_tar rule. I'll throw something together but it'll be brittle if the directory layout or executable permissions change on the jre archive. |
|
What is the ETA of publishing Java 21 Debian 12 Image as one of the supported Distroless Images? Do you need additional testers? Seems like this was moving along, but stalled? |
|
I mean it's probably good to go now. I'm not super fond of how I'm unpacking the tar in https://github.com/GoogleContainerTools/distroless/blob/main/private/remote/temurin_archive.bzl but I guess that's just an implementation detail. |
|
I have some feedback on the Java21 images. In the Java17 images, config was symlinked from a common location in This made it easy to build derived base images with tweaked config. The currently published java21 images don't symlink in the config, which makes things a bit more annoying to deal with. |
|
@markallanson can you provide a little more detail? We can probably fix this pretty easily. We're just going to end up organizing a temurin package like a debian java release. |
|
In the Java17 image as an example, configuration, properties, and policies are stored in the All output taken from the Taking a single file, In the current Java21 images this layout does not store config at all in |
|
Java 21 only on Debian 12, will support also cover Debian 11? |
|
No, Debian 11 is eol pretty soon. |
|
Hello guys, this is reminder! What's the plan ? Do we have any showstopper ? expected to have the image available under: |
|
What is the status / ETA of the publishing Java21 as an official Distroless Debian12 Image? |
|
once we get #1582, we should be able to publish them. |
I don't know about if it is possible to use gcr.io/distroless/java21-debian12 for production but just tested it and it worked. |
|
Yeah I think we're about ready to advertise it |
|
I see |
|
We seem to have reached parity with the existing images. So if that works for you then sure. There's one open issue around random number generation algorithms -- but that's not something distroless can fix. |
Do you have a reference? Appreciate it's not a distroless problem, but could be a show stopper depending on what it is. |
and others
Hi,
Java 21 is GA, when can we hope to have an updated distroless image ?
thanks
The text was updated successfully, but these errors were encountered: