On Thu, 2016-02-11 at 05:08 -0500, Daniel Riek wrote:
>
>
> On Thu, Feb 11, 2016 at 4:52 AM, Fabian Deutsch <fdeutsch redhat com>
> wrote:
> > On Wed, Feb 10, 2016 at 11:13 PM, Josh Berkus <jberkus 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 <podvody 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
Attachment:
signature.asc
Description: This is a digitally signed message part