【OpenStack】OpenStack keystone的理解 2

 keystone 里面的概念很多，有：User，Credentials，Authentication，Token，Tenant，Service，Endpoint，Role。在这么多概念中，其实最主要的就是 User 和 Tenant 。由于一些安全，服务问题，才引发了其它的概念。

    那什么叫做 User ，Tenant 呢？这里我举个比较好理解的例子。我们去宾馆住的时候，我们自己就相当于 User ，而宾馆就是 Tenant 。这是最简单的情况，宾馆值提供房间，我们只需要住房。

    随着后来生活物质等的提高，这种现象就变了。我们去宾馆住的时候，很多东西都不一样，比如，开房间要身份证，房间的钥匙是一个可以当卡刷的牌子，我们进出宾馆的时候需要用自己的钥匙来开启宾馆的大门；还有就是，宾馆不仅仅是用来住的了，它可以给我们提供饮食，娱乐，健身等各种服务；而且服务层次的不同，房间也不同，房间里面的配置豪华程度也不一样。在这种情况下，描述我们和宾馆之间的关系就复杂一些了，这就引发了一些新的概念。

    可能你已经意识到我要表达的意思了，如果是这样，那就停下来先自己想一想吧。下面的内容先不要看。

    举完这个例子， keystone 中的各种概念就可以和例子中的事物相挂钩了。

User	住宾馆的人
Credentials	开启房间的钥匙
Authentication	宾馆为了拒绝不必要的人进出宾馆，专门设置的机制，只有拥有钥匙的人才能进出
Token	也是一种钥匙，有点特别
Tenant	宾馆
Service	宾馆可以提供的服务类别，比如，饮食类，娱乐类
Endpoint	具体的一种服务，比如吃烧烤，打羽毛球
Role	VIP 等级，VIP越高，享有越高的权限

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服务更新镜像状态等元数据信息。