Red Hat offer a number of containers available via their catalog at https://catalog.redhat.com/software/containers/explore. What is somewhat less known is that these images can often hold a bunch of useful scripts and information that shows you how the image was built in the first place, and also the ENTRYPOINT from which the container starts up.

Taking a search on the catalog we can find a java container to look at:

OpenJDK8 Container

Let’s grab this image with Podman:

By navigating to the /root/buildinfo directory we can see the Dockerfiles from which the container has been built.

From this point we can see the content of the Dockerfiles.

It can be seen further down in the Dockerfile that this image is an s2i image, and the scripts are located at /usr/local/s2i.

For the Java images this is particularly useful in order to see how the applications are built, and how the application is configured on startup.

For s2i the build phase is kicked off via the assemble script (which triggers a maven build). The run script is what sets up the JVM in order to run the Java application. You can of course provide your own run.sh script, but it can be seen that the run script calls down to a run-java.sh.

run-java.sh can be found at /opt/jboss/container/java/run/run-java.sh. This script is maintained in the https://github.com/fabric8io-images/run-java-sh GitHub repo.

run-java.sh from its GitHub docs attempts to use sane default for JVM parameters based on container constraints on memory and cpus - which is super helpful and I will attempt to cover this in a future post in step with using Openshift quotas, requests, and limits.

Conclusion

Out of the box the Red Hat Java container images have so much more than just a JDK. They are based on a secure, well known RHEL base, and also give the user sane JVM defaults in order to run the java app placed within it. More reasons to consider using the Red Hat Java images from the contaner catalog rather than building your own.

References


codergists