WildFly - UBI9 runtime image

An image containing all you need to run a WildFly Server. This image is to be used in a docker build to install a WildFly server.

  • JDK11 based runtime image: docker pull quay.io/wildfly/wildfly-runtime:latest-jdk11

  • JDK17 based runtime image: docker pull quay.io/wildfly/wildfly-runtime:latest-jdk17

  • JDK21 based runtime image: docker pull quay.io/wildfly/wildfly-runtime:latest-jdk21

  • Latest LTS JDK (with which we have completed the full set of testing of WildFly) based runtime image: docker pull quay.io/wildfly/wildfly-runtime:latest

The example docker-build covers building an image from your Maven application project.

Image API

When running a WildFly server inside the WildFly S2i runtime, you can use these environment variables to configure the Java VM. The WildFly S2i runtime image is exposing a set of environment variables to fine tune the server execution.

WildFly - UBI9 S2I builder image

S2I build workflow

This image contains all you need to execute a Maven build of your project during an S2I build phase (using s2i tooling or OpenShift).

The builder image expects that, during the Maven build, a WildFly server containing the deployment is being provisioned (by default in <application project>/target/server directory). This provisioned server is installed by the image in /opt/server. Making the generated application image runnable.

In order to provision a server during the build phase you must integrate (generally in a profile named openshift profile) an execution of the WildFly Maven plugin.

Documentation of the WildFly Maven plugin can be found there.

S2I builder images

  • JDK11 based builder image: docker pull quay.io/wildfly/wildfly-s2i:latest-jdk11

  • JDK17 based builder image: docker pull quay.io/wildfly/wildfly-s2i:latest-jdk17

  • JDK21 based builder image: docker pull quay.io/wildfly/wildfly-s2i:latest-jdk21

  • Latest LTS JDK (with which we have completed the full set of testing of WildFly) based builder image: docker pull quay.io/wildfly/wildfly-s2i:latest

Using the S2I builder image

The more efficient way to use the WildFly S2I builder image to construct a WildFly application image is by using WildFly Helm charts. WildFly Helm Charts are automating the build (on OpenShift) and deployment of your application by the mean of a simple yaml file.

The examples directory contains Maven projects and documentation allowing you to get started.

Note
 If you are using the legacy centos7 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

WildFly cloud Galleon feature-pack

The WildFly cloud feature-pack contains all the cloud specifics that were contained in the wildfly/wildfly-centos7 image. This feature-pack has to be provisioned along with the WildFly feature-pack.

This example contains a Maven project that makes use of some of the org.wildfly.cloud:wildfly-cloud-galleon-pack features to highlight web session sharing.

More Maven projects that make use of the WildFly cloud feature-pack can be found in the WildFly quickstarts.

For more information on the WildFly cloud feature-pack features, check this documentation.

Backward compatible S2I workflow

In case you want to keep your existing project that used to work with the legacy WildFly S2i builder (quay.io/wildfly/wildfly-centos7) image, you can use a set of environment variables to initiate a server provisioning prior to execute the Maven build of your application:

  • GALLEON_PROVISION_FEATURE_PACKS: Comma separated lists of Galleon feature-packs, for example: GALLEON_PROVISION_FEATURE_PACKS=org.wildfly:wildfly-galleon-pack:30.0.0.Final,org.wildfly.cloud:wildfly-cloud-galleon-pack:5.0.0.Final

  • GALLEON_PROVISION_LAYERS: Comma separated lists of Galleon layers, for example: GALLEON_PROVISION_LAYERS=cloud-server

NB: This support is deprecated. You are strongly advised to update your project to integrate the WildFly Maven plugin in your Maven project.

OpenShift oc usage

  • Adding the Latest JDK image streams: oc create -f imagestreams/wildfly-s2i.yaml and oc create -f imagestreams/wildfly-runtime.yaml. wildfly-s2i and wildfly-runtime imagestreams are created.

Create a new application from the wildfly-s2i imagestream (s2i build and OpenShift deployment) with a jaxrs provisioned server:

  • oc new-app --name=my-app wildfly-s2i~https://github.com/wildfly/wildfly-s2i --context-dir=examples/jsf-ejb-jpa

Create a route:

  • oc expose svc/my-app

Using image streams with Helm chart for WildFly

In order to use the imported WildFly s2i builder and runtime imagestreams, you can use imagestreams tag or id.

When setting the kind to the ImageStreamTag value, you must set the builderImage and runtimeImage to the <imagestream name>:latest value. When setting the kind to the ImageStreamImage value, you must set the builderImage and runtimeImage to the <imagestream name>@image_id value.

For example, usage of JDK 17 builder and runtime imagestream tags:

  s2i:
    builderImage: wildfly-s2i:latest-jdk17
    runtimeImage: wildfly-runtime:latest-jdk17
    kind: ImageStreamTag