We are pleased to announce the first technology preview release of the jlink integration with Red Hat OpenShift for the Red Hat Universal Base Image (UBI) and Red Hat build of OpenJDK containers. We first publicly previewed this technology in a presentation at FOSDEM 2024. We will provide a quick overview of it in this article. For a deeper dive, please refer to the FOSDEM slides and recording.
Background
We ship two flavors of Universal Base Image and Red Hat build of OpenJDK containers: builder and runtime. The builders support OpenShift source-to-image (S2I). Using S2I, customers can set up automated pipelines to rebuild and deploy their application when their source is updated, or other relevant triggers.
S2I is conceptually simple, and that simplicity has advantages. But one drawback is the resulting application container is layered on top of the builder image. For Java applications, that means they include the full Java Development Kit, including compiler, and Apache Maven tooling. Customers may wish for smaller containers, or a reduced attack-surface.
In our 2021 article, we described how to configure OpenShift to perform a two-stage build, cherry-picking the application and layering it on top of the OpenJDK runtime images. The images produced by this method are smaller than plain S2I, but we felt we could make them even smaller. The OpenJDK runtime is about half the total image size, so it was our focus to find savings.
Java modules and jlink
In 2017, Project Jigsaw reorganized upstream OpenJDK into discrete modules. OpenJDK releases from version 9 onwards are modularized and include tooling for managing the following OpenJDK modules:
jdepsare used to analyze an application to determine which modules it requires.jlinkare used to produce a new OpenJDK runtime, containing only a specified sub-set of the full set of OpenJDK modules.
Our runtime images are designed to be suitable for a wide range of users, and so included the majority of OpenJDK’s modules. What if we could remove OpenJDK modules that were not needed for a specific application?
OpenShift and jlink
By extending S2I, we can analyze the Java application to determine which OpenJDK modules it requires, and produce a minimized OpenJDK runtime, tailored to that application. Building upon the two-stage build, we extract both the application and the bespoke runtime and layer them on top of a runtime image. Figure 1 shows the OpenShift jlink three-stage build pipeline.
As an additional bonus of this method, we can layer on top of the UBI micro image. This is a fraction of the size of the regular UBI runtime images, weighing in the order of 20-30MiB, or less than 10% the size of the UBI and OpenJDK runtime images.
Combined, these space savings mean we can build ultra-lean application containers. In our experiments, the container size of a Quarkus-based application is reduced by 57% compared to the lean-containers technique. Figure 2 shows a breakdown of the OpenShift jlinked image sizes.
How to get the tech preview image
Initially, we’re releasing this feature as a separate tech preview container image using the Red Hat build of OpenJDK 21. This is to give us an opportunity to gather feedback from the community about this feature. We’d love to know what you think of this feature. Let us know what results you get with your real-world containers. Your feedback will help shape the future of this feature!
We’ve packaged the required OpenShift configuration into this OpenShift template. Use the template in conjunction with the tech preview image, which is available from the Red Hat Ecosystem Catalog. You can also pull it from the Red Hat Container Registry with this command: registry.access.redhat.com/openjdk-tech-preview/openjdk-21-jlink-rhel9:latest.
You can find the full step-by-step instructions in this README. The example application in our template is a Quarkus quickstart, configured to use the "Uber JAR" package type. We welcome your feedback.
