Helm Chart for WildFly

By Jeff Mesnil | May 05, 2021

Helm is a tool that helps define, install and upgrade complex applications on Kubernetes clusters.

We have now released a Helm Chart for WildFly to help our users build and deploy WildFly applications on OpenShift that leverages all the innovative features provided by the WildFly ecosystem.

The wildfly Chart can be used to achieve two objectives:

build an application image from a Git repository containing a Java project. This step leverages WildFly features such as Galleon provisioning or Bootable Jar to provide the fittest image for your application requirements.
deploy an application image with all the resources and configuration needed to integrate it on OpenShift.

By default, the two steps are connected: the build step’s output is an application image that becomes the input of the deploy step. However, it is possible to enable or disable these steps: if you have another way to build your application image, you can disable the build step and still deploy it by specifying where your application image can be pulled.

All the chart configuration is described in the Chart documentation. In this post, we will focus on a simple MicroProfile application to show you how the Helm chart simplifies its deployment on OpenShift.

MicroProfile Application Example

We will use one WildFly quickstart as an example: microprofile-config. We will not cover the code of this example but the important things to mention are:

This application will be running as a WildFly Bootable Jar
It uses MicroProfile API and provides a HTTP endpoint. A WildFly server will be provisioned with the jaxrs-server and microprofile-platform layers so that server contains all the bits (and only those!) to run these features.
Its HTTP endpoint uses MicroProfile Config to read a config property from the CONFIG_PROP environment variable and returns its value in the HTTP response.

Install Helm and have access to an OpenShift cluster.

Please refer to Installing Helm page to install Helm in your environment.

We will use Developer Sandbox for Red Hat OpenShift as our OpenShift cluster and make sure that we are logged in the cluster and that the oc command applies to that cluster.

Install Helm Repository for WildFly Chart

The wildfly Chart can be installed from the https://docs.wildfly.org/wildfly-charts/ repository

$ helm repo add wildfly https://docs.wildfly.org/wildfly-charts/
"wildfly" has been added to your repositories
$ helm search repo wildfly
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
wildfly/wildfly         1.3.0           23.0            Build and Deploy WildFly applications on OpenShift

The first thing to notice is that the APP VERSION points to 23.0. By default, the Chart will deploy your application using the latest WildFly 23.0 release (23.0.2.Final at the time of this writing).

Install the Application on OpenShift

Once the wildfly Chart is added, we can instal a Helm release by using the helm install command with the name of the release as well as a YAML configuration file that contains all the settings to build and deploy the application:

$ helm install microprofile-config-app \
    wildfly/wildfly \
    -f https://raw.githubusercontent.com/wildfly/wildfly-charts/main/examples/microprofile-config/microprofile-config-app.yaml

NAME: microprofile-config-app
LAST DEPLOYED: Tue May  4 14:52:02 2021
NAMESPACE: jmesnil1-dev
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Your WildFly appplication is building! To follow the build, run:

$ oc get build -w

Note that your Deployment will report "ErrImagePull" and "ImagePullBackOff" until the build is complete. Once the build is complete, your image will be automatically rolled out.

To follow the deployment of your application, run:

$ oc get deployment microprofile-config-app -w

As you can read above, the ouput of the helm install command contains instructions to follow the installation of the application.

We can watch its build by running:

$ oc get build -w
NAME                        TYPE     FROM          STATUS    STARTED         DURATION
microprofile-config-app-1   Source   Git@7f0eed5   Running   2 minutes ago
microprofile-config-app-1   Source   Git@7f0eed5   Complete   4 minutes ago   4m30s

After the application is built, we can watch its deployment by running:

$ oc get deployment microprofile-config-app -w
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
microprofile-config-app   0/1     1            0           4m4s
microprofile-config-app   0/1     1            0           4m30s
microprofile-config-app   1/1     1            1           5m17s

The application is now available and we can query it. By default, the Helm Chart will create a Route to access the application:

$ oc get route
NAME                      HOST/PORT                                                                        PATH   SERVICES                  PORT    TERMINATION     WILDCARD
microprofile-config-app   microprofile-config-app-jmesnil1-dev.apps.sandbox-m2.ll9k.p1.openshiftapps.com          microprofile-config-app   <all>   edge/Redirect   None

Note	The `HOST/PORT` value is specific to my cluster and your route will have a different value

We can then query the HTTP endpoint by using this information:

$ curl -L  http://$(oc get route microprofile-config-app -o jsonpath="{.spec.host}")/config/value
Hello from OpenShift

The application is up and running. Let’s now look at the configuration file that the Chart used to install the application.

Looking at the Helm Release File

Let’s deep dive in the YAML File that we use to install the application (https://raw.githubusercontent.com/wildfly/wildfly-charts/main/examples/microprofile-config/microprofile-config-app.yaml):

build:
  uri: https://github.com/wildfly/quickstart.git
  ref: 23.0.2.SP1
  mode: bootable-jar
  env:
  - name: ARTIFACT_DIR
    value: microprofile-config/target
  - name: MAVEN_ARGS_APPEND
    # Use the bootable-jar-openshift profile to ensure that the application
    # can be deployed on OpenShift but disable JKube as the image will be
    # built and deployed by this chart.
    value: -am -pl microprofile-config -Pbootable-jar-openshift -Djkube.skip=true
  - name: MAVEN_OPTS
    value: '-XX:MetaspaceSize=251m -XX:MaxMetaspaceSize=256m'
deploy:
  replicas: 1
  env:
  - name: CONFIG_PROP
    value: Hello from OpenShift

The first thing to notice is that the configuration file contains two main sections build and deploy.

The build section focuses on building the application image using an OpenShift BuildConfig resource. The BuildConfig resource pulls the application from a Git repository (based on the uri and ref fields).

The mode field specifies which types of application image to build. There are two valid modes: s2i and bootable-jar.

The s2i build mode uses WildFly Source-to-Image (S2I) Builder and Runtime images to create the application image. In the bootable-jar build mode, the BuildConfig will compile the application as a Bootable Jar and use the OpenJDK 11 image as the base image.

Finally there is an env section that contains any environment variables needed to build the image. We have three environment variables that are needed for Maven options. As a whole they mean that we build only the specific microprofile-config Maven module from the quickstart Git repository with the bootable-jar-openshift Maven Profile (to create a Bootable Jar) and use its artifact as the target of the application image.

The deploy section focuses on deploying the application image on OpenShift. It creates different resources (Deployment, one or many Services, a Route) to make the application accessible from inside and outside the cluster by default.

We have only defined two fields in that section:

replicas which specifies the number of pods that the application will use
env wich are environment variables needed to run the image. In our example, we only have one named CONFIG_PROP and its value is used in the HTTP endpoint’s response.

There are a lot of things to discuss with this chart and we will have other blog posts to showcase its features. All of them are documented in the wildfly Chart documentation.

However as a last example, one of the interesting features of Helm is that the YAML configuration file can be overridden on the command line to provide additional customization to the application.

To highlight this, we will upgrade the application by changing the number of replicas of the applications so that we have 3 pods instead of 1 (by setting the deploy.replicas field to 3 with the helm upgrade command)

$ helm upgrade microprofile-config-app \
    wildfly/wildfly \
    -f https://raw.githubusercontent.com/wildfly/wildfly-charts/main/examples/microprofile-config/microprofile-config-app.yaml \
    --set deploy.replicas=3
Release "microprofile-config-app" has been upgraded. Happy Helming!
NAME: microprofile-config-app
LAST DEPLOYED: Tue May  4 15:21:29 2021
NAMESPACE: jmesnil1-dev
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:

If we watch the deployment, we see that the application is now scaling up to 3:

$ oc get deployment microprofile-config-app -w
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
microprofile-config-app   1/3     3            1           29m
microprofile-config-app   2/3     3            2           30m
microprofile-config-app   3/3     3            3           30m

Conclusion

The Helm Chart for WildFly simplifies building and deploying WildFly application on OpenShift and Kubernetes.

This wildfly Chart is designed to leverage WildFly features (such as Bootable Jar, Galleon provisioning, S2I) to make sure WildFly applications can be deployed and maintained on OpenShift with ease.