提供：ZStack云计算
前言
我们在之前的《Python Web服务器对比》文章中介绍过，uWSGI是一个宏大的项目，它能做的事情远远超过提供Web服务。不过很多Web应用的部署仍然青睐于它，因为它功能丰富，容易配置，而且跟Nginx配合的很好。
本文将深入介绍uWSGI的安装，以及在上面部署各种Python框架应用的步骤，无论是中小规模的部署还是生产环境的大规模部署都有所涉及。
本文还将同时介绍Nginx的相关配置（以及原理）。Nginx与uWSGI能够默契配合，针对大多数应用部署都是极好的选择。
了解uWSGI和Nginx的用法
uWSGI是一个充满野心的项目，它提供了各式各样的工具，其功能远远超过了Web应用托管的需求。多年以来，它已经成为了很多系统管理员和开发者们必不可少的工具之一。
Nginx自从0.8.40版本以来开始支持uwsgi协议，从此，在uWSGI上运行的WSGI应用就可以以最佳的方式与Nginx进行通讯，在配置的灵活性和性能方面都十分出色，使得该组合成为很多部署场景下的极佳选择。
uWSGI概述
以下是从《Python Web服务器对比》一文中摘抄的段落：
“虽然uWSGI的命名规范有点让人摸不着头脑，不过它是一个包含众多组件的大项目，致力于为托管服务提供一整套解决方案。uWSGI server作为其组件之一提供了运行Python WSGI应用的功能，该组件支持多种协议，包括其自家的uwsgi wire协议——可以说是SCGI的对应。应对在应用服务器之前使用独立HTTP服务器的需求，NGINX和Cherokee web服务器进行了模块化以支持uWSGI自家的uwsgi协议（该协议在uWSGI上是性能最好的），如此可以直接控制其进程。”
uWSGI的亮点
- uWSGI提供了WSGI适配器，如此可以完全支持运行在USGI上的Python应用。
- uWSGI提供了libpython。它在启动时加载应用代码并提供Python解释器的功能，对进来的请求进行语法分析以调用Python callable。
- uWSGI内置NGINX支持（以及Cherokee+和lighttpd支持）。
- uWSGI采用C语言编写。
- 由于uWSGI组件众多，所以如果需要扩展功能的时候会比较方便。
- 项目处于活跃状态，更新周期很快。
- 它提供了不同的应用引擎（异步、同步都支持）。
- 它占用的内存比较少。
配合Nginx进行Web应用部署
Nginx是一个高性能的web服务器/代理服务器/反向代理服务器，因为其轻量、易用和可扩展性（插件）而广受欢迎。其架构的设计使得它具备很强的请求处理能力（理论上是无限的），以至于一些大流量的网站几乎没有其他选择。
注：“处理”连接的技术含义是不丢弃并返回一些结果，一次成功的返回也可能是一条错误信息。要返回用户期待的结果，还需要应用和数据库方面能够保持正常工作。
uWSGI配合Nginx反向代理
很多框架和应用服务器都可以对静态文件的请求（如JavaScript、CSS、图片等）返回来自应用的响应，不过更好的做法是用反向代理服务器（比如Nginx）来处理此类请求，减轻应用服务器的负载，获得更好的性能。
随着应用扩大，可能会需要分布到不同的服务器（云主机）上，此类需求在早期可以用反向代理实现。
此外，Nginx的可扩展性（除了缓存之外，还有failover等其他机制）对于一些比较复杂的Web应用也很有帮助。
一个简单的服务器架构：
客户端请求 ----> Nginx (反向代理)
|
/|\
| | `-> App. Server I. 127.0.0.1:8081
| `--> App. Server II. 127.0.0.1:8082
`----> App. Server III. 127.0.0.1:8083注：只监听127.0.0.1的应用只能从本地访问，而如果设置成0.0.0.0就能够从外部访问了。
针对生产环境预备云主机
云主机的预备将执行如下步骤：
- 更新操作系统
- 下载安装通用Python工具（pip、virtualenv等）
- 创建应用运行的虚拟环境（提供了uWSGI等依赖）
有关Python工具的安装可参考这篇文章。
更新操作系统
以下操作将在一台新建的云主机上进行。如果你打算在一台经常使用的云主机上操作，我的建议是切换到一台新主机上。
Debian类系统（Ubuntu、Debian等）的更新：
aptitude update
aptitude -y upgradeRHEL类系统的更新：
yum -y update安装配置Python、pip和virtualenv
CentOS/RHEL系统默认状态下是比较裸的，大部分工具都需要自己安装（比如通过yum）。这里有一篇文章介绍如何在CentOS 6.4和5.8上安装Python 2.7.6和3.3.3。
Ubuntu和Debian的最新版本默认包含了Python解释器，我们只需要安装下面的这些软件包就行：
- python-dev（开发工具）
- pip（包管理工具）
- virtualenv（用于创建隔离的虚拟环境）
python-dev
python-dev是系统级的软件包，包含了用于构建Python模块的开发工具。
使用aptitude进行安装：
aptitude install python-devpip
pip软件包管理器可用于安装我们需要的应用。
运行如下命令以安装pip（需要sudo权限）：
curl https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py | python -
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python -
export PATH="/usr/local/bin:$PATH"virtualenv
每个Python应用最好是跟它的依赖项一起在一个独立的环境下运行。针对一个环境，最简单的描述方式就是一个独立的路径。virtualenv就是应对环境管理的需求而诞生的工具。
使用pip安装virtualenv：
sudo pip install virtualenv创建独立的虚拟（Python）环境
我们将创建一个环境用于我们的应用部署。如果你之前在本地开发机上的Python应用还没有设置过virtualenv，我建议你创建一个环境，将你的应用以及其依赖项都转移到该环境下。
首先创建一个目录。目录的命名按照自己的需求来，这里使用my_app作为命名。
mkdir my_app进入该目录，创建一个新的虚拟环境。这里使用my_app_venv作为该环境的命名，你可以根据自己的需要进行命名：
cd my_app
virtualenv my_app_venv创建一个目录用于存放Python应用模块：
mkdir app在虚拟环境中激活解释器：
source my_app_venv/bin/activate至此，你的目录结构应该是这样的：
my_app # 主目录
|
|=== my_app_venv # 虚拟环境目录，包含Python解释器
|=== app # 应用模块所在目录
|..
|.下载安装uWSGI
应用管理的最佳实践之一是在虚拟环境下包含所有的应用依赖项，所以我们之后的下载安装都要在刚才创建的环境中进行。
在刚才的虚拟环境目录下执行安装操作，软件会安装在该虚拟环境下。如果执行安装操作时不在任何虚拟环境下，则会全局生效，而这是我们不想要的。请随时记得使用virtualenv。
用pip安装uWSGI：
pip install uwsgi下载安装Nginx
CentOS/RHEL用户可参考这篇文章用yum安装Nginx。Ubuntu/Debian用户请执行如下命令（也可参考这篇文章）：
sudo aptitude install nginx然后启动nginx：
sudo service nginx startNginx服务可通过如下命令停止：
sudo service nginx stop以及重启（每次更改Nginx配置后都需要重启）：
sudo service nginx restart用uWSGI托管Python WSGI应用
uWSGI的用法跟其他应用容器没有太大差别，它需要你的应用提供一个接入点（callable）。在启动时，这个callable与其他的配置变量一起被传递给uWSGI，然后uWSGI开始工作。当请求到达uWSGI时，它对请求进行处理，然后将结果传递给应用控制器。
架构：
........
/|\
| | `-> App. Server I. 127.0.0.1:8080 <--> Application
| `--> App. Server II. 127.0.0.1:8081 <--> Application
.....WSGI
WSGI是web服务器和应用之间的一个接口，以确保不同的服务器和应用（框架）之间的通讯满足一组标准，从而满足兼容性的需求（比如从生产环境切换到生产环境的场景）。这在现代软件开发中很有必要。（有关WSGI的详细说明可参考这篇文章。）
WSGI应用对象（Callable）：“wsgi.py”
如上所述，运行在WSGI上的Web服务器需要一个应用对象（也就是你的应用的callable）。大部分框架和应用会包含一个wsgi.py作为这个对象。
下面，我们会创建一个wsgi.py，将其导入应用以提供给uWSGI。你也可以使用其他的文件名，不过wsgi.py是最常用的（比如Django使用的就是这个文件名。）
创建wsgi.py文件（我使用nano，你可以使用自己习惯的编辑器）：
nano wsgi.py将基本的WSGI应用代码复制粘贴到该文件内（此处是最基本的示范文件，到时候你需要把自己应用的内容替换进来）：
def application(env, start_response):
start_response('200 OK', [('Content-Type', 'text/html')])
return ["Hello!"]每次请求到达服务器时，服务器在解析URL的时候（比如 mysite.tld/controller/method/variable）都会使用这个callable来运行应用的请求处理器（也就是控制器）。
代码粘贴完毕后，保存退出。至此，你的应用目录应该是如下结构：
my_app # Main Folder to Contain Everything Together
|
|=== my_app_venv # V. Env. folder with the Python Int.
|=== app # Your application module
|
|--- wsgi.py # File containing application callable
|..
|.运行服务器
uWSGI的配置项众多，我们先从最简单的配置开始。
uWSGI的常规用法如下：
uwsgi [option] [option 2] .. -w [wsgi file with app. callable]从wsgi.py运行uWSGI：
uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi该命令会在前台运行服务，用CTRL+C快捷键停止。后台运行的命令如下：
uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi &注意：稍后配置Nginx的时候需要移除--protocol=http这一部分，否则Nginx和uWSGI之间会无法通讯。
应用在后台运行之后，我们需要进程管理器来对其进行管理。
管理uWSGI服务器进程
进程管理的命令列表如下：
- SIGHUP
-HUP正常重启worker和应用 - SIGTERM
-TERM强制重启 - SIGINT
-INT和 SIGQUIT-QUIT立刻终止所有worker - SIGUSR1
-USR1输出状态数据（stdout） - SIGUSR2
-USR2输出worker状态 - SIGURG
-URG从快照恢复 - SIGTSTP
-TSTP暂停或恢复一个实例的运行 - SIGWINCH
-WINCH唤醒之前被syscall阻塞的worker
示范：用SIGHUP重启服务
该命令按正常方式重启服务，即，它会等待worker完成当前的任务，然后将其终止。下次启动时会继承本次的配置。
kill -HUP [PID]
你也可以不使用PID，而使用pidfile选项通过文件控制进程。
示范：用SIGINT停止服务
服务和进程的停止需要INT信号，该命令会终止所有后台中运行的进程。
kill -INT [PID]
配置Nginx
接下来我们将配置Nginx以使其与uWSGI服务器对话。打开nginx.conf文件进行编辑：
sudo nano /etc/nginx/nginx.conf将如下内容复制粘贴到文件中以启用反向代理功能。（有关SSL证书的配置可参考这篇文章。）
针对Web应用的配置示范：
worker_processes 1;
events {
worker_connections 1024;
}
http {
sendfile on;
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 500;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/xml text/css
text/comma-separated-values
text/javascript
application/x-javascript
application/atom+xml;
# Configuration containing list of application servers
upstream uwsgicluster {
server 127.0.0.1:8080;
# server 127.0.0.1:8081;
# ..
# .
}
# Configuration for Nginx
server {
# Running port
listen 80;
# Settings to by-pass for static files
location ^~ /static/ {
# Example:
# root /full/path/to/application/static/file/dir;
root /app/static/;
}
# Serve a static file (ex. favico) outside static dir.
location = /favico.ico {
root /app/favico.ico;
}
# Proxying connections to application servers
location / {
include uwsgi_params;
uwsgi_pass uwsgicluster;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
}保存退出，运行如下命令重启Nginx以激活变更的配置：
sudo service nginx stop
sudo service nginx start有关Nginx配置的更多说明，可参考这篇文章。
配置uWSGI
uWSGI在启动时有多种方法接收必要的配置（如运行在哪个socket、进程的数量、主进程设置等），下面将介绍其中三种：
- 以参数方式传递配置变量
- 使用
.ini文件 - 使用
.json文件
注：uWSGI还提供了若干协议以将这些配置文件转换成stdin和HTTP。
方案1：以参数方式传递配置变量
最基础的方法，但容易造成混乱且不易管理。该方法的使用就跟其他shell脚本一样，将配置作为参数放到命令中。
用法：
# uwsgi [option] [option 2] .. -w [wsgi.py with application callable]
# Simple server running *wsgi*
uwsgi --socket 127.0.0.1:8080 -w wsgi
# Running Pyramid (Paster) applications
uwsgi --ini-paste production.ini
# Running web2py applications
uwsgi --pythonpath /path/to/app --module wsgihandler
# Running WSGI application with specific module / callable names
uwsgi --module wsgi_module_name --callable application_callable_name
uwsgi -w wsgi_module_name:application_callable_name更完整的列表可参考其官方文档页面。
方案2：使用.ini文件
使用.ini文件的方案可能比第一种好一些，此类文件的结构很容易理解，只需要每次uWSGI启动脚本执行的时候一起加载即可生效。
.ini文件示范（example_config.ini）：
[uwsgi]
# -------------
# Settings:
# key = value
# Comments >> #
# -------------
# socket = [addr:port]
socket = 127.0.0.1:8080
# Base application directory
# chdir = /full/path
chdir = /my_app
# WSGI module and callable
# module = [wsgi_module_name]:[application_callable_name]
module = app:application
# master = [master process (true of false)]
master = true
# processes = [number of processes]
processes = 5
..用法：
uwsgi --ini example_config.ini方案3：使用.json文件
Working with .json files is, apart from the structure, same as the examples shown above.
跟上面的用法差不多，只是文件结构不一样。
.json文件示范（example_config.json）：
{
"uwsgi": {
"socket": ["127.0.0.1:8080"],
"module": "my_app:app",
"master": true,
"processes": 5,
}
}用法：
uwsgi --json example_config.json有关uWSGI配置的更多信息可参考其官方文档页面。
uWSGI的常用配置
uWSGI默认是可以通吃各种框架/应用/平台的，不过有时候我们可能还是需要根据自己的需求指定一些配置。
根据uWSGI文档的说明，可能的配置组合几乎是无限的，本文只能讨论一些最常用的或者最关键的部分，并对其实现进行说明。
下面的示范是配合.ini文件使用的。使用.json文件的同学需要将其修改成json的格式。
Sockets
http-socket
设定uWSGI绑定的HTTP socket，如：
http-socket = :8080
socket
通过默认协议将uWSGI绑定到特定的socket，如：
socket = 127.0.0.1:8080
processes (workers)
设定可用于处理请求的进程数，如：
processes = 5
protocol
默认协议是uwsgi，这个配置项可以对其进行修改，如：
protocol = http
管理
master
用于启用或禁用uWSGI主进程。主进程可对其他接收请求的进程进行管理，这样有很多好处，比如无需打扰sockets就能优雅的重启workers，从而避免当机时间。配置方法：
master = true
max-requests
设定最大可以处理的请求数。如果你担心内存泄露而又没有更好的预防办法，可以考虑这个配置项。用法：
max-requests = 1001
threads
设定每个进程内运行的线程数量（rethread模式）。可以配合processes设置项使用以调整并发的规模。用法：
threads = 2
日志
disable-logging
关闭日志功能。用法：
disable-logging = true
uWSGI processes
procname
可自行设定进程名称，如：
procname = My Application
uid
指定uWSGI服务器运行的用户uid，如：
uid = 1001
gid
指定uWSGI服务器运行的用户组gid，如：
gid = 555
vacuum
退出时移除所有生成的pidfile/socket。
daemonize
将uWSGI设置为守护进程，并将信息写入指定的参数（也就是日志文件）。用法：
daemonize = /tmp/uwsgi_daemonize.log
pidfile
让uWSGI将进程的PID写入指定文件。对于uWSGI进程管理很有用。用法：
pidfile = /tmp/proj_pid.pid
其他
harakiri
设置一个进程在被终止或回收（一般由内存管理或进程管理服务触发）之前被允许存活的最大时间。用法：
harakiri = 30
针对上百个配置项的完整配置说明请参考官方文档。
延伸阅读：
防火墙
- Setting up a firewall using IP Tables
SSH加固
- How To Protect SSH with fail2ban on Ubuntu
- How To Protect SSH with fail2ban on CentOS 6
创建报警
- How To Send E-Mail Alerts on a CentOS VPS for System Monitoring
每日的访问日志监控
- How To Install and Use Logwatch Log Analyzer and Reporter