[lxc-users] docker in lxc

[Tamas Papp]

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.


Thanks,
tamas