WildFly S2I new architecture is final!

By Jean-François Denise | April 20, 2022

New WildFly on the cloud architecture

We have released the new components that make for a completely redesigned WildFly cloud experience. This redesign allows for more flexibility, simpler workflows and smaller application images.

Our new cloud architecture is composed of 5 main components:

The new S2I workfow can be summarized as:

  • Configure the WildFly Maven plugin to deploy your application in the WildFly server of your choice, finely tuned according to your needs (an example)!

  • Make your application sources available in a GIT repository (an example).

  • Define a Helm Chart for WildFly yaml file (an example).

  • Install your Helm file into OpenShift (an example). You are done!

To get you familiar with the various components you can directly jump to these examples. They will drive you through various use-cases from source to deployment on OpenShift (for immediate access to an OpenShift cluster, you can use OpenShift sandbox).

Legacy WildFly S2I and runtime centos7 images

We have released the legacy images for WildFly 26.1.0.Final in quay.io/wildfly. We are not planning to release any centos7 images starting WildFly 27.

Note

When using the legacy S2I images for WildFly, you must stay on the 1.x version of the Helm Chart for WildFly:

helm install my-legacy-app -f helm.yaml wildfly/wildfly --version ^1.x

New WildFly S2I and runtime images

We have released our new UBI8 minimal based images:

S2I builder images and runtime images, although directly usable from docker build (an example of docker image built from a WildFly runtime image can be found here) or S2I tooling, are best used when using Helm Chart for WildFly. Helm Chart create smart chained builds in order to output lightweight application images running on the runtime of your choice (JDK11 or JDK17).

Detailed documentation can be found there.

Universal Base Image 8 Minimal

Our new images are based on Universal Base Image. The UBI8 image has been designed and engineered to be the base layer for containerized applications. The Minimal flavor is a stripped down image.

Relationship with the openjdk S2I images

Our new images are sharing the Java VM configuration API with the openjdk images. This has multiple benefits:

  • JDK alignement. Benefit from latest updates.

  • JVM configuration alignment. Benefit from the same automatic tuning and configuration of Java VM.

In the end you are getting an homogeneous user experience whatever the kind of WildFly server packaging you have chosen: WildFly Bootable JAR that runs on the openjdk images or WildFly that runs on our new images.

An S2I builder image decoupled from WildFly server

S2I builder images are generic and can be used to deploy application for any WildFly server version.

Builder images have no dependency on a WildFly server release (as opposed to the legacy centos7 WildFly images that are bound to a given server version).

You can even run Jakarta EE8 or Jakarta EE9-based application from these images. The PostgreSQL example and PostgreSQL Jakarta EE9 example are identical applications deployed on different kind of WildFly server. Just a matter of choosing the right Galleon feature-packs to assemble the right server.

Release of the new images

Images release cadence is now decoupled from the WildFly server release cadence. Images have their own lifecycle. New releases will be done to address fixes and new features. Released images are deployed in the quay.io/wildfly organization For the one that love to be on the bleeding edge we are constantly deploying images under development to the quay.io/wildfly-snapshots organization.

Using the JDK 17 S2I builder image

Applications are built and run similarly on JDK11 and JDK17. For JDK17 just make sure to have your maven projects to use 3.3.2 version for the Maven war plugin. This example shows how to configure the Maven war plugin version.

Note

When using JDK17 images of a version < 1.0.2, you need to set the following env variable to workaround WFCORE-5835:

JAVA_OPTS_APPEND=--add-exports=jdk.naming.dns/com.sun.jndi.dns=ALL-UNNAMED

The latest JDK17 images have been fixed.

Multiarch images preview

We have released preview of Multiarch images (linux/amd64 and linux/arm64). Longer term we plan to make our official images multi arch and stop releasing the preview images, but we are not yet there.

Multi arch preview images:

New s2i build workflow

In order to create a server to be installed into the WildFly image we are relying on the WildFly Maven plugin 3.0.0.Final that can now provision a fully configured server containing your deployment. The WildFly Maven plugin 3.0.0.Final has been evolved with some new goals to provision, configure, and package the server and the deployment in one step. When designing your application pom file, add an execution of the WildFly Maven plugin package goal, configure it with the WildFly Galleon feature-pack and Galleon layer(s), and optionally reference WildFly CLI scripts to be executed and content to be copied inside the server. At the end of the build you will get (by default in the target/server directory) a server with your app deployed, ready to be installed in the image.

In order to allow for a smooth transition to the new images, we are still supporting (in a deprecated way) the legacy workflow. Your existing application would work, but you are now required to specify the Galleon feature-pack(s) and layer(s) (GALLEON_PROVISION_FEATURE_PACKS and GALLEON_PROVISION_LAYERS env variables) you want to provision during the S2I build.

Execution time server configuration

Application images built from the WildFly S2I builder or runtime images both expose the same API allowing you to fine tune the server execution. This API is exposed by means of environment variables to be set when configuring your deployment.

JVM configuration API

The JVM env variables that are used today with WildFly s2i images are still supported. They are a nice way to tune the JVM.

WildFly server startup configuration API

The new server startup configuration API is described in this documentation. This API comes with default values that should cover the main use-cases. 2 env variables open-up new possibilities:

  • SERVER_ARGS allows you to pass WildFly server arguments when starting the server.

  • CLI_LAUNCH_SCRIPT allows you to provide a path (relative to JBOSS_HOME or absolute) to a CLI script to be executed at startup time. Although CLI scripts should be executed at build time from the WildFly Maven plugin, in some cases it can be useful to adjust the configuration at execution time. You can package a set of CLI scripts inside your server at build time, then reference one of these CLI scripts to be executed at runtime.

WildFly server subsystems configuration API

If you are using WildFly s2i images you are perhaps asking yourself where are the env variables you have been using to configure the elytron subsystem, to add datasources, to configure logging or the microprofile-config subsystem,…​ They are provided by means of a new WildFly cloud Galleon feature-pack that you can combine with the WildFly Galleon feature-pack at build time to produce a server supporting these env variables.

  • If you only provision org.wildfly:wildfly-galleon-pack:26.1.0.Final you will get a "vanilla" WildFly server that will get lightly adjusted by the image entrypoint to properly execute on OpenShift.

  • If you provision org.wildfly:wildfly-galleon-pack:26.1.0.Final and org.wildfly.cloud:wildfly-cloud-galleon-pack:1.0.0.Final you will get a WildFly server pre configured for cloud execution ready to be configured thanks to the environment variables the cloud feature-pack exposes.

2 variants exist of the cloud feature-pack:

  • org.wildfly.cloud:wildfly-cloud-galleon-pack to be used with org.wildfly:wildfly-galleon-pack to provision an EE8 server as shown in this example.

  • org.wildfly.cloud:wildfly-preview-cloud-galleon-pack to be used with org.wildfly:wildfly-preview-feature-pack to provision a Jakarta EE9 server as shown in this example.

Detailed documentation can be found there.

Examples

We have defined a set of examples to help you get started. They cover different use-cases that highlight the new capabilities.

The examples rely on Helm Chart for WildFly to automate the build and deployment on OpenShift.

In order to deploy the examples onto OpenShift, you can log in to the Developer Sandbox for Red Hat OpenShift.

The use cases covered are:

  • Cloud default configuration, an application that interacts with a postgresql database. The projects shows how to provision a server configured in a way that is similar to the default WildFly server presents in the legacy WildFly cento7 image.

  • Docker build, highlights the steps needed to build a docker image that contains the server and your application.

  • JSF, EJB application, simple application.

  • Keycloak integration. Use WildFly elytron-oidc-client to interact with a Keycloak server. Also highlights the ability to provide server arguments at launch time.

  • Logging. We all need to enable logging at some point. With a simple CLI script executed at server boot time, enable logging and redirect all traces to the CONSOLE.

  • PostgreSQL. Create a WildFly application with support for postgreSQL database.

  • PostgreSQL Jakarta EE9. Create a WildFly application with support for postgreSQL database. The running server and application are both compliant with Jakarta EE9.

  • Clustering. A cluster of PODS that share web sessions. This example benefits from the WildFly cloud feature-pack and Helm Chart for WildFly capabilities to automatically enable the dns.DNS_PING JGroups protocol and generate the ping service.

Enjoy!

and…​keep us posted with your feedback. (You can log these as new project issues.)

Thank-you!

JF Denise

WildFly is fully open. All components are open source and follow a community-focused development process.

This website was built with Jekyll is hosted on Github Pages and is completely open source. If you want to make it better, fork it and show us what you’ve got.

Navigation
Contribute
Get Help
Find more Red Hat Middleware Community Projects
CC by 3.0 | Privacy Policy Sponsored by