Nginx+uWSGI+Django部署web服务器

Nginx+uWSGI+Django部署web服务器

环境说明

进行本文操作前需己搭建好的环境
- linux系统，我用的是openSUSE
  - 使用了operation用户的家目录做为测试环境
- python3.5.6
- virtualenv 16.0
- pip3 18.0
- nginx 1.13.1
后面进行安装的环境
- django 1.11
- uwsgi-2.0.17.1

前言

在多年前，基于python的web项目，常见的部署方法有：

fcgi：用spawn-fcgi或者框架自带的工具对各个project分别生成监听进程，然后和http服务互动。
wsgi：利用http服务的mod_wsgi模块来跑各个project。

不过uwsgi出现后，大部份部署就不会使用以上的两个协议了。

因为uwsgi它既不用wsgi协议也不用fcgi协议，而是自创了一个uwsgi的协议，据作者说该协议大约是fcgi协议的10倍那么快。uWSGI的主要特点如下：

超快的性能。
低内存占用（实测为apache2的mod_wsgi的一半左右）。
多app管理。
详尽的日志功能（可以用来分析app性能和瓶颈）。
高度可定制（内存大小限制，服务一定次数后重启等）。

所以在uwsgi协议的基础上，配合nginx来做python（类如django的框架）的web项目部署就很常见了。

uwsgi 实际上也是一个 http 服务器，只不过它只面向 python 的网络应用程序。

虽然 uwsgi 也是 http 服务器，但是却不便直接使用它部署 python web 应用程序。

uwsgi 所扮演的的角色是后端 http 服务器，nginx 扮演的角色是前端 http 服务器，django项目是客户所真正要访问到的提供数据方。用户从网页浏览器中发出请求，nginx 服务器收到请求后，会通过它的 uwsgi 模块将用户的请求转发给 uwsgi 服务器，uwsgi 服务器通过django处理完毕后将结果返回给 nginx，浏览器将最终的结果展现给用户。

搭建项目

建立一个虚拟环境
- 建议个人学习和测试的话，直接建在家用户目录下，以避免权限引起的各种拒绝问题
- 或者正式点，系统再建一个dev用户，在专门的工作目录下给好dev用户的权限去运行。
- 虚拟环境的目录名建议就带个env点明是虚拟环境，如果和后面的项目取相同的名字你会看到三重同名的串在一起，有点不太好认。
  
  virtualenv -p python3 py3env
启动虚拟环境

source py3env/bin/activate
安装django1.11，之所以装这个版本是学习所需要，后面自己的项目最好与时俱进。

pip install django==1.11
直接使用django-admin命令创建一个django项目
- 建议不要放在py3env目录下，而是在专门的工作目录下建立
  
  django-admin startproject luffy

如下，己经初步搭建好简单的项目：

cd luffy
(py3env) operation@opensuse-wordpress:~/work/luffy> tree -L 2
.
├── luffy
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

创建新应用，例如app01

python3 manage.py startapp app01

结构如下

(py3env) operation@opensuse-wordpress:~/work/luffy> tree -L 2
.
├── app01
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── luffy
│   ├── __init__.py
│   ├── __pycache__
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

Django部署

编辑`luffy/luffy/settings.py`

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = False
ALLOWED_HOSTS = ['*', ]
# Application definition
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'app01',
]

如上，主要是：

将DEBUG由True改成False（虽然只是在学习和测试搭建的，也要顾及好安全）
在ALLOWED_HOSTS 默认的空列表中填入你自己打算使用的域名，我这里测试的时候填的是*，真正上线部署的时候不建议填成通配符的*，而是要填允许访问的主机域名。一般django用于做后端服务器，而前端会有一个域名。详情可见django官方文档。
INSTALLED_APPS 列表下增加appo1，表示将app01应用给安装注册上。
补充，后面配置好nginx和新建好域名之后，我将ALLOWED_HOSTS = ['*', ]修改成ALLOWED_HOSTS = ['luffy.tielemao', ]了，通过域名访问仍然正常。而直接敲ip地址则会报400错误。

编辑`luffy/app01/views.py`

from django.shortcuts import render,HttpResponse
# Create your views here.
def index(request):
    return HttpResponse('Hello Hero')

由于只是简单演示，所以上面只是让用户访问index页面后，得到一个显示Hello Hero的页面。

编辑`luffy/luffy/urls.py`

from django.conf.urls import url
from django.contrib import admin
from app01 import views
urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^index/', views.index),
]

运行并测试

首先是运行，由于是单独对django进行运行测试，所以只是在进入项目根目录后命令行敲以下命令：

python manage.py runserver 0.0.0.0:8083

其中0.0.0.0表示捆绑监听服务器上的所有网卡IP地址，当然也就包括了127.0.0.1和外网的公网ip了。

最初我测试的是ALLOWED_HOSTS填的允许的HOSTS是自己的域名.tielemao.com，结果直接在浏览器上敲IP加8083端口接index当然是报错：

Bad Request（400）而由于我将DEBUG值设为了False，所以也不会将调试信息暴露出来。

然后我将.tielemao.com改为了通配符*(不安全，表示允许所有主机头）。

再访问http://39.x.x.x:8083/index/的时候，就能正常访问到了：

注意，我使用的是8083端口并且在防火墙和云控制平台上的安全组处己设置了开放该端口。

django能运行无误后，ctrl+c将它停止，再接下来做下面的操作。

uWSGI部署

同样为了环境的隔离和纯净，这次我也选择在同样的虚拟环境下安装：

pip3 install uwsgi

安装完成后可uwsgi --version查看版本，

uwsgi --python-version还可以间接查看到python的版本。

编写一个用于简单测试uwsgi的python脚本

vim test-uwsgi.py，内容如下：

def application(env,start_response):
    start_response('200 OK',[('Content-Type','text/html')])
    return [b"Hello Hero, all for one "]

测试运行uWSGI

以下命令表示运行uwsgi服务，同样是在8083端口上开放web访问。

注意--http 后是一个空格再接:端口号。

uwsgi --http :8083 --wsgi-file test-uwsgi.py

访问web服务器8083端口，正常显示test-uwsgi.py脚本中返回显示的文本。

因为我们现在要做的是基于nginx和uwsgi部署django，从客户端发起请求到服务器响应请求，会经过一下几个环节：

the web client <-> the web server(nginx) <-> the socket <-> uwsgi <-> Django

而单独测试uWSGI运行，访问显示正常的话，说明下面3个环节是通畅的：

the web client <-> uWSGI <-> Python

ctrl+c中止程序，再来进行以下的测试。

使用uWSGI运行django项目

在虚拟环境下，进入到django根目录下后敲以下命令：

 uwsgi --http :8000 --module luffy.wsgi

效果和直接敲以下命令

python manage.py runserver 0.0.0.0:8000

是一样的。

注：--module luffy.wsgi为加载指定的wsgi模块，你项目起的是什么名字，一般就是项目名.wsgi。

这样测试下来，可证明web客户端通过uWSGI到Django是通畅的：

the web client <-> uWSGI <-> Django

ctrl+c中止程序，再来进行以下的测试

uWSGi热加载Djangoa项目

在启动命令后面加上参数：

uwsgi --http :8083 --module luffy.wsgi --py-autoreload=1

同样，这个时候访问服务器8083端口，也就是访问了django项目（luffy）。

而且还多了一个参数：

--py-autoreload 监控python模块以触发重载(仅在开发中使用)

# 类似的发布命令
/home/operation/work/py3env/bin/uwsgi --http 0.0.0.0 :8000 --chdir /home/operation/work/luffy --module luffy.wsgi
# 此时修改django代码，uWSGI会自动加载django程序，页面生效
# 除此外，还可以接上很多参数

ctrl+c中止程序，再进行下面环节：

部署nginx

nginx配置uwsgi和django

将uwsgi_params文件拷贝到项目文件夹下。
uwsgi_params文件一般在/etc/nginx/目录下，也可以从nginx的github页面下载。

uwsgi_params配置文件如下：

uwsgi_param  QUERY_STRING       $query_string;
uwsgi_param  REQUEST_METHOD     $request_method;
uwsgi_param  CONTENT_TYPE       $content_type;
uwsgi_param  CONTENT_LENGTH     $content_length;
uwsgi_param  REQUEST_URI        $request_uri;
uwsgi_param  PATH_INFO          $document_uri;
uwsgi_param  DOCUMENT_ROOT      $document_root;
uwsgi_param  SERVER_PROTOCOL    $server_protocol;
uwsgi_param  REQUEST_SCHEME     $scheme;
uwsgi_param  HTTPS              $https if_not_empty;
uwsgi_param  REMOTE_ADDR        $remote_addr;
uwsgi_param  REMOTE_PORT        $remote_port;
uwsgi_param  SERVER_PORT        $server_port;
uwsgi_param  SERVER_NAME        $server_name;

拷贝到项目下：

sudo cp /etc/nginx/uwsgi_params /home/operation/work/luffy/
属主属组等权限重新修改

sudo chown operation:operation uwsgi_params
sudo chmod 664 /home/operation/work/luffy/uwsgi_params

在项目文件夹下创建文件luffy_nginx.conf,填入并修改下面内容：

# luffy_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:8083;
    # 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 luffy.tielemao.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 /home/operation/work/luffy/media;
        # your Django project's media files - amend as required
    }
    location /static {
        alias /home/operation/work/luffy/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     /home/operation/work/luffy/uwsgi_params;
        # the uwsgi_params file you installed
    }
}

这个配置文件告诉nginx从文件系统中拉起media和static文件作为服务，

同时响应django的request。

为此，我也在相应的项目目录下先建立起media和static文件夹。

为方便nginx使用，我在/etc/nginx/vhosts.d下创建了一个luffy_nginx.conf的软链接。当然，也有人是直接用默认的sites-enabled目录，自己看着来就行了。

sudo ln -s /home/operation/work/luffy/luffy_nginx.conf luffy.conf

django部署static文件

在项目文件夹下，建立好静态文件目录：

mkdir static
django的setting文件中，添加一行：

STATIC_ROOT = os.path.join(BASE_DIR, “static/”)
运行

python manage.py collectstatic
在项目文件夹下，建立一个media媒体文件目录（用于存放图片音乐等文件做测试）

mkdir media

在media目录中，我传入了一个图片文件princekin_fox.jpg用于测试nginx。

参数STATIC_ROOT用在哪？

通过python3 manage.py collectstatic 收集所有你使用的静态文件保存到STATIC_ROOT！

STATIC_ROOT 文件夹是用来将所有STATICFILES_DIRS中所有文件夹中的文件，以及各app中static中的文件都复制过来，把这些文件放到一起是为了用nginx等部署的时候更方便。

重新加载nginx进行测试

先进行检测，看之前的配置文件有无错误。

sudo /usr/sbin/nginx -t

重新加载nginx让软链接的luffy_nginx.conf生效。

sudo /usr/sbin/nginx -s reload

访问http://luffy.tielemao.com:8000/media/princekin_fox.jpg看能否正常访问到图片资源：

注意在做这一步之前，我是己经配置好域名和传送了一个用于测试的图片到服务器上。

我己经能成功访问到资源了，所以接下来再做下一步测试。

测试nginx 应用 uWSGI 和 test.py

还记得之前写好的一个测试的test-uwsgi.py文件吗？

我们就用配置好的nginx来访问uwsgi启动的test-uwsgi.py好了。

首先，启动uwsgi，并且端口是nginx配置中的负载均衡池8083端口：

uwsgi --socket :8083 --wsgi-file test-uwsgi.py

访问http://luffy.tielemao.com:8000/，实际上访问的就是uwsgi的8083端口。

如上图，能正常访问。表明下面的环节通畅：

the web client <-> the web server <-> the socket <-> uWSGI <-> Python

测试成功后中止程序，以便进行下面环节。

用UNIX socket取代TCP port

修改luffy_nginx.conf：

# luffy_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
    server unix:///home/operation/work/luffy/luffy.sock;
    # for a file socket
    # server 127.0.0.1:8083;
    # for a web port socket (we'll use this first)
}

上面其实是将原来的server 127.0.0.1:8083加以注释，而原来加了#注释的server unix:///home/operation/work/luffy/luffy.sock则取消了注释，也就是不是直接指定端口，而是指定了一个sock文件。

要注意的是，这个luffy.sock并不是自己提前写好的什么配置文件，而是由程序自动生成的。如图：

重新加载nginx，然后在项目下运行uWSGI

uwsgi --socket /home/operation/work/luffy/luffy.sock --wsgi-file test-uwsgi.py

访问http://luffy.tielemao.com:8000/ 报502网关错误。

检查nginx的错误日志error.log，一般位置会在/var/log/nginx/error.log，建议使用tail察看文件尾部的后10行。

会发现类似以下报权限受阻的错误：

2018/08/27 20:17:44 [crit] 25771#25771: *1847865 connect() to unix:///home/operation/work/luffy/luffy.sock failed (13: Permission denied) while connecting to upstream, client: 223.72.74.11, server: luffy.tielemao.com, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///home/operation/work/luffy/luffy.sock:", host: "luffy.tielemao.com:8000"

那么就中止uwsgi进程，添加上socket权限后再次运行：

uwsgi --socket /home/operation/work/luffy/luffy.sock --wsgi-file test-uwsgi.py --chmod-socket=664

还是报错的话，就需将operation用户添加到nginx组中了，当然某些系统中nginx组也可能是www-data。

将operation用户添加到nginx组中，记得要加上-a参数，不然operation将会离开原来的operation组。

sudo usermod -a -G nginx operation

然后将项目目录也归属到nginx组中

sudo chown operation:nginx -R luffy

这样就能保证nginx能对luffy.sock有足够的权限了。

果然，设置好权限后，就能正常访问了。

每次都运行上面命令来拉起django项目实在不方便，我们可以将这些配置写在.ini文件中，能大大简化工作。

停掉uwsgi服务后，见下一环节。

uwsgi部署加强

使用uwsgi配置文件运行django项目

uwsgi支持ini，xml等多种配置方式，以ini为例，在/home/operation/work/conf目录下新建uwsgi_luffy.ini，示例配置如下：

# luffy_uwsgi.ini file
[uwsgi]
# Django-related settings
# the base directory (full path)
# 指定运行目录，其实就是项目的根目录
chdir = /home/operation/work/luffy
# Django's wsgi file
# 导入django项目的wsgi模块
module = luffy.wsgi:application
# 载入wsgi-file
wsgi-file = luffy/wsgi.py
# the virtualenv (full path)
# 配置虚拟环境python相关依赖包所在路径
home = /home/operation/work/py3env
# 补充，uwsgi启动时的用户和用户组,注意要按你自己的实际权限进行配置
# 我这边是因为项目属主是operation，而operation我设置了添加进了nginx组
# 但这种情况下uid仍不能设置nginx，除非你的项目目录所有文件属主都改为了nginx
uid = operation
gid = nginx
# process-related settings
# 开启master主进程
master = true 
# maximum number of worker processes
# 开启多少个进程数，workers项也等同processes
# threads项则是设置运行线程，测试倒不用设置上线程
processes = 4
# the socket (use the full path to be safe)
# 设置使用的socket端口或socket地址
# socket = 0.0.0.0:8000
# 上面的socket建议配置成一个luffy.socket文件后使用nginx来连接uWSGI运行,不然容易报socket的请求头错误和权限错误等。
socket = /home/operation/work/luffy/luffy.socket
# ... with appropriate permissions - may be needed
# 配置生成的sock文件的权限
chmod-socket = 664 
# clear environment on exit
＃ 退出时清空环境，其实就是将自动生成的luffy.sock和相关pid文件给干掉。
vacuum = true

uwsgi指定配置文件启动django项目，建议使用nginx用户执行：

uwsgi --ini /home/operation/work/conf/uwsgi_luffy.ini

注：以上启动后如果你是在配置文件中直接指定的socket = 0.0.0.0:8000可能会产生如下问题:浏览器访问服务器8000端口加上url后，浏览器会报连接出错，而服务器运行后台也会看到如下错误信息：

invalid request block size: 21573 (max 4096)...skip

之前我们直接使用http协议的方式就不会出现块请求大小超出

 uwsgi --http :8000 --module luffy.wsgi

究其原因，使用配置文件启动是以socket方式提供通信端口，默认的协议是tcp，和http不同。socket请求头默认大小是4096，所以请求头超出默认大小后就会出现错误。当然后面我们可以通过和nginx合作的方式解决。

而如果只是想测试，那么只要在上面的命令后面再指定块请求大小-b 24576之类的便可以解决。

我们中止uwsgi后重新指定块大小，运行命令：

uwsgi -b 24576 --ini /home/operation/work/conf/uwsgi_luffy.ini

可以解决请求头错误。

不过ini配置文件主要是用于和nginx配合，这也是为什么前面讲述完nginx的部署后再回过头来讲uwsgi的ini配置文件。

将uWSGI中使用的相同选项放入一个配置文件中，然后要求uWSGI使用该文件运行。这会使得管理配置变得更加容易。
要注意的是，因为要配合nginx，所以生成的项目名.sock文件，nginx需要能有权限读写。

如下图：

由于我前面执行uwsgi命令时使用的是operation用户，

这样子自动生成的luffy.sock文件属组并不是nginx的，所以ini配置文件中最好加上uid和gid的配置项使用nginx用户执行uwsgi。

# uwsgi启动用户名和用户组
uid = operation
gid = nginx

我是修改完luffy.sock的属组为nginx后就能正常访问到django项目了，不然会被nginx报502错误。

安装uWSGI到真实环境中

到目前为止，我们都是在虚拟环境下工作的，接下来介绍将uwsgi装在实际环境中，且将uwsgi加入到nginx组（有的是www-data组)中，就可避免现在所遇到的权限等问题。

退出虚拟环境

deactivate
安装uWSGI，注意要使用python3中的pip3来进行安装。我系统中是python2.7和python3.5.6共存的，不过默认的环境是2.7。

sudo /usr/local/python3.5.6/bin/pip3 install uwsgi
之前我使用默认的pip进行安装，结果是python2版本的uwsgi，在运行虚拟环境中的python3的django项目时会报以下错误：

Python version: 2.7.13 (default, Jan 03 2017, 17:41:54) [GCC]
Set PythonHome to /home/operation/work/py3env
ImportError: No module named site
VACUUM: unix socket /home/operation/work/luffy/luffy.sock removed.

报模块导入错误，原因还是在于我真实环境使用的是python2.7版本的原因，ini中配置了虚拟环境家目录是python3的依赖库，pip安装的uwsgi不能正确导入。

再次检查，在真实环境中是否能如同虚拟环境之前一样能运行django项目。

当然，由于我前面的python3没有导入系统环境中，所以此处仍然要像前面使用python3的pip3一样，需要打全路径：

sudo /usr/local/python-3.5.6/bin/uwsgi --ini /home/operation/work/conf/uwsgi_luffy.ini

模块无法导入的错误己排除了，但是还会报一个bind绑定拒绝的错误。

出现这个错误还是和文件权限有关，因为我之前uwsgi的ini配置文件中uid设置的用户是nginx，而项目真正的属主是operation这个用户，所以我将uid设置回operation就解决问题了，当然将项目整个属主设为nginx用户也是可行的。

# 因为权限问题踩了不少坑，在此继续加强强调。
# 注意的是你要按自己的实际环境配置
uid = operation
gid = nginx

成功运行uwsgi的截图我也放出给大家对比一下看吧。

当然，访问页面成功的截图就不放了，和之前测试成功的是一样的。

uwsgi配置文件更多参数

前面己经给大家看到了uwsgi的ini文件的一些配置参数，在此以luffy项目为例，再介绍一些常用到的参数：

# set an environment variable
# 设置变量环境，其实就是应用上django项目中的settings
env = DJANGO_SETTINGS_MODULE=luffy.settings
# create a pidfile
# 创建pid文件，注意权限，所以一般放置在tmp目录下
pidfile = /tmp/project-master.pid 
# background the process & log
# 后台运行，有用，基本都会设置上，同时还会输出日志
daemonize = /var/log/uwsgi/luffy.log 
# 以固定的文件大小（单位kb），进行切割日志
# 下例为50M大小一个日志文件
log-maxsize = 50000000
# 不记录请求信息的日志。只记录错误以及uWSGI内部消息到日志中。
disable-logging = true
#
# 在指定的地址上，开启状态服务。应该就是你访问该地址，就能看到整个uwsgi
的状态，类似nginx也有。所以一般会只在环回地址上开放。
stats = 127.0.0.1:8009
# 以下都是一些性能和资源上的限制和调配
# respawn processes taking more than 20 seconds
harakiri = 20
# limit the project to 128 MB
# 控制进程的总内存量
limit-as = 128
# respawn processes after serving 5000 requests
max-requests = 5000

访问stats状态服务页面大致如下：

uWSGI开机启动服务

继续以django的luffy项目为例，让uWSGI开机就启动服务，编辑文件/etc/rc.local, 添加下面内容到这行代码之前exit 0:

/usr/local/python-3.5.6/bin/uwsgi --ini /home/operation/work/conf/uwsgi_luffy.ini

要注意的是记得ini配置文件中设置好用户用户组，sock文件，sock文件的权限和后台运行等配置。

end

by 铁乐与猫

参考