-
-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat-multi-arch-containers #5533
base: develop
Are you sure you want to change the base?
Changes from all commits
e3e3e85
75981d8
9bc97a1
bd809c9
5cf787a
9b1a3cf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,7 +21,7 @@ | |
# | ||
|
||
# Use JDK 17 in Debian Bullseye (as our production image gcr.io/distroless/java:17 is based on Debian Bullseye with just a JRE) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this comment is out of date if you are switching the non-debug build to bookworm also. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, better remove the name of a specific build of Debian from the comment, otherwise we will need to change it everytime the base image changes |
||
FROM debian:bullseye-slim | ||
FROM debian:bookworm-slim | ||
RUN apt-get update && apt-get -y dist-upgrade | ||
RUN apt-get install -y openjdk-17-jdk-headless | ||
RUN apt-get install -y expat fontconfig # Install tools required by FOP | ||
|
@@ -52,10 +52,10 @@ ARG MAX_BROKER | |
ARG JVM_MAX_RAM_PERCENTAGE | ||
ARG JVM_JDWP_SUSPEND | ||
|
||
ENV EXIST_HOME "/exist" | ||
ENV EXIST_HOME=/exist | ||
ENV CLASSPATH=/exist/lib/${exist.uber.jar.filename} | ||
|
||
ENV JAVA_TOOL_OPTIONS \ | ||
ENV JAVA_TOOL_OPTIONS="\ | ||
-Dfile.encoding=UTF8 \ | ||
-Dsun.jnu.encoding=UTF-8 \ | ||
-Djava.awt.headless=true \ | ||
|
@@ -72,7 +72,7 @@ ENV JAVA_TOOL_OPTIONS \ | |
-XX:+UseContainerSupport \ | ||
-XX:MaxRAMPercentage=${JVM_MAX_RAM_PERCENTAGE:-75.0} \ | ||
-XX:+ExitOnOutOfMemoryError \ | ||
-agentlib:jdwp=transport=dt_socket,server=y,suspend=${JVM_JDWP_SUSPEND:-n},address=5005 | ||
-agentlib:jdwp=transport=dt_socket,server=y,suspend=${JVM_JDWP_SUSPEND:-n},address=5005" | ||
|
||
HEALTHCHECK CMD [ "java", \ | ||
"org.exist.start.Main", "client", \ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change breaks XSL:FO in eXist-db when using Apache FOP. Unfortunately, the
gcr.io/distroless/java17-debian12:latest
image you have chosen to update to does not include these libraries. Please test a proper XSL-FO to PDF transformation with these changes, and you will see the error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR switches from
gcr.io/distroless/java17:latest
togcr.io/distroless/java17-debian12:latest
The lines stating they would be needed for FOP are commented out (lines 24-27 and 32-41) and select a different base image
debian:bullseye-slim
.So, even if those additional libraries were needed for PDF-generation using XSL:FO they are already missing and nothing is changed from the status quo.
It, therefore, would be beneficial to create an additional Dockerfile that has all that is needed for this specific use-case. This could also be provided by a third party.
This is all just under the pretense that this is really needed for PDF generation and the adoption rate would also show us how common it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@line-o It looks like they are only commented out because they were recently done so in a prior Pull Request that looks like it broke this.
I pointed out the problems in #4895 would break Apache FOP here, here, and here.
The response was that the base image now contains the required libraries, however, I have now checked the base image, and it is clear that that is not the case. See below:
We can see in the above image that
/usr/lib
inside the base image does not contain the previously required libraries.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they are no longer included that's a bug likely introduced when moving to debian 12. see GoogleContainerTools/distroless#321 or GoogleContainerTools/distroless#789 from 2019 and 2021 for relevant discussions. I will check the java-base image and move the discussion to the distroless repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see it as a bug with Debian 12 or GCR. Simply, GCR has never included these libraries as many Java Applications don't need them. However, we do need them for eXist-db, which is why previously we explicitly installed them into a base Debian image and then copied them into our derivative of GCR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@duncdrum I can't see it in the GCR java-base images (see below)... Where are you seeing it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamretter https://github.com/GoogleContainerTools/distroless/blob/main/java/BUILD#L117 here actually. I also remember and tested that the files were present after the discussions 3-4 years ago. If they no longer are it's a bug. Only libssl should no longer be included on Debian 12 Java images. I won't have time to look into this for another week or so. But I will check again. In the meantime I don't see how keeping a failing deploy tank running is helping. More fixes should come in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@duncdrum Interesting that the files even though listed in that BUILD file don't seem to have ever been in the published GCR images as far as I can see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be sure @adamretter You are checking in subsequent layers as well, and not seeing the dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@duncdrum Yes, I think so. What do you see when you look in the image?