该模块能够使得Nginx与uWSGI进程进行交互,并且会控制传递给uWSGI进程的参数。对于uwsgi协议和uWSGI服务器,uWSGI服务器就是uwsgi协议的一个实现。
该模块首次提供出现在nginx-0.8.40版本中,因此,如果要使用这个功能那么必须要选择这个版本及其以上。
5.1 示例配置
location / { include uwsgi_params; uwsgi_pass unix:/var/run/example.com.sock; } |
一个有缓存的例子
http { uwsgi_cache_path /path/to/cache levels=1:2 keys_zone=NAME:10m inactive=5m;
server { location / { uwsgi_pass unix:/var/run/example.com.sock; uwsgi_cache NAME; uwsgi_cache_valid 200 302 1h; uwsgi_cache_valid 301 1d; uwsgi_cache_valid any 1m; uwsgi_cache_min_uses 1; uwsgi_cache_use_stale error timeout invalid_header http_500; } } } |
缓存只对后台Cache-Control、Expires等感兴趣,而Vary处理不受影响。
指 令 省略
传递到uWSGI服务器的参数
被传递到uWSGI服务器的请求头是以参数的形式实现的,从uWSGI服务器运行应用程序或者脚本,这些环境变量的参数格式通常很容易被取得。例如,"User-agent"头将会通过HTTP_USER_AGENT参数来传递,除了HTTP请求头之外,还有可能通过uwsgi_param指令来传递任意参数。
使用配置
下面的一个例子来自于Nginx官方提供,在此了解以下,有关这个例子的实施参考实例部分。
它是一个由单个uWSGI后台服务器实例提供多个主机名称或者是每个主机有多个应用的情况。因此,这个实例比较经典。
添加配置:
我先看以下Nginx的配置文件:
upstream uwsgi_host { server 127.0.0.1:1088; }
include uwsgi_params; uwsgi_param SCRIPT_NAME $app; uwsgi_param UWSGI_MODULE $app; uwsgi_param UWSGI_CALLABLE "${app}_handler"; uwsgi_param UWSGI_PYHOME $document_root; uwsgi_param UWSGI_CHDIR $document_root; uwsgi_modifier1 30; #properly sets PATH_INFO variable
server { server_name foo; root /var/www/foo;
location /app1/ { set $app app1; uwsgi_pass 127.0.0.1:1088; }
location /app2/ { set $app app2; uwsgi_pass 127.0.0.1:1088; } }
server { server_name bar; root /var/www/bar;
location /app1/ { set $app app1; uwsgi_pass uwsgi_host; }
location /app3/ { set $app app3; uwsgi_pass uwsgi_host; } }
|
在这个配置文件中,提供了两个域名,即foo和bar,而每个域名下都有两个应用,其中app1在两个域名下都有,这是为了测试效果,实际的应用中可能不会这么巧合,当然也不应定,比如index.py。
在这个配置中,使用了uwsgi协议的两个参数:SCRIPT_NAME和SERVER_NAME,它们将会被自动处理,SERVER_NAME在uwsgi_params文件中被映射,而SCRIPT_NAME被传递到明确地后台服务器,即uWSGI服务器,这是因为uWSGI的vhost应用名册上将键值设定为"host|script"格式,
具有相同的主机和相同的脚本名称,才会处理对相同应用程序处理所有的请求,例如,如果我们访问http://bar/app1/、http://foo/app1/,即使app1完全一样,但不会提供同样的功能,除非这两个网站完全一样,包括所有的数据。
如果没有提供脚本名称,那么就会为空,另外,第一次访问该脚本时首先会被初始化,例如:
这是第一次访问:
WSGI application 2 (SCRIPT_NAME=bar|app3) ready on interpreter 0x8272860 pid: 21532 bar [pid: 21532|app: 2|req: 1/10] 192.168.3.248 () {50 vars in 770 bytes} [Thu Jul 21 19:12:03 2011] GET /app3/ => generated 4 bytes in 20 msecs (HTTP/1.1 200) 1 headers in 45 bytes (0 switches on core 0) |
这是第二次访问:
bar [pid: 21527|app: 2|req: 2/11] 192.168.3.248 () {50 vars in 770 bytes} [Thu Jul 21 19:12:07 2011] GET /app3/ => generated 4 bytes in 0 msecs (HTTP/1.1 200) 1 headers in 45 bytes (0 switches on core 0) |
另外,注意UWSGI_MODULE 和 UWSGI_CALLABLE这两个变量,第一个即UWSGI_MODULE的功能在于能够为WSGI应用程序(应用程序是由UWSGI_PYHOME提供的,该参数用于添加Python的路径)提供一个入口点;第二个变量,即UWSGI_CALLABLE,它所指的的是被实例化类的名称。
创建Python模块
以下是三个app,原文有误,应该在每一个def行的结尾添加“:”。
app1.py
def app1_handler(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return b'app1' |
app2.py
def app2_handler(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return b'app2' |
app3.py
def app3_handler(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return b'app3' |
在这个设置中,uWSGI将会有两个绝然不同的app1实例(一个基于/var/www/foo/app1.py内容的foo主机名,另一个是基于/var/www/bar/app1.py内容的bar主机名),另外,还有主机名为foo的app2(基于/var/www/foo/app2.py内容)、主机名为foo的app3(基于/var/www/foo/app3.py内容)。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/27043155/viewspace-734734/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/27043155/viewspace-734734/