☰

地址已被使用：为什么 Python 会监听我为 Supervisord 指定的任何端口？

tag-icon • tag-icon ubuntu nginx django supervisord
地址已被使用：为什么 Python 会监听我为 Supervisord 指定的任何端口？

Django Channels服务器端流程不是我的强项，我在尝试将我的应用程序放在 Ubuntu 16.04 上的 Digital Ocean 上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 Channels 部署文档

我们让 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
}

答案1

前段时间，我使用 nginx 和 Dapnhe 设置了一个 Django Channels 应用程序，也遇到了类似的情况。您可以查看我的旧帖子有关此主题的更多信息。

但一般来说：

  • 您的command命令看起来很可疑 - 请确保套接字文件所在的目录存在。
  • 接下来，--fd:fileno=0我推测你这样写是因为上面描述的 bug这里，但是，这个问题已经得到修复，您可以简单地使用--fd 0。
  • 除此之外，Supervisor 配置中的套接字地址应该与 nginx 配置中指定的上游相匹配，但这不是您的情况（端口不同）。

相关内容