for those, they can strip locales (see david link) how much would they save?
On Tue, Jun 21, 2016 at 4:11 AM, Derek Carr <dec...@redhat.com> wrote: > 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 <als...@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. <de...@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. >>> >>
