On Mon, Jan 13, 2014 at 7:31 PM, Roberto De Ioris <[email protected]> wrote:
>
> > Hi, Roberto,
> >
> > any news in your developments with this issue?
>
> Well, it has been easier than i thought, docker images can be easily
> mounted with overlayfs, the problem is that the docker api does not allow
> to get the full path of images.
>
> My idea is that docker could be a great solution for serving "rootfs"
> images
> while you can use the more advanced namespace support in uWSGI.
>
> Something like:
>
> [uwsgi]
> unshare = fs,ipc,uts
> rootfs-from-docker = ubuntu
> ...
>
> that internally would make a request to the docker socket for getting the
> path of the "ubuntu" image, and then this directory is bind-mounted
> readonly in the uWSGI namespace and "joined" via overlayfs (or aufs if
> your kernel supports it) with the writable user-related directory.
>
The problem here is, that you also assume that the image will always be
available as a single directory. That may not be always true, cause images
are composed of several diff layers.
Images consist of layers, and, though the docker daemon seems to pre-mount
every image, I doubt docker developers expect you to rely on this behavior.
E.g., on my system, the image mounts are located in
/var/lib/aufs/mnt/{IMAGE_ID}/ directories. But right after reboot, not all
of them are available straight away.
When you launch a container via it's api, docker will make sure the needed
image is mounted.
I'm not a docker developer, but as far as I can tell from the source, the
mounting of a container or image is probably done in
docker.graphdriver.Get(string id) function:
https://github.com/dotcloud/docker/blob/45ecdf9c8e468bb93a96665fe92e526dabf2ee43/graphdriver/driver.go#L19
So they should probably expose this function or it's result in the API, for
the above way to become non-hacky.
>
>
> Another approach is the new --setns feature of uWSGI 2.0
>
> You can use docker to spawn a very minimal (even the core) uWSGI instance
> in a new namespace and then you can "attach" new instances to it:
>
> #in docker (--socket is no more needed in 2.0.1)
> uwsgi --setns-socket /foobar/join.me --socket /tmp/foobar
>
> # in your uWSGI instance (even as a vassal)
> [uwsgi]
> # join docker jail
> setns = /foobar/join.me
> http-socket = :8080
> # your app options
> ...
> ...
>
> the funny thing is that multiple instances can join the same docker
> container
>
This way seems more docker-friendly, though looks like you'll need an
additional uwsgi process for every vassal, if you want vassal isolation.
Do you see a way to use it without the overhead of pre-spawning the
process? E.g. compatible with using uwsgi socket activation and lazy
instances.
Will launching this as a hook work? E.g. something like
[vassal's uwsgi]
exec-as-root=mkdir -p /setns-sockets
exec-as-root=docker restart uwsgi-%n || docker run -name uwsgi-%n -d -v
/setns-sockets:/setns-sockets BASEIMAGE uwsgi --setns-socket
/setns-sockets/%n --socket /tmp/foobar
exec-as-root-atexit=docker stop uwsgi-%n
setns=/setns-sockets/%n
...
So, If I got it right, this should work, and create containers on first
launch. I'll try to play with it when I have time.
Thanks, Roberto!
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
