5:58 p.m.
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).
Nothing more. The server provisioning and configuration steps have been
removed from the s2i build process. All the server runtime
configurability based on env variables have been removed. (e.g.: ability
to add datasources, ability to simply configure elytron, https,
keycloak, …) We will see next how to bring them back but this time as a
desired choice not as a mandatory way to configure the server.
A Maven plugin to provision and configure WildFly
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.
Adding back existing WildFly s2i configurability
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.
Unified experience for application “Builder” Cloud images
This new architecture should allow an unified experience across the
various builder images technologies. For example, the same application
maven project could be used eventually with WildFly BuildPacks builder
or with WildFly s2i builder image.
Thank-you for your reading.
JF