On 02/11/2016 09:05 AM, Muayyad AlSadi wrote:
> here are what I install
>
> bash grep tar coreutils findutils rpm sed cpio cyrus-sasl file nc
> file-libs gawk xz openssh-server vi setup filesystem man passwd sudo
> iproute procps-ng iputils which net-tools psmisc
>
> sometimes when I over optimize I replace systemd (by a fake runtime
> rpm that claim to provides systemd and a like) with supervisord
>
> Compress cracklib
>
> gzip -9 $OSROOT/usr/share/cracklib/pw_dict.pwd
>
Why isn't this the default?
> Minimize locale-archive
>
> localedef --prefix $OSROOT --list-archive | egrep -v
> $strip_locales_to_keep_re | xargs localedef --prefix $OSROOT
> --delete-from-archive
> mv $OSROOT/usr/lib/locale/locale-archive
> $OSROOT/usr/lib/locale/locale-archive.tmpl
> chroot $OSROOT /usr/sbin/build-locale-archive
>
> find "$OSROOT/usr/share/i18n/locales/" -type f | egrep -v
> $strip_locales_to_keep_re | xargs rm -rf
> find "$OSROOT/usr/share/zoneinfo/" -type f | egrep -v
> $strip_tz_to_keep_re | xargs rm -rf
>
Should we optimize these out via standard commands. Locales should
probably come from the host in most cases.
> regarding locals I want to keep things like date formats ..etc. but
> not translation (I don't want french version of ls --help)
>
How small did you get?
> -------------------
>
> regarding a more stripped image image without dnf/yum, this would be
> useful in case if we have pivot root support in Dockerfile
>
> https://github.com/jlhawn/dockramp/issues/1
>
> rpm --root $OSROOT --dbpath ...
> yum --nogpgcheck --installroot=$OSROOT --releasever=$release
> $yumsetopt install
>
>
>
>
>
> On Thu, Feb 11, 2016 at 2:12 PM, Pavel Odvody <podv...@redhat.com
> <mailto:podv...@redhat.com>> wrote:
>
> On Thu, 2016-02-11 at 05:08 -0500, Daniel Riek wrote:
> >
> >
> > On Thu, Feb 11, 2016 at 4:52 AM, Fabian Deutsch
> <fdeut...@redhat.com <mailto:fdeut...@redhat.com>>
> > wrote:
> > > On Wed, Feb 10, 2016 at 11:13 PM, Josh Berkus
> <jber...@redhat.com <mailto:jber...@redhat.com>>
> > > wrote:
> > > > On 02/10/2016 11:38 AM, Courtney Pacheco wrote:
> > > >>
> > > >> If possible, I'd like some feedback on the work I did. Comments
> > > and
> > > >> criticism are more than welcomed! I realize there may be some
> > > >> controversy in terms of what I chose to remove and what I chose
> > > to turn
> > > >> into weak dependencies, but I would like to hear your thoughts
> > > either way.
> > > >>
> > > >
> > > > First, thanks for doing this! It really shows a lot. I'd be
> > > really curious
> > > > as to what's in the remaining 144MB, given that Alpine and
> > > BusyBox can get
> > > > away with a userspace which is 25% of that size.
> > > >
> > > > As Dan points out, we can't necessarily dispose of DNF/Yum
> during
> > > the
> > > > standard container build (i.e. Dockerfile). However ...
> could we
> > > remove
> > > > them afterwards?
> > >
> > > Maybe this can be handled by a tooling itself - add yum, install,
> > > cleanup afterwards.
> > >
> > >
> > >
> > With squashing that is doable, but it's ugly and fragile.
> >
>
> Agreed, until Docker itself supports squashing of layers we should
> stay
> away from that.
>
> > A better way would be to move them into "sidecar" images, that get
> > mounted during docker build and can be added at runtime. We can use
> > the atomic wrapper or kubernetes or atomic app to automate that. The
> > key todos I see here are :
> > * Get an out-of-tree dnf that brings it own dependencies and can be
> > mounted into a container during build (similar to the secrets
> patch).
>
> This might be satisfied with the standalone DNF bundles, the other
> option would be having a DNF version that can execute from an "empty"
> chroot (not nice due to all the corner cases with NSS/glibc and cURL).
>
> > * Figure out how to manage that across multiple versions of base
> > images.
> > * Enable mounting containers as volumes (unless I am mistaken, right
> > now we can only mount host directories as volumes? Might be wrong)
>
> Yes, but there's a nice loophole! If we mount hosts / we can use
> /proc/{PID}/root to get to the root of particular container, from my
> Fedora 22 host:
>
> $ docker run -tid ubuntu:latest bash
> a19fdc5ab50e3507d99cf16b4367e23a9f6b932655bbf531384e403026399c5c
> $ docker inspect --format "{{ .State.Pid }}"
> a19fdc5ab50e3507d99cf16b4367e23a9f6b932655bbf531384e403026399c5c
> 30328
> $ cat /proc/30328/root/etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
>
> This way we could run the service SPC container like:
>
> $ docker run --privileged -v /:/host fedora:23 cat
> /host/proc/30328/root/etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
>
> TLDR version: I just used Fedora 23 container to inspect an Ubuntu
> 14.04 container on my Fedora 22 host.
>
> > * Create the tooling and metadata to make it work in practice.
> >
> > I think there has been some work along those lines, it would be
> great
> > to drive it forward.
>
> In the above example, if we exchange Ubuntu container for another
> Fedora container we could do:
>
> $ docker run --name ServiceContainer --privileged -v /:/host fedora:23
> dnf update --installroot /host/proc/XXXX/root/
>
> And it will work even if the target container doesn't have
> DNF/RPM, the
> only problem is that scriptlets would be executed in the context
> of the
> ServiceContainer, so we'd either have to disable them, or have the
> bundled/standalone version of DNF that could be bind mounted into the
> container and execute it in correct context. Note that most scriptlets
> should execute just fine, one problem would be scriptlets that operate
> directly with PIDs, but this should be a subject of further
> research to
> decide how much of a problem it really is.
>
> I guess what we're missing right now are concrete user stories.
>
> >
> > Regards,
> >
> > Daniel
>
> --
> Pavel Odvody <podv...@redhat.com <mailto:podv...@redhat.com>>
> Software Engineer - EMEA ENG Developer Experience
> 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
>
>
>
