Ejecutar uWSGI con supervisor en un contenedor docker está dando permiso denegado

Tengo una aplicación Django que quiero ejecutar con UWSGI en un contenedor Docker usando Supervisor.

Estoy usando OSX so para montar con éxito mi sistema de archivos OSX dentro de mi boot2docker VM (para que pueda montar volúmenes con docker run -v /source/:/destination) He tenido que usar sshfs lo que creo que está causando algunos permisos extraños en mi sistema de archivos montado.

Tengo dos monturas en mi boot2docker VM; uno que apunta a la base de código de mis aplicaciones y otro que apunta a una ubicación arbitraria en mi host para escribir registros persistentes

Host: /Users/username/workspace/project --- > boot2docker: /home/docker/osxHost: /containers/project               --- > boot2docker: /containers/project

Inicio mi contenedor Docker con:

docker run -t -i -p 80 -v /home/docker/osx/project/www:/var/www -v /containers/project:/host image-name /bin/bash

La configuración de mi supervisor para mi aplicación se ve así:

[program:app_name]command=uwsgi --ini /var/www/wsgi/uwsgi.inidirectory=/var/wwwautostart=trueautorestart=truestdout_logfile=/host/logs/app-name.logredirect_stderr=True

Mi usgi.ini se parece a esto:

[uwsgi]http = :3041chdir = /var/wwwmodule = run.wsgiuid = www-datagid = 33master = Trueprocesses = 4threads = 1pidfile = /var/run/uwsgi.pidtouch-reload = /var/run/uwsgi.pidlogto = /host/logs/uwsgi.log

Cuando ejecuto mi aplicación con supervisorctl obtengo los siguientes errores:

root@4237fd060a40:/var/www# supervisorctlapp_name               FATAL      Exited too quickly (process log may have details)supervisor> start app_name2014-06-15 10:22:16,559 INFO spawned: 'app_name' with pid 1052014-06-15 10:22:16,633 INFO exited: app_name (exit status 1; not expected)2014-06-15 10:22:17,658 INFO spawned: 'app_name' with pid 106app_name: ERROR (abnormal termination)

Y en los registros de uWSGI estoy viendo:

[uWSGI] getting INI configuration from /var/www/run/uwsgi.ini*** Starting uWSGI 1.9.10 (64bit) on [Sun Jun 15 10:22:22 2014] ***compiled with version: 4.6.3 on 13 June 2014 15:25:05os: Linux-3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014nodename: 4237fd060a40machine: x86_64clock source: unixdetected number of CPU cores: 4current working directory: /var/wwwwriting pidfile to /var/run/uwsgi.piddetected binary path: /usr/local/bin/uwsgisetgid() to 33setuid() to 33chdir(): Permission denied [core/uwsgi.c line 2121]

Ejecutar id -g www-data me muestra que mi gid es correcto y que www-data existir:

root@4237fd060a40:/var/www# id -g www-data33

Y dentro de mi contenedor docker, los permisos de archivo que veo se ven así:

root@4237fd060a40:/var/www# lltotal 76drwxr-xr-x  1 10133 10000   578 Jun 15 09:55 ./drwxr-xr-x 30 root  root   4096 Jun 15 09:52 ../drwxr-xr-x  1 10133 10000   714 Jun 13 10:55 some_folder/drwxr-xr-x  1 10133 10000  1292 Jun  9 11:29 some_file.py

Porque estoy viendo uids y gidaquí, los archivos / carpetas son propiedad de un usuario que no existe (coinciden con los nombres de usuario de mi host OSX uid y gid), y obtengo los errores de permiso anteriores porque www-data el usuario no tiene acceso para escribir en el sistema de archivos montado, lo que puedo probar usando su:

root@4237fd060a40:/var/www# su www-data$ pwd/var/www$ touch test2touch: cannot touch `test2': Permission denied

Tiene sentido hasta ahora, pero cuando intento escribir un archivo como raíz:

root@4237fd060a40:/var/www# touch testroot@4237fd060a40:/var/www# lltotal 76...-rw-r--r--  1 10133 10000     0 Jun 15 10:20 test

Escribir un archivo funciona bien, e incluso tiene el derecho uid y gid.

Entonces, hubiera esperado ejecutar uWSGI como root con esto uwsgi.ini file:

[uwsgi]http = :3041chdir = /var/wwwmodule = run.wsgiuid = rootgid = 10000master = Trueprocesses = 4threads = 1pidfile = /var/run/uwsgi.pidtouch-reload = /var/run/uwsgi.pidlogto = /host/logs/uwsgi.log

O como 10133 con esto uwsgi.ini file:

[uwsgi]http = :3041chdir = /var/wwwmodule = run.wsgiuid = 10133gid = 10000master = Trueprocesses = 4threads = 1pidfile = /var/run/uwsgi.pidtouch-reload = /var/run/uwsgi.pidlogto = /host/logs/uwsgi.log

Funcionaría, pero no estoy recibiendo amor:

[uWSGI] getting INI configuration from /var/www/run/uwsgi.ini*** Starting uWSGI 1.9.10 (64bit) on [Sun Jun 15 10:30:05 2014] ***compiled with version: 4.6.3 on 13 June 2014 15:25:05os: Linux-3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014nodename: 4237fd060a40machine: x86_64clock source: unixdetected number of CPU cores: 4current working directory: /var/wwwwriting pidfile to /var/run/uwsgi.piddetected binary path: /usr/local/bin/uwsgisetgid() to 10000*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***chdir(): Permission denied [core/uwsgi.c line 2121]

Y

[uWSGI] getting INI configuration from /var/www/run/uwsgi.ini*** Starting uWSGI 1.9.10 (64bit) on [Sun Jun 15 10:30:36 2014] ***compiled with version: 4.6.3 on 13 June 2014 15:25:05os: Linux-3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014nodename: 4237fd060a40machine: x86_64clock source: unixdetected number of CPU cores: 4current working directory: /var/wwwwriting pidfile to /var/run/uwsgi.piddetected binary path: /usr/local/bin/uwsgiuWSGI running as root, you can use --uid/--gid/--chroot optionssetgid() to 10000setuid() to 10133chdir(): Permission denied [core/uwsgi.c line 2121]

¿Qué me estoy perdiendo?

Estaba viendo errores de permiso denegado aquí porque el guid no existía dentro del contenedor.

Cambiar la línea guid=10000 a guid=root solucionarlo.

Gotcha. Si aún no se ha suscrito a docker volumes w remote daemon · Issue #4023 · moby/moby · GitHub, es posible que desee comprobarlo.

¿Ha intentado copiar / sincronizar sus datos en el host boot2docker para eliminar SSHFS como fuente del problema?

Hola Andy, sí, he considerado hacer eso, pero necesito tener un sistema de archivos montado para permitir la “edición en vivo” de la base de código para el desarrollo. Tener que crear una nueva imagen cada vez que un código ha cambiado no es aceptable para mí.

Y cuando digo “edición en vivo”, me refiero a que los usuarios del contenedor pueden desarrollar en su propio entorno de host y ver instantáneamente los cambios en la base de código reflejados en su navegador.