Estoy usando django-channels por lo tanto, necesito usar daphne , pero para los archivos estáticos y otras cosas quiero usar gunicorn . Puedo iniciar a gunicorn daphne pero no puedo iniciar a ambos al mismo tiempo.
Mi pregunta es ¿debo comenzar ambos al mismo tiempo o hay alguna opción mejor? Si debería, ¿cómo puedo hacer eso?
Aquí está mi comando de servidor en ejecución:
gunicorn app.wsgi:application --bind 0.0.0.0:8000 --reload && daphne -b 0.0.0.0 -p 8089 app.asgi:application PD: Dividí location de / y /ws/ para gunicorn y daphne en nginx.conf .
Su problema es que está llamando a ambos procesos en el mismo contexto/línea y nunca se llama a uno porque el primero nunca "termina".
este proceso: gunicorn app.wsgi:application --bind 0.0.0.0:8000 --reload
no terminará en ningún momento, por lo que el comando && nunca se ejecutará a menos que elimine ese comando manualmente, y en ese momento no estoy seguro de que no elimine toda la cadena de procesos por completo.
si desea ejecutar ambos, puede ejecutar ambos procesos en segundo plano con &, por ejemplo
(no se puede probar, pero esto debería funcionar)
gunicorn app.wsgi:application --bind 0.0.0.0:8000 --reload & daphne -b 0.0.0.0 -p 8089 app.asgi:application &La información de enseñar a un hombre a pescar sobre este tipo de problema está aquí
Estoy bastante seguro de que perderá el registro normal de la consola que normalmente tendría al ejecutarlos en segundo plano, por lo que le sugiero que busque en nohup en lugar de & o envíe los registros a algún lugar con una utilidad de registro para que no esté volando. ciego.
En cuanto a otras opciones, si planea escalar a una gran cantidad de usuarios, probablemente más de 100, simplemente ejecutaría dos servidores, uno para solicitudes wsgi django http y otro para solicitudes asgi daphne ws. Tenga un proxy nginx entre los dos para lo que necesite y listo. Eso es también lo que Channels recomienda para aplicaciones más grandes.
Es una buena práctica usar un prefijo de ruta común como /ws/ para distinguir las conexiones WebSocket de las conexiones HTTP ordinarias porque facilitará la implementación de canales en un entorno de producción en ciertas configuraciones.
En particular, para sitios grandes, será posible configurar un servidor HTTP de nivel de producción como nginx para enrutar solicitudes en función de la ruta a (1) un servidor WSGI de nivel de producción como Gunicorn+Django para solicitudes HTTP ordinarias o (2) un servidor de producción Servidor ASGI de grado como Daphne+Channels para solicitudes WebSocket.
Tenga en cuenta que para sitios más pequeños puede usar una estrategia de implementación más simple donde Daphne atiende todas las solicitudes (HTTP y WebSocket) en lugar de tener un servidor WSGI separado. En esta configuración de implementación, no es necesario un prefijo de ruta común como /ws/.
no es necesario para ejecutar ambos. Daphne es un servidor de protocolo HTTP, HTTP2 y WebSocket. echa un vistazo a README en este enlace: https://github.com/django/daphne