|
编者按：《通过demo学习OpenStack开发》专栏是刘陈泓的系列文章，专栏通过开发一个demo的形式来介绍一些参与OpenStack项目开发的必要的基础知识，希望帮助大家入门企业级Python项目的开发和OpenStack项目的开发。刘陈泓主要关注OpenStack的身份认证和计费领域。另外，还对云计算、分布式系统应用和开发感兴趣。
本文会重点讲解OpenStack中使用的API开发框架的使用。但是本文的目的并不是覆盖这些框架的使用细节，而是通过说明重要的部分，降低初学者的入门的门槛。框架的使用细节都可以从文档中找到。说明一下，除非特殊说明，本文中的相对路径都是相对于项目源码目录的相对路径。
Paste + PasteDeploy + Routes + WebOb
我们在API服务(1)中已经提到了，这个框架只在早期开始的项目中使用，新的项目都已经转到Pecan框架了。但是，早期的项目都是比较核心的项目，因此我们还是要学会如何使用这个框架。我们会以Keystone项目为例，来说明如何阅读使用这个框架的开发的API代码。
CNUTCon全球容器技术大会北京站，9月9日-10日，喜来登长城饭店，点击了解详情！
重点在于确定URL路由
RESTful API程序的主要特点就是URL path会和功能对应起来。这点从API文档就可以看得出来，比如用户管理的功能一般都放在/user这个路径下。因此，看一个RESTful
API程序，一般都是看它实现了哪些URL path，以及每个path对应了什么功能，这个一般都是由框架的URL路由功能负责的。所以，熟悉一个RESTful
API程序的重点在于确定URL路由。本章所说的这个框架对于初学者的难点也是如何确定URL路由。
WSGI入口和中间件
作为基础知识，你需要先了解一下WSGI的相关概念，可以参考这篇文章WSGI简介。
WSGI入口
在API服务(1)中提到了WSGI可以使用Apache进行部署，也可以使用eventlet进行部署。Keystone项目同时提供了这两种方案的代码，也就是我们要找的WSGI的入口。
Keystone项目在httpd/目录下，存放了可以用于Apache服务器部署WSGI服务的文件。其中，wsgi-keystone.conf是一个mod_wsgi的示例配置文件，keystone.py则是WSGI应用程序的入口文件。httpd/keystone.py也就是我们要找的入口文件之一。这个文件的内容很简单：
import os
from keystone.server import wsgi as wsgi_server
name = os.path.basename(__file__)
application = wsgi_server.initialize_application(name) |
文件中创建了WSGI入口需要使用的application对象。
keystone-all命令则是采用eventlet来进行部署时的入口，可以从setup.cfg文件按中确定keystone-all命令的入口：
[entry_points]
console_scripts =
keystone-all = keystone.cmd.all:main
keystone-manage = keystone.cmd.manage:main |
从setup.cfg文件的entry_points部分可以看出，keystone-all的入口是keystone/cmd/all.py文件中的main()函数，这个函数的内容也很简单：
def main():
eventlet_server.run(possible_topdir) |
main()函数的主要作用就是启动一个eventlet_server，配置文件从possible_topdir中查找。因为eventlet的部署方式涉及到eventlet库的使用方法，本文不再展开说明。读者可以在学会确定URL路由后再回来看这个代码。下面，继续以httpd/keystone.py文件作为入口来说明如何阅读代码。
Paste和PasteDeploy
httpd/keystone.py中调用的initialize_application(name)函数载入了整个WSGI应用，这里主要用到了Paste和PasteDeploy库。
def initialize_application(name):
...
def loadapp():
return keystone_service.loadapp(
'config:%s' % config.find_paste_config(), name)
_unused, application = common.setup_backends(
startup_application_fn=loadapp)
return application
|
上面是删掉无关代码后的initialize_application()函数。config.find_paste_config()用来查找PasteDeploy需要用到的WSGI配置文件，这个文件在源码中是etc/keystone-paste.ini文件，如果在线上环境中，一般是/etc/keystone-paste.init。keystone_service.loadapp()函数内部则调用了paste.deploy.loadapp()函数来加载WSGI应用，如何加载则使用了刚才提到的keystone-paste.ini文件，这个文件也是看懂整个程序的关键。
name很关键
在上面的代码中我们可以看到，name这个变量从httpd/keystone.py文件传递到initialize_application()函数，又被传递到keystone_service.loadapp()函数，最终被传递到paste.deploy.loadapp()函数。那么，这个name变量到底起什么作用呢？先把这个问题放在一边，我们后面再来解决它。
paste.ini
使用Paste和PasteDeploy模块来实现WSGI服务时，都需要一个paste.ini文件。这个文件也是Paste框架的精髓，这里需要重点说明一下这个文件如何阅读。
paste.ini文件的格式类似于INI格式，每个section的格式为[type:name]。这里重要的是理解几种不同type的section的作用。
composite: 这种section用于将HTTP请求分发到指定的app。
app: 这种section表示具体的app。
filter: 实现一个过滤器中间件。
pipeline: 用来把把一系列的filter串起来。
上面这些section是在keystone的paste.ini中用到的，下面详细介绍一下如何使用。这里需要用到WSGIMiddleware(WSGI中间件)的知识，可以在WSGI简介这篇文章中找到。
section composite
这种section用来决定如何分发HTTP请求。Keystone的paste.ini文件中有两个composite的section：
[composite:main]
use = egg:Paste#urlmap
v2.0 = public_api
/v3 = api_v3
/ = public_version_api[composite:admin]
use = egg:Paste#urlmap
/v2.0 = admin_api
/v3 = api_v3
/ = admin_version_api
|
在composite seciont中，use是一个关键字，指定处理请求的代码。egg:Paste#urlmap表示到Paste模块的egg-info中去查找urlmap关键字所对应的函数。在virtualenv环境下，是文件/lib/python2.7/site-packages/Paste-2.0.2.dist-info/metadata.json：
{
...
"extensions": {
...
"python.exports": {
"paste.composite_factory": {
"cascade": "paste.cascade:make_cascade",
"urlmap": "paste.urlmap:urlmap_factory"
},
...
} |
在这个文件中，你可以找到urlmap对应的是paste.urlmap:urlmap_factory，也就是paste/urlmap.py文件中的urlmap_factory()函数。
composite section中其他的关键字则是urlmap_factory()函数的参数，用于表示不同的URL
path前缀。urlmap_factory()函数会返回一个WSGI app，其功能是根据不同的URL
path前缀，把请求路由给不同的app。以[composite:main]为例：
[composite:main]
use = egg:Paste#urlmap
/v2.0 = public_api # /v2.0 开头的请求会路由给public_api处理
/v3 = api_v3 # /v3 开头的请求会路由个api_v3处理
/ = public_version_api # / 开头的请求会路由给public_version_api处理 |
路由的对象其实就是paste.ini中其他secion的名字，类型必须是app或者pipeline。
section pipeline
pipeline是把filter和app串起来的一种section。它只有一个关键字就是pipeline。我们以api_v3这个pipeline为例：
[pipeline:api_v3]
# The last item in this pipeline must be service_v3
or an equivalent
# application. It cannot be a filter.
pipeline = sizelimit url_normalize request_id build_auth_context
token_auth admin_token_auth json_body ec2_extension_v3
s3_extension
simple_cert_extension revoke_extension federation_extension
oauth1_extension endpoint_filter_extension endpoint_policy_extension
service_v3 |
pipeline关键字指定了很多个名字，这些名字也是paste.ini文件中其他section的名字。请求会从最前面的section开始处理，一直向后传递。pipeline指定的section有如下要求：
最后一个名字对应的section一定要是一个app。
非最后一个名字对应的section一定要是一个filter。
section filter
filter是用来过滤请求和响应的，以WSGI中间件的方式实现。
[filter:sizelimit]
paste.filter_factory = oslo_middleware.sizelimit:
RequestBodySizeLimiter.factory |
这个是api_v3这个pipeline指定的第一个filter，作用是限制请求的大小。其中的paste.filter_factory表示调用哪个函数来获得这个filter中间件。
section app
app表示实现主要功能的应用，是一个标准的WSGI application。
[app:service_v3]
paste.app_factory = keystone.service:v3_app_factory |
paste.app_factory表示调用哪个函数来获得这个app。
总结一下
paste.ini中这一大堆配置的作用就是把我们用Python写的WSGI application和middleware串起来，规定好HTTP请求处理的路径。
name是用来确定入口的
上面我们提到了一个问题，就是name变量的作用到底是什么？name变量表示paste.ini中一个section的名字，指定这个section作为HTTP请求处理的第一站。在Keystone的paste.ini中，请求必须先由[composite:main]或者[composite:admin]处理，所以在keystone项目中，name的值必须是main或者admin。
上面提到的httpd/keystone.py文件中，name等于文件名的basename，所以实际部署中，必须把keystone.py重命名为main.py或者admin.py。
举个例子
一般情况下，从Keystone服务获取一个token时，会使用下面这个API：
POST http://hostname:35357/v3/auth/tokens |
我们根据Keystone的paste.ini来说明这个API是如何被处理的：
hostname:35357 这一部分是由Web服务器处理的，比如Apache。然后，请求会被转到WSGI的入口，也就是httpd/keystone.py中的application对象取处理。
application对象是根据paste.ini中的配置来处理的。这里会先由[composite:admin]来处理（一般是admin监听35357端口，main监听5000端口）。
[composite:admin]发现请求的path是/v3开头的，于是就把请求转发给[pipeline:api_v3]去处理，转发之前，会把/v3这个部分去掉。
[pipeline:api_v3]收到请求，path是/auth/tokens，然后开始调用各个filter来处理请求。最后会把请求交给[app:service_v3]进行处理。
[app:service_v3]收到请求，path是/auth/tokens，然后交给最终的WSGI app去处理。
下一步
到此为止，paste.ini中的配置的所有工作都已经做完了。下面请求就要转移到最终的app内部去处理了。前面已经说过了，我们的重点是确定URL路由，那么现在还有一部分的path的路由还没确定，/auth/tokens，这个还需要下一步的工作。
中间件的实现
上面我们提到paste.ini中用到了许多的WSGI中间件，那么这些中间件是如何实现的呢？我们来看一个例子就知道了。
[filter:build_auth_context]
paste.filter_factory =
keystone.middleware:AuthContextMiddleware.factory |
build_auth_context这个中间件的作用是在WSGI的environ中添加KEYSTONE_AUTH_CONTEXT这个键，包含的内容是认证信息的上下文。实现这个中间件的类继承关系如下：
keystone.middleware.core.AuthContextMiddleware
-> keystone.common.wsgi.Middleware
-> keystone.common.wsgi.Application
-> keystone.common.wsgi.BaseApplication |
这里实现的关键主要在前面两个类中。
keystone.common.wsgi.Middleware类实现了__call__()方法，这个就是WSGI中application端被调用时运行的方法。
class Middleware(Application):
...
@webob.dec.wsgify()
def __call__(self, request):
try:
response = self.process_request(request)
if response:
return response
response = request.get_response(self.application)
return self.process_response(request, response)
except exceptin.Error as e:
...
... |
__call__()方法实现为接收一个request对象，返回一个response对象的形式，然后使用WebOB模块的装饰器webob.dec.wsgify()将它变成标准的WSGI
application接口。这里的request和response对象分别是webob.Request和webob.Response。这里，__call__()方法内部调用了self.process_request()方法，这个方法在keystone.middleware.core.AuthContextMiddleware中实现：
class AuthContextMiddleware(wsgi.Middleware):
...
def process_request(self, request):
...
request.environ[authorization.AUTH_CONTEXT_ENV] = auth_context |
这个函数会根据功能设计创建auth_context，然后赋值给`request.environ[‘KEYSTONE_AUTH_CONTEXT]“，这样就能通过WSGI
application方法的environ传递到下一个WSGI application中去了。
最后的Application
上面我们已经看到了，对于/v3开头的请求，在paste.ini中会被路由到[app:service_v3]这个section，会交给keystone.service:v3_app_factory这个函数生成的application处理。最后这个application需要根据URL
path中剩下的部分，/auth/tokens，来实现URL路由。从这里开始，就需要用到Routes模块了。
同样由于篇幅限制，我们只能展示Routes模块的大概用法。Routes模块是用Python实现的类似Rails的URL路由系统，它的主要功能就是把path映射到对应的动作。
Routes模块的一般用法是创建一个Mapper对象，然后调用该对象的connect()方法把path和method映射到一个controller的某个action上，这里controller是一个自定义的类实例，action是表示controller对象的方法的字符串。一般调用的时候还会指定映射哪些方法，比如GET或者POST之类的。
举个例子，来看下keystone/auth/routers.py的代码：
class Routers(wsgi.RoutersBase):
def append_v3_routers(self, mapper, routers):
auth_controller = controllers.Auth()
self._add_resource(
mapper, auth_controller,
path='/auth/tokens',
get_action='validate_token'
head_action='check_token',
post_action='authenticate_for_token',
delete_action='revoke_token',
rel=json_home.build_v3_resource_relation('auth_tokens')) ...
|
这里调用了自己Keystone自己封装的_add_resource()方法批量为一个/auth/tokens这个path添加多个方法的处理函数。其中，controller是一个controllers.Auth实例，也就是
keystone.auth.controllers.Auth。其他的参数，我们从名称可以猜出其作用是指定对应方法的处理函数，比如get_action用于指定GET方法的处理函数为validate_token。我们再深入一下，看下_add_resource()这个方法的实现：
def _add_resource(self, mapper, controller, path,
rel,
get_action=None, head_action=None, get_head_action=None,
put_action=None, post_action=None, patch_action=None,
delete_action=None, get_post_action=None,
path_vars=None, status=json_home.Status.STABLE):
...
if get_action:
getattr(controller, get_action) # ensure the attribute
exists
mapper.connect(path, controller=controller, action=get_action,
conditions=dict(method=['GET']))
... |
这个函数其实很简单，就是调用mapper对象的connect方法指定一个path的某些method的处理函数。
Keystone项目的代码结构
Keystone项目把每个功能都分到单独的目录下，比如token相关的功能是放在keystone/token/目录下，assignment相关的功能是放在keystone/assignment/目录下。目录下都一般会有三个文件：routers.py,
controllers.py, core.py。routers.py中实现了URL路由，把URL和controllers.py中的action对应起来；controllers.py中的action调用core.py中的底层接口实现RESTful
API承诺的功能。所以，我们要进一步确定URL路由是如何做的，就要看routers.py文件。
注意，这个只是Keystone项目的结构，其他项目即使用了同样的框架，也不一定是这么做的。
Keystone中的路由汇总
每个模块都定义了自己的路由，但是这些路由最终要还是要通过一个WSGI application来调用的。上面已经提到了，在Keystone中，/v3开头的请求最终都会交给keystone.service.v3_app_factory这个函数生成的application来处理。这个函数里也包含了路由最后分发的秘密，我们来看代码：
def v3_app_factory(global_conf, **local_conf):
...
mapper = routes.Mapper()
...
router_modules = [auth,
assignment,
catalog,
credential,
identity,
policy,
resource]
...
for module in router_modules:
routers_instance = module.routers.Routers()
_routers.append(routers_instance)
routers_instance.append_v3_routers(mapper, sub_routers)
# Add in the v3 version api
sub_routers.append(routers.VersionV3('public', _routers))
return wsgi.ComposingRouter(mapper, sub_routers)
|
v3_app_factory()函数中先遍历了所有的模块，将每个模块的路由都添加到同一个mapper对象中，然后把mapper对象作为参数用于初始化wsgi.ComposingRouter对象，所以我们可以判断，这个wsgi.ComposingRouter对象一定是一个WSGI
application，我们看看代码就知道了：
class Router(object):
"""WSGI middleware that maps incoming
requests to WSGI apps.""" def __init__(self, mapper):
self.map = mapper
self._router = routes.middleware.RoutesMiddleware(self._dispatch,
self.map)
@webob.dec.wsgify()
def __call__(self, req):
return self._router
...
class ComposingRouter(Router):
def __init__(self, mapper=None, routers=None):
...
|
上述代码证实了我们的猜测。这个ComposingRouter对象被调用时（在其父类Router中实现），会返回一个WSGI
application。这个application中则使用了routes模块的中间件来实现了请求路由，在routes.middleware.RoutesMiddleware中实现。这里对path进行路由的结果就是返回各个模块的controllers.py中定义的controller。各个模块的controller都是一个WSGI
application，这个你可以通过这些controller的类继承关系看出来。
但是这里只讲到了，routes模块把path映射到了一个controller，但是如何把对path的处理映射到controller的方法呢？这个可以从controller的父类keystone.common.wsgi.Application的实现看出来。这个Application类中使用了environ['wsgiorg.routing_args']中的数据来确定调用controller的哪个方法，这些数据是由上面提到的routes.middleware.RoutesMiddleware设置的。
总结
到这里我们大概把Paste + PasteDeploy + Routes + WebOb这个框架的流程讲了一遍，从本文的长度你就可以看出这个框架有多啰嗦，用起来有多麻烦。下一篇文章我们会讲Pecan框架，我们的demo也将会使用Pecan框架来开发。 |
