nova创建虚拟机源码分析系列之三 PasteDeploy

上一篇博文介绍WSGI在nova创建虚拟机过程的作用是解析URL，是以一个最简单的例子去给读者有一个印象。在openstack中URL复杂程度也大大超过上一个例子。所以openstack使用了PasteDeploy模块去解析复杂的URL。

首先看“笨办法”是如何处理不同的URL。

在WSGI简单的模型中，如果有多个URL，可以判断请求方和请求路径的然后分别处理不同的URL。

处理函数 app.py

def application(environ, start_response):
    method = environ['REQUEST_METHOD']  #从环境变量中提取请求方法
    path = environ['PATH_INFO']         #从环境变量中提取请求路径
    if method=='GET' and path=='/':     #通过判断的方法来确定处理的函数
        return <h1>path = /</h1> #该函数对应的URL是 "/"
    if method=='POST' and path='/signin':
        return <h1>path = /signin </h1> #该函数对应URL的是 "/sigin"

服务器函数 server.py

# 从wsgiref模块导入:
from wsgiref.simple_server import make_server
# 导入我们自己编写的application函数:
from hello import application

# 创建一个服务器，IP地址为空，端口是8000，处理函数是application:
httpd = make_server('', 8000, application)
print "Serving HTTP on port 8000..."
# 开始监听HTTP请求:
httpd.serve_forever()

这种方法是简单，直接的，但也是可重复性差，不可维护的。一个restful中有可能50个以上的URL路径，如果这么写下去，那维护的人要抓狂。

所以要以一种简单清晰，可维护性好的方式去解析URL，这种方式便是使用PasteDeploy模型。

PasteDeploy的工作模式是使用一个配置文件configure.ini去解析URL。借鉴一个例子来讲解，原文 http://blog.csdn.net/li_101357/article/details/52755367

在家里水系统的模型大概如下图,以及对应的模拟路径：

总开关      /main

淋浴器      /main/boiler/shower

水龙头      /main/tap

PasteDeploy模型中有4中部件，分别是：

    

       

对应到上例：

1. app             水龙头  淋浴器
2. filter            热水器
3. pipeline      热水器  + 淋浴器
4. composite  总开关

确定了对应的URL之后，使用PasteDeploy组件来构造解析文件configure.ini。

[composite:main]
use = egg:Paste#urlmap
/main/tap = tap
/main/boil/shower = pip_to_shower

[app:tap]
paste.app_factory = tap:app_factory
in_arg = water

[pipeline:pip_to_shower]
pipeline = boiler shower

[filter:boiler]
paste.filter_app_factory = boiler:filter_app_factory
in_arg = water

[app:shower]
paste.app_factory = shower:app_factory
in_arg = hot_water

 [composite:main]

　　use = egg:Paste#urlmap

　　/main/tap = tap

　　/main/boil/shower = pip_to_shower

Paste#urlmap 表示，默认使用Paste.urlmap。
use = egg:Paste#urlmap  意味着直接使用来自于Paste包的urlmap的composite应用。 urlmap是特别常
见的composite应用——它使用路径前缀来映射将你的请求与其他应用对应起来。

基本含义就是说，这是Paste已经提供好的一个composite，如果你想自定义就需要另外写一个composite_factory了。

[app:tap]

      paste.app_factory = tap:app_factory

      in_arg = water

 表示路径"/tap"的处理方法paste.app_factory存在于tap.py文件的的app_factory中，这是一个方法。

[pipeline:pip_to_shower]

      pipeline = boiler shower

pipeline 主要起到组合的作用，将filter(过滤器)和app(应用)组合起来，形成一条管道。

 [filter:boiler]

　　paste.filter_app_factory = boiler:filter_app_factory

       in_arg = water

filter类似app，只不过换成了paste.filter_app_factory，filter首先执行过滤功能，然后执行app。

配置文件中将路径的处理都配置好：

　　/main/tap 路径对应的处理函数 tap ，tap是文件tap.py的app_factory方法。

   　 /main/boil/shower 路径对应的处理函数是管道 pip_to_shower 。管道由过滤器 boiler和应用shower组成。首次经过boiler的过滤，然后调用shower函数处理。

下面完成tap、shower和filter文件。

tap.py

class Tap(object):  
    def __init__(self, in_arg):  
        self.in_arg = in_arg  
  
    def __call__(self, environ, start_response):  
        print 'Tap'  
        start_response('200 ok', [('Content-Type', 'text/html')])  
        return "<h1> Tap! </h1>" 
  
def app_factory(global_config, in_arg):  
    return Tap(in_arg)  

app_factory是tap对应的处理方法，返回时调用了Tap方法，Tap对应的是类Tap的__call__方法，在该方法中打印一个"Tap"，然后发送报文头，最后返回一个字符串。

 shower.py

class Shower(object):  
    def __init__(self, in_arg):  
        self.in_arg = in_arg  
  
    def __call__(self, environ, start_response):  
        print 'Shower'  
        start_response('200 ok', [('Content Type', 'text/html')])  
        return "<h1> Shower! </h1>"  
  
def app_factory(global_config, in_arg):  
    return Shower(in_arg) 

shower的分析同上

boiler.py

class Boiler(object):  
    def __init__(self, app, in_arg):  
        self.app = app  
        self.in_arg = in_arg  
  
    def __call__(self, environ, start_response):  
        print 'Boiler'  
        return self.app(environ, start_response)  

    def filter_app_factory(app, global_config, in_arg):
        return Boiler(app, in_arg)  

 filter_app_factory是boiler对应的处理方法，其中传入的参数中有一个app，返回时调用了Boiler,并传入参数app。

Boiler是类Boiler的__call__方法，首先打印了字符串"Boiler"，然后返回时调用了函数app。这个app具体到本例就是调用了shower

所有的文件都准备齐全了，接下来开启WSGI服务，让程序跑起来。

server.py

    from wsgiref.simple_server import make_server  
    from paste import httpserver  
    from paste.deploy import loadapp  
    import os  
      
    if __name__ == '__main__':  
        configfile = 'configure.ini' #定义配置文件 
        appname = 'main'             #composite的名称
        wsgi_app = loadapp('config:%s' % os.path.abspath(configfile), appname) #载入配置文件  
        
　　　　　print "start the server listening on 8080"
        server = make_server('0.0.0.0', 8080, wsgi_app)  
        server.serve_forever()  

运行server程序。

 

 在浏览器中请求URL http://[ip ]:8080/main/tap

 在浏览器中请求URL http://[ip ]:8080/main/boiler/shower

 小结：

使用PasteDeploy模块将URL解析从判断的方式转变到文件配置的方式。

使用configuer.ini文件配置了URL /main/tap 对应处理函数 app_factory和/main/boiler/shower 对应处理函数 shower.py中的app_factory。

本篇主要讲的是使用PasteDeploy模块去配置WSGI解析URL。在openstack源码中就是基于这样的模型去完成restful 的解析，处理等。当一条restful的请求如：http://192.168.252.177:5000/v2.0/token

到达服务器时，服务器处理的流程就是如上，通过配置文件查找URL处理函数，然后调用处理函数返回处理结果。

通过对简单模型的掌握，便于理解后续的复杂的内容。

本篇博文参考：http://blog.csdn.net/li_101357/article/details/52755367