Django + Guncorn + nginx: 111:В соединении отказано; недопустимый шлюз 502

По некоторым причинам это не работает. Вы видите какие-либо проблемы в этом коде? Спасибо за Ваш обзор заранее!

Error.log:

2019/11/10 18:02:02 [error] 8761#8761: *1 connect() to unix:/run/gunicorn.sock failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: demid.com, request: "GET / HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/", host: "127.0.0.1"

Терминал:

demid@demid-Aspire-7736:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
demid@demid-Aspire-7736:~$ systemctl daemon-reload
demid@demid-Aspire-7736:~$ systemctl restart gunicorn.socket gunicorn.service nginx.service; systemctl status gunicorn.socket gunicorn.service nginx.service
Failed to dump process list, ignoring: No such file or directory
● gunicorn.socket - gunicorn socket
   Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-11-10 17:59:39 EET; 288ms ago
   Listen: /run/gunicorn.sock (Stream)
   CGroup: /system.slice/gunicorn.socket

lapkr. 10 17:59:39 demid-Aspire-7736 systemd[1]: Listening on gunicorn socket.

● gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-11-10 17:59:39 EET; 213ms ago
 Main PID: 8756 (gunicorn)
    Tasks: 1 (limit: 4669)
   CGroup: /system.slice/gunicorn.service
           └─8756 /home/demid/myprojectdir/myprojectenv/bin/python3 /home/demid/myprojectdir/myprojectenv/bin/gunicorn

lapkr. 10 17:59:39 demid-Aspire-7736 systemd[1]: Started gunicorn daemon.

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-11-10 17:59:39 EET; 70ms ago
     Docs: man:nginx(8)
Process: 8757 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, 
  Process: 8759 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Process: 8758 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 8760 (nginx)
    Tasks: 3 (limit: 4669)
   CGroup: /system.slice/nginx.service
           ├─8760 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           ├─8761 nginx: worker process
           └─8762 nginx: worker process

lapkr. 10 17:59:39 demid-Aspire-7736 systemd[1]: Starting A high performance web server and a reverse proxy server...
lapkr. 10 17:59:39 demid-Aspire-7736 systemd[1]: Started A high performance web server and a reverse proxy server.

/etc/nginx/conf.d/demid.com.conf

server {
    listen         80 default_server;
    listen         [::]:80 default_server;
    server_name    demid.com;
    location = /favicon.ico {access_log off; log_not_found off;}
    location /static/ {
root /demid/myprojectdir;
    }

    location / {
include proxy_params;
#proxy_set_header Host $http_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-Proto $scheme;
    #proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
proxy_pass http://unix:/run/gunicorn.sock;
}
}

/etc/systemd/system/gunicorn.service

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

[Service]
User=root
Group=www-data
WorkingDirectory=/home/demid/myprojectdir
ExecStart=/home/demid/myprojectdir/myprojectenv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
myproject.wsgi:application

[Install]
WantedBy=multi-user.target

/etc/nginx/nginx.conf

worker_processes auto;
worker_rlimit_nofile 50000;

events {
    worker_connections  1024;
    use epoll;
    multi_accept on;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout  65;
    keepalive_requests 256;
    reset_timedout_connection on;

    gzip  on;
    gzip_vary on;
    gzip_proxied any;
    gzip_min_length 1000;
    gzip_types text/plain text/xml text/css text/javascript application/x-javascript application/json application/xml application/xml+rss image/png image/gif image/jpeg image/jpg;

    open_file_cache max=50000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;

    client_max_body_size 512m;

    server_tokens off;

    include /etc/nginx/conf.d/*.conf;
}
0
задан 10 November 2019 в 19:12

1 ответ

Подводить итог - nginx возвращался 111: Connection refused после попытки соединиться с gunicorn через сокет UNIX, расположенный в /run/gunicorn.sock.

Сначала мы удостоверились, что это не было проблемой разрешения:

# ls -l /run/gunicorn.sock
srw-rw-rw- 1 root root 0 lapkr 10 20:34 /run/gunicorn.sock

rw-rw-rw- средства, которые каждый пользователь может считать и записать в файл.

(Примечание стороны - эти полномочия слишком широки, лучшая практика могла бы быть должна удостовериться это nginx рабочие выполняются тем же пользователем как gunicorn.service и дайте разрешения RW только этому пользователю, но этот ответ фокусируется главным образом на создании работы соединения, и это действительно не мой домен так или иначе.)

Следующее действие должно было перечислить процессы, слушающие на сокете:

# netstat --protocol=unix -nlp | grep 'gunicorn'

(Вместо gunicorn Вы можете также grep весь путь сокета, но здесь это было достаточно).

Вывод был пуст, gunicorn не слушал.

После рассмотрения gunicorn сервисные журналы:

# systemctl status gunicorn.service
# journalctl -u gunicorn.service

мы нашли, что привязка сокета перестала работать с сообщением:

ModuleNotFoundError: No module named 'myproject.wsgi' 

Это было вызвано при помощи неправильного пути к приложению Python для привязки сокета в /etc/systemd/system/gunicorn.service.

Файл содержит два параметрических усилителя, которые влияют на это - WorkingDirectory и ExecStart.

WorkingDirectory должен указать на каталог, который содержит основное gunicorn файл конфигурации - settings.py.

ExecStart должен содержать основную команду для выполнения gunicorn двоичный файл virtualenv. Необходимо выполнить его с опцией --bind /run/gunicorn.sock myproject.wsgi:application, где /run/gunicorn.sock сокет filepath и myproject.wsgi:application относительный путь к модулю Python entrypoint (директора разделяются точками, расширением .py опущен, имя модуля сопровождается двоеточием и вызываемым application переменная).

0
ответ дан 22 December 2019 в 00:01

Другие вопросы по тегам:

Похожие вопросы: