Thanks, Jeff. So AIUI the idea is to support multiarch and linux/arm64 on
the runtime image, and thus on the docker image that would now be based
upon it instead of the base-jdk image. And since we have both SE 11 and 17
runtime images it's trivial to produce an SE 17 docker image. That all
sounds reasonable; more in-line.
On Fri, Aug 5, 2022 at 7:13 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
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
Does what you're proposing address this aspect? Is the runtime image
smaller/less attack surface than the base-jdk image currently used?
* We want better image health index
A smaller attack surface would help with that and I believe the idea is
that aligning on the runtime images will improve our ability to handle
things like respins. Is that your thinking?
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.
Why would we *not* do this? Any meaningful downsides I'm not thinking of?
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/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His