docker: reduce ubi8 images size by using ubi8-minimal as base

[jvidalallende]

This PR changes the base image from ubi-8 to ubi8-minimal, which has smaller size and a simpler package manager. By using this base image and properly cleaning caches, the final image size has been shrinked to about 65% of its original size, from 630MB to 400MB (note that comparison is done with ubi-8 building version 46eb7c8808 and ubi8-minimal building latest HEAD as of submitting this PR).

REPOSITORY     TAG                          IMAGE ID       CREATED          SIZE
frr            ubi8-minimal-cf2960e0df      b3c14b578f4d   15 minutes ago   400MB
frr            ubi-8-46eb7c8808             155a09c339b3   42 minutes ago   630MB

The ubi8-minimal Dockerfile also uses packages built from RHEL, as opposed to the previous ubi-8 Dockerfile which used packages built for CentOS.

[NetDEF-CI]

Continuous Integration Result: SUCCESSFUL

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-9643/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

[qlyoung]

Thank you for the PR. Out of curiosity, are you using this image? If so, what for?

[jvidalallende]

Thank you for the PR. Out of curiosity, are you using this image? If so, what for?

Hi! I'm part of the IBM team, perhaps you know some of my peers @rampxxxx @lynnemorrison .

We're using these images in our project, and found out that ubi8-minimal is a great fit as base image due to their small footprint but good curated set of default packages, including the microdnf package manager.

[ton31337]

Why not use our maintained docker image built on top of Alpine?

[jvidalallende]

Why not use our maintained docker image built on top of Alpine?

We have several services that we base on ubi8-minimal, and keep moving forward the base image as security fixes are released for them. Keeping the same base image simplifies our operations.

Also, we sometimes have private paches that we test before they get to upstream, or we base them just on stable versions (while upstream moves them to master), so we prefer to build our own image.

[qlyoung]

Thank for the info! The purpose of my questions is to find out who's using what images for what purpose. I'm not sure I fully understand a couple points in your response:

We have several services that we base on ubi8-minimal, and keep moving forward the base image as security fixes are released for them. Keeping the same base image simplifies our operations.

I understand this to mean that you have containers that you maintain that uses ubi8-minimal as a base image, and when the ubi8-minimal base image updates, you update your containers to use the updated base image. Correct? So when you say "Keeping the same base image simplifies our operations" you're referring to your experience with images that your team maintains. Or do you mean you have images that use the FRR images being modified here as a base image?

Also, we sometimes have private paches that we test before they get to upstream, or we base them just on stable versions (while upstream moves them to master), so we prefer to build our own image.

This part lost me - you're speaking of your experience with the images your team maintains, right? And saying that based on your good experience with ubi8-minimal in your team, you think it's a good fit for the images being modified in this PR?

I know this is a lot of questions but personally I'm not sure where these ubi8 images came from in the first place, and as I concern myself mostly with maintaining the docker images for this project these days, I'm gathering info.

[jvidalallende]

I know this is a lot of questions but personally I'm not sure where these ubi8 images came from in the first place, and as I concern myself mostly with maintaining the docker images for this project these days, I'm gathering info.

No problem, that is fair and maybe I did not explain myself clearly.

I understand this to mean that you have containers that you maintain that uses ubi8-minimal as a base image, and when the ubi8-minimal base image updates, you update your containers to use the updated base image. Correct? So when you say "Keeping the same base image simplifies our operations" you're referring to your experience with images that your team maintains. Or do you mean you have images that use the FRR images being modified here as a base image?

Right, I refer to the images that we maintain, which are based on this very same Dockerfile. The Dockerfile takes the ubi8-minimal version as input, and builds on latest if it is not defined. We ususally prefer to pin versions of all our dependencies.

We have our private fork of FRR, which is quite close to upstream. Actually, now we are updating to use FRR 8.4.2 and the delta with upstream, except for some stuff to use our internal infrastructure, is just this PR. We build our FRR images, which are subsequently used as base images for another service.

Apart from this component, there are other services in our product that are also packaged as containers, and all of them use the same base image, this is why I meant by "simplifying our operations" when updating the base image.

Also, we sometimes have private paches that we test before they get to upstream, or we base them just on stable versions (while upstream moves them to master), so we prefer to build our own image.

This part lost me - you're speaking of your experience with the images your team maintains, right? And saying that based on your good experience with ubi8-minimal in your team, you think it's a good fit for the images being modified in this PR?

You are again on the right track, I am speaking about our own images, but they use this very same Dockerfile, verbatim. Initially we used ubi-8, but after looking on better optimizing the size of the images while keeping ease of use, we found out that ubi8-minimal was a better fit, providing smaller images while also having a nice and handy package manager.

We have been using ubi8-minimal images for some time (along with FRR 8.2.2). When we started the process to update to 8.4.2, we discovered that they did not properly build due to the requirement for librtr >= 0.8.0, so we modified them. And then comparing to what had been contributed, we saw that the ubi8-minimal patches had not been upstreamed, hence this PR.

I hope that I clarified your points now, if you have any further doubt don't hesitate on asking ;)

[NetDEF-CI]

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-9787/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

[jvidalallende]

@qlyoung do you have any further questions or comments regarding this PR?

Is there anything that I can do to push it forward?

[jvidalallende]

@qlyoung @ton31337 Is there anything that I can do to move this PR forward?

I would appreciate any feedback if there is anything to improve about it...

[qlyoung]

@jvidalallende Apologies for the delay here, I forgot to check in on this one.

[qlyoung]

Sincerely apologize for the 2 month delay. I have all my Github notifications off otherwise I get way too many emails. It should never take this long. Thank you for the patch.

[jvidalallende]

No problem, better late than never! Thanks for going through it!