Quarkus Native Builds With OpenShift s2i

(This article is an outcome of a Red Hat Hackathon. Thanks to Jiri, Romain, Jochen, Thomas and Roland for contributing to it!).

TL;DR

# Create BuildConfig and app - omit --context-dir, if not needed
oc new-app quay.io/quarkus/centos-quarkus-native-s2i~{YOUR-QUARKUS-CODE-REPO-URL} --context-dir={YOUR-PROJECT'S-SUBDIRECTORY-IF-AVAILABLE-OTHERWISE-DON'T-USE} --name={YOUR-QUARKUS-APP-NAME}

# Check running build
oc logs -f bc/{YOUR-QUARKUS-APP-NAME}

# Cancel first build
oc cancel-build bc/{YOUR-QUARKUS-APP-NAME}

# Increase build resources
oc patch bc/{YOUR-QUARKUS-APP-NAME} -p '{"spec":{"resources":{"limits":{"cpu":"4", "memory":"4Gi"}}}}'

Quarkus is the new kid on the Java block. It leverages GraalVM (and Substrate) to create native executables which perfectly match micro services and serverless architectures.

Think of golang native compiles: Super fast, low footprint. Actually Quarkus’ performance comes close to this of golang, which eliminates a big disadvantage of Java based services: In the space of serverless architectures they weren’t really suitable because of bootstrap and memory overhead. Up to now.

If you’re using OpenShift (which is despite the rumours I hear from way too many FUDders and OSS haters a certified Kubernetes distribution and, thus, fully compatible, but putting additional tools for enterprise environment), you might be looking for an easy way to create a native build.

The official Quarkus documentation describes how to run a locally created image on OpenShift/kubernetes. This workflow means:

1. Develop your Quarkus app.
2. (Commit the changes to your source repo).
3. Create a native Linux 64-bit (or else) executable.
4. Put this executable into a container image.
5. Deploy the container image to the container platform.

But when using OpenShift’s Source-to-Image (s2i) functionality, as a developer, you rather want to follow this flow:

1. Develop your Quarkus app (preferably Java, not native).
2. Commit the changes to your source repo.
3. (Build the native app, the container image and deploy the image automatically on OpenShift).

After a one time setup, step 3 can afterwards be performed automatically thanks to web hook build triggers.

In fact, this is already possible, but a little bit hidden in the Quarkus repo documentation (thanks to Roland Huß for the hint!). In short, what you need to do is the following at the command line (oc):

oc new-app quay.io/quarkus/centos-quarkus-native-s2i~{YOUR-QUARKUS-CODE-REPO-URL} --context-dir={YOUR-PROJECT'S-SUBDIRECTORY-IF-AVAILABLE-OTHERWISE-DON'T-USE} --name={YOUR-QUARKUS-APP-NAME}

This will create a build config and trigger a build.

As Quarkus native builds demand a lot of resources (CPU and memory), it’s not unlikely that your build will fail.

Check this with

oc logs -f bc/{YOUR-QUARKUS-APP-NAME}

Unfortunately, there’s actually no parameter preventing OpenShift from creating this first build (but we raised an issue, perhaps this gets fixed). With

oc cancel-build bc/{YOUR-QUARKUS-APP-NAME}

…you can cancel the build.

Then you can change the build resource parameters with e.g…

oc patch bc/{YOUR-QUARKUS-APP-NAME} -p '{"spec":{"resources":{"limits":{"cpu":"4", "memory":"4Gi"}}}}'

…and your build should run smoothly. If not, hack around with the resource parameters.

Finally, you can set up the web hook(s) and build and deploy your native Quarkus image automatically whenver you commit. Enjoy!