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@xxxxxxxxxx> wrote:
Daniel P. Berrangé <berrange@xxxxxxxxxx> 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.
_______________________________________________
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
