Ошибка развертывания цифрового океана: 502 Bad Gateway

У меня сайт работает, но админка CSS не загружается, я не уверен, что я сделал, что сервер не согласился, но теперь весь сайт не работает с сообщением 502 Bad Gateway.

Вот содержимое некоторых ключевых файлов

sudo nano /etc/systemd/system/gunicorn.socket файл:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

gunicorn.service файл (sudo nano /etc/systemd/system/gunicorn.service)

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

[Service]
User=eson
Group=www-data
WorkingDirectory=/home/eson/example
ExecStart=/home/eson/example/env/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          example.wsgi:application
[Install]
WantedBy=multi-user.target

Вот что есть у Nginx sudo nano /etc/nginx/sites-available/example:

server {
    server_name www.example.com example.com;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/eson/example;
    }

    location /media/ {
        root /home/eson/example;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/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 = www.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name www.example.com example.com;
    return 404; # managed by Certbot
}

Когда я набираю sudo systemctl status gunicorn.socket, я получаю:

● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
     Active: failed (Result: service-start-limit-hit) since Wed 2022-05-11 01:42:19 UTC; 2s ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)

Когда я запускаю file /run/gunicorn.sock, я получаю /run/gunicorn.sock: socket

Nginx выглядит нормально:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Но, когда я запускаю sudo tail -30 /var/log/nginx/error.log, я получаю:

2022/05/11 15:26:47 [error] 739#739: *49 connect() to unix:/run/gunicorn.sock failed (111: Connection refused) while connecting to upstream, client: 192.241.219.87, server: www.example.com, request: "GET /owa/auth/x.js HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/owa/auth/x.js", host: "128.199.2.252"
2022/05/11 15:29:47 [error] 739#739: *51 connect() to unix:/run/gunicorn.sock failed (111: Connection refused) while connecting to upstream, client: 192.241.212.218, server: www.example.com, request: "GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application", host: "128.199.2.252"
2022/05/11 15:30:50 [error] 739#739: *53 connect() to unix:/run/gunicorn.sock failed (111: Connection refused) while connecting to upstream, client: 192.241.221.172, server: www.example.com, request: "GET /owa/auth/logon.aspx HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/owa/auth/logon.aspx", host: "128.199.2.252"
2022/05/11 15:49:48 [error] 739#739: *55 connect() to unix:/run/gunicorn.sock failed (111: Connection refused) while connecting to upstream, client: 72.143.229.153, server: www.example.com, request: "GET /admin/login/?next=/admin/ HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/admin/login/?next=/admin/", host: "example.com"
2022/05/11 16:13:25 [crit] 739#739: *57 SSL_do_handshake() failed (SSL: error:14201044:SSL routines:tls_choose_sigalg:internal error) while SSL handshaking, client: 23.92.22.17, server: 0.0.0.0:443
2022/05/11 16:21:15 [crit] 739#739: *61 connect() to unix:/home/django/gunicorn.socket failed (2: No such file or directory) while connecting to upstream, client: 45.9.20.101, server: _, request: "GET /_ignition/execute-solution HTTP/1.1", upstream: "http://unix:/home/django/gunicorn.socket:/_ignition/execute-solution", host: "128.199.2.252:80"

и мой брандмауэр разрешает следующие приложения:

sudo ufw app list
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH
  Postfix
  Postfix SMTPS
  Postfix Submission

Когда я запускаю и включаю gunicorn, состояние сокета gunicorn в порядке:

sudo systemctl status gunicorn.socket
● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
     Active: active (listening) since Wed 2022-05-11 16:14:05 UTC; 11min ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)
      Tasks: 0 (limit: 2339)
     Memory: 0B
     CGroup: /system.slice/gunicorn.socket

Но, статус гиникорна - это НЕ:

sudo systemctl status gunicorn
● gunicorn.service - gunicorn daemon
     Loaded: loaded (/etc/systemd/system/gunicorn.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2022-05-11 14:01:54 UTC; 2h 23min ago
TriggeredBy: ● gunicorn.socket
   Main PID: 1775 (code=exited, status=1/FAILURE)

Я попытался перезапустить все:

sudo systemctl daemon-reload 
sudo systemctl restart gunicorn
sudo systemctl enable gunicorn.socket

Когда я запускаю sudo tail -F /var/log/nginx/error.log:

digital ocean doc предполагает, что

**connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)**

This indicates that Nginx was unable to find the gunicorn.sock file at the given location. You should compare the proxy_pass location defined within /etc/nginx/sites-available/myproject file to the actual location of the gunicorn.sock file generated by the gunicorn.socket systemd unit. If you cannot find a gunicorn.sock file within the /run directory, it generally means that the systemd socket file was unable to create it. Go back to the section on checking for the Gunicorn socket file to step through the troubleshooting steps for Gunicorn.

Так я и сделал, и там сказано запустить file /run/gunicorn.sock, и я получаю /run/gunicorn.sock: socket, идентичный вывод, как у них.

Также, когда я запускаю: sudo journalctl -u gunicorn.socket

Я получаю следующее:

-- Logs begin at Tue 2022-02-22 09:51:29 UTC, end at Wed 2022-05-11 01:49:37 UTC. --
May 10 21:53:50 django-s-1vcpu-2gb-sfo3-01 systemd[1]: gunicorn.socket: Failed with result 'service-start-lim>
May 10 23:51:14 django-s-1vcpu-2gb-sfo3-01 systemd[1]: Listening on gunicorn socket.
May 10 23:52:17 django-s-1vcpu-2gb-sfo3-01 systemd[1]: gunicorn.socket: Failed with result 'service-start-lim>
May 11 01:18:28 django-s-1vcpu-2gb-sfo3-01 systemd[1]: Listening on gunicorn socket.
May 11 01:20:47 django-s-1vcpu-2gb-sfo3-01 systemd[1]: gunicorn.socket: Failed with result 'service-start-lim>
May 11 01:35:43 django-s-1vcpu-2gb-sfo3-01 systemd[1]: Listening on gunicorn socket.
May 11 01:36:19 django-s-1vcpu-2gb-sfo3-01 systemd[1]: gunicorn.socket: Failed with result 'service-start-lim>
May 11 01:40:16 django-s-1vcpu-2gb-sfo3-01 systemd[1]: Listening on gunicorn socket.
May 11 01:40:33 django-s-1vcpu-2gb-sfo3-01 systemd[1]: gunicorn.socket: Failed with result 'service-start-lim>
May 11 01:40:51 django-s-1vcpu-2gb-sfo3-01 systemd[1]: Listening on gunicorn socket.
May 11 01:42:19 django-s-1vcpu-2gb-sfo3-01 systemd[1]: gunicorn.socket: Failed with result 'service-start-lim>
lines 1-12/12 (END)

Я выполнил sudo journalctl -u gunicorn, и обнаружил там ошибку. Вот отслеживание:

Я проверил свой файл settings.py на наличие корсхедера, и вот он:

# Application definition
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # 3rd party apps:
    'corsheaders',
    ...
    ]

MIDDLEWARE = [
    # 3rd party middleware
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    ...
    ]

CORS_ALLOWED_ORIGINS = [
        "https://example.com",
        "http://example.com",
        "http://localhost:8000",
        "http://localhost:3000",
        "http://127.0.0.1:8000",
    ]

Итак, в чем мои проблемы? В том, что

"Nginx не смог найти файл gunicorn.sock в указанном location"

Это из-за корсхедера? Или может быть и то и другое? И как это исправить? У меня был тот же код до внесения некоторых изменений, чтобы исправить проблему с css на странице администратора, и он не жаловался на corseheader. Спасибо, что прочитали этот длинный журнал и вопрос. Я подумал, что вам нужно увидеть полную картину, чтобы понять, в чем может быть причина. Я очень ценю вашу помощь, так как из-за этого сайт не работает в критический для нас момент.

EDIT 1: Я также должен отметить, что когда я запускаю sudo nano /run/gunicorn.sock, файл открывается с этим сообщением:

[ Error reading /run/gunicorn.sock: No such device or address ]

Итак, мои проблемы, которые могут быть и проблемами кого-то другого, были следующими:

  1. У меня не все пакеты были установлены в виртуальной среде (отсюда пресловутое 502 bad gateway)
  2. Мои переменные окружения не были установлены (поэтому я получил 500 Server Error). Я просто создал файл .env на сервере и скопировал туда все свои переменные окружения (не рекомендуется отслеживать .env файл)
    3. .
  3. Мои миграции не были перенесены в мою производственную БД. Поэтому я должен python manage.py migrate
    4. .

Я смог отладить проблему, установив DEBUG = True в settings.py и посмотреть, где я получаю ошибки и что на самом деле означают эти ошибки программирования (например, если вы получаете AttributeError, это означает, что вы не перенесли некоторые файлы миграции). О, убедитесь, что вы отключили DEBUG = False после этого, чтобы избежать раскрытия сайта. Надеюсь, это сэкономит кому-то 3 дня копания и отладки ;)

Вернуться на верх