[lxc-users] docker in lxc

[Akshay Karle]

Hey Serge and Maxim,

I've been busy with some work here and haven't had a lot of time to look
into this. I can spend sometime now to help out.

Since I don't have much idea of how to go about creating the graph driver
proxy for docker, I started by trying to see what problems we get when
starting docker 1.10 experimental daemon inside an unprivileged container
and seems that it fails to start with an error "Error starting daemon:
Devices cgroup isn't mounted". Now, this seems to be an error unrelated to
what the graph driver would resolve, but please correct me if I'm wrong as
I'm quite new to lxc or docker dev. Looking at the docker code [1], it
looks like the libcontainer which does parsing of cgroup mount point
doesn't take into consideration the fact that cgroups are running on lxcfs
inside the container. I'm now investigating what the solution could be to
solve this. Let me know if you have any ideas.

Also, do you think it makes more sense to have this discussion on lxc-devel
than lxc-users?

1 -
https://github.com/docker/docker/blob/master/vendor/src/github.com/opencontainers/runc/libcontainer/cgroups/utils.go#L22-L47

On Mon, Nov 9, 2015 at 5:25 PM Maxim Patlasov <mpatlasov at parallels.com>
wrote:

> 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
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20151110/814cb3e7/attachment.html>