Re: [atomic-devel] Smaller fedora & centos images

[Derek Carr <decarr redhat com>]

Why does 1 not matter?  If a cluster orchestrator charges your container for its image size, it would matter.  There are some Kubernetes users in the community that have that goal and want to charge local disk usage to the pod (including shared image layers).  Admittedly, there are other users that do not want to do that, but it does mean the on disk format matters for some folks.

On Monday, June 20, 2016, Muayyad AlSadi <alsadi gmail com> wrote:

I gave up shrinking locales because they compress will

There are two use cases for small images
1. The on disk format, which is shared between multiple containers via layers

2. When export tarball and pass it.

For 1. Fat does not matter and for 2 it also does not matter because ~100mb becomes 2mb.

On Tue, Jun 21, 2016, 3:43 AM David O. <devel oszi one> wrote:

A little self-plug: Here's how I do it: https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh

It's designed to run in a container of the same OS (F23 can build F24) so it can be built anywhere...

Anyway, apart from systemd and locales I'm in favor of fat base images when an entire OS is needed. Because in the end not only it saves storage and bandwidth but also memory (same page cache).

What we should focus on is avoiding fracturization (everything built on different base images) and educating people that smaller is not always better.

So I don't think it's worth the effort to remove even dnf from the base images when it would/should include python3 either way.

We could also go down the rabbit hole and create a tree of base images starting with the bare minimum.

Is this also in the realm of the "layered images" project?

Just my two cents.

And for static binaries and unikernels there is no need for an OS anyway.