[lxc-users] docker in lxc

Maxim Patlasov mpatlasov at parallels.com
Sat Nov 7 00:01:41 UTC 2015


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"?

Thanks,
Maxim


More information about the lxc-users mailing list