[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