问题背景
最近在研究openstack 服务的源代码,由于项目代码较多对其又不熟悉,刚开始就不知道从哪里开始入手分析。经过分析发现,在正式分析源码之前需要对python的wsgi、paste、routes和webob这几个模块有所了解才可以继续深入。在此,就我对paste的学习理解首先分享出来,其余模块接下来会娓娓道来。
研究对象
- Devstack 安装的OpenStack Pike版本的Cinder项目
研究过程
1、打开cinder项目下的paste.ini文件,如下所示:
[composite:osapi_volume]
use = call:cinder.api:root_app_factory
/: apiversions
/v1: openstack_volume_api_v1
/v2: openstack_volume_api_v2
/v3: openstack_volume_api_v3
[composite:openstack_volume_api_v1]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv1
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1
[composite:openstack_volume_api_v2]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv2
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2
[composite:openstack_volume_api_v3]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv3
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
[filter:request_id]
paste.filter_factory = oslo_middleware.request_id:RequestId.factory
[filter:http_proxy_to_wsgi]
paste.filter_factory = oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory
[filter:cors]
paste.filter_factory = oslo_middleware.cors:filter_factory
oslo_config_project = cinder
[filter:faultwrap]
paste.filter_factory = cinder.api.middleware.fault:FaultWrapper.factory
[filter:osprofiler]
paste.filter_factory = osprofiler.web:WsgiMiddleware.factory
[filter:noauth]
paste.filter_factory = cinder.api.middleware.auth:NoAuthMiddleware.factory
[filter:sizelimit]
paste.filter_factory = oslo_middleware.sizelimit:RequestBodySizeLimiter.factory
[app:apiv1]
paste.app_factory = cinder.api.v1.router:APIRouter.factory
[app:apiv2]
paste.app_factory = cinder.api.v2.router:APIRouter.factory
[app:apiv3]
paste.app_factory = cinder.api.v3.router:APIRouter.factory
[pipeline:apiversions]
pipeline = cors http_proxy_to_wsgi faultwrap osvolumeversionapp
[app:osvolumeversionapp]
paste.app_factory = cinder.api.versions:Versions.factory
[filter:keystonecontext]
paste.filter_factory = cinder.api.middleware.auth:CinderKeystoneContext.factory
[filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
通过观察,我们很快就能发现这个文件的规律。都是以[type:name]的形式组织起来的,只不过type:name的名称和所包含的内容不太相同而已,接下来我们就对这个文件进行分析;
2、首先,我们需要明确几个概念:
- 针对composite、app、filter或者pipeline这种带有[]的,我们称之为section;
- composite:request进来后通过的第一个section,表示需要将一个http url request调度到一个或者多个application上;
- filter:是一个实现了过滤功能的中间件(将application进行进一步的封装),用于过滤request和response;
- pipeline:最后一个名字对应的一定是app类型,非最后一个名字对应的是filter;
- app:一个app就是一个实现主要功能的具体application。所以,app必须是callable object类型,接受的参数(environ, start_response),这是WSGI server交给application的符合WSGI规范的参数。
3、下面对各个section进行简单介绍
(1)[composite:name]
composite section定义了一种application,表示将请求调度定向到多个或者多种应用上。composite section可以是WSGI application的集合,可以包括其他application section中定义的application,常用用法:
[composite:osapi_volume]
use = call:cinder.api:root_app_factory
/: apiversions
/v1: openstack_volume_api_v1
/v2: openstack_volume_api_v2
/v3: openstack_volume_api_v3
[composite:openstack_volume_api_v1]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv1
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1
[composite:openstack_volume_api_v2]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv2
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2
[composite:openstack_volume_api_v3]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv3
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
(2)[filter:name]
filter section定义了一个过滤器,过滤器接收一个application参数作为对象,并返回一个封装后的application;
(3)[filter-app:name]
filter-app section定义的也是过滤器,这个过滤器直接作用在application上面。filter-app section表明对某个application进行修饰,需要修饰的application通过参数next指明,例如:
[filter-app:myblog]
use = egg:Authentication
next = myblogapp
这个字段表明在正式调用myblogapp之前,会调用egg:Authentication进行用户验证,随后才会调用myblogapp进行处理,这也就实现了对myblogapp的修饰。
(4)[pipeline:name]
当使用多个filter的时候需要使用pipeline的方式,它需要提供一个key参数pipeline,后面的值是一个列表,最后以应用结尾。如下:
[pipeline:apiversions]
pipeline = cors http_proxy_to_wsgi faultwrap osvolumeversionapp
(5)[app:name]
app section直接或间接地定义了一个符合WSGI协议的应用application,有以下几种使用方法:
- 指向某个配置文件中的application
[app:app_1]
use = config:another_config_file.ini
- 指向某个URL
[app:app_2]
use = egg:App_2 - 指向从指定模块可调用的application
[app:app_3]
use = call:my.project:APP_3 - 指向其他已经定义或即将定义的section
[app:app_4]
use = app_4 - 直接指向具体的python代码(cinder中,应用的就是这种定义的section方式)
[app:app_5]
paste.app_factory = myapp.moudulename:app_factor