On 5/19/21 04:34, Daniel P. Berrangé wrote:
On Wed, May 19, 2021 at 09:04:08AM +0200, Clement Verna wrote:
> On Mon, 17 May 2021 at 16:40, Frank Ch. Eigler <fche(a)redhat.com> wrote:
>
>> Daniel P. Berrangé <berrange(a)redhat.com> writes:
>>
>>> The container runtime in the host OS will have configured most mount
>>> points before the container starts. It would be relatively uncommon
>>> for processes inside the container image to need to mount additional
>>> volumes later.
>> That's fair, but util-linux contains many other tools that may be useful
>> at runtine within a containerized tool (logger, flock, lsmem, rename,
>> taskset, whereis, others?). Some those be moved somewhere else?
>>
>> /usr/bin/* files from f33's util-linux:
>>
>> cal chmem choom chrt col colcrt colrm column dmesg eject fallocate
>> fincore findmnt flock getopt hardlink hexdump i386 ionice ipcmk ipcrm
>> ipcs irqtop isosize kill last lastb linux32 linux64 logger login look
>> lsblk lscpu lsipc lsirq lslocks lslogins lsmem lsns mcookie mesg more
>> mount mountpoint namei nsenter prlimit raw rename renice rev script
>> scriptlive scriptreplay setarch setpriv setsid setterm su taskset ul
>> umount uname26 unshare utmpdump uuidgen uuidparse wall wdctl whereis
>> write x86_64
>>
> It is all about tradeoff between what **may** be useful and the size of the
> base image. In the container base image space, size is very important (see
> how successful is Alpine) and we have to make tradeoff in terms of what
> tools are included by default in the image.
This is very true, but to be brutally honest when you look at these
differences below, I can't see any of the traditional distros ever
winning on size, because Alpine is a different order of magnitude
compared to them. If minimal size is the user's primary goal we're
not even in the same contest as Alpine.
That means we have to win on some other metric with the remaining
users, for whom size is not the primary driving factor.
We have to at least not look terrible size-wise compared to other
traditional distros, which means we need to be as close as practical
to Ubuntu / Debian (slim).
IMHO even then we would need the default "fedora" image to be the
minimal one, as that's what a casual user will compare, unless they
happen to know "fedora-minimal" exists.
> To get an idea on how Fedora does compared to some other distros
>
> REPOSITORY TAG IMAGE ID
> CREATED SIZE
>
registry.fedoraproject.org/fedora rawhide 5e91f1acac7d 47
> hours ago 187 MB
>
registry.fedoraproject.org/fedora-minimal latest 438d4fec7485 5
> days ago 119 MB
> docker.io/library/debian latest 4a7a1f401734 7
> days ago 119 MB
FWIW, there's also debian:stable-slim at 72 MB
>
registry.opensuse.org/opensuse/leap latest 1a798c6c690f 5
> days ago 108 MB
> docker.io/library/ubuntu latest 7e0aa2d69a15 3
> weeks ago 75.1 MB
So we need to cull 45 MB / 36% of 'fedora-minimal' to reach this target,
or 112 MB / 60% of 'fedora'.
util-linux is a decent sized chunk of that, so makes sense to question
its need.
> docker.io/library/alpine latest 6dbb9cc54074 4
> weeks ago 5.88 MB
Regards,
Daniel
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.
Now with the crazy developers driving the show, we end up with upside
down wedding cakes, where basically everyone shares the absolute minimal
base and then adds a ton of stuff on top.
In production, the apps end up sharing almost nothing, meaning they use
much more disk, much more bandwidth when pulling images and much more
memory in the OS since the kernel sees files that should be shared in
memory as existing at different INODES.
We can work to help fix some of these by improving the pulling and
storing of images, but for now shrinking the size of the image is
counter productive for running containers in something like Kubernetes.