Hi (answers inlined)
On 5 Aug 2022, at 21:10, Brian Stansberry
<brian.stansberry(a)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/