TL;DR; We are proposing here a new WildFly s2i architecture in order to remove existing pain points we are encountering today when building WildFly application for the cloud.

Uncoupling the WildFly S2i image from WildFly server installations

Today, we are relying on the WildFly s2i builder image to build a WildFly application image. There is a strong coupling inside this image that implies releasing a new image for each new WildFly release. This approach is not flexible. We should be able to build an application image for any WildFly release (even for a locally built SNAPSHOT) without having to wait for the WildFly s2i builder image to be deployed.

In addition, the WildFly server located inside the builder image, enforces a set of configuration API (a set of environment variables) and bash launch scripts. At startup time, a complex CLI script generation that impacts the server startup time is mandatorily executed. Having this level of configurability should be a user choice and not be enforced by the WildFly s2i image.

To solve these pain points, we should remove the server and its configuration aspects from the image. The WildFly s2i image should become a generic image allowing to properly install and execute any provisioned WildFly server. As a developer one should be able in max 2 steps to deploy to the cloud an app. Same for WildFly developers that should deploy a locally built WildFly SNAPSHOT in one step (as done with WildFly Bootable JAR today). 

The role of a WildFly s2i builder image should be limited to:

• Provide JDK and maven tooling
• Provide automatic and configurable JVM configuration at server startup (same as the openjdk builder image)
• Understand the execution constraints for the server and adapt the server launch processing (e.g.: start the server in a way that would allow a server killed by POD to terminate properly).
• Provide nice defaults for the minimal set of server configuration items (e.g.: jboss.node.name derived from hostname, public interface address, management address)
• Install the server in the image (eg: /opt/wildfly).
• Understand that the s2i is a build from source vs a build from binary.
• Handle incremental build (e.g.: cache maven repository)
• Built application Image must be runnable but also usable inside a docker chained build to construct a final application image (that doesn't contain any build tooling).

The steps that have been removed from the WildFly s2i build processing are now aggregated inside a single point of configuration inside a new WildFly Maven plugin. This plugin is very similar to the bootable JAR maven plugin. Such a plugin handles Galleon provisioning, user CLI scripts execution, ability to enrich server content and application(s) deployment.

This plugin used in conjunction with the new WildFly s2i image is all what is needed to offer a flexible experience. We gain the flexibility to provision/configure a WildFly instance to answer specific requirements instead of relying on a fixed set of features packaged inside a WildFly s2i builder image.

To retrieve the WildFly s2i built-in server configurability, we are introducing a WildFly Legacy Cloud Galleon feature-pack to provision a “legacy” server, offering all the capabilities found today in WildFly s2i. This becomes a user choice. By provisioning a vanilla WildFly, you will get a vanilla WildFly behaving properly in the cloud. By provisioning this legacy Galleon pack, one will get the fully featured server found in current S2i image.

NB: In the future we could define a non legacy WildFly cloud galleon feature-pack with some new WildFly cloud specific features.