[wildfly-dev] Re: Better synergies for WildFly Container images

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(a)redhat.com&gt; wrote: wrote: 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. attacks smaller/less attack surface than the base-jdk image currently used? 159MiB for the docker image). to trim the WildFly content to install. base-jdk11 image has not been updated for 2 years now. that aligning on the runtime images will improve our ability to handle things like respins. Is that your thinking? changed the workflow to automate the images respins. image would be an enabler for a lot of this work and would ensure that WildFly is in better shape to run on containers. of? the packages we need to run the server. on CentOS 7 while the runtime image is based on UBI 8 minimal. would have to move from using yum to microdnf. -- Jeff Mesnil Principal Software Engineer Red Hat http://jmesnil.net/