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
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:
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.
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-helloworldFound the article helpful? if so please follow us on Socials