Executar uWSGI com supervisor em um contêiner docker está dando permissão negada

português
#1

Eu Tenho o aplicativo Django que quero executar com UWSGI em um contêiner Docker usando Supervisor.

Estou usando OSX para montar com sucesso meu sistema de arquivos OSX dentro do meu boot2docker VM (para que eu possa montar volumes com docker run -v /source/:/destination) Eu tive que usar sshfs o que eu acho que está causando algum estranho permissões no meu sistema de arquivos montado.

Eu tenho duas montarias no meu boot2docker VM; um que aponta para minha base de código de aplicativos e outro que aponta para um local arbitrário em meu host para gravar logs persistentes em

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

Eu começo meu contêiner docker com:

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

Minha configuração de supervisor para meu aplicativo se parece com isso:

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

As usgi.ini aspecto:

[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

Quando executo meu aplicativo com supervisorctl, recebo os seguintes erros:

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)

E nos logs uWSGI estou vendo:

[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]

Execucao id -g www-data mostra-me que o meu gid está certo e que www-data existir:

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

E dentro do meu contêiner docker as permissões de arquivo que estou vendo são assim:

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

Então, porque eu estou vendo uids e gids aqui, os arquivos / pastas são de propriedade de um usuário que não existe (eles correspondem aos nomes de usuário do meu host OSX uid e gid), e estou recebendo os erros de permissão acima porque o www-data o Usuário não tem acesso para gravar no sistema de arquivos montado, o que posso provar usando su:

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

Faz sentido até agora, mas quando tento escrever um arquivo como root:

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

Escrever um arquivo funciona bem e até tem o direito uid e gid.

Então, eu teria esperado executar uWSGI como root com isso uwsgi.ini arquivo:

[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

Ou como 10133 com este uwsgi.ini arquivo:

[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

Funcionaria, mas não estou recebendo 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]

E

[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]

O que eu estou ausente?

#2

Eu estava vendo erros de permissão negados aqui porque o guid não existia dentro do recipiente.

Alterando a linha guid=10000 para guid=root corrigido.

#3

Apanhei-te. Se você ainda não se inscreveu docker volumes w remote daemon · Issue #4023 · moby/moby · GitHub, você pode querer verificar isso.

#4

Você já tentou copiar / rsyncing seus dados para o host boot2docker para eliminar SSHFS como a origem do problema?

#5

Oi Andy, sim, eu considerei fazer isso, mas preciso ter um sistema de arquivos montado para habilitar a “edição ao vivo” da base de código para desenvolvimento. Ter que criar uma nova imagem toda vez que algum código mudou não é aceitável para mim.

#6

E quando digo “edição ao vivo”, quero dizer que os usuários do contêiner podem se desenvolver em seu próprio ambiente de host e ver instantaneamente as alterações na base de código refletidas em seu navegador.