There has been some progress on the WildFly docker images.

A contributor, Henri-Laiho, proposed in a PR[1]to switch the WildFly images to the centos variants of the Eclipse Temurin images[2].

There are many advantages with that approach:

* The Temurin images are official images based on the Eclipse Adoptium project.

* They have variants based on CentOS 7 (as our existing WildFly docker images) so any Docker images built on top of them would required no changes.

* They provide maintained images for the JDK versions that are supported by WildFly (11 & 17). We would be able to provide WildFly images for both JDK too.

* They are multiarch (and would make the WildFly image multiarch too).

Before making a decision on switching to these images, I wanted to get some community feedback.

* Do you see any reason to reject this switch?

* Should we switch to the OpenJDK images instead?

* What would be the first WildFly release that would use these base images? We are about to release WildFly 27 that requires Jakarta EE 10. This would be a good first target. But we have a lot of users that will remain on Jakarta EE 9 (and thus WildFly 26) that would appreciate running their apps on JDK 17 (and ARM architecture for example)?

I'll keep that thread open for feedback before we decide if, when and how we could make that switch.

Best regards,

jeff

[1] https://github.com/jboss-dockerfiles/wildfly/pull/161
[2] https://hub.docker.com/_/eclipse-temurin/tags

On Mon, Aug 8, 2022 at 2:16 PM Jean-Frederic Mesnil <jmesnil@redhat.com> wrote:
>
> Hi (answers inlined)
>
> > On 5 Aug 2022, at 21:10, Brian Stansberry <brian.stansberry@redhat.com> wrote:
> >
> > 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.
> >
> > * 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?
>
> The gain in image size is not significant (124MiB for the runtime image, 159MiB for the docker image).
> The gain becomes more evident when layers are used with the runtime image to trim the WildFly content to install.
>
> Freshness of the images is meaningful for the security attacks. The base-jdk11 image has not been updated for 2 years now.
>
>
> > * We want better image health inde
>
> > 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?
>
> Yes. When we move the docker image from hub.docker.com to quay.io, we changed the workflow to automate the images respins.
>
> > 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?
>
> From a WildFly perspective, there are no downside as we would have all the packages we need to run the server.
>
> The big shift is in the underlying base image. The docker image is based on CentOS 7 while the runtime image is based on UBI 8 minimal.
> Users that are extending the docker image and installing other packages would have to move from using yum to microdnf.
>
> Best regards,
> Jeff
>
> --
> Jeff Mesnil
> Principal Software Engineer
> Red Hat
> http://jmesnil.net/
>

--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/