[lxc-users] docker in lxc

[Serge Hallyn]

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)