What's new for WildFly 27 in the cloud.
WildFly S2I (Source To Image) images
In April we announced the new WildFly architecture for the cloud. I strongly encourage you to read that post to get familiar with this new architecture.
We have discontinued the release of WildFly s2i centos7 based images starting WildFly 26.1.2. For new features and bug fixes, we are now only releasing UBI8 based JDK11/JDK17 s2i builder and runtime images along with the Galleon wildfly-cloud-galleon-pack.
The latest artifacts that form the WildFly cloud experience are:
New features overview
Generation of an efficient WildFly s2i builder image. This feature, covered in detail in this blog post, is specified in this enhancement description. The environment variables that allow you to configure an S2I build to produce a WildFly S2I builder for a given WildFly server can be found here.
postgresql-serverWildFly s2i builders. The Maven projects cloud-server and postgresql-server define s2i builders maven projects and Helm chart for WildFly yaml files that you can re-use to build s2i builders. Such builders will then be usable to build your application images in an efficient way. This example highlights the usage of the generated builders.
Support for automatically discovering and registering the deployments to be secured with OIDC. This support complies with this WildFly proposal. This support is based on the
elytron-oidc-clientsubsystem. It is equivalent to the Keycloak OIDC support provided in the legacy images. The environment variables that allow you to configure the server can be found here.
Overriding of simple server configuration attributes using environment variables. This feature, enabled by default in the WildFly s2i images, is specified by this proposal. WildFly on the cloud relies on container environment variables to customize its configuration for the container platform. It is difficult to change the value of a management attribute from the standalone configuration if the attribute does not provide a default value with an expression that can be resolved at runtime. This feature introduces a generic mechanism to let user override any simple management attribute using environment variables. Complex attributes (of type
PROPERTY) are not impacted by this change.
As an example, the user could set an env var when starting WildFly to change the value of a
proxy-address-forwarding attribute with
the env var
WildFly S2I builder generation
One of the main areas feedback we got for this new architecture is that an s2i build takes more time compared to legacy WildFly s2i images.
That is due to the maven resolution of the WildFly server artifacts (JBoss Modules modules jar retrieved from remote maven repositories) during provisioning.
incremental-build (re-use of the maven cache from previous build) is enabled by default when using the Helm chart for WildFly, when building multiple
incremental build is not an answer, as the maven local cache can’t be shared among different build configs.
In order to provide an answer to this issue, we have made the WildFly s2i builder image able to generate an S2i builder image for a given trimmed server.
Such a builder contains an installed WildFly server in
/opt/server) in which a deployment built during the next s2i phase is deployed.
This kind of builder offers an efficient build phase, as no more provisioning is performed when building the application.
The builder image size is also reduced compared to the legacy WildFly s2i builder image. The image contains only the needed trimmed server artifacts.
|An interesting aspect of generated builders is that they can be shared across the s2i builds of different application deployments that require the same server capabilities.|
The following diagrams covers the three S2I workflows.
Legacy S2I workflow
New WildFly S2I workflow
2 phases S2I build workflow based on generated builder
When building such a WildFly s2i builder, the Maven and s2i environment variables that you would need to use (e.g. to configure maven repositories, set maven args, etc)
need to be isolated in order not to collide with the same environment variables one could set when using the generated builder.
For this isolation, you need to suffix any env variable with
_WILDFLY_SERVER_BUILDER (for example
The suffix is automatically removed during the build and the proper environment variable is exported.
A WildFly s2i builder is built from sources (actually just a pom.xml file) located inside a maven project. The WildFly Maven Plugin is used to provision the server, configured
with the Galleon layers of your choice (e.g.
cloud-server+ejb, etc). The Galleon layers you can use are not limited to the WildFly Galleon layers.
You can use different Galleon feature-packs to build-up your server.
This pom.xml file contains the provisioning of a cloud-server plus a postgresql driver and datasource
that the wildfly-datasources-galleon-pack defines.
To make WildFly s2i builder generation possible using the Helm chart for WildFly, we have evolved it with support for the following:
Ability to disable the chained build that produces an application image. That is done thanks to the new
build.s2i.buildApplicationImageproperty. When set to
false, the name of the generated image is the name of the chart. For example
helm install cloud-server-builder -f helm.yaml wildfly/wildflywill produce an Openshift imagestream named
cloud-server-builder. The suffix
-build-artifactsthat is appended when the chained build is enabled is not added. The generated imagestream is what will then be used when building your application using the generated builder.
Ability to set a different kind of image for the s2i builder image and the runtime image. By default the WildFly s2i docker images are used for s2i build and chained build. In the context of a generated builder, the builder is of type imagestream (
ImageStreamImage). You can set the builder type using the
This helm chart file shows how to configure an s2i build to produce a WildFly s2i builder.
WildFly 27 supports only Jakarta EE 10, so the WildFly s2i examples have been migrated to jakarta EE 10.
In addition to the set of examples that we introduced for WildFLy 26, new examples have been included:
Automatic discovery and registration of deployments secured with keycloak OIDC protocol example.
A JMS broker, message provider and consumer example that relies on the new
embedded-activemqGalleon layer that WildFly provides.
An example to provision a postgresql driver and multiple datasources.
An example that highlights the new "WildFly s2i builder" generation features.
We hope that you will have an interest in these new features. As usual we need your feedback to evolve WildFly on the cloud in the right direction. Feel free to log these as new project issues.