nginx+supervisor+daphne+django重启后代码不生效-踩坑记录

前言

项目架构 nginx+supervisor+daphne+django,因为django里面使用了channel包来处理websockert请求所以django的网关协议从WSGI升级为了ASGI,从而使用了风评较好且支持ASGI协议的daphne来进行网关框架部署,supervisor进行进程管理,nginx进行请求代理.

问题点1

nginx(80)配置转发websockert的时候(location /api)一直握手不成功。nginx配置如下:

server {
    listen       80;
    charset utf-8;
    access_log  /var/log/nginx/access.log;
    gzip_types text/plain application/x-javascript text/css text/javascript application/x-httpd-php application/json text/json image/jpeg image/gif image/png application/octet-stream;
...
    location /api {
        proxy_pass http://10.200.1.228:6099;


        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        client_max_body_size    1000m;
        chunked_transfer_encoding       on;
        proxy_connect_timeout    600;
        proxy_read_timeout       600;
        proxy_send_timeout       600;
        proxy_set_header  X-Real-IP  $remote_addr; #获取真实ip
        proxy_http_version 1.1; #http协议版本
        proxy_set_header Connection "upgrade"; #连接方式-请求升级
        proxy_set_header Upgrade $http_upgrade; #升级协议

    }
...
}

问题解决1

websokert请求升级的头都有添加,看了channels的官网也是这么配置的.
初期排查是因为我的websocker的url是 application/message/.....,我确实废物这个问题竟然没发现

问题点2

我修改了websockert的url,从application/message/改为了api/application/message/,但是握手还是握不上这就触及到我知识盲区了..修改的操作如下.

# 杀掉supervisor进程
ps -aux | grep supervisor
kill -s 9 pid
# 修改url
从application/message/改为api/application/message/
具体操作略过
# 启动supervisor
supervisor -c supervisor.conf

问题解决2

我不走nginx直接取访问后端端口(6099)上的websockert服务api/application/message/竟然也访问不到但是原来的urlapplication/message是可以访问到的,这说明我新改的代码没有生效呀.
于是我又去查看django日志的时候发现刷出了几百行的6099端口占用中的日志证实猜想,我的新进程根本就没有起来.
然后我就把6099端口上的服务和superviso杀掉,再次重启supervisor.
6099上的api/application/message/就可以访问了同样的nginx就可以正常转发了.

问题刨析2

后面我又做了下实验有如下发现:

1. kill杀掉supervisor进程时挂载的command(本文的6099后端服务)并不会停掉.

2.kill杀掉某一个command时只要supervisor配置了autorestart它就会一直去重启command
上面的操作是有问题的

# 杀掉supervisor进程
ps -aux | grep supervisor
kill -s 9 pid
# 这里我以为是杀掉后端服务其实6099一直都在，并不会随着supervisor停止而停止

# 修改url
从application/message/改为api/application/message/
具体操作略过

# 启动supervisor
supervisor -c supervisor.conf
#由于上面的6099服务并没停止导致了我在这里进行启动的command(6099服务)一直在报端口被占用..

总结

supervisor的启停还是用人家自己命令吧,不知道就百度为了省这一分钟花了两个小时去解决。。
supervisor命令贴一份

#daphne是supervisor配置文件中的program命名
supervisorctl 是 supervisord的命令行客户端工具
supervisorctl status：  查看所有进程的状态
supervisorctl stop daphne：停止daphne  
supervisorctl start daphne：启动daphne  
supervisorctl restart daphne: 重启daphne  
supervisorctl update ： 配置文件修改后可以使用该命令加载新的配置
supervisorctl reload:     重新启动配置中的所有程序
...
把 daphne 换成 all 可以管理配置中的所有进程