Запуск uWSGI с супервизором в контейнере docker дает отказ в разрешении

У меня есть приложение Django, которое я хочу запустить с UWSGI в контейнере Docker с помощью Supervisor.

Я использую OSX, поэтому для успешного монтирования моей файловой системы OSX внутри моего boot2docker Виртуальная машина (чтобы я мог монтировать тома с помощью docker run -v /source/:/destination) Мне приходилось использовать sshfs что, я думаю, вызывает некоторые странные разрешения в моей смонтированной файловой системе.

У меня есть два маунта на моем boot2docker Виртуальная машина; тот, который указывает на кодовую базу моих приложений, и тот, который указывает на произвольное местоположение на моем хосте для записи постоянных журналов в

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

Я запускаю свой контейнер docker с помощью:

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

Моя конфигурация супервизора для моего приложения выглядит следующим образом:

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

Мой usgi.ini выглядит так:

[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

Когда я запускаю свое приложение с помощью supervisorctl, я получаю следующие ошибки:

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)

И в журналах uWSGI я вижу:

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

Бегущий id -g www-data показывает мне, что мой гид прав и что www-data существует:

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

И внутри моего контейнера docker права доступа к файлам, которые я вижу, выглядят следующим образом:

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

Так что, потому что я вижу uids и gids здесь файлы / папки принадлежат пользователю, которого не существует (они совпадают с именами пользователей моего хоста OSX uid и gid), и я получаю ошибки разрешения выше, потому что www-data у пользователя нет доступа для записи в смонтированную файловую систему, что я могу доказать с помощью su:

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

Пока это имеет смысл, но когда я пытаюсь записать файл от имени root:

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

Запись файла работает нормально и даже имеет право uid и gid.

Итак, я бы ожидал запуска uWSGI от имени root с помощью этого uwsgi.ini файл:

[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

Или как 10133 с этим uwsgi.ini файл:

[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

Это сработало бы, но я не получаю никакой любви:

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

И

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

Что я упускаю из виду?

Я видел здесь ошибки с отказом в разрешении, потому что guid не существовало внутри контейнера.

Изменение линии guid=10000 к guid=root исправил это.

Попался. Если вы еще не подписались на docker volumes w remote daemon · Issue #4023 · moby/moby · GitHub , возможно, вы захотите это проверить.

Пробовали ли вы копировать / повторно синхронизировать свои данные на хост boot2docker, чтобы устранить SSHFS как источник проблемы?

Привет, Энди, да, я подумывал об этом, но мне нужна смонтированная файловая система, чтобы включить “живое редактирование” кодовой базы для разработки. Необходимость создавать новое изображение каждый раз, когда какой-то код меняется, для меня неприемлема.

И когда я говорю “живое редактирование”, я имею в виду, что пользователи контейнера могут разрабатывать в своей собственной среде хостинга и мгновенно видеть изменения в кодовой базе, отраженные в их браузере.