502 Bad Gateway nginx с селеном и Django

Question

У меня есть веб-приложение с DigitalOcean (gunicorn / nginx) с использованием Selenium и Django.

Я пытаюсь собрать данные с 3 сайтов и сохранить их в базе данных, но Я получаю эту ошибку, если процесс занимает более 60 секунд

502 Bad Gateway
nginx/1.14.0 (Ubuntu)

Как мне продлить или отключить время ожидания ответа для nginx?

Answer 1

Это сообщение об ошибке ...

502 Bad Gateway
nginx/1.14.0 (Ubuntu)

... с использованием DigitalOcean (gunicorn / nginx) может появляться по ряду причин. Определение точной причины ошибки 502 зависит от используемого вами веб-сервера, а также от сервера приложений, интерпретирующего запросы.

---

502 Плохой шлюз

Плохие ошибки шлюза обычно вызваны нарушение связи между веб-сервером и обработчиком приложения. Во многих случаях основной проблемой является либо чрезмерная задержка, либо чрезвычайно короткий тайм-аут windows.

Иногда 502 Bad Gateway также вызвано неверно настроенным сервером приложений, когда веб-сервер понял запрос и передал его соответствующему обработчику, но между ними произошло какое-то нарушение.

---

Решение

Gunicorn , являющийся одним из широко используемых Python WSGI-серверов, диагностика причины ошибки 502 Bad Gateway будет в основном зависеть от используемого вами сервера приложений и некоторых Общие проблемы заключаются в следующем:

• Gunicorn не работает : Вы должны убедиться, что Gunicorn работает с использованием ps . Чтобы убедиться, что Gunicorn работает, вы должны увидеть аналогичный вывод:

  www-data@nginx0:/var/log/nginx$ ps aux | grep gunicorn
  www-data     13805  0.0  1.8  52292 18460 pts/0    S    20:32   0:00 /home/www-data/test_app/bin/python /home/www-data/test_app/bin/gunicorn --error-logfile /var/log/gunicorn/errors.log -b 0.0.0.0:8080 wsgi
  www-data     13836  0.0  1.5  52432 15392 pts/0    S    20:34   0:00 /home/www-data/test_app/bin/python /home/www-data/test_app/bin/gunicorn --error-logfile /var/log/gunicorn/errors.log -b 0.0.0.0:8080 wsgi
  

• Gunicorn не запускается : время от времени Gunicorn выигрывал не запускается из-за опечатки в файле конфигурации или конфликта портов, недоступного каталога журналов или любой комбинации этих ситуаций. В этих случаях для проверки конфигурации Gunicorn выполните команду:

  gunicorn --check-config [APP_MODULE]
  

• NGINX неправильно настроен : Incase Gunicorn настроен правильно, возможно, что NGINX не ищет его в нужном месте. В этих случаях откройте файл конфигурации NGINX (/etc/nginx/nginx.conf) и найдите блок, начинающийся с ключевого слова upstream, следующим образом:

  upstream app_servers {
      server 127.0.0.1:8080;
  }
  

  Этот параметр предназначен для настроить NGINX для перенаправления запросов для _app_servers_ в, в данном случае, 127.0.0.1:8080. Если Gunicorn не привязан к 127.0.0.1 или не прослушивает 8080, либо измените конфигурацию Gunicorn, чтобы она соответствовала NGINX, либо измените конфигурацию NGINX, чтобы она соответствовала Gunicorn. Кроме того, убедитесь, что конфигурация вашего сайта перенаправляет ваше приложение на соответствующий вышестоящий сервер. Для этого вам необходимо открыть конфигурацию вашего сайта, например, /etc/nginx/sites-enabled/your_site и найти блок, определяющий конечную точку URL-адреса для вашего приложения. В качестве примера:

  location /my-app {
          proxy_pass         http://app_servers;
          proxy_redirect     off;
          proxy_set_header   Host $host;
          proxy_set_header   X-Real-IP $remote_addr;
          proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header   X-Forwarded-Host $server_name;
  
  }
  

• Время истечения срока действия Gunicorn : если ваше приложение отнимает много времени (по умолчанию> 30 с), Gunicorn может вернуть 502 до NGINX. Это можно проверить, проверив журналы Gunicorn (по умолчанию STDOUT, если файл журнала не установлен). Например,

  [2016-09-21 20:33:04 +0000] [13805] [CRITICAL] WORKER TIMEOUT (pid:13810)
  

  Приведенный выше журнал подразумевает, что приложению требуется слишком много времени для ответа на Gunicorn, в результате чего рабочий поток прерывается, потому что Gunicorn считает, что рабочий завис. В таких случаях лучшим решением будет увеличение максимального времени выполнения Gunicorn. Однако с точки зрения приложения и обработки набора данных тайм-аут увеличения windows может оказаться не лучшим решением, и вам может потребоваться профилирование и оптимизация используемого приложения.

• Тонкая настройка read_timeout: Если вы по-прежнему видите 502 Bad Gateway после изменения порога времени ожидания Gunicorn, вам необходимо выполнить следующие шаги, упомянутые ниже, чтобы увеличить окно времени ожидания для NGINX:

  • Откройте NGINX config (/etc/nginx/nginx.conf)
  • Добавить fastcgi_read_timeout XXX; в блоке http, где XXX - окно времени ожидания в секундах (см. Пример ниже)
  • Сохранить и закройте файл
  • Перезагрузите NGINX config

  • Пример:

    http { 
    ...
    
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    }
    

Answer 2

1 / 502 Bad Gateway вызвано GUNICORN
a - sudo nano /etc/systemd/system/gunicorn.service.
b-

[Unit]
Description=gunicorn daemon
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn --access-logfile - --timeout 300 --workers 3 --bind unix:/home/sammy/myproject/myproject.sock myproject.wsgi:application

[Install]
WantedBy=multi-user.target

c -

sudo systemctl start gunicorn
sudo systemctl enable gunicorn
sudo systemctl daemon-reload
sudo systemctl restart gunicorn

2 / 504 Bad Gateway , вызванный NGINX
a - sudo nano / etc / nginx / nginx .conf
b - добавить их в http

client_body_timeout 999;
client_header_timeout 999;
keepalive_timeout 999;
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 999;
fastcgi_send_timeout 999;
fastcgi_read_timeout 999;

c - изменить это в events

worker_connections 1024;

d - сервис nginx перезагрузка