OpenStack 之 keystone学习

毕业前夕->正式上班过渡期，开始学习opentack，前段时间刚刚抽空学习了下python，现在开始openstack学习之路，记录自己的学习过程：

    OpenStack keystone的安装：http://blog.sina.com.cn/s/blog_4b5039210102e40k.html

    Openstack，不做过多解释，让我们直入主题---Keystone。Openstack是一个SOA的架构，理论上各个子项目独立提供相关的服务，互不依赖。例如Nova提供计算服务，Swift提供对象存储服务，Glance提供镜像服务等。但是实际上(至少从Openstack目前开源实现上来看)，所有组件都依赖于Keystone提供3A(Account,Authentication, Authorization)服务。除了3A之外，Keystone还对外提供服务目录(ServiceCatalog)服务，类似于UDDI服务的概念，用户(无论是Dashboard, APIClient)都需要访问Keystone获取服务列表，以及每个服务的地址(Openstack中称为Endpoint)。所以，学习Openstack第一个必须搞定的组件必然是Keystone。

    首先我们先看一下Keystone的几个基本概念，灰常重要！！！
User: 直译过来就是用户，如果意译的话就是马甲 :)也就是一个人的账号，当然一个人可以有多个马甲，你懂得。
Crenditial:用来证明用户身份的证据，大白话就是“信物”，这是一个逻辑概念。具体可以是密码，驾照、身份证等。
Authentication: 鉴权，也即对用户身份鉴别的一个过程。
Token:令牌。对用户鉴权完毕之后，Keystone会为用户颁发一个令牌，这样用户在请求其他服务的时候，只需要亮出自己的令牌即可，而不需要发送自己的密钥。当然以防仿冒令牌，令牌是有时限的。
Service：服务。之前提到过，Keystone提供了系统能够提供的服务目录，例如Nova, Glance, Swift等。
Endpoint：直译为端点，其实指的是访问服务的地址。如果细分的话，又可以进一步分为对外提供服务的地址，管理地址等。
Role:权限。这就是3A中的Authorization，也即赋予该用户的权限。我们知道Openstack提供的是一个多租户环境，在Openstack中租户对应到项目(Project)。一个用户可以同时属于多个不同的项目，当然在不同的项目中可以充当不同的角色，也即拥有不同的权限。
    关键的两点：1) User从Keystone获取令牌以及服务列表；2)User访问服务时，亮出自己的令牌。相关的服务向Keystone求证令牌的合法性。
    大致了解了这个流程之后，我们再来理解keystone的配置就不难了：
    1)从用户的角度来看，它归属于一个或多个Project，并且在每个项目中充当一个角色。所以我们需要创建Project，创建User，创建Role，并将User和Project、Role关联起来；
    2)Keystone本质是提供Identity服务的，所以它的实现或者提供的机制也是基于用户来设计的。为了提供服务目录，配置Keystone的时候创建了一个特殊的ServiceProject，为每个服务创建对应的用户(Nova, Swift, Quantum...)，并且都归属于ServiceProject。然后配置、设置相应的Endpoint。

以上转自：http://blog.sina.com.cn/s/blog_60f6c9680101bn75.html

（这位老兄似乎也只提供了这么一片相关文章）

     keystone，glance，nova结构都非常相似，使用WSGI(网关接口)协议,webob,paste, routes几个框架，像我这样以前Python没接触过的人可能也没接触过这些东西，先可以大致了解下这几个框架，再来看源码就大致知道怎么回事了。
    先来说下keystone过程，下面是刚学习的时候记录的，直接贴过来，可能存在错误，有问题请指出，谢谢。
    启动keystone服务时，需要查找keystone.conf配置文件并解析，通过keystone.conf配置的logging.conf解析logging日志配置。deploy.appconfig会解析paste.deploy配置中 main section的部分create_server中deploy.loadapp一开始与appconfig一样，load app context。之后通过create方法解析paste配置的组成部分，并执行相关初始化。use = egg:Paste#urlmap先得到解析执行，进入paste.urlmap#urlmap_factory，将先前loadContext得到的config map作为参数传入。这里urlmap将会通过配置的uri和app对应起来，例如如果是composite:admin中的/2.0路径，将会继续通过查找每一个section pre找到pipeline中有一个pipeline:admin_api。然后查找pipeline中最后一个应用的配置放入context.app_context，这里是admin_service。Admin_service的协议是paste.app_factory，执行的方法是keystone.service:admin_app_factory。再同样的方法查找所有filter放入context.filter_contexts.然后用这个pipeline context调用create方法，pipeline中则是先create app context再依次create filter context。（从这里将从deploy模块回到keystone模块）Create app context执行admin_app_factory。
解析目录模版：
Catalog.RegionOne.identity.publicURL
Region=RegionOne
Service=identity
Key=publicURL
组合成json格式串
{‘RegionOne’:{‘identity’:{‘publicuRL’:’http://localhost:${public_port}s/v2.0’}}}
最终将整个目录模版解析成json格式的字典对象。解析完成后得到一个带有adminURL目录信息的version_controller，之后向routes.mapper添加路由信息，最终将构建完成的router返回给urlmap，完成请求路径与路由路径的一一对应。路由对象保存了请求路径信息，controller信息，action信息。
    至此,Keystone-all执行完成，启动了两个server等待请求，一个是admin_port等待，一个是public_port等待。请求到达服务时，将会按照paste配置执行filters，然后根据路由表配置进入模块方法执行。
    上面的介绍实际主要是讲paste和routes的过程，keystone利用这些框架，提供REST API，降低耦合，可以为各个模块提供用户认证功能。
下面简单介绍glance项目。
1.registry提供对DB操作的http服务，glance api通过对registry的http请求操作存储在DB中的镜像元数据，虽然registry api可访问，一般用户不直接操作registry api
2.glance-api和glance-registry启动服务后，分别根据应用名和项目名查找paste配置文件，并部署路由信息将镜像元数据放入HTTP请求头，并将镜像文件作为内容请求glance-api地址。 glance-api接收请求，解析以x-image-meta和x-image-meta-property-开头的请求头信息作为镜像元数据， 之后使用registry client请求registry服务，在DB中存储镜像元数据，并获取ID值作为镜像文件存储的文件名，
文件存储或者以其他方式存储完镜像文件后，再次请求registry服务更新镜像状态等元数据信息。

以上转自：http://blog.csdn.net/xiangmin2587/article/details/8224042

（这位老兄还是有好几篇文章值得一看的）

[openstack][G版]keystone源码学习

    Keystone项目的主要目的是给整个openstack的各个组件（项目）提供一个统一的验证方式。用户管理，身份验证是几乎所有的软件管理都要处理的问题，Keystone对于通常的应用场景所不同的是他要解决分布式环境下的统一认证。
    Keystone的程序结构也是采用openstack通常所用的manager，driver方式，这中方式的一个好处是driver可以被灵活的替换，通过配置的方式动态替换。   

    Keystone的实现方式同其他openstack项目不太一样的是，他使用了了一个python语言的特性让driver中的方法直接融入进manager类。在keystone中，验证数据的存储方式都有很多种，有sql数据库形式，kvs形式（Dict在内存中存储）等，一种driver就是对应一种存储形式。  

def__getattr__(self, name):    """Forward calls to theunderlying driver."""    # NOTE(termie): context is the firstargument, we're going to strip    # that for now, in the futurewe'll probably do some    # logging and whatnot in thisclass    f = getattr(self.driver, name)    @functools.wraps(f)    def _wrapper(context, *args, **kw):        return f(*args, **kw)    setattr(self, name, _wrapper)    return _wrapper

      简单介绍一下各个模块的功能，auth实现通过插件的方式实现验证功能，Keystone/auth/plugins目录下password.py，token.py实现了密码和token两个验证方法，你也可以通过继承AuthMethodHandler类实现自己的验证方法，作为插件插入验证链中。Catalog主要实现如构造Catalog等相关功能，实现endpoints的注册，提供endpoints的发现机制。对应于每个服务（如：identity，volume，image，compute等）都会有一个对应的endpoints，如对应compute服务的endpoints为如下格式。

    {"adminurl":"http://192.168.128.8:8774/v2/$(tenant_id)s","internalurl":"http://192.168.128.8:8774/v2/$(tenant_id)s", "publicurl":"http://192.168.128.8:8774/v2/$(tenant_id)s"}

policy提供了基于规则的验证引擎和验证管理接口。Token提供对于Token的生成删除等相关功能。Trust提供级联授权的相关功能，感兴趣的朋友可以看下这个文档https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3-os-trust-ext.md。

        实际的openstack的项目，对于keystone的应用是通过WSGImiddleware 这种可插拔的方式来实现的，具体就是通过paste 配置实现keystone验证功能的filter或app。以nova对于keystone的使用为例，nova实际是加了authtoken这个filter，authtoken的实际是在keystone的client api （python-keystoneclient-master）keystoneclient/middleware/auth_token.py文件中实现的，其中filter_factory，app_factory调用AuthProtocol类来具体实现相关功能。（注：这里对于WSGI，和paste，以及openstack对其的实现的方式不作具体讲解了）。

       Keystone V3 版本的api改动比较大，v3 api现在还没有完全实现，这里有一个v3api的文档https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md。

以上转自：

http://www.w3c.com.cn/openstackg%E7%89%88keystone%E6%BA%90%E7%A0%81%E5%AD%A6%E4%B9%A0