Better synergies for WildFly Container images
by Jean-Frederic Mesnil
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/
2 years
