[lxc-users] docker in lxc

[Serge Hallyn]

Quoting Tamas Papp (tompos at martos.bme.hu):
> 
> 
> On 11/09/2015 09:06 PM, Serge Hallyn wrote:
> >Quoting Maxim Patlasov (mpatlasov at parallels.com):
> >>On 11/06/2015 02:52 PM, Serge Hallyn wrote:
> >>>Quoting Maxim Patlasov (mpatlasov at parallels.com):
> >>>>Hi Serge,
> >>>>
> >>>>I had been working for a while on porting proxy-graphdriver-daemon
> >>>>to extpoint feature, but then switched to another task. I hope to
> >>>>switch back in a week. It would be great if we all together come to
> >>>>agreement about universal way to mount something from host to
> >>>>container namespace. The simplest way would be to specify the pid of
> >>>>container "init" as a command-line arg of proxy-daemon, so it could
> >>>>use the pid for setns(2) directly. Is such an approach safe enough
> >>>>and will work for all of us?
> >>>Surely safe enough.  It's too bad that it requires a graphdriver
> >>>per docker-using container, and that it breaks up the container
> >>>start (I can't start the graphdriver first and just pass the unix
> >>>socket into the container), but I think it's ok.
> >>>
> >>>In general, what do we need exactly?
> >>>
> >>>1. Some way to identify target pid.  We can
> >>>    a. pass pid to graphdriver on cmdline
> >>>    b. we can get pid from peercred
> >>>2. A MS_SLAVE directory to allow the mount to be passed from the
> >>>    host to the container (whereupon it can be moved to its final
> >>>    destination.  This path location needs to be passed to the
> >>>    graphdriver somehow.  In what you suggest we can just pass the
> >>>    absolute paths (both on the host and in the container) on the
> >>>    command line as well.
> >>>3. An actual request, presumably sent as
> >>>       some-host-dev-id destination-path
> >>>    over a unix socket.
> >>After more thinking it came to me that may be we can avoid all this
> >>hassle altogether. When I started to work on proxy-grpahdriver, I
> >>tried to follow the behavior of devicemapper graphdriver as close as
> >>possible. In particular, I thought it's important to create
> >>mount-points where the client (docker inside container) would expect
> >>to find them (under /var/lib/docker by default). But now, having a
> >>look at integration-cli/docker_cli_external_graphdriver_unix_test.go
> >>from https://github.com/docker/docker/pull/13777/files, it seems
> >>that mount-points may be placed anywhere. If it's true we could
> >>place them in a directory visible both from host system and inside
> >>container -- no need for setns(2) at all!
> >>
> >>In fact, we need a place visible both from host and container anyway
> >>-- to have unix socket accessible both by proxy-daemon (running on
> >>host) and docker-daemon (running inside container). In case of
> >>docker containers, such a common directory may be specified by "-v"
> >>option, like:
> >>
> >>$  docker run --privileged --rm -ti -v
> >>`pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
> >>(see http://docs.docker.com/opensource/project/set-up-dev-env/)
> >>
> >>In case of OpenVZ containers, per-container /tmp is visible as
> >>/vz/root/<id>/tmp from the host, so proxy-daemon might mount
> >>requested dm-thin thin to /vz/root/<id>/tmp/tempXXX and pass
> >>"/tmp/tempXXX" back to container as result of Get() request.
> >>
> >>What about lxc -- does it have an option similar to docker' "-v"?
> >If I read it right, it just bind mounts a host dir to a container dir?  In lxc
> >that's a lxc.mount.entry = /hostdir containerdir none bind.  But if it needs to
> >be ms_slave or ms_shared then lxc doesn't do it all for you.  (This is how lxd
> >does insertion of 'disks' from host into container, it always has a ms_slave
> >directory from /var/lib/lxd/shmounts/$container to /dev/shmounts, somewhat akin
> >to OpenVZ's /tmp I guess)
> >
> 
> hi All,
> 
> I didn't follow the list recently.
> 
> Is there any follow-up in this development?
> I (and my devs...) look forward to testing the feature.

I've been playing with docker in lxd containers under cgroup namespaces.
There are still a few things to tweak, but it mostly works.

-serge