Я пытаюсь настроить приложение Django с помощью uwsgi и nginx, но все время сталкиваюсь с очень раздражающей проблемой.
Я использовал uwsgi docs как справочное руководство.
При обслуживании приложения через uwsgi (uwsgi --http :8000 --module myproject.wsgi
) все работает нормально, но когда я пытаюсь подключиться через сокет с nginx (uwsgi --ini myproject.ini
) и откройте myproject.com:8000/<django-app>
в моем браузере появляется ошибка 502 и
2018/02/07 08:25:26 [критический] 30339 # 30339: * 1 connect () to unix: /// var / www / [myproject] / [myproject] .sock не удалось (13: Permission denied) при подключении в восходящий поток, клиент: [client-ip], сервер: [server-ip], запрос: «GET / [django-app] / HTTP / 1.1», восходящий поток: «unix: /// var / www / [myproject] /[myproject ].sock: ", host:" [fqdn]: 8000 "
это ^ в /var/log/nginx/error.log
Папка моего проекта находится в /var/www/
, принадлежит <me>:www-data
, и с 764
как разрешения. Каждая подпапка и файл (в настоящее время) находятся под этим владельцем и этими разрешениями.
Я запускаю все на виртуальной машине Ubuntu 16.04 (управляемой моим администратором), и у моего пользователя sudo
доступ.
Я упускаю что-то очевидное?
Обновить:
На данный момент все работает, когда other
имеет read-write
разрешения на сокет и read-execute
разрешения на остальную часть проекта.
Итак, nginx не распознается должным образом ... Я дважды проверил, и nginx работает как www-data
пользователь, который является владельцем группы всего моего проекта и который имеет read-execute
разрешения, так же как other
теперь есть.
myproject_nginx.conf
(В дополнение к настройкам в этом файле я поставил user www-data www-data;
в /etc/nginx/nginx.conf
.)
# myproject_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
server unix:///var/www/myproject/myproject.sock;
}
# configuration of the server
server {
# the port your site will be served on
listen 8000;
# the domain name it will serve for
server_name my.ip.goes.here; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Django media
location /media {
alias /var/www/myproject/media; # your Django project's media files - amend as required
}
location /static {
alias /var/www/myproject/static; # your Django project's static files - amend as required
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /var/www/myproject/uwsgi_params; # the uwsgi_params file you installed
}
}
myproject_uwsgi.ini
# myproject_uwsgi.ini file
[uwsgi]
# Django-related settings
# the base directory (full path)
chdir = /var/www/myproject
# Django's wsgi file
module = myproject.wsgi
# the virtualenv (full path)
home = /var/www/myenv
# process-related settings
master = true
# maximum number of worker processes
processes = 10
# the socket (full path)
socket = /var/www/myproject/myproject.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
uid = me
gid = www-data
# clear environment on exit
vacuum = true
После нескольких часов боли я нашел решение именно этой проблемы.
Проблем две: 1) права доступа к папке 2) виртуальная среда
Виртуальная среда искажает ваши разрешения и мешает uwsgi правильно создать сокет - просто отключите venv и pip install django и uwsgi для всей системы. Возможно, есть способ решить эту проблему с помощью venv, но я не знаю ни одного.
Затем установите разрешения для папки проекта django на 777 (или измените ее владельца на root).
cd в папку и выполните команду wsgi от имени пользователя root:
sudo uwsgi --socket mysite.sock --module mysite.wsgi --chmod-socket=664 --uid www-data --gid www-data
это создает mysite.sock с www-данными владельца, и я больше не получаю ошибку отказа в разрешении.
Надеюсь, это поможет.
-edit- после дополнительного расследования я последовал этот учебник и заставил его работать как службу systemd без каких-либо из этих проблем - я думаю, что в официальном руководстве некоторые вещи принимаются как должное.
Я столкнулся с аналогичной проблемой на основе аналогичного учебника по цифровому океану.
Мой взлом был chmod a+rw mysite.sock
после запуска uwsgi.
Однако я полагаю, что изменение --chmod-socket = 666 также сработает.