Python/WSGI应用快速入门¶
这个快速入门将会告诉你如何部署简单的WSGI应用和常见的web框架。
这里，Python指的是CPython，对于PyPy，你需要使用特定的插件： PyPy插件，Jython支持正在开发中。
注解
要遵循此快速入门，你至少需要uWSGI 1.4。更老的版本不再维护，并且有灰常多bug！
安装uWSGI以及Python支持¶
uWSGI是一个(大的)C应用，因此，你需要一个C编译器 (例如gcc或者clang)，以及Python开发头文件。
在基于Debian的发行版上，
apt-get install build-essential python-dev
就够了。
你有多种方式为Python安装uWSGI：
via pip
pip install uwsgi
使用网络安装器
curl http://uwsgi.it/install | bash -s default /tmp/uwsgi
(这将会把uWSGI二进制安装到 /tmp/uwsgi ，你可以随意修改它)。
通过下载源tarball文件，然后执行”make”命令
wget http://projects.unbit.it/downloads/uwsgi-latest.tar.gz
tar zxvf uwsgi-latest.tar.gz
cd
make
(构建之后，当前目录下，你会获得一个 uwsgi 二进制文件)。
未涵盖通过包发布来安装(不可能取悦所有人)，但是所有的一般规则都适用。
当使用发行版提供的包来测试这个快速入门时，你也许想要考虑一件事，就是非常有可能你的发行版本以模块化的方式构建了uWSGI (每个特性都是一个必须加载的不同插件)。要完成这个快速入门，你必须在第一个系列的例子前面加上 --plugin python,http ，以及当移除了HTTP路由器时加上 --plugin python (如果这对你没意义，那就请继续往下读)。
第一个WSGI应用¶
让我们从一个简单的”Hello World”开始：
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return [b"Hello World"]
(将其保存为 foobar.py)。
正如你所见，它由一个简单的Python函数组成。之所以称之为 “application”，是因为它是uWSGI Python加载器将会搜索的默认函数 (但你显然可以自定义)。
将其部署在HTTP端口9090¶
现在，启动uWSGI来运行一个HTTP服务器/路由器，它会传递请求到你的WSGI应用：
uwsgi --http :9090 --wsgi-file foobar.py
就这样。
注解
当你有一个前端web服务器，或者你正进行某些形式的基准时，不要使用 --http ，使用 --http-socket 。继续阅读快速入门来了解原因。
添加并发和监控¶
你想进行的第一个调整可能是增加并发性 (默认情况下，uWSGI启动一个单一的进程和一个单一的线程)。
你可以用 --processes 选项添加更多的进程，或者使用 --threads 选项添加更多的线程 (或者可以同时添加)。
uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2
这将会生成4个进程 (每个进程有2个线程)，一个master进程 (在Inc死掉的时候会生成它们) 和HTTP路由器 (见前面)。
一个重要的任务是监控。在生产部署上，了解正在发生的事情是至关重要的。stats子系统允许你将uWSGI的内部统计数据作为JSON导出：
uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
对你的应用进行几次请求，然后telnet到端口9191，你会获得大量有趣的信息。你可能想要使用”uwsgitop” (仅需 pip install 来安装它)，这是一个类似于top的工具，用来监控实例。
注解
绑定stats socket到一个私有地址 (除非你知道你在做什么)，否则，每个人都能够访问它！
将它放在一个完整的web服务器之后¶
即使uWSGI HTTP路由器是稳定并且高性能的，但是你或许想要将你的应用放在一个全功能的web服务器之后。
uWSGI原生支持HTTP, FastCGI, SCGI及其特定的名为”uwsgi”的协议 (是哒，错误的命名选择)。最好的协议显然是uwsgi，nginx和Cherokee已经支持它了 (虽然有各种Apache模块可用)
一个常用的nginx配置如下：
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:3031;
}
这表示“传递每一个请求给绑定到3031端口并使用uwsgi协议的服务器”。
现在，我们可以生成uWSGI来本地使用uwsgi协议：
uwsgi --socket 127.0.0.1:3031 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
如果你要运行 ps aux ，那么你会看到一个进程。已经移除了HTTP路由器，因为我们的“worker” (被分配给uWSGI的进程) 本地使用uwsgi协议。
如果你的代理/web服务器/路由器使用HTTP，那么你必须告诉uWSGI本地使用http协议 (这与会自己生成一个代理的–http不同):
uwsgi --http-socket 127.0.0.1:3031 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
开机自动启动uWSGI¶
如果你在想打开vi，然后写一个init.d脚本来生成uWSGI，那么请坐下(并且冷静下来)，先确保你的系统没有提供一个更好(更现代)的方法。
每个发行版本都选择了一个启动系统 (Upstart, Systemd...) ，并且有大量可用的进程管理器 (supervisord, god, monit, circus...)。
uWSGI会跟它们都很好地集成 (我们希望是这样的)，但如果你计划部署大量的应用，那么看看uWSGI Emperor - 它或多或少是每个devops工程师的梦想。
部署Django¶
Django大概是最常使用的Python web框架了。部署它是相当容易的 (我们继续配置4个进程，每个进程有2个线程)。
假设Django工程位于 /home/foobar/myproject:
uwsgi --socket 127.0.0.1:3031 --chdir /home/foobar/myproject/ --wsgi-file myproject/wsgi.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
(使用 --chdir ，我们移到指定的目录下)。在Django中，需要使用它来正确加载模块。
哎呀！这是什么鬼？！是哒，你是对的，对的……处理这样长的命令行并不实际，并且愚蠢而易于犯错。不要害怕！uWSGI支持多种配置风格。在这个入门中，我们会使用.ini文件。
[uwsgi]
socket = 127.0.0.1:3031
chdir = /home/foobar/myproject/
wsgi-file = myproject/wsgi.py
processes = 4
threads = 2
stats = 127.0.0.1:9191
好得多了！
仅需运行：
uwsgi yourfile.ini
如果文件 /home/foobar/myproject/myproject/wsgi.py (或者任何你的工程的名字) 并不存在，那么你很有可能使用的是Django的一个老(< 1.4)版本。在这种情况下，你需要多一点配置：
uwsgi --socket 127.0.0.1:3031 --chdir /home/foobar/myproject/ --pythonpath .. --env DJANGO_SETTINGS_MODULE=myproject.settings --module "django.core.handlers.wsgi:WSGIHandler()" --processes 4 --threads 2 --stats 127.0.0.1:9191
或者，使用.ini文件：
[uwsgi]
socket = 127.0.0.1:3031
chdir = /home/foobar/myproject/
pythonpath = ..
env = DJANGO_SETTINGS_MODULE=myproject.settings
module = django.core.handlers.wsgi:WSGIHandler()
processes = 4
threads = 2
stats = 127.0.0.1:9191
更老的(< 1.4)Django发布版本需要设置 env, module 和 pythonpath (.. 允许我们访问 myproject.settings 模块)。
部署Flask¶
Flask是一个流行的Python web微框架。
将下面例子保存为 myflaskapp.py:
from flask import Flask
app = Flask(__name__)
@app.route('/')
def index():
return "I am app 1"
Flask将其WSGI函数 (就是那个在这个快速入门开始的地方我们称为”application”的那个)导出为”app”，因此，我们需要指示uWSGI使用它。我们仍然使用4个进程/2个线程，以及uwsgi socket：
uwsgi --socket 127.0.0.1:3031 --wsgi-file myflaskapp.py --callable app --processes 4 --threads 2 --stats 127.0.0.1:9191
(唯一添加的是 --callable 选项)。
部署web2py¶
又一个流行选择。解压缩web2py源发布版本到所选的目录下，然后编写一个uWSGI配置文件：
[uwsgi]
http = :9090
chdir = path_to_web2py
module = wsgihandler
master = true
processes = 8
注解
在近期的web2py发布版本中，你可能需要将 wsgihandler.py 脚本拷贝出 handlers 目录。
再次使用HTTP路由器。仅需在浏览器中访问端口9090，你就能看到web2py欢迎页面。
点击管理员界面，然后……哎哟，不能用，因为需要HTTPS。不要担心，uWSGI路由器是可以使用HTTPS的 (确保你有OpenSSL开发头文件：安装它们，然后重新构建uWSGI，构建系统将会自动检测到它)。
首先，生成密钥和证书：
openssl genrsa -out foobar.key 2048
openssl req -new -key foobar.key -out foobar.csr
openssl x509 -req -days 365 -in foobar.csr -signkey foobar.key -out foobar.crt
现在，你有了2个文件 (好吧，算上 foobar.csr ，是3个)， foobar.key 和 foobar.crt 。修改uWSGI配置：
[uwsgi]
https = :9090,foobar.crt,foobar.key
chdir = path_to_web2py
module = wsgihandler
master = true
processes = 8
重新运行uWSGI，并且在浏览器中使用 https:// 访问9090端口。
关于Python线程的注意事项¶
如果你在不使用线程的情况下启动uWSGI，那么Python GIL将不会启动，因此，你的应用生成的线程将不会运行。你或许不会喜欢这个选择，但是记住，uWSGI是一个语言无关的服务器，因此它的大多数选择都是为了维护它的“不可知论”。
但是，不用担心，uWSGI开发者做的选择基本上没有选项不能改变的。(也就是说，基本上你可以通过选项改变它)
如果你想要维护Python线程支持，而不为你的应用启动多线程，那么仅需添加 --enable-threads 选项 (或者在ini风格的文件中添加 enable-threads = true )。
virtualenv¶
可以配置uWSGI在指定的virtualenv中搜索Python模块。
仅需添加 virtualenv = 到你的选项中。
安全性和可用性¶
总是 避免以root用户运行你的uWSGI实例。你可以使用 uid 和 gid 选项来去除权限：
[uwsgi]
https = :9090,foobar.crt,foobar.key
uid = foo
gid = bar
chdir = path_to_web2py
module = wsgihandler
master = true
processes = 8
如果你需要绑定到特许端口 (例如用于HTTPS的443)，那么使用共享socket。它们在去除权限之前创建，并且可以通过 =N 语法引用，其中， N 是socket号 (从0开始)：
[uwsgi]
shared-socket = :443
https = =0,foobar.crt,foobar.key
uid = foo
gid = bar
chdir = path_to_web2py
module = wsgihandler
master = true
processes = 8
web应用部署的一个常见问题是“卡住的请求”。你所有的线程/worker都卡住了 (请求阻塞) ，而你的应用无法接收更多的请求。要避免这个问题，你可以设置一个 harakiri 定时器。它是一个监控器 (由master进程管理)，会摧毁那些卡住超过指定秒数的进程 (小心选择 harakiri 值)。例如，你也许想要摧毁那些阻塞超过30秒的worker：
[uwsgi]
shared-socket = :443
https = =0,foobar.crt,foobar.key
uid = foo
gid = bar
chdir = path_to_web2py
module = wsgihandler
master = true
processes = 8
harakiri = 30
除此之外，自uWSGI 1.9起，stats服务器导出了全部请求变量，因此，你可以(实时)看到你的实例正在做什么 (对于每个worker, thread 或者异步核)。
卸载¶
uWSGI 卸载(offloading)子系统 允许你在特定模式匹配的适合尽快地释放你的worker，并且可以被委派给一个纯C线程。举几个栗子，从文件系统发送静态文件，从网络传输数据到客户端，等等。
卸载是非常复杂的，但它的使用对最终用户是透明的。如果你想试一试，那么仅需添加 --offload-threads ，其中，是要生成的线程数 (每个CPU1个是开始的一个不错的值)。
当启用了卸载线程，将会自动检测所有可以被优化的部分。
彩蛋：对不同Python版本使用相同的uWSGI二进制文件¶
正如我们所见的，uWSGI是由一个小核心和各种插件组成的。插件可以嵌入到二进制文件中，或者动态加载。当你为Python构建uWSGI的时候，一系列的插件，加上Python本身将会嵌入到最后的二进制文件中。
如果你想要支持多个Python版本，而不想为每个版本构建一个二进制文件的适合，这会是个问题。
最好的方法可能是使用一个小的二进制文件，其中内建语言无关的特性，然后为每个Python版本准备一个插件，按需加载。
在uWSGI源代码目录中：
make PROFILE=nolang
这将会构建一个uwsgi二进制文件，它内建了除了Python之外所有默认的插件。
现在，在相同的目录下，我们开始构建Python插件：
PYTHON=python3.4 ./uwsgi --build-plugin "plugins/python python34"
PYTHON=python2.7 ./uwsgi --build-plugin "plugins/python python27"
PYTHON=python2.6 ./uwsgi --build-plugin "plugins/python python26"
最后，你将获得三个文件： python34_plugin.so, python27_plugin.so, python26_plugin.so 。拷贝这些到你想要的目录下。 (默认情况下，uWSGI会在当前工作目录下搜索插件。)
现在，在你的配置文件中，你可以简单地添加 (在最顶部) plugins-dir 和 plugin 指令。
[uwsgi]
plugins-dir =
plugin = python26
这将会从目录下加载 python26_plugin.so 插件库到你拷贝插件到的那里。
现在……¶
有了这些概念，你应该已经能够投入生产了，但是uWSGI是一个庞大的项目，它有数百种特性和配置。如果你想成为一个更好的系统管理员，那么继续阅读整个文档吧。
