This project defines Images allowing you to build and deploy WildFly applications on the cloud.
Relationship with WildFly s2i centos7 images
These new images replace the quay.io/wildfly/wildfly-centos7
and quay.io/wildfy/wildfly-runtime-centos7
images.
As opposed to the wildfly-centos7
WildFly s2i builder image that is containing a WildFly server, the new builder image
is a generic builder allowing to build image for any WildFly releases.
Releasing new images is no more bound to WildFly server releases. Releases are done for fixes and new features done in the image.
WildFly - UBI8 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-jdk11:latest
-
JDK17 based runtime image:
docker pull quay.io/wildfly/wildfly-runtime-jdk17: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 this 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 - UBI8 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-jdk11:latest
-
JDK17 based builder image:
docker pull quay.io/wildfly/wildfly-s2i-jdk17: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 test directory.
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:27.0.0.Final,org.wildfly.cloud:wildfly-cloud-galleon-pack:2.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.
oc
usage
OpenShift -
Adding the JDK 11 image streams:
oc create -f imagestreams/wildfly-s2i-jdk11.yaml
andoc create -f imagestreams/wildfly-runtime-jdk11.yaml
.wildfly-s2i-jdk11
andwildfly-runtime-jdk11
imagestreams are created. -
Adding the JDK 17 image streams:
oc create -f imagestreams/wildfly-s2i-jdk17.yaml
andoc create -f imagestreams/wildfly-runtime-jdk17.yaml
.wildfly-s2i-jdk17
andwildfly-runtime-jdk17
imagestreams are created.
Create a new application from the wildfly-s2i-jdk11
imagestream (s2i build and OpenShift deployment) with a jaxrs
provisioned server:
oc new-app --name=my-app wildfly-s2i-jdk11~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-jdk17:latest
runtimeImage: wildfly-runtime-jdk17:latest
kind: ImageStreamTag
Building the images
You must have cekit installed.
Building the JDK11 images
cd wildfly-builder-image; cekit build docker
cd wildfly-runtime-image; cekit build docker
Building the JDK17 images
cd wildfly-builder-image; cekit build --overrides=jdk17-overrides.yaml docker
cd wildfly-runtime-image; cekit build --overrides=jdk17-overrides.yaml docker