预计阅读3分钟
上一篇文章有些同学感觉不够详细理解起来有些困难,我再来简单解释一下。
我们在开发的情况下:
浏览器请求→ python manage.py runserver(比如8000) → 到应用代码(Django,Flask等等)
部署到线上的情况:
域名请求→ DNS解析→ 服务器IP→ Nginx(80端口)→ 代理转发 127.0.0.1:8000(IP不一定是127.0.0.1)→ 到项目应用代码逻辑。
在整个部署过程中,我们加了一层docker来进行隔离部署,不仅解决了开发(dev)测试(test)线上(prod)多个环境不一致的问题,也达到了一次封装,处处运行的目的,我们日常使用virtualenv进行Python包环境隔离都不需要了,这在多人开发模式下面非常方便。
我其实在docker入门篇
Docker 容器化部署实践--入门
已经讲过了。至于新手的话如果觉得一开始觉得不太容易上手,可以考虑去掉docker这个中间环节,直接把服务跑在Linux机器上面。
解释完上面,接下来进入我们今天的主题:
Django + Nginx + Gunicorn 部署
Gunicorn
Gunicorn,是「Green Unicorn」,最初来于Ruby社区的Unicorn,是用于Unix的Python WSGI HTTP服务器,Gunicorn与各种Web框架广泛兼容,简单轻便。
我们之所以使用使用uWSGI或Gunicorn原因就是Flask,Django自带的WSGI服务性能不够好,一般用在测试开发环境用,线上主要使用更为高性能的WSGI服务。
作为介绍我这里引用一个官方例子:
装好gunicorn之后,我们可以通过 进行查看配置,通常情况下为了方便,我们都是把gunicorn放在配置文件中。
同uWSGI一样我给一个简单的supervisor例子:
上面说下为什么worker数目是CPU核数*2+1,这个没有太多科学依据,主要是根据一个work进行读写操作,另一个work处理请求,具体可以根据自己情况进行配置。更多特殊配置,大家可以进行自行查阅文档。
supervisor & nginx & docker-compose
supervisor同上篇文章使用Docker容器化部署实践之Django应用部署(一)一样,唯一变化的就是我们command从uUWSGI变为了gunicorn,这里我就不多列出来supervisor完整配置了。
Nginx同上篇文章一样,我这里列一个简单的样例:
docker-compose配置同之前文章一样,内容较多,就不列出来了。可以参考上篇文章使用Docker容器化部署实践之Django应用部署(一)的配置。
说到最后
今天我们主要阐述了Django部署使用的第二种方式,实际上这个过程和没有docker几乎差不多的,你可以剥离掉docker,对你整个过程没有太大影响。
同样的我整个部署过程阐述的过程比较简单,实际情况会多少有些出入,不知道你听懂了么?欢迎大家给我留言,我们一起讨论。
Docker容器化部署相关我们下一篇我们聊聊Kubernets这个大杀器。
免费加入,一起进步
领取专属 10元无门槛券
私享最新 技术干货