Introduce a micro image based on ubi-micro

[matthyx]

related to https://github.com/quarkusio/quarkus/issues/21051 fixes #166

[cescoffier]

I would not call that new setup "distroless". I'm not against it, but it needs to be its own new base image (with another name).

[matthyx]

I would not call that new setup "distroless". I'm not against it, but it needs to be its own new base image (with another name).

True in a sense, it depends whether you want to refer to using Google's distroless or to the fact that there is no distribution in that image. I'm open to discussion, but having 2 bare minimal images seems overkill... please also take a look at #166 which I missed initially.

[jerboaa]

"distroless" in my understanding means images without a package manager installed. UBI-8 micro is that. There are probably many more. So I concur what's been proposed in https://github.com/quarkusio/quarkus-images/issues/166 to standardize on UBI-8.

[cescoffier]

From the distroless README: "Distroless" images contain only your application and its runtime dependencies., so it's more than just package managers. At the moment the distroless base images provided by Google are all Debian-based.

Our current approach creates a suitable image that is 22.7MB (and I know I can shave 2-3 Mb, so, we can probably go beyond 20Mb), Ubi-Micro alone is 36.7MB.

Again, I'm not against it, but switching to Ubi-Micro discards our effort to create very small images. That's why I think it needs to be another image. I would not call it distroless but "slim" or "micro" (I tend to like micro).

[matthyx]

Again, I'm not against it, but switching to Ubi-Micro discards our effort to create very small images. That's why I think it needs to be another image. I would not call it distroless but "slim" or "micro" (I tend to like micro).

Ok, so let's introduce the new "micro" flavour that could be used for all Quickstart images! (updated PR content and title to reflect that)

[Karm]

@cescoffier Well, we either need Debian builder image a and use the whole Debian toolchain ( -1 on that) or we need to migrate from Debian Slim to UBI Micro (Micro not Minimal) (+1 on that).

Doing this https://github.com/quarkusio/quarkus-images/blob/main/quarkus-distroless-image.yaml#L16 for a Quarkus binary that was built with UBI based builder image is plain wrong. It works just by chance that the zlib version in those distros at this time is similar enough and that their glibc is also similar enough...at the time of writing.

Current Debian based distroless option should be removed (refactored).

[cescoffier]

So if I follow you, we won't be able to have small images because we need a base image that is clearly too large to compete.

Before doing the current approach, we did quite some tests. If you follow the whole history, we even had bazel based workflows for a long time. The current approach seems to provide a good trade off, it worked for all the apps I tried. Of course, we may find applications that will have issues. In this case I would recommend going back to bazel.

I always considered our distroless approach experimental, and I would not recommend it without preliminary tests.

We can change the docker file provided by Quarkus to use 'micro', but we need something smaller - a lot smaller. I would even say that the current approach is too large, and we need to divide the size by 2 or 3. I've tested upx but the need for libc++ and the memory consumption are not helping much. I have some ideas, and yes, using Debian builders (like we did with Bazel as I ran bazel from a Debian based image) is one of them. But see that as experiments to try to reduce the resulting image size, and not something prod-ready without preliminary checks.

[matthyx]

So, do we want that micro image that could serve as a base layer for Quickstart?

[galderz]

@cescoffier Couldn't an image based on UBI micro be shrunk once all the bits are in place to reduce its size? I'd favour stability provided by using the same toolchain, even if it costs some megas, rather than having some weird error caused by the use of different toolchains, which could be rather tricky to discover.

[cescoffier]

@galderz Sure, we could, but it's long and hard. Basically, we need to redo all the work distroless did (and they are brilliant and know a thing or two about the OS they use). So that would take a long time to reach the same size and stability.

Another approach that I abandoned, but maybe revisited is to go back to "from Scratch" and install everything manually (glibc, libz, openssl, certs, users/groups...) and the application. I gave up with this approach (I still believe that the way to get even smaller) because it was just too hard to maintain in the long run. Any update requires diving into the gory details of the OS (and most of the time it's specific to the distribution you are trying to reproduce - in our case, UBI).

[matthyx]

@cescoffier @Karm any update?

[cescoffier]

I will work on this shortly (probably tomorrow)

[cescoffier]

Thank you!

I made minor changes in the README. This will be merged and pushed later today.

Next steps:

• Update or replace the image produced by Quarkus to use this new image
• Update the quickstart to use this new image

This is track using: https://github.com/quarkusio/quarkus/issues/21557.

[matthyx]

Next steps:

• Update or replace the image produced by Quarkus to use this new image
• Update the quickstart to use this new image

Thanks Clement, are you taking care of them?

[cescoffier]

@matthyx Most probably yes. Either I will handle them or delegate to someone. I'm targeting Quarkus 2.6 (Dec 8th for the CR1).

[cescoffier]

(@matthyx Of course, any help is more than welcome :-D)

[matthyx]

(@matthyx Of course, any help is more than welcome :-D)

@cescoffier do you need my help for upcoming 2.6 ?

[cescoffier]

@matthyx If you could handle some of the quickstarts it would be great! We had a few issues around AWT, but it's getting fixed.