安装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 <dir>
  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

就这样。

添加并发和监控¶

你想进行的第一个调整可能是增加并发性 (默认情况下，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的工具，用来监控实例。

将它放在一个完整的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 "<span style='color:red'>I am app 1</span>"

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

再次使用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 = <path> 到你的选项中。

安全性和可用性¶

总是 避免以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 <n> ，其中，<n>是要生成的线程数 (每个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 = <path_to_your_plugin_directory>
plugin = python26

这将会从目录下加载 python26_plugin.so 插件库到你拷贝插件到的那里。

现在……¶

有了这些概念，你应该已经能够投入生产了，但是uWSGI是一个庞大的项目，它有数百种特性和配置。如果你想成为一个更好的系统管理员，那么继续阅读整个文档吧。

安装带Perl支持的uWSGI¶

要构建uWSGI，你需要一个c编译器 (支持gcc和clang) 和python二进制文件 (它将只运行uwsgiconfig.py脚本，这个脚本将会执行各种编译步骤)。由于我们要构建一个带perl支持的uWSGI二进制文件，因此我们也需要perl开发头文件 (基于debian发行版的libperl-dev包)

你可以手工构建uWSGI：

python uwsgiconfig.py --build psgi

这与下面相同

UWSGI_PROFILE=psgi make

或者使用网络安装程序：

curl http://uwsgi.it/install | bash -s psgi /tmp/uwsgi

那会在/tmp/uwsgi中创建一个uWSGI二进制文件 (随意修改路径为任意你想要的)

发行版包的注意事项¶

你的发行版非常有可能包含了一个uWSGI包集，所以，除了核心部分之外，你需要安装所需插件。必须在你的配置中加载插件。在学习阶段，我们强烈建议不要使用发行版包，才能轻松遵循文档和教程。

一旦你适应了“uWSGI方式”，你就可以为你的部署选择最佳方法。

你第一个PSGI应用¶

将其保存为一个名为myapp.pl的文件

my $app = sub {
     my $env = shift;
     return [
             '200',
             [ 'Content-Type' => 'text/html' ],
             [ "<h1>Hello World</h1>" ],
     ];
};

然后通过uWSGI，在http模式下运行它：

uwsgi --http :8080 --http-modifier1 5 --psgi myapp.pl

(如果’uwsgi’不在你当前的$PATH中，那么记得替换它)

或者如果你使用模块化构建 (就像你发行版那样)

uwsgi --plugins http,psgi --http :8080 --http-modifier1 5 --psgi myapp.pl

那个’–http-modifier1 5’是啥鬼东西？？？¶

uWSGI支持各种的语言和平台。当服务器接收到了一个请求的时候，它必须知道要把它“路由”到哪里。

每个uWSGI插件都被分配了一个数字 (modifier)，perl/psgi这个分配到的是5。所以–http-modifier1 5表示”路由到psgi插件”

尽管uWSGI有一个更加”人类友好的” internal routing system ，但是使用modifier是最快的方式，所以，如果有可能的话，总是使用它们吧。

使用一个完整的web服务器：nginx¶

提供的http路由器，只是 (对哒，令人难以置信的) 一个路由器。你可以将它作为一个负载均衡器或者代理使用，但是如果你需要一个完整的web服务器 (来有效地提供静态文件，或者所有web服务器擅长的那些任务)，那么你可以摆脱uwsgi http路由器 (如果你使用模块化构建，那么记得修改–plugins http,psgi为–plugins psgi)，然后将你的应用放在nginx之后。

要与nginx通信，uWSGI可以使用各种协议：http, uwsgi, fastcgi, scgi...

最有效的是uwsgi那个。Nginx默认包含uwsgi协议支持。

在一个uwsgi socket之上运行你的psgi应用：

uwsgi --socket 127.0.0.1:3031 --psgi myapp.pl

然后在你的nginx配置中添加一个location节

location / {
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:3031;
    uwsgi_modifier1 5;
}

重载你的nginx服务器，它应该开始代理请求到你的uWSGI实例

注意，你不需要配置uWSGI来设置一个指定的modifier，nginx将会使用 uwsgi_modifier1 5; 指令来做到这点

如果你的代理/web服务器/路由器使用HTTP，那么你必须告诉uWSGI原生使用http协议 (这与–http不同，后者自己会生成一个代理)：

uwsgi --http-socket 127.0.0.1:3031 --http-socket-modifier1 5 --psgi myapp.pl

正如你所见，我们需要指定使用的modifier1，因为http协议不能够携带这类信息

添加并发¶

你可以通过多进程、多线程或者各种异步模式为你的应用提供并发性。

要生成额外的进程，使用–processes选项

uwsgi --socket 127.0.0.1:3031 --psgi myapp.pl --processes 4

要拥有额外的线程，使用–threads

uwsgi --socket 127.0.0.1:3031 --psgi myapp.pl --threads 8

或者两者一起来

uwsgi --socket 127.0.0.1:3031 --psgi myapp.pl --threads 8 --processes 4

perl世界中一个非常常见的非阻塞/协程库是Coro::AnyEvent。uWSGI可以简单包括 coroae 插件来使用它 (甚至与多进程结合在一起)。

要构建一个带 coroae 支持的uWSGI二进制文件，只需运行

UWSGI_PROFILE=coroae make

或者

curl http://uwsgi.it/install | bash -s coroae /tmp/uwsgi

你将得到一个同时包含了 psgi 和 coroae 插件的uWSGI二进制文件。

现在，以Coro::AnyEvent模式运行你的应用：

uwsgi --socket 127.0.0.1:3031 --psgi myapp.pl --coroae 1000 --processes 4

它将运行4个进程，每个都能够管理多达1000个协程 (或者Coro微线程)。

添加鲁棒性：Master进程¶

高度推荐在生产应用上总是运行master进程。

它将不断监控你的进程/线程，并且会添加有趣的特性，例如 uWSGI Stats服务器

要启用master，只需添加–master

uwsgi --socket 127.0.0.1:3031 --psgi myapp.pl --processes 4 --master

使用配置文件¶

uWSGI有数百个选项。通过命令行与它们打交道基本上是种愚蠢的行为，所以试着一直使用配置文件吧。uWSGI支持各种标准 (xml, .ini, json, yaml...)。从一种移到另一种是相当简单的。你通过命令行可以使用的选项也一样可以在配置文件中使用，只需要移除 -- 前缀即可：

[uwsgi]
socket = 127.0.0.1:3031
psgi = myapp.pl
processes = 4
master = true

或者xml:

<uwsgi>
  <socket>127.0.0.1:3031</socket>
  <psgi>myapp.pl</psgi>
  <processes>4</processes>
  <master/>
</uwsgi>

要使用配置文件来运行uWSGI，只需将其作为一个参数指定：

uwsgi yourconfig.ini

如果出于某些原因，你的配置不能以期望的扩展名 (.ini, .xml, .yml, .js) 结尾，那么你可以这样强制二进制文件使用一个指定的解析器：

uwsgi --ini yourconfig.foo

uwsgi --xml yourconfig.foo

uwsgi --yaml yourconfig.foo

等等等等

你甚至可以使用管道配置 (使用破折号来强制从标准输入读取):

perl myjsonconfig_generator.pl | uwsgi --json -

自动在开机启动uWSGI¶

如果你在考虑编写一些init.d脚本来生成uWSGI，那么只需坐下（并且冷静下来），检查看看你的系统是否没给你提供一个更好的（更现代的）方法。

每个发行版都选择了一个启动系统 (Upstart, Systemd...)，并且有大量可用的进程管理器 (supervisord, god...).

uWSGI将会和它们很好的集成（我们希望是），但是如果你计划部署大量的应用，那么看看uWSGI Emperor ，它是每个devops的梦想。

安全性和可用性¶

总是避免将你的uWSGI实例作为root运行。你可以使用uid和gid选项来移除特权

[uwsgi]
socket = 127.0.0.1:3031
uid = foo
gid = bar
chdir = path_toyour_app
psgi = myapp.pl
master = true
processes = 8

web应用的部署的一个常见问题是“卡住请求”。你所有的线程/worker都卡在一个请求上了，导致你的应用不能再接收请求。

要避免那个问题，你可以设置一个 harakiri 定时器。它是一个监控器 (由master进程管理)，它将销毁那些卡住超过指定秒数的进程

[uwsgi]
socket = 127.0.0.1:3031
uid = foo
gid = bar
chdir = path_toyour_app
psgi = myapp.pl
master = true
processes = 8
harakiri = 30

将会摧毁那些阻塞超过30秒的worker。小心选择harakiri的值！！！

除此之外，自uWSGI 1.9起，统计信息服务器导出了整套请求变量，所以你可以看到（实时）你的实例在做什么 (对每个worker，线程或者异步核)

启用统计信息服务器是很容易的：

[uwsgi]
socket = 127.0.0.1:3031
uid = foo
gid = bar
chdir = path_toyour_app
psgi = myapp.pl
master = true
processes = 8
harakiri = 30
stats = 127.0.0.1:5000

只需将其绑定到一个地址 (UNIX或者TCP)，然后连接上 (你也可以使用telnet) 它，来接收你的实例的一个JSON表示。

uwsgitop 应用 (你可以在官方的github仓库中找到它) 是一个使用统计信息服务器来实现类top实时监控的工具的例子 (有颜色！！！)

卸载¶

uWSGI 卸载(offloading)子系统 允许你在某些特定的模式匹配的时候尽快释放你的worker，并且能够委托给一个纯c线程。例如，发送来自文件系统的静态文件，从网络传输数据到客户端，等等。

卸载是非常复杂的，但是它的使用对终端用户是透明的。如果你想要试一试，那么只需添加–offload-threads <n>，其中，<n>是要生成的线程数 (一个cpu一个线程是个不错的值)。

当启用了卸载线程时，所有可以被优化的部分将会被自动检测到。

以及现在¶

有了这些许概念，你应该已经可以上生产了，但是uWSGI是个巨大的项目，它有数百个特性和配置。如果你想要成为一个更好的系统管理员，那么请求继续阅读完整的文档。

安装带Ruby支持的uWSGI¶

要构建uWSGI，你需要一个C编译器 (支持gcc和clang) 和Python二进制文件 (用来运行uwsgiconfig.py脚本，它将执行各种编译步骤)。

因为我们正在构建一个带Ruby支持的uWSGI二进制文件，因此我们也需要Ruby开发头文件 (基于Debian发行版上的 ruby-dev 包)。

你可以手工构建uWSGI —— 这些都是等价的：

make rack
UWSGI_PROFILE=rack make
make PROFILE=rack
python uwsgiconfig.py --build rack

但是如果你懒癌犯了，那么你可以一次性下载、构建和安装一个uWSGI + Ruby二进制文件：

curl http://uwsgi.it/install | bash -s rack /tmp/uwsgi

或者以一种更“Ruby友好型”方式：

gem install uwsgi

这些方法都构建一个“单片”uWSGI二进制文件。uWSGI项目是由许多插件注册的。你可以选择构建服务器核心，并为每个特性使用一个插件（需要时加载），或者你可以构建一个带有所有你需要的特性的单个二进制文件。后者这种构建称之为“单片”。

这个快速入门假设使用一个单片二进制文件 (因此你无需加载插件)。如果你更喜欢使用你的包发行版 (而不是从官方来源构建uWSGI)，那么见下。

关于发布包的注意事项¶

你的发行版非常有可能包含一个uWSGI包集合。那些uWSGI包趋向于高模块化的 (并且偶尔高度过时)，因此，除了核心部分之外，你需要安装所需插件。必须在你的uWSGI配置中加载插件。在学习阶段，我们强烈建议不要使用发行版包，从而轻松跟着文档和教程。

一旦你适应了“uWSGI方式”，你就可以为你的部署选择最佳方式。

例如，本教程利用”http”和”rack”插件。如果你正使用模块化构建，那么确保通过 --plugins http,rack 选项加载它们。

你的第一个Rack应用¶

Rack是编写Ruby web应用的标准方式。

这是一个标准的Rack Hello world脚本 (称之为app.ru)：

class App

  def call(environ)
    [200, {'Content-Type' => 'text/html'}, ['Hello']]
  end

end

run App.new

扩展名 .ru 表示”rackup”，这是Rack发行版中包含的部署工具。Rackup使用了一点DSL，因此，要将其用到uWSGI中，你需要安装rack gem：

gem install rack

现在，我们准备好部署uWSGI了：

uwsgi --http :8080 --http-modifier1 7 --rack app.ru

(如果‘uwsgi’并不在你当前的$PATH中，记得替换它)

或者如果你正使用的是一个模块化构建 (就像你的发行版的那个)

uwsgi --plugins http,rack --http :8080 --http-modifier1 7 --rack app.ru

使用这个命令行，我们生成了一个HTTP代理，路由每个请求到一个进程 (名为’worker’)，进程管理它并把响应发送回HTTP路由器 (接着路由器发送回客户端)。

如果你对为什么生成两个进程有疑问，那么（我告诉你）是因为这是你将会在生产上使用的正常架构 (一个带有一个后端应用服务器的前线web服务器)。

如果你不想要生成HTTP代理，而是直接强制worker应答HTTP请求，那么仅需将命令行修改为

uwsgi --http-socket :8080 --http-socket-modifier1 7 --rack app.ru

现在，你有了单个管理请求的进程了 (但记住，直接将应用服务器公开一般是危险的，并且并不通用)。

那个’–http-modifier1 7’东东是啥？¶

uWSGI支持多种语言和平台。当服务器接收到一个请求的时候，它必须知道将其“路由” 到哪里。

每个uWSGI插件都有一个分配的数字 (即modifier)，ruby/rack这个使用的是7。因此， --http-modifier1 7 意思是“路由到rack插件”。

虽然uWSGI也有一个更加“人类友好型”的 internal routing system ，但是，使用modifier是最快的方式，所以，尽可能使用它们。

使用一个完整的web服务器：nginx¶

提供的HTTP路由器，是 (是哒，真的已经够了) 只是一个路由器。你可以将它当成一个负载均衡器或者代理使用，但是如果你需要一个完整的web服务器 (用于有效提供静态文件，或者一个web服务器所擅长的所有那些任务)，那么你可以摆脱uwsgi HTTP路由器 (如果你正使用模块化构建，那么记得修改–plugins http,rack为–plugins rack)，然后将你的应用放在Nginx之后。

为了与Nginx通信，uWSGI可以使用多个协议：HTTP, uwsgi, FastCGI, SCGI, 等等。

最有效的是uwsgi。Nginx默认支持uwsgi协议。

在一个uwsgi socket上运行你的rack应用：

uwsgi --socket 127.0.0.1:3031 --rack app.ru

然后在你的nginx配置中添加一个location节

location / {
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:3031;
    uwsgi_modifier1 7;
}

重载你的nginx服务器，然后它应该开始代理请求到你的uWSGI实例。

注意，你不需要配置uWSGI来设置一个指定的modifier，nginx将会使用 uwsgi_modifier1 5; 指令来实现它。

添加并发性¶

通过前面的例子，你部署了一个能够服务单个请求的栈。

要增加并发性，你需要添加更多的进程。如果你希望有一个魔法数学公式可以找到要生成的正确进程数，嗯……很抱歉，我们没有。你需要进行实验，并且监控你的应用，以找到正确的值。考虑到每个进程是你的应用的一个完全拷贝，因此，必须考虑内存使用。

要添加更多的进程，只需使用 –processes <n> 选项：

uwsgi --socket 127.0.0.1:3031 --rack app.ru --processes 8

将生成8个进程。

Ruby 1.9/2.0引入了一个改进的线程支持，uWSGI通过’rbthreads’插件支持它。当你编译uWSGI+ruby (>=1.9)单片二进制文件的时候，会自动内建这个插件。

要添加更多线程：

uwsgi --socket 127.0.0.1:3031 --rack app.ru --rbthreads 4

或者线程+进程

uwsgi --socket 127.0.0.1:3031 --rack app.ru --processes --rbthreads 4

有其他（一般更高级/复杂）的方式来提高并发性 (例如，’fiber’)，但是，大多时候，你最终会得到一个普通的旧式多进程或者多线程模型。如果你感兴趣，那么请查看 Rack 之上的完整文档。

添加健壮性：Master进程¶

It is highly recommended to have the uWSGI master process always running on productions apps.

It will constantly monitor your processes/threads and will add fun features like the uWSGI Stats服务器.

To enable the master simply add --master

uwsgi --socket 127.0.0.1:3031 --rack app.ru --processes 4 --master

使用配置文件¶

uWSGI有数百个选项 (但一般来说，你不会使用超过数十个)。通过命令行处理它们有点蠢，因此，试着总是使用配置文件。

uWSGI支持各种标准 (XML, INI, JSON, YAML, 等等)。从一个移到另一个相当简单。你可以通过命令行使用的相同的选项也可以在配置文件中使用，只需将前缀 -- 移除：

[uwsgi]
socket = 127.0.0.1:3031
rack = app.ru
processes = 4
master = true

或者xml:

<uwsgi>
  <socket>127.0.0.1:3031</socket>
  <rack>app.ru</rack>
  <processes>4</processes>
  <master/>
</uwsgi>

要通过配置文件运行uWSGI，只需将其当做一个参数指定：

uwsgi yourconfig.ini

如果出于某些原因，你的配置不以期望的扩展名 (.ini, .xml, .yml, .js) 结尾，那么你可以通过这种方式，强制二进制文件使用一个指定的解析器：

uwsgi --ini yourconfig.foo

uwsgi --xml yourconfig.foo

uwsgi --yaml yourconfig.foo

等等等等。

你甚至可以通过管道使用配置 (使用破折号强制从标准输入中读取)：

ruby myjsonconfig_generator.rb | uwsgi --json -

当你生成多个进程时的fork()问题¶

uWSGI某种程度上是“Perl化的”，我们没法隐藏它。它的大多数抉择 (从“不止一种实现的方式”开始) 来自于Perl世界 (更一般来说，是来自于传统的UNIX系统管理员方法)。

当应用到其他语言/平台上的时候，这个方法有时会导致意外行为。

当你开始学习uWSGI的时候，你会面对的其中一个“问题”是它的 fork() 使用。

默认情况下，uWSGI在第一个生成的进程中加载你的应用，然后多次 fork() 自身。

这意味着，你的应用被单次加载，然后被拷贝。

虽然这个方法加速了服务器的启动，但是有些应用在这项技术下会出问题 (特别是那些在启动时初始化db连接的应用，因为将会在子进程中继承连接的文件描述符)。

如果你对uWSGI使用的粗暴的preforking不确定，那么只需使用 --lazy-apps 选项来禁用它。它将会强制uWSGI在每个worker中完全加载你的应用一次。

部署Sinatra¶

让我们忘掉fork()，回到有趣的事情上来。这次，我们部署一个Sinatra应用：

require 'sinatra'

get '/hi' do
  "Hello World"
end

run Sinatra::Application

将其另存为 config.ru ，然后如前所见那样运行：

[uwsgi]
socket = 127.0.0.1:3031
rack = config.ru
master = true
processes = 4
lazy-apps = true

uwsgi yourconf.ini

好吧，或许你已经注意到，基本与前面的app.ru例子没啥区别。

这是因为，基本上，每个现代的Rack应用都将其自身作为一个.ru文件（一般称为config.ru）公开，因此，无需使用多个选项来加载应用 (例如，像Python/WSGI世界中的那样)。

部署RubyOnRails >= 3¶

从3.0起，Rails就是完全兼容Rack的，并且它公开了一个你可以直接加载的config.ru文件 (就像我们用Sinatra那样)。

与Sinatra的唯一不同是，你的项目有一个特定的布局/约定，期望你当前的工作目录是包含项目的那个目录，因此，让我们添加一个chdir选项：

[uwsgi]
socket = 127.0.0.1:3031
rack = config.ru
master = true
processes = 4
lazy-apps = true
chdir = <path_to_your_rails_app>
env = RAILS_ENV=production

uwsgi yourconf.ini

除了chdir之外，我们添加了’env’选项，它设置 RAILS_ENV 环境变量。

从4.0起，Rails支持多线程 (只适用于ruby 2.0)：

[uwsgi]
socket = 127.0.0.1:3031
rack = config.ru
master = true
processes = 4
rbthreads = 2
lazy-apps = true
chdir = <path_to_your_rails_app>
env = RAILS_ENV=production

部署更老的RubyOnRails¶

较老的Rails版本并非完全Rack兼容的。出于这样的原因，uWSGI中有一个特定的选项，用来加载较老的Rails应用 (你也会需要’thin’这个gem)。

[uwsgi]
socket = 127.0.0.1:3031
master = true
processes = 4
lazy-apps = true
rails = <path_to_your_rails_app>
env = RAILS_ENV=production

所以，长话短说，指定 rails 选项，将rails应用的目录（而不是Rackup文件）作为参数传递。

Bundler和RVM¶

Bundler是用来管理依赖的标准的事实上的Ruby工具。基本上，你在Gemfile文本文件中指定你的应用所需的gem，然后启动bundler来安装它们。

要让uWSGI遵守bundler安装，你只需要添加：

rbrequire = rubygems
rbrequire = bundler/setup
env = BUNDLE_GEMFILE=<path_to_your_Gemfile>

(第一个并非ruby 1.9/2.x要求的必须节。)

基本上，这些行强制uWSGI加载bundler引擎，并且使用在 BUNDLE_GEMFILE 环境变量中指定的Gemfile。

当使用Bundler的时候 (就像现代框架所做的那样)，你的常见部署配置将会是：

[uwsgi]
socket = 127.0.0.1:3031
rack = config.ru
master = true
processes = 4
lazy-apps = true
rbrequire = rubygems
rbrequire = bundler/setup
env = BUNDLE_GEMFILE=<path_to_your_Gemfile>

除了Bundler之外，RVM是另一个常见的工具。

它允许你在单个系统中安装多个 (独立的) Ruby版本 (带自己的gemset)。

要指示uWSGI使用一个指定RVM版本的gemset，只需使用 –gemset 选项：

[uwsgi]
socket = 127.0.0.1:3031
rack = config.ru
master = true
processes = 4
lazy-apps = true
rbrequire = rubygems
rbrequire = bundler/setup
env = BUNDLE_GEMFILE=<path_to_your_Gemfile>
gemset = ruby-2.0@foobar

只是注意，对于每个Ruby版本（是Ruby版本，不是gemset！），你都需要一个uWSGI二进制文件（或者如果你使用模块化构建，则是一个插件）。

如果你有兴趣，那么这里是构建uWSGI核心+每个rvm中安装的Ruby版本1个插件的命令列表。

# build the core
make nolang
# build plugin for 1.8.7
rvm use 1.8.7
./uwsgi --build-plugin "plugins/rack rack187"
# build for 1.9.2
rvm use 1.9.2
./uwsgi --build-plugin "plugins/rack rack192"
# and so on...

然后，如果你想要使用ruby 1.9.2和@oops gemset：

[uwsgi]
plugins = ruby192
socket = 127.0.0.1:3031
rack = config.ru
master = true
processes = 4
lazy-apps = true
rbrequire = rubygems
rbrequire = bundler/setup
env = BUNDLE_GEMFILE=<path_to_your_Gemfile>
gemset = ruby-1.9.2@oops

开机时自动启动uWSGI¶

如果你正想着打开vi，然后编写一个init.d脚本来生成uWSGI，那么坐下（并且淡定），首先确保你的系统并没有提供一个更好（更现代）的方法。

每个发行版都选择了一个启动系统 (Upstart, Systemd...)，并且有大量可用的进程管理器 (supervisord, god, monit, circus...)。

uWSGI将与它们完美集成（我们希望），但是如果你计划部署大量的应用，那么看看uWSGI Emperor - 它或多或少是每个devops工程师的梦想。

安全性和可用性¶

总是避免以root运行你的uWSGI实例。你可以使用uid和gid选项来移除特权。

[uwsgi]
socket = 127.0.0.1:3031
uid = foo
gid = bar
chdir = path_toyour_app
rack = app.ru
master = true
processes = 8

web应用部署的一个常见问题是“卡住的请求”。你所有的线程/worker都卡住了 (请求阻塞) ，而你的应用无法接收更多的请求。

要避免这个问题，你可以设置一个 harakiri 定时器。它是一个监控器 (由master进程管理)，会摧毁那些卡住超过指定秒数的进程。

[uwsgi]
socket = 127.0.0.1:3031
uid = foo
gid = bar
chdir = path_toyour_app
rack = app.ru
master = true
processes = 8
harakiri = 30

这将会摧毁那些阻塞超过30秒的worker。小心选择 harakiri 值！

除此之外，自uWSGI 1.9起，stats服务器导出了全部请求变量，因此，你可以（实时）看到你的实例正在做什么 (对于每个worker, thread 或者异步核)。

启用统计信息服务器是很简单的：

[uwsgi]
socket = 127.0.0.1:3031
uid = foo
gid = bar
chdir = path_to_your_app
rack = app.ru
master = true
processes = 8
harakiri = 30
stats = 127.0.0.1:5000

只需将其绑定到一个地址 (UNIX或者TCP) 上，并且只需连接 (你也可以使用telnet) 到它上面，来接收你的实例的一个JSON内容。

uwsgitop 应用 (你可以在官方的github仓库中找到它) 是一个使用统计信息服务器来实现类top实时监控的工具的例子 (有颜色！！！)

内存使用¶

低内存使用是整个uWSGI项目的卖点之一。

不幸的是，默认对内存的积极态度也许（看好：是也许）会导致某些性能问题。

默认情况下，uWSGI Rack插件在每次请求之后调用Ruby GC (垃圾回收器)。如果你想要减少这个频率，只需添加``–rb-gc-freq <n>`` 选项，其中，n是调用GC之后的请求数。

如果你计划进行uWSGI的基准 (或者把它与其他方法对比)，那么考虑它对GC的使用。

Ruby可以是一个真正的内存吞噬者，因此，我们更喜欢默认积极对待内存，而不是取悦hello-world基准点。

卸载¶

uWSGI 卸载(offloading)子系统 允许你在某些特定的模式匹配的时候尽快释放你的worker，并且能够委托给一个纯c线程。例如，发送来自文件系统的静态文件，从网络传输数据到客户端，等等。

卸载是非常复杂的，但是它的使用对终端用户是透明的。如果你想要试一试，那么只需添加–offload-threads <n>，其中，<n>是要生成的线程数 (一个cpu一个线程是个不错的值)。

当启用了卸载线程时，所有可以被优化的部分将会被自动检测到。

以及现在¶

有了这些许概念，你应该已经可以上生产了，但是uWSGI是个巨大的项目，它有数百个特性和配置。如果你想要成为一个更好的系统管理员，那么请求继续阅读完整的文档。

欢迎进入uWSGI的世界！

X-Sendfile模拟¶

即使你的前端代理/web服务器不支持X-Sendfile (或者不能访问你的静态资源)，但是你可以使用uWSGI的内部卸载（你的进程/线程将会委托实际的静态文件服务给卸载线程）来模拟它。

[uwsgi]
...
; load router_static plugin (compiled in by default in monolithic profiles)
plugins = router_static
; spawn 2 offload threads
offload-threads = 2
; files under /private can be safely served
static-safe = /private
; collect the X-Sendfile response header as X_SENDFILE var
collect-header = X-Sendfile X_SENDFILE
; if X_SENDFILE is not empty, pass its value to the "static" routing action (it will automatically use offloading if available)
response-route-if-not = empty:${X_SENDFILE} static:${X_SENDFILE}

强制使用HTTPS¶

这将会强制整个站点使用HTTPS。

[uwsgi]
...
; load router_redirect plugin (compiled in by default in monolithic profiles)
plugins = router_redirect
route-if-not = equal:${HTTPS};on redirect-permanent:https://${HTTP_HOST}${REQUEST_URI}

而这个只会强制 /admin (使用HTTPS)

[uwsgi]
...
; load router_redirect plugin (compiled in by default in monolithic profiles)
plugins = router_redirect
route = ^/admin goto:https
; stop the chain
route-run = last:

route-label = https
route-if-not = equal:${HTTPS};on redirect-permanent:https://${HTTP_HOST}${REQUEST_URI}

最终，你可能也想要发送HSTS (强制安全传输技术，HTTP Strict Transport Security)头。

[uwsgi]
...
; load router_redirect plugin (compiled in by default in monolithic profiles)
plugins = router_redirect
route-if-not = equal:${HTTPS};on redirect-permanent:https://${HTTP_HOST}${REQUEST_URI}
route-if = equal:${HTTPS};on addheader:Strict-Transport-Security: max-age=31536000

Python自动重载 (DEVELOPMENT ONLY!)¶

在生产环境中，你可以监控文件/目录的改动来触发重载 (touch-reload, fs-reload...).

在开发期间，拥有一个用于所有的重载/已用python模块的监控器是很方便的。但是请只在开发期间才使用它。

检查是通过一个以指定频率扫描模块列表的线程来完成的：

[uwsgi]
...
py-autoreload = 2

将会每2秒检查一次python模块的改动，并最终重启实例。

再次说明：

全栈CGI设置¶

这个例子从一个uWSGI的邮件列表线程生成。

我们在/var/www中有静态文件，在/var/cgi中有cgi。将会使用/cgi-bin挂载点访问cgi。所以将会在到/cgi-bin/foo.lua的请求上运行/var/cgi/foo.lua

[uwsgi]
workdir = /var
ipaddress = 0.0.0.0

; start an http router on port 8080
http = %(ipaddress):8080
; enable the stats server on port 9191
stats = 127.0.0.1:9191
; spawn 2 threads in 4 processes (concurrency level: 8)
processes = 4
threads = 2
; drop privileges
uid = nobody
gid = nogroup

; serve static files in /var/www
static-index = index.html
static-index = index.htm
check-static = %(workdir)/www

; skip serving static files ending with .lua
static-skip-ext = .lua

; route requests to the CGI plugin
http-modifier1 = 9
; map /cgi-bin requests to /var/cgi
cgi = /cgi-bin=%(workdir)/cgi
; only .lua script can be executed
cgi-allowed-ext = .lua
; .lua files are executed with the 'lua' command (it avoids the need of giving execute permission to files)
cgi-helper = .lua=lua
; search for index.lua if a directory is requested
cgi-index = index.lua

不同挂载点中的多个flask应用¶

写3个flask应用：

#app1.py
from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World! i am app1"

#app2.py
from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World! i am app2"

#app3.py
from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World! i am app3"

每个将会被分别挂载在/app1, /app2, /app3上

要在uWSGI中挂载一个使用指定“键”的应用，使用–mount选项：

` --mount <mountpoint>=<app> `

在我们的例子中，我们想要挂载3个python应用，每个使用WSGI SCRIPT_NAME变量名作为键：

[uwsgi]
plugin = python
mount = /app1=app1.py
mount = /app2=app2.py
mount = /app3=app3.py
; generally flask apps expose the 'app' callable instead of 'application'
callable = app

; tell uWSGI to rewrite PATH_INFO and SCRIPT_NAME according to mount-points
manage-script-name = true

; bind to a socket
socket = /var/run/uwsgi.sock

现在，直接将你的webserver.proxy指向实例socket (无需进行额外的配置)

注意事项：默认情况下，每个应用都会在一个新的python解释器中加载 (那意味着每个应用都有一个相当棒的隔离的名字空间)。如果你想要在相同的python vm中加载所有的应用，那么使用–single-interpreter选项。

另一个注意事项：你或许发现到一个不起眼的”modifier1 30”引用技巧。它已经被弃用了，并且非常丑陋。uWSGI能够以许多种高级方式重写请求变量

最后一个注意事项：默认情况下，第一个加载的应用作为”默认应用”挂载。当没有挂载点匹配上的时候，将会使用那个应用。

OSX上的rbenv (应该也能在其他平台上用)¶

安装rbenv

brew update
brew install rbenv ruby-build

(不要像经典的howto中描述的那样在.bash_profile中设置魔术行，因为我们希望不破坏环境，并且让uWSGI摆脱它)

获取一个uWSGI压缩包，并且构建’nolang’版本 (它是一个单片版本，其中并未编译任何语言插件)

wget http://projects.unbit.it/downloads/uwsgi-latest.tar.gz
tar zxvf uwsgi-latest.tar.gz
cd uwsgi-xxx
make nolang

现在，开始安装你需要的ruby版本

rbenv install 1.9.3-p551
rbenv install 2.1.5

并且安装你需要的gem (这个例子中是sinatra)：

# set the current ruby env
rbenv local 1.9.3-p551
# get the path of the gem binary
rbenv which gem
# /Users/roberta/.rbenv/versions/1.9.3-p551/bin/gem
/Users/roberta/.rbenv/versions/1.9.3-p551/bin/gem install sinatra
# from the uwsgi sources directory, build the rack plugin for 1.9.3-p551, naming it rack_193_plugin.so
# the trick here is changing PATH to find the right ruby binary during the build procedure
PATH=/Users/roberta/.rbenv/versions/1.9.3-p551/bin:$PATH ./uwsgi --build-plugin "plugins/rack rack_193"
# set ruby 2.1.5
rbenv local 2.1.5
rbenv which gem
# /Users/roberta/.rbenv/versions/2.1.5/bin/gem
/Users/roberta/.rbenv/versions/2.1.5/bin/gem install sinatra
PATH=/Users/roberta/.rbenv/versions/2.1.5/bin:$PATH ./uwsgi --build-plugin "plugins/rack rack_215"

现在，从一个ruby切换到另一个，只需修改插件：

[uwsgi]
plugin = rack_193
rack = config.ru
http-socket = :9090

或者

[uwsgi]
plugin = rack_215
rack = config.ru
http-socket = :9090

确保插件存储在当前的工作目录中，或者设置plugins-dir指令，又或者像这样涌绝对路径指定它们

[uwsgi]
plugin = /foobar/rack_215_plugin.so
rack = config.ru
http-socket = :9090

认证的WebSocket代理¶

应用服务器识别websocket流量，相对于应用自身策略/基础架构，使用任何CGI变量来认证/鉴权用户，然后卸载/代理请求到一个简单的kafka-websocket后端。

首先，创建 auth_kafka.py:

from pprint import pprint

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return ['It Works!']

def auth_kafka(request_uri, http_cookie, http_authorization):
    pprint(locals())
    return 'true'

import uwsgi
uwsgi.register_rpc('auth_kafka', auth_kafka)

然后创建 auth_kafka.ini:

[uwsgi]

; setup
http-socket = 127.0.0.1:8000
master = true
module = auth_kafka

; critical! else worker timeouts apply to proxied websocket connections
offload-threads = 2

; match websocket protocol
kafka-ws-upgrade-regex = ^[Ww]eb[Ss]ocket$

; DRY place for websocket check
is-kafka-ws-request =  regexp:${HTTP_UPGRADE};%(kafka-ws-upgrade-regex)

; location of the kafka-ws server
kafka-ws-host = 127.0.0.1:7080

; base endpoint uri for websocket server
kafka-ws-endpoint-uri = /v2/broker/

; call auth_kafka(...); if AUTH_KAFKA gets set, request is good!
route-if = %(is-kafka-ws-request) rpcvar:AUTH_KAFKA auth_kafka ${REQUEST_URI} ${HTTP_COOKIE} ${HTTP_AUTHORIZATION}

; update request uri to websocket endpoint (rewrite only changes PATH_INFO?)
route-if-not = empty:${AUTH_KAFKA} seturi:%(kafka-ws-endpoint-uri)?${QUERY_STRING}

; route the request to our websocket server
route-if-not = empty:${AUTH_KAFKA} httpdumb:%(kafka-ws-host)

启动一个”kafka-websocket”服务器：

nc -l -k -p 7080

现在，在一个web浏览器中访问 http://127.0.0.1:8000 ！你应该看到 Hello! 。打开chrome的查看器或者firebug，然后输入：

ws = new WebSocket('ws://127.0.0.1:8000/?subscribe=true')

你应该看到这个请求代理到你的 nc 命令！这个模式允许内部网络托管一个或多或少全开/通用的kafka -> websocket网关，并且委托认证需求给应用服务器。使用 offload-threads 意味着代理请求 不会 阻塞worker；使用 httpdumb 避免了重整请求 (http 动作强制使用 HTTP/1.0)

SELinux和uWSGI¶

SELinux允许你将web应用进程彼此隔离，并且限制每个程序只用于自身目的。应用可以被放置于高度隔离的独立沙箱中，将它们与其他应用以及底层操作系统分离开来。由于SELinux是在内核中实现的，因此不需要特殊编写或修改应用就能让其在SELinux之下使用。github上有一个 SELinux security policy for web applications ，非常适于uWSGI。这个安全策略也支持运行在一个域中的uWSGI emperor进程，以及运行在一个分隔域中的每个web应用的worker进程，即使使用了Linux名字空间，worker进程也只要求最小的特权。当然，使用SELinux不要求emperor模式，或者Linux名字空间。

在Linux上，有可能使用文件系统、ipc、uts、网络、pid和uid的专有视图来运行每个vassal。然后，每个vassal可以，比方说，修改文件系统布局、网络和主机名，而无需损坏主系统。有了这个设置，特权任务，例如挂载文件系统、设置主机名、配置网络和设置worker进程的gid和uid就可以在修改vassal进程的SELinux安全上下文之前完成了，确保每个worker进程只需要最少的特权。

首先，配置、编译和加载SELinux web应用安全策略。然后，重新标记应用文件。关于如何配置web应用策略的进一步信息可以在 SELinux security policy for web applications 中包含的README.md上找到。最后，在每个vassal的配置文件中，调用libselinux的setcon函数来设置web应用的SELinux安全上下文：

[uwsgi]
...
hook-as-user = callret:setcon system_u:system_r:webapp_id_t:s0

其中，id是域的标识。例如，foo是webapp_foo_t域的标识。

也许需要使用–dlopen选项在uWSGI地址空间内加载libselinux:

/path/to/uwsgi --dlopen /path/to/libselinux.so

从发布包安装¶

在一些操作系统/发布版本中，uWSGI已作为软件包提供。

通过源码包安装¶

要构建uWSGI，你需要Python和一个C编译器 (支持 gcc 和 clang )。取决于你想要支持的语言，你将需要它们的开发头文件。在Debian/Ubuntu系统上，你可以这样安装它们（以及构建软件所需的其余的基础设施）：

apt-get install build-essential python

而如果你想要构建一个带有Python/wsgi支持的二进制文件的话 (举个例子)

apt-get install python-dev

在Fedora/Redhat系统上，你可以这样安装它们：

yum groupinstall "Development Tools"
yum install python

而对于python/wsgi支持：

yum install python-devel

如果你的系统中有了可用的 make 变体，那么你可以简单运行 make 。如果没有 make (或者想有更多的控制权)，那么运行：

python uwsgiconfig.py --build

你还可以使用pip来安装uWSGI (它将会构建一个带python支持的二进制文件)。

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

或者你可以使用ruby gems (它将会构建一个带ruby/rack支持的二进制文件)。

# Install the latest stable release:
gem install uwsgi

在构建的最后，你将会获得启用特性的报告。如果缺少了任何你需要的，那么仅需添加开发头文件，然后重新运行构建。例如，要构建带ssl和perl正则表达式支持的uWSGI，你需要libssl-dev和pcre头文件。

可替换构建配置文件¶

出于历史原因，当你运行’make’的时候，会构建把Python作为唯一支持的语言的uWSGI。你可以使用构建配置文件来自定义uWSGI服务器，配置文件位于 buildconf/ 目录中。你可以这样使用一个特定的配置文件：

python uwsgiconfig.py --build <profile>

或者你可以通过一个环境变量传递它：

UWSGI_PROFILE=lua make
# ... or even ...
UWSGI_PROFILE=gevent pip install uwsgi

模块化构建¶

这是你的发行版应该遵循的方法，也是在你想要在uWSGI之上构建一个商用服务必须遵循的方法（见下）。大部分的uWSGI特性是作为插件提供的。可以使用–plugin选项来加载插件。如果你想提供给用户最大量的灵活性，让他们只使用最少的资源，那么仅需创建一个模块化构建。一个名为”core”的构建配置文件是可用的。

python uwsgiconfig.py --build core

这将会狗偶家一个不带插件的uWSGi二进制文件。这被称为”服务器核心”。现在，你可以开始构建所需的所有的插件。检查源代码发布中的plugins/ 目录，以获取完整列表。

python uwsgiconfig.py --plugin plugins/psgi core
python uwsgiconfig.py --plugin plugins/rack core
python uwsgiconfig.py --plugin plugins/python core
python uwsgiconfig.py --plugin plugins/lua core
python uwsgiconfig.py --plugin plugins/corerouter core
python uwsgiconfig.py --plugin plugins/http core
...

记得要传递构建配置文件 (这里是’core’) 作为第三个参数。

uwsgiconfig.py¶

这是一个旨在调用不同编译/链接阶段的python脚本。

在2009年期间，当开始定义uWSGI指导方针 (以及准则) 时，人们一致认为，autotools, cmake和它们的小伙伴们不受许多系统管理员喜爱。尽管它们相当标准，但是需要包数量，以及它们之前的不兼容（特别是在autotools的世界中）对于一个具有快速开发/演进的项目来说，是个问题，其中“从源代码编译”曾经，现在是，并且可能将是从产品获得最好的最好的方式。除此之外，构建过程一定要快 (在入门级的x86上少于1分钟是主要规则)

出于这样的原因，要编译uWSGI，你只需要有一个c编译套件 (gcc, clang...) 和一个python解释器。有人可能会说，perl可能是一个更好的选择，也许这是事实 (默认情况下，许多操作系统一般都会安装它)，但是我们还是决定主要用python，因为，在uWSGI项目启动的时候，它是一个仅支持python的应用。(显然，如果你想要开发一个可替换的构建系统，请随意)

基本上，uwsgiconfig.py检测系统中的可用特性，并使用所谓的“构建配置文件”构建一个uwsgi二进制（及其插件）

构建配置文件¶

第一个例子¶

CC和CPP¶

这2个环境变量告诉uwsgiconfig.py使用一个替换的C编译器和C预处理器。

如果不定义它们，那么过程如下：

对于CC -> 尝试从运行uwsgiconfig.py的python二进制中获得CC config_var，回退到’gcc’

对于CPP -> 回退到’cpp’

例如，在一个同时拥有gcc和clang的系统上，你会得到

CC=clang CPP=clang-cpp python uwsgiconfig.py --build

CPUCOUNT¶

在“即使在生产系统上，也要轻松快速构建”的精神下，uwsgiconfig.py试着使用你所有的cpu核来生成c编译器的多个实例 (每个核一个)。

你可以使用CPUCOUNT环境变量来覆盖这个系统，强制已检测的CPU核数目 (设为1将会禁用并行构建)。

CPUCOUNT=2 python uwsgiconfig.py --build

UWSGI_FORCE_REBUILD¶

插件和uwsgiplugin.py¶

一个uWSGI插件是一个导出<name>_plugin符号的共享库。其中，<name>是插件名。

例如，psgi插件将会导出psgi_plugin符号，而pypy将会导出pypy_plugin符号，以此类推。

这个符号是一个uwsgi_plugin C结构，定义插件的钩子。

当你让uWSGI加载一个插件的时候，它简单调用dlopen()，并通过dlsym()获得uwsgi_plugin结构。

uWSGI项目的绝大部分是作为插件开发的，这保证了配置的模块化，以及明显理智的发展方式。

系统管理员可以随意嵌入每个插件在服务器二进制文件中，或将每个插件当成一个外部共享库构建。

已嵌入的插件在构建配置文件的’embedded_plugins’指令中定义。你可以使用UWSGI_EMBED_PLUGINS环境变量，从命令行添加更多嵌入插件（见下）。

事实上，如果你想要把一个插件作为共享库构建，那么只需带–plugin选项运行uwsgiconfig.py

python uwsgiconfig.py --plugin plugins/psgi

这将会构建plugins/psgi中的插件为psgi_plugin.so文件

要在构建插件的时候，指定一个构建配置文件，你可以把这个配置文件当成一个额外的参数传递

python uwsgiconfig.py --plugin plugins/psgi mybuildprofile

UWSGI_INCLUDES¶

• 这个已在1.9.13添加

在启动时，运行CPP二进制文件来检测默认的包含路径。你可以使用UWSGI_INCLUDES环境变量来添加更多路径

UWSGI_INCLUDES=/usr/local/include,/opt/dev/include python uwsgiconfig.py --build

UWSGI_EMBED_PLUGINS¶

UWSGI_EMBED_CONFIG¶

允许嵌入指定的.ini文件到服务器二进制文件中 (目前仅支持Linux)

在启动的时候，服务器立即解析嵌入的文件。

嵌入的配置中自定义的选项将如标准选项一般可用。

UWSGI_BIN_NAME¶

CFLAGS和LDFLAGS¶

用于插件的 UWSGICONFIG_*¶

libuwsgi.so¶

uwsgibuild.log¶

uwsgibuild.lastcflags¶

cflags和uwsgi.h magic¶

嵌入文件¶

fake make¶

启动服务器¶

启动一个uWSGI服务器是系统管理员的角色，例如启动Web服务器。不应该由Web服务器来启动uWSGI服务器 —— 虽然如果这适合你的架构，你也能那样做。

如何在引导的时候最好的启动uWSGI服务取决于你使用的操作系统。

在现代系统中，下述应该行得通。在“传统的”操作系统上，你可以使用 init.d/rc.d 脚本，或者诸如Supervisor, Daemontools 或 inetd/xinetd 这样的工具。

用来控制uWSGI的信号哦¶

你可以使用 safe-pidfile 选项，指示uWSGI将master进程的PID写入到一个文件中。

uWSGI对以下信号进行响应。

注意：比起使用信号，有更好的管理你的实例的方式，例如，master-fifo就是一个更健壮的方式。

重载服务器¶

当运行在 master 进程模式下时，uWSGI服务器可以在无需关闭主socket的情况下优雅地重启。

这个功能允许你在无需关闭与web服务器的连接以及丢失请求的情况下修补/更新uWSGI服务器。

当你发送 SIGHUP 给主进程时，它会试着优雅地停止所有的worker，等待任何当前运行中的请求完成。

然后，它关闭所有与uWSGI无关的最终打开的文件描述符。

最后，它使用一个新的来二进制修补 (使用 execve()) uWSGI进程镜像，继承所有之前的文件描述符。

服务器将会知道它是一个已重载的实例，并且会跳过所有的socket初始化，重用之前的。

有多种方式来让uWSGI优雅地重启。

# using kill to send the signal
kill -HUP `cat /tmp/project-master.pid`
# or the convenience option --reload
uwsgi --reload /tmp/project-master.pid
# or if uwsgi was started with touch-reload=/tmp/somefile
touch /tmp/somefile

或在你的应用中，使用Python:

uwsgi.reload()

或者使用Ruby,

UWSGI.reload

停止服务器¶

如果出于某些原因，你让uWSGI进程在前台运行，那么使用CTRL+C就可以杀死它了。

在处理后台进程时，你将需要再次使用master pidfile。SIGINT信号将会杀死uWSGI.

kill -INT `cat /tmp/project-master.pid`
# or for convenience...
uwsgi --stop /tmp/project-master.pid

Master FIFO¶

自uWSGI 1.9.17起，添加了一个新的管理系统，它使用unix命名管道 (fifo): Master FIFO

Nginx¶

自Nginx官方发行版本0.8.40起就包含了uWSGI模块。uWSGI包里维护了一个支持Nginx 0.7.x的版本。

这是一个稳定的处理程序，由Unbit提供商业支持。

Apache¶

Apache2 mod_uwsgi 模块式第一个为uWSGI开发的web服务器集成模块。它稳定，但可以更好地与Apache API集成。

由Unbit提供商业支持。

自uWSGI 0.9.6-dev起，包含了一个名为 mod_Ruwsgi 的第二个Apache2模块。它更加Apache API友好。 Unbit未对mod_Ruwsgi提供商业支持。

在1.2开发周期中，添加了另一个名为 mod_proxy_uwsgi 模块。不久，这应该是基于Apache部署的最好的选择。

Lighttpd (试验性)¶

该模块是最新开发的，但是在官方的inclusion发布版本中其包含已经被拒了，因为主作者认为 uwsgi protocol 是“重复发明轮子” ，而建议使用一个FastCGI方法。我们尊重这种态度。这个模块会继续存在uWSGI源代码树中，但是当前未对其进行维护。

对于这个处理程序，当前并无商业支持。我们认为这个模块是“试验性的”。

Twisted¶

这是一个”商用”处理程序，主要在不安装一个完整的web服务器的情况下测试应用的时候有用。如果你想要开发一个uWSGI服务器，那么看看这个模块。 Twisted.

Tomcat¶

可以使用包含的服务小程序来从Tomcat转发请求到uWSGI服务器。它稳定，但当前缺乏文档。

对于这个处理程序，当前并无商业支持。

CGI¶

CGI处理程序是用于“偷懒”安装的。不鼓励在生产环境上使用它们。

Cherokee (废弃)¶

Cherokee web服务器官方支持uWSGI。 Cherokee是快而且轻量的，拥有一个漂亮的admin界面，以及一个不错的社区。从一开始，他们对uWSGI的支持就很棒，在大多数的情况下，我们都推荐使用它。 Cherokee uWSGI处理程序的用户群可能是最大的。Cherokee uWSGI处理程序由Unbit提供商业支持。

Mongrel2 (废弃)¶

自0.9.8-dev起，对 Mongrel2 Project 的支持通过 ZeroMQ 协议插件可用。

在我们的测试中，Mongrel2几乎通过了我们发送的所有负载。

非常棒和稳定的项目。试试吧 :)

我应该选择uWSGI吗？¶

因为你可以呀！ :) uWSGI想要成为一个完整的web应用部署解决方案，包含以下助力：

• ProcessManagement
• Management of long-running tasks
• uWSGI RPC栈
• Clustering
• LoadBalancing
• Monitoring
• ResourceLimiting

... 以及许多其他你必须委托给外部脚本和手工系统管理员任务的烦人日常任务。

如果你正为你的WSGI, PSGI或者Rack应用搜寻一个简单的服务器，那么uWSGI可能不适合你。不过，如果你正构建一个应用，它需要坚如磐石、快速、易于分发并且为各种负载进行优化，那么你很可能会发现自己需要uWSGI。

uWSGI最好的定义是“你的网络应用的瑞士军刀”。

协议是什么？¶

uwsgi (全部小写) 是从SCGI衍生而来的，但使用二进制字符串长度表示，以及一个包含var块（16位长）大小的4字节头部，和几个通用字节。我们不重新发明轮子。二进制管理比字符串解析容易且廉价得多，而每一位对我们的项目都是必须的。如果你需要证明，那么看看 official protocol documentation ，你将会明白，为什么需要一个新的协议。显然，你可以随意使用其他支持的协议。记住，如果在某些场景下，你不能使用uWSGI，那么这是一个uWSGI问题。

我可以将它用于集群环境中吗？¶

是哒，这是uWSGI的主要特性之一。你可以将多个实例绑定在不同的服务器上，而使用你的web服务器/代理/路由器的负载均衡功能，你可以分布负载。像 uWSGI RPC栈 这样的系统允许你快速调用远端节点的函数，而 uWSGI Legion子系统 允许你在多节点设置中选出一个master。

那么，为嘛会有所有那些超时配置标志？¶

理智选择超时时间是高可用性的关键。不要信任那些不允许你选择超时时间的网络应用。

我需要帮助！我该怎么做？¶

在uWSGI邮件列表上发布一条信息，其中包含你的

• 操作系统版本
• CPU架构
• 使用的web服务器（如果有的话）
• uWSGI版本
• uWSGI命令行或配置文件

你应该添加 –show-config 选项，然后把输出贴到消息中。这对找出uWSGI有啥问题将非常有用。你也可以使用调试符号进行 rebuild uWSGI ，并且将其运行在诸如 gdb 这样的调试器下。

uWSGI是一个浩大的工程，带有数百个选项。你应该做好准备，并不是所有的东西在第一次使用的时候都是对的。寻求帮助，寻求帮助，以及寻求帮助。如果你感到沮丧，那么不要把时间花在谴责和咆哮上 —— 相反，简单加入邮件列表，然后寻求帮助。它是开源的，如果你只是咆哮，那么只是无用功。

我不是系统管理员，也不是UNIX专家。我可以用uWSGI吗？¶

这是一个好问题 :) 但是忧伤的是，没有简单的答案。uWSGI在开发中并未考虑简单性，而是通用性。你可以通过其中一个快速入门来开始，如果有问题，只需在邮件列表，或者IRC频道中寻求帮助。

我可以如何为我的公司购买商业支持？¶

发送邮件到unbit.it上的info，并在主题中使用单词”uWSGI”。你发送的邮件应该包含你的公司信息以及你的具体要求。我们将尽快答复。

这会允许我在我古旧的ISP上运行我美妙的应用吗？¶

可能不行哦。uWSGI服务器要求一个现代的平台/环境。

基准在何处？¶

抱歉哈，我们只为回归测试进行“官方”基准。如果基准对你非常重要，那么你可以在邮件列表上搜索，自己做基准，或者Google一下。uWSGI赋予机器健康优先权，因此，不要期望你使用不切实际数目的并发连接数的 ab 测试无需调整就能完美进行管理。如果你想要进行有效的基准（并且避免有人在你的博客下咆哮），那么一些socket和网络知识是必须的。还要记得，uWSGI可以在各种模式下运行，因此，如果你不想看起来不可理喻，那么避免把preforking模式下配置的服务器与其他在非阻塞/异步模式下配置的服务器进行对比。

哎呀！服务器XXX比uWSGI快！用那个！¶

如前所述，uWSGI不是灵丹妙药，它并不打算让整个世界都喜欢，而显然，它也不是世界上最快的服务器。它就是一个软件，遵循一个你可能不喜欢，又或者爱得要死的问题“解决方法”。使用的方法对于某些情况下会更好，而应该在每个应用自己的优点上进行分析，使用适当而准确的真实世界的基准。

‘Harakiri模式’是什么？¶

在Unbit，我们在服务器上托管了数百个不可靠的web应用。它们所有都运行在没有限制（内核级别）环境下，其中因为一个实现错误导致的进程阻塞将会导致整个站点挂掉。而harakiri模式有两种操作模式：

• 一个我们定义为“原始，并且有点靠不住”（用于不带进程管理器的简单设置）
• 另一个我们定义为“可靠的”，依赖于uWSGI进程管理器 (见 ProcessManagement)。

第一个在每个请求的开始设置一个简单的告警。如果进程获得 SIGALRM 信号，那么它会终止。我们称其为不可靠的，因为你的应用或者你使用的一些模块可能会通过简单调用 alarm() ，从而覆盖或者简单取消告警。

第二个使用一个master进程共享内存区域 (通过 mmap)，它维护池中每个worker上的统计信息。在每个请求的开始，worker设置一个时间戳，表示过了多久， 进程将在其专用区域被杀死。这个时间戳会在每次成功请求之后清零。如果master进程发现了一个带有过去时间戳的worker，那么它会毫不留情地杀死它。

用uWSGI会让我的应用运行得更快吗？¶

不可能。web应用部署中的最大瓶颈是应用本身。如果你想要一个更快的环境，那么优化你的代码，或者使用诸如集群、缓存这样的技术。我们之所以说uWSGI快，是因为它引入非常少等待开销到部署结构中。

uWSGI环境中，对于性能和健壮性，什么是最重要的选项？¶

默认情况下，是用合理的“几乎是会所有”的值来配置uWSGI的。但是如果以及当事情开始变得不可控制的时候，调整是必须的。

• 增加（或减少）超时时间是重要的，修改socket监听队列大小也是如此。
• 考虑线程。如果你不需要线程，那么不要启用它们。
• 如果你只是运行一个应用，那么你可以禁用多解释器。
• 总是记住在生产环境上启用master进程。见 ProcessManagement 。
• 增加worker不是意味着“增加性能”，因此，基于你的应用的性质，为 workers 选项选择一个合适的值 (受IO限制，受CPU限制，IO等待……)

为什么不简单地使用HTTP作为协议？¶

一个好问题，它有一个简单的答案：HTTP解析很慢，真的很慢。为嘛我们应该做一个复杂的任务两次呢？web服务器已经解析请求了！ uwsgi protocol 对机器而言，是非常容易解析的，而HTTP对人类而言，是非常容易解析的。一旦人类被当成服务器使用，我们会放弃uwsgi协议，支持HTTP协议。这就是说，你也可以通过 原生HTTP支持, FastCGI, ZeroMQ 和其他协议使用uWSGI。

为嘛你支持配置的多种方式？¶

系统管理是件关于技能和品味的事。uWSGI试图为系统管理员提供尽可能多的选择来与任何已经能用的基础设施集成。拥有多种配置方法只是我们达成此目标的一种方式。

最好的webserver处理器是什么？¶

见 Web服务器集成.

加载配置文件¶

除了简单的磁盘文件，uWSGI支持通过多种方式加载配置文件:

uwsgi --ini http://uwsgi.it/configs/myapp.ini # HTTP
uwsgi --xml - # standard input
uwsgi --yaml fd://0 # file descriptor
uwsgi --json 'exec://nc 192.168.11.2:33000' # arbitrary executable

魔术变量¶

uWSGI配置文件可以包含“魔术”变量，以百分号%作为前缀。目前，定义了如下魔术变量 (你可以通过 uwsgi.magic_table 在Python中访问它们)。

注意，它们大多数指的是它们所在的文件，即使那个文件被包含在其他文件中。

一个例外是大部分的大写版本，指的是加载的第一个非模板配置文件。这意味着，第一个配置文件并不是通过 --include 或者 --inherit 加载的，而是通过例如 --ini, --yaml 或者 --config 加载的。这些是为了使用emperor，来指向用 --vassals-include 或者 --vassals-inherit 包含的实际的vassal配置文件，而不是模板。

例如，这里是 funnyapp.ini 。

[uwsgi]
socket = /tmp/%n.sock
module = werkzeug.testapp:test_app
processes = 4
master = 1

%n 将会使用配置文件的名字来替代，不加扩展名，因此，这个情况下的结果将会是

[uwsgi]
socket = /tmp/funnyapp.sock
module = werkzeug.testapp:test_app
processes = 4
master = 1

占位符¶

占位符是通过设置你自己发明的一个新的配置变量，在配置时间定义的自定义的魔术变量。

[uwsgi]
; These are placeholders...
my_funny_domain = uwsgi.it
set-ph = max_customer_address_space=64
set-placeholder = customers_base_dir=/var/www
; And these aren't.
socket = /tmp/sockets/%(my_funny_domain).sock
chdir = %(customers_base_dir)/%(my_funny_domain)
limit-as = %(max_customer_address_space)

可以直接指定占位符，或者使用 set-placeholder / set-ph 选项。后者在以下情况下有用：

• 更明显的表示出你在设置的是占位符，而不是常规选项。
• 在命令行设置选项，因为诸如 --foo=bar 这样的未知选项会被拒绝，但是 --set-placeholder foo=bar 是可以的。
• 当启用strict模式的时候，设置占位符。

占位符是可访问的，像任何uWSGI选项一样，在你的应用代码中，通过 uwsgi.opt 进行访问。

import uwsgi
print uwsgi.opt['customers_base_dir']

这个特性可以被（滥）用来减少你的应用所需的配置文件的数目。

类似地，可以使用 $(ENV_VAR) 和 @(file_name) 语法来包含环境变量和外部文本文件的内容。又见 uWSGI是如何解析配置文件的.

占位符数学 (自uWSGI 1.9.20-dev起)¶

你可以使用这种特殊的语法，应用数学公式到占位符上：

[uwsgi]
foo = 17
bar = 30
; total will be 50
total = %(foo + bar + 3)

运算符之间不要忘了空格。

在管道中（而不是一般的数学格式）执行运算：

[uwsgi]
foo = 17
bar = 30
total = %(foo + bar + 3 * 2)

‘total’ 将会被计算为100:

(((foo + bar) + 3) * 2)

可以用递增和递减快捷方式

[uwsgi]
foo = 29
; remember the space !!!
bar = %(foo ++)

bar将会是30

如果在两个项之间你不指定一个运算符，那么会假设使用“字符串连接”：

[uwsgi]
foo = 2
bar = 9
; remember the space !!!
bar = %(foo bar ++)

头两个项将会被计算为‘29’ (不是11，因为未指定任何数学运算)

‘@’魔法¶

我们已经看到了可以使用@(filename)形式来包含一个文件的内容

[uwsgi]
foo = @(/tmp/foobar)

真相是，’@’可以读取来自所有支持的uwsgi方案的内容

[uwsgi]
; read from a symbol
foo = @(sym://uwsgi_funny_function)
; read from binary appended data
bar = @(data://0)
; read from http
test = @(http://example.com/hello)
; read from a file descriptor
content = @(fd://3)
; read from a process stdout
body = @(exec://foo.pl)
; call a function returning a char *
characters = @(call://uwsgi_func)

命令行参数¶

例子:

uwsgi --socket /tmp/uwsgi.sock --socket 127.0.0.1:8000 --master --workers 3

环境变量¶

当作为环境变量传递时，会把选项首字母大写，并加上 UWSGI_ 前缀，而破折号会被下划线替代。

例子:

UWSGI_SOCKET=127.0.0.1 UWSGI_MASTER=1 UWSGI_WORKERS=3 uwsgi

INI文件¶

.INI文件实际上是一种标准的配置格式，用在许多应用中。它由 [section] 和 key=value 对组成。

一个样例uWSGI INI配置：

[uwsgi]
socket = /tmp/uwsgi.sock
socket = 127.0.0.1:8000
workers = 3
master = true

默认情况下，uWSGI使用 [uwsgi] 段，但是你可以在使用 filename:section 语法加载INI文件的时候指定另一个段名，也就是:

uwsgi --ini myconf.ini:app1

作为选择，你可以通过省略文件名并只指定段名来从相同的文件中加载另一个段。注意，技术上来讲，这会从上个加载的.ini文件中加载命名段，而不是从当前的文件中加载，因此，当包含其他文件的时候，小心为上。

[uwsgi]
# This will load the app1 section below
ini = :app1
# This will load the defaults.ini file
ini = defaults.ini
# This will load the app2 section from the defaults.ini file!
ini = :app2

[app1]
plugin = rack

[app2]
plugin = php

• 行内空格是不重要的。
• 以分号 (;) 或者一个哈希/井号 (#) 开头的行会被当成注释忽略。
• 可以在没有值那个部分的情况下设置布尔型的值。因此，简单的 master 等价于 master=true 。这或许与其他INI解析器，例如 paste.deploy ，并不兼容。
• 为了方便，uWSGI特殊识别裸 .ini 参数，因此，调用 uwsgi myconf.ini 等价于 uwsgi --ini myconf.ini 。

XML文件¶

根节点应该是 <uwsgi> ，而选项值是节点文本。

一个例子：

<uwsgi>
  <socket>/tmp/uwsgi.sock</socket>
  <socket>127.0.0.1:8000</socket>
  <master/>
  <workers>3</workers>
</uwsgi>

文件中还可以有多个 <uwsgi> 节，由不同的 id 属性标记。要选择使用的节，则在 xml 选项中的文件名之后指定其id，使用冒号作为分隔符。当使用这种 id 模式时，文件的根节点可以是任何你喜欢的。这会允许你将 uwsgi 配置节点嵌入到其他XML文件中。

<i-love-xml>
  <uwsgi id="turbogears"><socket>/tmp/tg.sock</socket></uwsgi>
  <uwsgi id="django"><socket>/tmp/django.sock</socket></uwsgi>
</i-love-xml>

• 可在没有文本值的情况下设置布尔类型的值。
• 为了方便起见，uWSGI特殊识别裸 .ini 参数，因此，调用 uwsgi myconf.xml 等价于 uwsgi --xml myconf.xml 。

JSON 文件¶

JSON应该使用一个键值对来表示一个对象，键是 “uwsgi” ，而值是配置变量的一个对象。支持原生JSON列表、布尔型和数字。

一个例子：

{"uwsgi": {
  "socket": ["/tmp/uwsgi.sock", "127.0.0.1:8000"],
  "master": true,
  "workers": 3
}}

再次，可以使用文件名后冒号来加载一个命名段。

{"app1": {
  "plugin": "rack"
}, "app2": {
  "plugin": "php"
}}

然后这样加载:

uwsgi --json myconf.json:app2

YAML 文件¶

根元素应该是 uwsgi 。布尔型选项要设置成 true 或 1 。

一个例子：

uwsgi:
  socket: /tmp/uwsgi.sock
  socket: 127.0.0.1:8000
  master: 1
  workers: 3

另外，一个命名段可以使用文件名后的冒号进行加载。

app1:
  plugin: rack
app2:
  plugin: php

然后这样加载它:

uwsgi --yaml myconf.yaml:app2

SQLite配置¶

LDAP 配置¶

LDAP是集中uWSGI服务器大型集群配置的一种灵活的方式。配置它是一个负责的主题。见 使用LDAP配置uWSGI 以获得更多信息。

简单的例子¶

一个非常普遍的问题是screwing-up the port on which the instance is listening.

为了模拟这样的错误，我们试着以非特权用户来绑定80端口:

uwsgi --uid 1000 --http-socket :80

uWSGI将会退出:

bind(): Permission denied [core/socket.c line 755]

在内部 (从内核的角度)，实例退出，状态为1

现在，我们想让实例在用户提供的配置失败的时候自动绑定到端口8080.

让我们来定义一个回退配置 (你可以将其保存为safe.ini):

[uwsgi]
print = Hello i am the fallback config !!!
http-socket = :8080
wsgi-file = welcomeapp.wsgi

现在，我们可以重新运行（损坏的）实例：

uwsgi --fallback-config safe.ini --uid 1000 --http-socket :80

现在，错误将如下：

bind(): Permission denied [core/socket.c line 755]
Thu Jul 25 21:55:39 2013 - !!! /home/roberto/uwsgi/uwsgi (pid: 7409) exited with status 1 !!!
Thu Jul 25 21:55:39 2013 - !!! Fallback config to safe.ini !!!
[uWSGI] getting INI configuration from safe.ini
*** Starting uWSGI 1.9.15-dev-a0cb71c (64bit) on [Thu Jul 25 21:55:39 2013] ***
...

正如你所见，实例检测到退出码1，并且用一个新的配置对自身打了二进制补丁 (无需更改pid，或者调用fork())

已破坏应用¶

另一个常见的问题是不能加载应用，但并非让整个站点挂掉，而是想要加载一个备用应用：

uwsgi --fallback-config safe.ini --need-app --http-socket :8080 --wsgi-file brokenapp.py

这里，键是–need-app。如果实例一直未能加载至少一个应用，那么它将会调用exit(1)。

多种回退层次¶

你的回退配置文件也可以指定一个fallback-config指令，允许多种回退层次。当心循环！！！

它是如何工作的¶

目标是在进程本身被销毁之前捕获到其退出码 (不想要调用另一个fork()，或者销毁已打开的文件描述符)

uWSGI大量使用atexit()钩子，因此我们仅需将回退处理器作为第一个进行注册 (钩子是以相反的顺序执行的)。

除此之外，我们需要在我们的atexit()钩子中获取退出码，这个默认不支持 (on_exit()函数现在已弃用)。

解决方法是用uwsgi_exit(x)对exit(x)“打补丁”，它是一个简单的设置uwsgi.last_exit_code内存指针的封装器。

现在，钩子仅需检测uwsgi.last_exit_code == 1，并最终再次execve()二进制文件，将回退配置传递给它

char *argv[3];
argv[0] = uwsgi.binary_path;
argv[1] = uwsgi.fallback_config;
argv[2] = NULL;
execvp(uwsgi.binary_path, argv);

注意事项¶

试着尽可能快地将–fallback-config放到你的配置树中。在回退文件被注册之前，各种配置解析器可能会失败 (调用exit(1))

for¶

for迭代由空格隔开的字符串。以下三个代码块是等价的。

[uwsgi]
master = true
; iterate over a list of ports
for = 3031 3032 3033 3034 3035
socket = 127.0.0.1:%(_)
endfor =
module = helloworld

<uwsgi>
  <master/>
  <for>3031 3032 3033 3034 3035</for>
    <socket>127.0.0.1:%(_)</socket>
  <endfor/>
  <module>helloworld</module>
</uwsgi>

uwsgi --for="3031 3032 3033 3034 3035" --socket="127.0.0.1:%(_)" --endfor --module helloworld

注意，for循环是分别被应用到块中的每一行的，而不是应用到块整体上。例如，这个：

[uwsgi]
for = a b c
socket = /var/run/%(_).socket
http-socket = /var/run/%(_)-http.socket
endfor =

展开为：

[uwsgi]
socket = /var/run/a.socket
socket = /var/run/b.socket
socket = /var/run/c.socket
http-socket = /var/run/a-http.socket
http-socket = /var/run/b-http.socket
http-socket = /var/run/c-http.socket

if-env¶

检查是否定义了一个环境变量，将其值放在上下文占位符中。

[uwsgi]
if-env = PATH
print = Your path is %(_)
check-static = /var/www
endif =
socket = :3031

if-exists¶

检查一个文件或目录是否存在。设置上下文占位符为找到的文件名。

[uwsgi]
http = :9090
; redirect all requests if a file exists
if-exists = /tmp/maintenance.txt
route = .* redirect:/offline
endif =

if-file¶

检查给定的路径是否存在，是否为一个常规的文件。设置上下文占位符为找到的文件名。

<uwsgi>
  <plugins>python</plugins>
  <http-socket>:8080</http-socket>
  <if-file>settings.py</if-file>
    <module>django.core.handlers.wsgi:WSGIHandler()</module>
  <endif/>
</uwsgi>

if-dir¶

检查给定的路径是否存在，是否为一个目录。设置上下文占位符为找到的文件名。

uwsgi:
  socket: 4040
  processes: 2
  if-dir: config.ru
  rack: %(_)
  endif:

if-opt¶

检查是否设置了给定选项，或者给定选项是否具有一个给定的值。设置上下文占位符为选项引用的值。

检查是否设置了一个选项，仅需将选项名传递给 if-opt 。

uwsgi:
  cheaper: 3
  if-opt: cheaper
  print: Running in cheaper mode, with initially %(_) processes
  endif:

要检查给定选项是否具有一个给定的值，则将 option-name=value 传递给 if-opt 。

uwsgi:
  # Set busyness parameters if it was chosen
  if-opt: cheaper-algo=busyness
  cheaper-busyness-max: 25
  cheaper-busyness-min: 10
  endif:

由于uWSGI解析其配置文件的方式，你只能使用uWSGI之前解析到的选项。特别是，这意味着：

• 只考虑在 if-opt 选项之上设置的选项。这包含了任何由前面 include (或者特定类型的包含，例如 ini) 选项设置的任何选项，但不要包含由前面 inherit 选项设置的选项)。

• if-opt 是在展开魔术变量之后，展开占位符和其他变量之前进行处理的。因此，如果你使用 if-opt 来比较一个选项的值，那么只使用魔术变量来核对该值和配置文件中一致。

  如果你在 if-opt 块内使用上下文占位符 %(_) ，那么应该没问题：任何占位符稍后将会被展开。

• 如果多次指定一个选项，那么 if-opt 只能看到第一个的值。

• 只会看到显式设置的值，而不会看到隐式默认值。

uWSGI核心¶