Django + Uwsgi + Nginx 实现生产环境部署

uwsgi 介绍

uwsgi安装使用

nginx安装配置

django with nginx

 

区分uWSGI和WSGI

在python web开发中，我们经常使用uwsgi配合nginx部署一个web框架，如Django或flask。同时我们又会说，框架和web服务器之间要符合WSGI协议。那就来厘清一下这几个概念。

web服务器和web框架

在讲uWSGI和WSGI之前，先要弄清楚web开发的两大块，web服务器和web框架。
web服务器即用来接受客户端请求，建立连接，转发响应的程序。至于转发的内容是什么，交由web框架来处理，即处理这些业务逻辑。如查询数据库、生成实时信息等。Nginx就是一个web服务器，Django或flask就是web框架。

回到uWSGI和WSGI。

那么如何实现uWSGI和WSGI的配合呢？如何做到任意一个web服务器，都能搭配任意一个框架呢？这就产生了WSGI协议。只要web服务器和web框架满足WSGI协议，它们就能相互搭配。所以WSGI只是一个协议，一个约定。而不是python的模块、框架等具体的功能。

而uWSGI，则是实现了WSGI协议的一个web服务器。即用来接受客户端请求，转发响应的程序。实际上，一个uWSGI的web服务器，再加上Django这样的web框架，就已经可以实现网站的功能了。那为什么还需要Nginx呢？

为什么需要Nginx

一个普通的个人网站，访问量不大的话，当然可以由uWSGI和Django构成。但是一旦访问量过大，客户端请求连接就要进行长时间的等待。这个时候就出来了分布式服务器，我们可以多来几台web服务器，都能处理请求。但是谁来分配客户端的请求连接和web服务器呢？Nginx就是这样一个管家的存在，由它来分配。这也就是由Nginx实现反向代理，即代理服务器。

 

 

1 首先nginx 是对外的服务接口，外部浏览器通过url访问nginx,

2nginx 接收到浏览器发送过来的http请求，将包进行解析，分析url，如果是静态文件请求就直接访问用户给nginx配置的静态文件目录，直接返回用户请求的静态文件，

  如果不是静态文件，而是一个动态的请求，那么nginx就将请求转发给uwsgi,uwsgi 接收到请求之后将包进行处理，处理成wsgi可以接受的格式，并发给wsgi,wsgi 根据请求调用应用程序的某个文件，某个文件的某个函数，最后处理完将返回值再次交给wsgi,wsgi将返回值进行打包，打包成uwsgi能够接收的格式，uwsgi接收wsgi 发送的请求，并转发给nginx,nginx最终将返回值返回给浏览器。

3要知道第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程，但是要考虑到某些情况

  1 安全问题，程序不能直接被浏览器访问到，而是通过nginx,nginx只开放某个接口，uwsgi本身是内网接口，这样运维人员在nginx上加上安全性的限制，可以达到保护程序的作用。

  2负载均衡问题，一个uwsgi很可能不够用，即使开了多个work也是不行，毕竟一台机器的cpu和内存都是有限的，有了nginx做代理，一个nginx可以代理多台uwsgi完成uwsgi的负载均衡。

  3静态文件问题，用django或是uwsgi这种东西来负责静态文件的处理是很浪费的行为，而且他们本身对文件的处理也不如nginx好，所以整个静态文件的处理都直接由nginx完成，静态文件的访问完全不去经过uwsgi以及其后面的东西。
————————————————

如何在生产上部署Django?

Django的部署可以有很多方式，采用nginx+uwsgi的方式是其中比较常见的一种方式。

 

 

 

uwsgi介绍

uWSGI是一个Web服务器，它实现了WSGI协议、uwsgi、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。

要注意 WSGI / uwsgi / uWSGI 这三个概念的区分。

  1. WSGI是一种Web服务器网关接口。它是一个Web服务器（如nginx，uWSGI等服务器）与web应用（如用Flask框架写的程序）通信的一种规范。
  2. uwsgi是一种线路协议而不是通信协议，在此常用于在uWSGI服务器与其他网络服务器的数据通信。
  3. 而uWSGI是实现了uwsgi和WSGI两种协议的Web服务器。
  4. uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型（type of information），每一个uwsgi packet前4byte为传输信息类型描述，它与WSGI相比是两样东西。

 

uwsgi性能非常高

 

uWSGI的主要特点如下

  1. 超快的性能
  2. 低内存占用（实测为apache2的mod_wsgi的一半左右）
  3. 多app管理（终于不用冥思苦想下个app用哪个端口比较好了-.-）
  4. 详尽的日志功能（可以用来分析app性能和瓶颈）
  5. 高度可定制（内存大小限制，服务一定次数后重启等）

总而言之uwgi是个部署用的好东东，正如uWSGI作者所吹嘘的：

If you are searching for a simple wsgi-only server, uWSGI is not for you, but if you are building a real (production-ready) app that need to be rock-solid, fast and easy to distribute/optimize for various load-average, you will pathetically and morbidly fall in love (we hope) with uWSGI.

 

Uwsgi 安装使用

1
2
3
4
# Install the latest stable release:
pip install uwsgi
# ... or if you want to install the latest LTS (long term support) release,
pip install https://projects.unbit.it/downloads/uwsgi-lts.tar.gz

 

基本测试

Create a file called test.py:

1
2
3
4
5
# test.py
def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    return [b"Hello World"] # python3
    #return ["Hello World"] # python2

运行

1
uwsgi --http :8000 --wsgi-file test.py

 

用uwsgi 启动django

1
uwsgi --http :8000 --module mysite.wsgi

　　

可以把参数写到配置文件里

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
alex@alex-ubuntu:~/uwsgi-test$ more crazye-uwsgi.ini 
 
 
[uwsgi]
http = :9000
#the local unix socket file than commnuincate to Nginx
socket = 127.0.0.1:8001
# the base directory (full path)
chdir = /home/alex/CrazyEye 
# Django's wsgi file
wsgi-file = CrazyEye/wsgi.py
# maximum number of worker processes
processes = 4
#thread numbers startched in each worker process
threads = 2
 
#monitor uwsgi status 
stats = 127.0.0.1:9191
# clear environment on exit
vacuum          = true

启动

1
/usr/local/bin/uwsgi crazye-uwsgi.ini

　　

Nginx安装使用　　

1
2
sudo apt-get install nginx
sudo /etc/init.d/nginx start    # start nginx

 

为你的项目生成Nginx配置文件

You will need the uwsgi_params file, which is available in the nginx directory of the uWSGI distribution, or from https://github.com/nginx/nginx/blob/master/conf/uwsgi_params

Copy it into your project directory. In a moment we will tell nginx to refer to it.

Now create a file called mysite_nginx.conf, and put this in it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# mysite_nginx.conf
 
# the upstream component nginx needs to connect to
upstream django {
    # server unix:///path/to/your/mysite/mysite.sock; # for a file socket
    server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}
 
# configuration of the server
server {
    # the port your site will be served on
    listen      8000;
    # the domain name it will serve for
    server_name .example.com; # substitute your machine's IP address or FQDN
    charset     utf-8;
 
    # max upload size
    client_max_body_size 75M;   # adjust to taste
 
    # Django media
    location /media  {
        alias /path/to/your/mysite/media;  # your Django project's media files - amend as required
    }
 
    location /static {
        alias /path/to/your/mysite/static; # your Django project's static files - amend as required
    }
 
    # Finally, send all non-media requests to the Django server.
    location / {
        uwsgi_pass  django;
        include     /path/to/your/mysite/uwsgi_params; # the uwsgi_params file you installed
    }
}

This conf file tells nginx to serve up media and static files from the filesystem, as well as handle requests that require Django’s intervention. For a large deployment it is considered good practice to let one server handle static/media files, and another handle Django applications, but for now, this will do just fine.

Symlink to this file from /etc/nginx/sites-enabled so nginx can see it:

1
sudo ln -s ~/path/to/your/mysite/mysite_nginx.conf /etc/nginx/sites-enabled/

Deploying static files

Before running nginx, you have to collect all Django static files in the static folder. First of all you have to edit mysite/settings.py adding:

1
STATIC_ROOT = os.path.join(BASE_DIR, "static/")

and then run

1
python manage.py collectstatic

　　

此时启动Nginx 和Uwsgi，你的django项目就可以实现高并发啦！

　　

　　

 


一、前言

献给和我一样懵懂中不断汲取知识，进步的人们。

霓虹闪烁，但人们真正需要的，只是一个可以照亮前路的烛光

二、必要的前提

2.1 准备知识

django
一个基于python的开源web框架，请确保自己熟悉它的框架目录结构。
uWSGI
一个基于自有的uwsgi协议、wsgi协议和http服务协议的web网关
nginx
常用高性能代理服务器
wsgi.py
django项目携带的一个wsgi接口文件
如果项目名叫destiny的话，此文件就位于[destiny/destiny/wsgi.py]
2.2 相关资料

wsgi：一种实现python解析的通用接口标准/协议，是一种通用的接口标准或者接口协议，实现了python web程序与服务器之间交互的通用性。
利用它，web.py或bottle或者django等等的python web开发框架，就可以轻松地部署在不同的web server上了；
uwsgi:同WSGI一样是一种通信协议
uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型，它与WSGI相比是两样东西。
uWSGI :一种python web server或称为Server/Gateway
uWSGI类似tornadoweb或者flup，是一种python web server，uWSGI是实现了uwsgi和WSGI两种协议的Web服务器，负责响应python 的web请求。
因为apache、nginx等，它们自己都没有解析动态语言如php的功能，而是分派给其他模块来做，比如apache就可以说内置了php模块，让人感觉好像apache就支持php一样。
uWSGI实现了wsgi协议、uwsgi协议、http等协议。 Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。
2.3 项目流程
其实网上很多教程，都是关于uwsgi+nginx部署django的，StackOverflow也有一些解决常见错误的方法，但是部署还是容易出问题，新手难解决。
归根到底是自己不了解整个项目的流程。教程都只教方法，但为什么这样部署，这样部署有什么好处，每个组件都起什么作用却只字不提。致使只要部署稍微有那么一点不同，就无可是从了。
所以说，项目流程和每个组件的用途才是此次部署最重要的部分。

首先客户端请求服务资源，
nginx作为直接对外的服务接口,接收到客户端发送过来的http请求,会解包、分析，
如果是静态文件请求就根据nginx配置的静态文件目录，返回请求的资源，
如果是动态的请求,nginx就通过配置文件,将请求传递给uWSGI；uWSGI 将接收到的包进行处理，并转发给wsgi，
wsgi根据请求调用django工程的某个文件或函数，处理完后django将返回值交给wsgi，
wsgi将返回值进行打包，转发给uWSGI，
uWSGI接收后转发给nginx,nginx最终将返回值返回给客户端(如浏览器)。
*注:不同的组件之间传递信息涉及到数据格式和协议的转换
作用:
1. 第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程；
2. 在nginx上加上安全性或其他的限制，可以达到保护程序的作用；
3. uWSGI本身是内网接口，开启多个work和processes可能也不够用，而nginx可以代理多台uWSGI完成uWSGI的负载均衡；
4. django在debug=False下对静态文件的处理能力不是很好，而用nginx来处理更加高效。

三、安装与配置

首先，确保你已经安装好了nginx并可以正常使用。
其次，确保自己安装完成了python，并已经完成了pip的安装。如果没有，请先安装。
接着，别忘了确认自己项目所需的django已经完成安装并正常工作。
没有的话参考以下命令安装django , 建立一个工程或利用已经写好的工程，打开浏览器，输入部署地址(如:http://127.0.0.1:8000/)(或http://内网ip:8000、或http://外网ip:8000)测试，确认是否可正常打开浏览。

安装:sudo pip install django==1.10
测试:python manage.py runserver 0.0.0.0:8000
上面的工作都完成了，接着安装uWSGI

sudo pip install uwsgi
测试uWSGI: 新建文件test.py，写入以下内容

def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return "Hello World"
运行

sudo uwsgi --http 0.0.0.0:8000 --wsgi-file test.py
如果端口占用，使用

lsof -i :8000
列出占用端口的程序的pid号，并使用以下命令杀掉所有占用端口的程序

sudo kill -9 pid
然后浏览 http://127.0.0.1:8000(或http://内网ip:8000、或http://外网ip:8000)查看效果，有”Hello World”输出即安装成功。

下一步，建立工程单独的nginx配置文件
首先确认自己准确的知道nginx的默认配置文件目录(nginx.conf)的路径，如果不清楚，请使用如下命令获取:

nginx -t
大概会列出以下类似信息:

nginx: the configuration file /etc/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/conf/nginx.conf test is successful
里面说明了nginx默认配置文件的路径是:/etc/nginx/conf/nginx.conf；

然后，确保nginx.conf的同目录下有uwsgi_params文件(/etc/nginx/conf/uwsgi_params)，没有的话根据链接获取， 后面要用到。

在自己的工程目录下，建立如destiny.conf（/wwwroot/destiny/destiny.conf）的配置文件；复制nginx.conf里面全部的内容，全部写入destiny.conf中。
然后按照下面写的，把destiny.conf配置文件中的server段部分全部替换掉。

server {
listen 80;
server_name localhost;
charset utf-8;
access_log /wwwroot/destiny/nginx_access.log;
error_log /wwwroot/destiny/nginx_error.log;
client_max_body_size 75M;


location /static {
alias /wwwroot/destiny/destiny/static;
}

location / {
include /etc/nginx/conf/uwsgi_params;
uwsgi_pass 127.0.0.1:9090;
}
}
其中的 listen 80代表服务器开放80端口；
location [目录名]代表项目路径的引导;
access_log 和error_log是定义nginx访问日志和错误日志的存放路径。
“location /static”中的”/static”是自己定义的项目引用静态文件时，浏览器中显示的静态资源所在的根目录名;这样的话，用户在浏览器中查看到的所有image、css或js资源都是处在http://127.0.0.1/static下的。
django静态文件的绝对路径是根据自己的实际情况来确定的，一般在自己的django的app名/static目录下,或自己python manage.py collectstatic后的路径下。像我的是在/wwwroot/destiny/destiny/static根目录下。
“location /”是指访问项目根目录时，nginx要做的事。其中需要指定 uwsgi_params文件的绝对路径，上面已经提到了；如果还有media文件之类的静态目录，仿照static的写法，自己补充。
127.0.0.1:9090是指uWSGI绑定的监听地址，这里使用了9090端口。
需要注意的是，请确认自己django的静态文件目录所有者是www用户，如果不是，请用以下命令更改静态目录权限归属者:

sudo chown -R www:www /wwwroot/destiny/destiny/static
下面接着建立uWSGI的配置文件，在自己工程目录下创建uwsgi.ini文件,写入以下内容

[uwsgi]
socket = 127.0.0.1:9090
chdir=/wwwroot/destiny
module=destiny.wsgi
master = true
processes=2
threads=2
max-requests=2000
chmod-socket=664
vacuum=true
daemonize = /wwwroot/destiny/uwsgi.log
其中的socket字段值”127.0.0.1:9090”必须要和上面写的density.conf配置文件中的uWSGI监听地址完全一样;
chdir指自己工程的绝对路径;
module指的是wsgi.py在自己工程中的相对路径，”.”指代一层目录;我的django工程的wsgi.py文件是在”/wwwroot/destiny/destiny/wsgi.py”，所以写成destiny.wsgi;
daemonize指定uWSGI日志的存储路径。

好了，现在理一下路径:

工程路径: /wwwroot/destiny
工程静态文件路径: /wwwroot/destiny/destiny/static
wsgi.py的路径: /wwwroot/destiny/destiny/wsgi.py
uwsgi.ini的路径: /wwwroot/destiny/uwsgi.ini
uwsgi日志路径: /wwwroot/destiny/uwsgi.log
destiny.conf的路径: /wwwroot/destiny/destiny.conf
uwsgi_params的路径: /etc/nginx/conf/uwsgi_params
nginx访问日志路径: /wwwroot/destiny/nginx_access.log
nginx错误日志路径: /wwwroot/destiny/nginx_error.log
可以发现，我几乎把所有有关工程的配置文件和日志文件都放在工程目录下了，方便后期维护与查错。
启动uWSGI

sudo uwsgi --ini /wwwroot/destiny/destiny.ini
启动nginx
在这之前，我们要先去nginx配置文件的根目录拷贝mime.types(/etc/nginx/conf/mime.types)到工程目录(/wwwroot/destiny/mime.types)，和destiny.conf放在一起。
否则用配置文件启动nginx会报错:

nginx: [emerg] open() "/**/**/**/mime.types" failed (2: No such file or directory)
当然，如果不想拷贝mime.types文件，也可以将配置文件中“include mime.types;”一项，改成绝对路径“include /etc/nginx/conf/mime.types;”
如果nginx已经开启，先关闭nginx(service nginx stop或nginx -s stop)，再执行以下命令:

nginx -c /wwwroot/destiny/destiny.conf
这里的-c 表示加载配置文件启动

四、后记

到这里，工作基本就做完了，可以打开浏览器，输入自己项目的IP地址，如http://127.0.0.1/查看效果了。

 

如果启动时就报错，查看终端信息，解决错误。
如果终端没有报错，但是浏览时出现500、502等错误，就去项目目录查看nginx日志和uWSGI日志，解决错误。

自己在部署时，遇到很多坑，网上的教程大多附带virtualenv和supervisor的部署，但是连最基本的部署都说不明白，部署出来的东西性能再好也没指导意义。基于自己踩坑脱坑的过程，写下此文。

正如以上所说，我只是用单独的一个conf文件，在nginx上部署了一个工程，没有说明部署多个工程的问题；也没有使用virtualenv开发环境、使用supervisor来管理进程等。请根据个人爱好和需要去实践扩展。

 

 

 

　　

　　

　　

　　

 

　　

 

posted @ 2019-08-26 09:19  kiko0o0  阅读(425)  评论(0)  编辑  收藏  举报