Назад | Перейти на главную страницу

Адрес уже используется: почему Python прослушивает любой порт, указанный мной для Supervisord?

Серверные процессы - не моя сильная сторона, и я все время натыкаюсь на стену, пытаясь Django Channels приложение Digital Ocean в Ubuntu 16.04 с использованием Nginx в качестве основного веб-сервера и supervisord бежать и управлять Daphne.

Я получаю сообщение об ошибке supervisord.conf говоря

Could not create FastCGI socket [Errno 98] Address already in use

я остановился Nginx затем перезапустили Supervisor чтобы увидеть, сбросит ли он порт 7000 и разрешите ему подключиться, но ошибка все еще существует.

Когда я проверяю sudo netstat -lnp | grep :7000 я вижу

tcp        0      0 127.0.0.1:7000          0.0.0.0:*               LISTEN      11526/python 

Когда я убью этот экземпляр и перезапущу supervisord он появляется снова, так что supervisord очевидно, запускает python, а затем заявляет, что не может подключиться к порту, потому что что-то уже прослушивает.

Я уверен, что здесь происходит какая-то круговая логика, но я использую supervisord справляться daphne который является сервером asgi для Django channels.

Из Документы по развертыванию каналов Django

Мы заставляем Supervisor прослушивать TCP-порт, а затем передаем этот сокет дочерним процессам, чтобы все они могли использовать один и тот же связанный порт:

Конфигурационный файл моего супервизора

[fcgi-program:asgi]
# TCP socket used by Nginx backend upstream
socket=tcp://127.0.0.1:7000

# Directory where your site's project files are located
directory=/home/me/myapp/src/myapp

# Each process needs to have a separate socket file, so we use process_num
command=daphne -u /home/me/daphne/run/daphne%(process_num)d.sock --fd:fileno=0 --access-log - --proxy-headers myapp.asgi:application

# Number of processes to startup, roughly the number of CPUs you have
numprocs=4

# Give each process a unique name so they can be told apart
process_name=asgi%(process_num)d

# Automatically start and recover processes
autostart=true
autorestart=true

# Choose where you want your log to go
stdout_logfile=/home/me/daphne/logs/asgi.log
redirect_stderr=true

Необходимо указать Nginx для проксирования трафика на запущенные экземпляры Daphne.

моя конфигурация nginx

upstream myapp {
    server 127.0.0.1:8000;
}

server {
    server_name myapp.com www.myapp.com;

    location = /favicon.ico { access_log off; log_not_found off; }

    location / {
        try_files $uri @proxy_to_app;
    }

    location /static/ {
        root /home/me/myapp/src/myapp;
    }

    location /media/  {
        root /home/me/myapp/src/myapp;
        include /etc/nginx/mime.types;
    }

    location @proxy_to_app {
        proxy_pass http://myapp;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        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;
    }

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


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


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

Некоторое время назад я настраивал приложение Django Channels с nginx и Dapnhe, и у меня были очень похожие приключения. Вы можете проверить моя старая ветка по этой теме для получения дополнительной информации.

Но в целом:

  • Ваш command выглядит подозрительно - убедитесь, что каталог, в котором должны находиться файлы сокета, существует.
  • Следующий, --fd:fileno=0 - Я полагаю, вы написали это из-за описанной ошибки Вотоднако это исправлено, и вы можете просто использовать --fd 0.
  • Кроме того, адрес сокета в конфигурации супервизора должен соответствовать восходящему потоку, указанному в конфигурации nginx, что не в вашем случае (порты различаются).