Django + gunicorn + nginx: 502 плохих шлюзов, но иногда только?
Недавно я решил просто отказаться от apache2 + mod_wsgi и попробовать gunicorn + nginx для запуска моего приложения Django.
Я следовал этим учебникам без проблем на чистой установке Ubuntu 16.04:
- https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
- https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-16-04
Я думал, что все будет хорошо, но просматривая мой сайт, я заметил, что время от времени несколько страниц вообще не отображаются, а просто показывают 502 Bad Gateway
ошибка. Глядя в error/var/log/nginx/error.log
У меня есть только ошибки, подобные следующим:
upstream prematurely closed connection while reading response header from upstream
Я понятия не имею, что это означает:
- почему это будет моя установка Django, если у меня нет проблем при работе, например, на localhost?
- также: иногда все страницы работают и отображаются нормально; иногда одни и те же страницы выдают ошибку 502:(
- как я могу узнать, что не так с моей установкой gunicorn, если проблема возникла оттуда? Как отлаживать?
Для вас информация:
/etc/systemd/system/gunicorn.socket
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=myself
Group=www-data
WorkingDirectory=/home/myself/django/myproject
ExecStart=/home/myself/django/myproject/venvprod/bin/gunicorn \
--access-logfile - \
--bind unix:/run/gunicorn.sock \
myproject.wsgi:application
[Install]
WantedBy=multi-user.target
/ И т.д. / Nginx / сайты с поддержкой / MyProject
server {
server_name mysite.fr mysite.com;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/myself/django/myproject;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/mysite.fr/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/mysite.fr/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = mysite.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = mysite.fr) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name mysite.fr mysite.com;
return 404; # managed by Certbot
}
Если что-то еще нужно, пожалуйста, просто спросите! Моя настоящая проблема в том, что я понятия не имею, как ее найти. Какой инструмент я могу использовать?
Заранее спасибо за помощь.
РЕДАКТИРОВАТЬ 1
Я могу подтвердить, что в моем коде Django нет ошибок. Я записал все следующим образом:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'file': {
'level': 'DEBUG',
'class': 'logging.FileHandler',
'filename': '/home/krazymax/debug-m2g.log',
},
},
'loggers': {
'django': {
'handlers': ['file'],
'level': 'DEBUG',
'propagate': True,
},
'django.template': {
'handlers': ['file'],
'level': 'INFO',
'propagate': True,
},
},
}
и у меня нет ошибок во время просмотра моего веб-сайта (со страницами, которые всегда отображаются, другие, которые никогда не отображаются, и некоторые, которые иногда отображаются, иногда не отображаются).
РЕДАКТИРОВАТЬ 2
Я пытался следовать этому руководству, т.е. без использования промежуточного файла носка. Безуспешно, даже если при выполнении myvenv/bin/gunicorn -c myvenvprod/gunicorn_config.py myproject.wsgi
Я могу получить доступ к своему веб-сайту (и не иначе): мои страницы по-прежнему отображаются (или нет) в случайном порядке. Я действительно понятия не имею, и это официально, это случайное поведение сводит меня с ума!
4 ответа
Эта ошибка обычно означает, что между Nginx и Gunicorn нет "соединения", проблема в файле сокета.
Запустите "/ home / себя / django / myproject / venvprod / bin / gunicorn myproject.wsgi -b 0.0.0.0:8000" и посмотрите вывод. Это запустит сервер gunicorn с вашим процессом Django, не демонизируя его.
Возможно, в вашем коде Django есть ошибка, и сокет создан неправильно. Пока Gunicorn открыт, попробуйте также посетить YOUR_IP:8888 (es. 52.45.241.21:8888) из браузера: вы видите веб-сайт?
Если вы видите некоторые ошибки Python, вы должны сначала отладить ваш проект с помощью "manage.py runserver 0.0.0.0:8000".
0.0.0.0:8000 после запуска сервера позволяет посещать ваш сайт из внешнего браузера (например, параметр -b 0.0.0.0:8000 в Gunicorn)
Помните: перед тем, как следовать любому руководству по развертыванию проекта Django, убедитесь, что проект работает правильно на компьютере с использованием сервера запуска
РЕДАКТИРОВАТЬ: Попробуйте также более простой учебник, как это: https://gist.github.com/ravidsrk/8431321
Надеюсь, что это hepls!:)
У меня такая же проблема. Я устанавливаю Django, Gunicorn, nginx по этой ссылке: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18-04 Иногда мой веб-сайт замедляется и выдает ошибку 502. Особенно при простое и возвращении. Сначала щелкните получить 502, а затем дважды щелкните, чтобы веб-сайт работал нормально. И я основал это: https://www.datadoghq.com/blog/nginx-502-bad-gateway-errors-gunicorn/ в моем случае: я увеличиваю таймаут Gunicorn и nginx:
nginx:
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_connect_timeout 300s;
proxy_read_timeout 300s;
}
служба пулеметчиков:
ExecStart=/home/myself/django/myproject/venvprod/bin/gunicorn \
--access-logfile - \
--bind unix:/run/gunicorn.sock \
--timeout 60 \
myproject.wsgi:application
После тысячи поисков я нашел решение своей проблемы.
Я установил Gunicorn в виртуальной среде. Мне пришлось перейти в папку установки /virtual/venv/lib/python3.7/site-packages/gunicorn$ и изменить файл config.py, увеличив время ожидания до 3000.
Наконец, проблема была связана с новым официальным выпуском Python 3.7
, который просто бездельничал. Ни на секунду не думал, что это может быть проблемой (также я никогда не получал никаких предупреждений / ошибок при установке, и я действительно следовал официальной установке tuto для mod_wsgi, установка Python
в качестве общей библиотеки и т. д.). Чтение основных дампов мне тоже не помогло (никакой полезной информации или просто у меня нет уровня для их анализа).