Some more questions regarding the approach with running uwsgi
--setns-socket inside docker.

- it seems 2 uwsgi processes are created when doing "uwsgi --setns-socket".
Is it possible to launch only one to minimize the memory footprint?
- also, if the absolutely core and minimal uwsgi here is needed, what's the
way to compile it for minimal memory footprint?

-
[uwsgi]
setns=/foobar/join.me
http=:8080

When this is launched in the parent system, http does not work, the port is
opened inside the container, where network is jailed.
Would placing a socket in a shared docker volume be a solution to this
problem then?
- Is it right, that "unshare" with this approach makes no sense, cause
docker jailed everything already?
- If I specify "uid=somebody", the user inside the container is used,
right? Does it make sense to provide non-root uids, if everything is
already jailed?
- Should I do anything with users in the parent system in this case? Like
pre-create the same users or anything like that.

Thanks!



On Wed, Jan 15, 2014 at 12:54 PM, Igor Katson <[email protected]> wrote:

> 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

Reply via email to