On 5/20/21 08:21, Daniel P. Berrangé wrote:
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.
I usually look more towards ubi images, which update at a much slower rate.
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.
Yes
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.
Yes, but I wonder how many applications start with the default base images
and then install content. From fedora, from alpine as opposed to `from
fedora-httpd`
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.
Sure, and in some ways this is happening with fedora-minimal.
Hopefully in the future we will have new features in conainers/storage
that will alleviate some of the problems I have described in previous
emails, through the use of reflinks, pulling only changes in images, and
other features like support for zstd images.
https://github.com/containers/storage/pull/795
https://github.com/containers/storage/pull/775
Regards,
Daniel
_______________________________________________
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
