7:13 a.m.
Hi,
To run WildFly on a Cloud with a container image, you have 2 approaches:
* Use the “docker” image that provides a downloaded installation of WildFly, put your
deployment in it and deploy on your container platform.
* Use the “s2i” images to build an application with S2I (Source-to-image) on OpenShift,
put it in a runtime image and deploy it on OpenShift.
Both approaches have their own strength and weaknesses and evolved at their own pace
without any coordination.
However in the last few months, the activity on the docker image slowed down due to
external factor (hub.docker constraints) and our lack of attention to it…
Meanwhile, we have ramped up the activity on the S2I images and provided a whole new
architecture that relies on Maven to assemble the application runtime (WildFly +
deployments) instead of hiding that assembly in the S2I process.
I just wrote down an article on wildfly.org explaining how WildFly users that uses the
“docker” image can adapt their workflow to the new architecture (without having to switch
to S2I!)
https://www.wildfly.org/news/2022/08/04/wildfly-maven-docker/
The target audience for this article is the “docker” users so that they can keep their
workflow (I build my deployment, I create a container image from a Dockerfile) and benefit
from all the work done around WildFly provisioning (feature packs, layers, packaging
scripts, etc.)
While writing this article and looking at the issues for the docker image, I spotted a few
themes shared between all these images:
* We want to consume more recent versions of JDK (17 in particular)
* We want to run on linux/arm64 (in addition to Intel arch)
* We want to trim the image size / reduce the surface area of security attacks
* We want better image health index
I think the investment we made on the S2I bundler and runtime images can benefit to the
docker image and vice versa.
In particular, we are dedicated to provide a runtime image that contains all it needs to
run WildFly (ie OpenJDK + a few more bits) with a good health index.
On the docker image, the base-jdk image we are using is lagging behind and I wonder if we
should not take the opportunity to use the WildFly runtime image as the base for the
docker image (after all, its sole purpose is to run WildFly!)
I’ve started a Board to list the synergies and feature gap we have in our images:
https://trello.com/b/QGnEci3i/willdfly-image-alignments
I think that using the runtime image as the base image for the docker image would be an
enabler for a lot of this work and would ensure that WildFly is in better shape to run on
containers.
As I wrote in the article, we will continue to deliver the Docker image for WildFly but we
are focusing on the new architecture and the new images to expand the capabilities of
WildFly.
We are looking forward to our users trying this new approach and validates how it improves
their workflow.
I’ve opened this thread to gather input on this alignment to make sure we get all the
requirement in place before putting this in action.
I’m looking forward to hearing your ideas on it.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/