WildFly Helm Charts with custom configuration

by

This article provides a step-by-step guide to deploy WildFly in a Kubernetes environment using Helm Charts and custom application server settings. By the end of it, you will be able to customize effectively your WildFly applications on the cloud using just plan environment variables.

Getting Started with Helm Charts and WildFly

Helm charts provide a simple and effective way to package, configure, and deploy applications on Kubernetes clusters. Integrating WildFly with Helm empowers users to define application deployments using YAML-based configuration files.

If you are new to Helm Charts and WildFly we recommend checking this article first: How to run WildFly with Helm Charts

In the next section of this article, we will learn how to customize an Helm Chart for WildFly by providing custom configuration settings.

Setting up the WildFly Helm Chart

The Chart.yaml file is a fundamental component of a Helm chart. It serves as a metadata file that provides essential information about the chart itself. This file contains details and configurations necessary for managing and deploying the chart using Helm.

in the following Chart.yaml we will include the Chart name and the dependency on WildFly Chart: 

apiVersion: v2
name: helloworld
description: A Helm chart for Kubernetes
type: application


version: 1.0.0

appVersion: "0.0.2"

dependencies:
    - name: wildfly
      repository: http://docs.wildfly.org/wildfly-charts/
      version: 2.3.2

When you run helm dependency build for your chart, Helm fetches the specified chart from the specified repository (in this case, http://docs.wildfly.org/wildfly-charts/) and stores it in the charts/ directory of your chart.

Next, we will configure the values.yaml file, which acts as the main configuration file for the WildFly Helm chart. This file allows defining various aspects of the WildFly deployment, including build and deployment specifications.

wildfly:
    build:
      uri: https://github.com/wildfly/quickstart.git
      ref: main
      contextDir: helloworld
    deploy:
      replicas: 1
      env:
        - name: SUBSYSTEM_TRANSACTIONS__DEFAULT_TIMEOUT
          value: "450"
        - name: GC_MAX_METASPACE_SIZE
          value: "256"
        - name: GC_METASPACE_SIZE
          value: "96"

Within the above yaml file, we are using two main configuration sections:

  • build: Specifies the source for the WildFly deployment, including the Git repository URI, branch, and context directory.
  • deploy: Defines deployment-related configurations such as the number of replicas and environment variables.

Using environment variables in the Helm Charts

By using environment variables in your Helm Charts you can customize the configuration of WildFly without adding any CLI command or custom XML snippets.

You can do it in two ways: Firstly, you can translate Model attributes into Environment variables. For example, the expression 

 - name: SUBSYSTEM_TRANSACTIONS__DEFAULT_TIMEOUT
          value: "450"

…translates in the following CLI Command:

/subsystem=transactions:write-attribute(name=default-timeout,value=450)

To learn more about translating environment variables into WildFly Model check this article: How to customize WildFly using Env variables

Then, you can use built-in Environment Variables such as GC_MAX_METASPACE_SIZE or GC_METASPACE_SIZE. These variables automatically translate into the corresponding JVM Options as start up.

A good source of information for built-in Environment variable is JBoss EAP 7 on OpenShift reference guide.

Installing the Helm Chart

Next step, will be installing the Chart. As the Chart.yaml file includes a dependency in it, we need first to install the dependency:

helm dependency build ./charts

Then, install the chart “helloworld” using the charts available in the folder charts:

helm install helloworld ./charts

Shortly, you should be able to see the Pods which will move to the status Running, upon successful build:

$ oc get pods
NAME                                 READY   STATUS      RESTARTS   AGE
helloworld-2-build                   0/1     Completed   0          19m
helloworld-8665d8b557-hg9rh          1/1     Running     0          14s
helloworld-build-artifacts-1-build   0/1     Completed   0          21m

To check that the WildFly Model includes the default-timeout setting we can simply log into the Pod with rsh and launch the CLI:

$ oc rsh helloworld-8665d8b557-hg9rh
sh-4.4$ /opt/wildfly/bin/jboss-cli.sh -c

As you can see, we managed to apply the default-timeout setting by including it as environment variable in the Hem Chart.

wildfly with helm charts advanced tutorial

Conclusion

In conclusion, this tutorial has provided a comprehensive walkthrough of customizing WildFly using Helm charts, empowering users to tailor their application server environment within Kubernetes effortlessly.

You can find the example Helm Chart here: https://github.com/fmarchioni/mastertheboss/tree/master/openshift/helm-helloworld