What's new for WildFly 27 in the cloud.

By Jean-François Denise | November 09, 2022

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.

  • cloud-server and postgresql-server WildFly 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-client subsystem. 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 OBJECT, LIST, 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 SUBSYSTEM_UNDERTOW_SERVER_DEFAULT_SERVER_HTTP_LISTENER_DEFAULT__PROXY_ADDRESS_FORWARDING.

  • Image streams that you can import in OpenShift and use with helm Charts:

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. Although 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 applications 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 $JBOSS_HOME (/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.

Note
 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

legacy S2I

New WildFly S2I workflow

new S2I

2 phases S2I build workflow based on generated builder

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 MAVEN_ARGS_APPEND_WILDFLY_SERVER_BUILDER). 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. jaxrs-server, 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.buildApplicationImage property. 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/wildfly will produce an Openshift imagestream named cloud-server-builder. The suffix -build-artifacts that 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 (ImageStreamTag or ImageStreamImage). You can set the builder type using the build.s2i.builderKind property.

This helm chart file shows how to configure an s2i build to produce a WildFly s2i builder.

New Examples

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-activemq Galleon 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.

Enjoy!

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.

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