On Wed, May 19, 2021 at 04:37:55PM -0400, Daniel Walsh wrote: > > The sad thing with these types of slimming is that it is horrible in > production use case. > > I often describe layered images in the form of a wedding cake, where you > have a large base > > and then smaller mid section say with httpd or java engine and then a small > layer on top which has the actual application. > > This gives applications the ability to share most of the content of the base > image and those who share the mid section ability to share. This shrinks > the overall disk space and more importantly allows the kernel to realize > that the same glibc or jre is being used so it is not loaded into memory for > each application run. I wonder how much of a difference it actually makes a difference in the practice. Lets say the Fedora base image is refreshed with updated RPMs on a weekly basis. Each application republishes their app containers on an arbitrarily different schedule, maybe fortnightly, monthly, whatever. Thus out of 10 different apps deployed, you could easily find yourself shipping 10 different versions of the base image. IOW we only get the space benefit of sharing a large image, if a large number of apps are aligned with using the same point in time version base image. If we assume that apps in general will NOT align on the same point in time version of a base image, and the base image gets refreshed frequently then a small base image feels more important. If you can control all your apps such that they get built using the exact same version of the base, then a large base would get the benefits you describe. It is easier to achieve sharing with a slow refreshed container - IOW perhaps it matter more for RHEL than for Fedora. It feels like we probably can cope with both scenarios at the same time though. The large base to maximize sharing doesn't actually have to be the bottom most layer to get sharing. We just need a large base /somewhere/ below the end user applications. It could easily be the second layer. Lets say we have a "fedora" image that's tiny with the absolute bare minimum - just package manager and things that needs. Then we could have a "fedora-max" that inherits from this and throws in the kitchen sink. Or you could have more targetted layers "fedora-python", "fedora-java", etc. That way if you are deployed a bunch of python apps you can derive from the large-ish "fedora-python" container image and get maximum sharing of python stack, while we still offer a very small base image for those who don't care about sharing and just want to win on size. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
