Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux