神刀安全网

通过demo学习OpenStack开发–API服务(2)

编者按:《通过demo学习OpenStack开发》专栏是刘陈泓的系列文章,专栏通过开发一个demo的形式来介绍一些参与OpenStack项目开发的必要的基础知识,希望帮助大家入门企业级Python项目的开发和OpenStack项目的开发。刘陈泓主要关注OpenStack的身份认证和计费领域。另外,还对云计算、分布式系统应用和开发感兴趣。

本文会重点讲解OpenStack中使用的API开发框架的使用。但是本文的目的并不是覆盖这些框架的使用细节,而是通过说明重要的部分,降低初学者的入门的门槛。框架的使用细节都可以从文档中找到。说明一下,除非特殊说明,本文中的相对路径都是相对于项目源码目录的相对路径。

Paste + PasteDeploy + Routes + WebOb

我们在API服务(1)中已经提到了,这个框架只在早期开始的项目中使用,新的项目都已经转到Pecan框架了。但是,早期的项目都是比较核心的项目,因此我们还是要学会如何使用这个框架。我们会以Keystone项目为例,来说明如何阅读使用这个框架的开发的API代码。

重点在于确定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.initkeystone_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:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

0

我们根据Keystone的paste.ini来说明这个API是如何被处理的:

  1. hostname:35357 这一部分是由Web服务器处理的,比如Apache。然后,请求会被转到WSGI的入口,也就是 httpd/keystone.py 中的 application 对象取处理。
  2. application 对象是根据paste.ini中的配置来处理的。这里会先由[composite:admin]来处理(一般是admin监听35357端口,main监听5000端口)。
  3. [composite:admin]发现请求的path是/v3开头的,于是就把请求转发给[pipeline:api_v3]去处理,转发之前,会把/v3这个部分去掉。
  4. [pipeline: api_v3 ]收到请求,path是/auth/tokens,然后开始调用各个filter来处理请求。最后会把请求交给[app: service_v3 ]进行处理。
  5. [app:service_v3]收到请求,path是/auth/tokens,然后交给最终的WSGI app去处理。

下一步

到此为止,paste.ini中的配置的所有工作都已经做完了。下面请求就要转移到最终的app内部去处理了。前面已经说过了,我们的重点是确定URL路由,那么现在还有一部分的path的路由还没确定,/auth/tokens,这个还需要下一步的工作。

中间件的实现

上面我们提到paste.ini中用到了许多的WSGI中间件,那么这些中间件是如何实现的呢?我们来看一个例子就知道了。

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

1

build_auth_context这个中间件的作用是在WSGI的environ中添加 KEYSTONE_AUTH_CONTEXT 这个键,包含的内容是认证信息的上下文。实现这个中间件的类继承关系如下:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

2

这里实现的关键主要在前面两个类中。

keystone.common.wsgi.Middleware 类实现了 __call__() 方法,这个就是WSGI中application端被调用时运行的方法。

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

3

__call__() 方法实现为接收一个request对象,返回一个response对象的形式,然后使用WebOB模块的装饰器 webob.dec.wsgify() 将它变成标准的WSGI application接口。这里的request和response对象分别是 webob.Requestwebob.Response 。这里, __call__() 方法内部调用了 self.process_request() 方法,这个方法在 keystone.middleware.core.AuthContextMiddleware 中实现:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

4

这个函数会根据功能设计创建 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 的代码:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

5

这里调用了自己Keystone自己封装的 _add_resource() 方法批量为一个 /auth/tokens 这个path添加多个方法的处理函数。其中,controller是一个 controllers.Auth 实例,也就是 keystone.auth.controllers.Auth 。其他的参数,我们从名称可以猜出其作用是指定对应方法的处理函数,比如 get_action 用于指定GET方法的处理函数为 validate_token 。我们再深入一下,看下 _add_resource() 这个方法的实现:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

6

这个函数其实很简单,就是调用mapper对象的connect方法指定一个path的某些method的处理函数。

Keystone项目的代码结构

Keystone项目把每个功能都分到单独的目录下,比如token相关的功能是放在 keystone/token/ 目录下,assignment相关的功能是放在 keystone/assignment/ 目录下。目录下都一般会有三个文件: routers.py, controllers.py, core.pyrouters.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来处理。这个函数里也包含了路由最后分发的秘密,我们来看代码:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

7

v3_app_factory() 函数中先遍历了所有的模块,将每个模块的路由都添加到同一个mapper对象中,然后把mapper对象作为参数用于初始化 wsgi.ComposingRouter 对象,所以我们可以判断,这个 wsgi.ComposingRouter 对象一定是一个WSGI application,我们看看代码就知道了:

[entry_points] console_scripts =     keystone-all = keystone.cmd.all:main     keystone-manage = keystone.cmd.manage:main

8

上述代码证实了我们的猜测。这个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框架来开发。

参考资源

本文主要提到了Python Paste中的各种库,这些库的相关文档都可以在项目 官网 找到:。

另外,routes库的 项目官网

感谢魏星对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群 通过demo学习OpenStack开发--API服务(2) (已满),InfoQ读者交流群(#2) 通过demo学习OpenStack开发--API服务(2) )。

原文  http://www.infoq.com/cn/articles/OpenStack-UnitedStack-API2

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 通过demo学习OpenStack开发–API服务(2)

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮