nova创建虚拟机源码分析系列之三 PasteDeploy
2017-10-30 19:39
561 查看
上一篇博文介绍WSGI在nova创建虚拟机过程的作用是解析URL,是以一个最简单的例子去给读者有一个印象。在openstack中URL复杂程度也大大超过上一个例子。所以openstack使用了PasteDeploy模块去解析复杂的URL。
首先看“笨办法”是如何处理不同的URL。
在WSGI简单的模型中,如果有多个URL,可以判断请求方和请求路径的然后分别处理不同的URL。
处理函数 app.py
服务器函数 server.py
这种方法是简单,直接的,但也是可重复性差,不可维护的。一个restful中有可能50个以上的URL路径,如果这么写下去,那维护的人要抓狂。
所以要以一种简单清晰,可维护性好的方式去解析URL,这种方式便是使用PasteDeploy模型。
PasteDeploy的工作模式是使用一个配置文件configure.ini去解析URL。借鉴一个例子来讲解,原文 http://blog.csdn.net/li_101357/article/details/52755367
在家里水系统的模型大概如下图,以及对应的模拟路径:
PasteDeploy模型中有4中部件,分别是:
对应到上例:
app 水龙头 淋浴器
filter 热水器
pipeline 热水器 + 淋浴器
composite 总开关
确定了对应的URL之后,使用PasteDeploy组件来构造解析文件configure.ini。
[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
app_factory是tap对应的处理方法,返回时调用了Tap方法,Tap对应的是类Tap的__call__方法,在该方法中打印一个"Tap",然后发送报文头,最后返回一个字符串。
shower.py
shower的分析同上
boiler.py
filter_app_factory是boiler对应的处理方法,其中传入的参数中有一个app,返回时调用了Boiler,并传入参数app。
Boiler是类Boiler的__call__方法,首先打印了字符串"Boiler",然后返回时调用了函数app。这个app具体到本例就是调用了shower
所有的文件都准备齐全了,接下来开启WSGI服务,让程序跑起来。
server.py
运行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
首先看“笨办法”是如何处理不同的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中部件,分别是:
对应到上例:
app 水龙头 淋浴器
filter 热水器
pipeline 热水器 + 淋浴器
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
相关文章推荐
- nova创建虚拟机源码分析系列之四 nova代码模拟
- nova创建虚拟机源码分析系列之五 nova源码分发实现
- nova创建虚拟机源码分析系列之八 compute创建虚机
- nova创建虚拟机源码分析系列之七 传入参数转换成内部id
- nova创建虚拟机源码分析系列之六 api入口create方法
- nova创建虚拟机源码系列分析之二 wsgi模型
- nova创建虚拟机源码分析系列之一 restful api
- nova创建虚拟机过程源码简要分析(一)
- OpenStack Nova深入学习 -- 创建instance的过程之源码分析
- Extjs4 源码分析系列一 类的创建过程
- redis客户端Jedis源码分析系列——连接池的创建过程
- OpenStack之Nova分析——创建虚拟机(五)
- Nova创建虚拟机的底层代码分析
- nova-api源码分析(APP的创建)
- OpenStack基于Libvirt的虚拟化平台调度实现----Nova虚拟机动态迁移源码分析
- 卷二 Dalvik与Android源码分析 第二章 进程与线程 2.1 Dalvik虚拟机的进程创建机制 图书版试读--请勿转发
- OpenStack之Nova分析——创建虚拟机(一)
- OpenStack之Nova分析——创建虚拟机(六)
- OpenStack之Nova分析——创建虚拟机(七)——创建虚拟机镜像文件
- OpenStack基于Libvirt的虚拟化平台调度实现----Nova虚拟机动态迁移源码分析