WildFly S2I new architecture is final!
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!
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.
When using the legacy S2I images for WildFly, you must stay on the
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
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).
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.
When using JDK17 images of a version < 1.0.2, you need to set the following env variable to workaround WFCORE-5835:
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:
https://quay.io/repository/wildfly-snapshots/wildfly-s2i-jdk11-multi-arch preview multi arch JDK11 S2I builder image.
https://quay.io/repository/wildfly-snapshots/wildfly-s2i-jdk17-multi-arch preview multi arch JDK17 S2I builder image.
https://quay.io/repository/wildfly-snapshots/wildfly-runtime-jdk11-multi-arch preview JDK11 multi arch runtime image.
https://quay.io/repository/wildfly-snapshots/wildfly-runtime-jdk17-multi-arch preview JDK17 multi arch runtime image.
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
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_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_ARGSallows you to pass WildFly server arguments when starting the server.
CLI_LAUNCH_SCRIPTallows you to provide a path (relative to
JBOSS_HOMEor 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.Finalyou 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.cloud:wildfly-cloud-galleon-pack:1.0.0.Finalyou 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-packto be used with
org.wildfly:wildfly-galleon-packto provision an EE8 server as shown in this example.
org.wildfly.cloud:wildfly-preview-cloud-galleon-packto be used with
org.wildfly:wildfly-preview-feature-packto provision a Jakarta EE9 server as shown in this example.
Detailed documentation can be found there.
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
postgresqldatabase. 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-clientto 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_PINGJGroups protocol and generate the ping service.
and…keep us posted with your feedback. (You can log these as new project issues.)