gpt4 book ai didi

Django Channels Nginx 制作

转载 作者:行者123 更新时间:2023-12-02 06:58:35 27 4
gpt4 key购买 nike

我有一个 django 项目,最近添加了使用 websockets 的 channel 。这似乎一切正常,但我遇到的问题是如何做好生产准备。

我的设置如下:

Nginx web server
Gunicorn for django
SSL enabled

自从我在混音中添加了 channel 后。我花了最后一天的时间试图让它发挥作用。

在所有的turtotials上,他们说你在某个端口上运行daphne,然后展示如何为此设置nginx。

但是让 Gunicorn 服务 django 怎么样?

所以现在我有guncorn在8001上运行这个django应用程序

如果我在另一个端口上运行 daphne,比如说 8002 - 它应该如何知道它在这个 django 项目中的部分?那么运行 worker 呢?

Gunicorn、Daphne 和 runworkers 应该一起跑吗?

最佳答案

这个问题实际上在最新的Django Channels docs中得到了解决。 :

It is good practice to use a common path prefix like /ws/ to distinguish WebSocket connections from ordinary HTTP connections because it will make deploying Channels to a production environment in certain configurations easier.

In particular for large sites it will be possible to configure a production-grade HTTP server like nginx to route requests based on path to either (1) a production-grade WSGI server like Gunicorn+Django for ordinary HTTP requests or (2) a production-grade ASGI server like Daphne+Channels for WebSocket requests.

Note that for smaller sites you can use a simpler deployment strategy where Daphne serves all requests - HTTP and WebSocket - rather than having a separate WSGI server. In this deployment configuration no common path prefix like is /ws/ is necessary.

实际上,您的 NGINX 配置将类似于(缩短为仅包含相关位):

upstream daphne_server {
server unix:/var/www/html/env/run/daphne.sock fail_timeout=0;
}

upstream gunicorn_server {
server unix:/var/www/html/env/run/gunicorn.sock fail_timeout=0;
}

server {
listen 80;
server_name _;

location /ws/ {
proxy_pass http://daphne_server;
}

location / {
proxy_pass http://gunicorn_server;
}
}

(上面假设您将 Gunicorn 和 Daphne 服务器绑定(bind)到 Unix 套接字文件。)

关于Django Channels Nginx 制作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46175452/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com