Glance源码架构探秘（一）

Glance源码架构探秘（一）

Glance源码架构探秘（二）

Glance源码架构探秘（三）

Glance源码架构探秘（四）

前言

从本章开始，将会陆续为大家分享有关OpenStack各组件模块代码架构的探秘。首先从OpenStack的镜像管理模块Glance开始，原因是Glance只负责镜像的上传，下载等管理，功能对比Nova模块来说相对比较少，便于代码结构的分析。还是那句话，Stacker们，大家多交流，我看到留言会回复的~

Glance项目提供虚拟机镜像的查找，注册和重现，使用RESTful接口接受虚拟机镜像管理的查询请求。

2013-4-15新增

从F版开始使用的API V2，相对于V1版大大简化了流程，将glance-api与glance-registry合并在了一起。

glance-api V2

然而因为目前国内大多还停留在E版本的系统上，所以本文还是着重研究下E版本的代码。目前暂时还不清楚此项更改对应的blue-print。

程辉博客中glance v1版架构图

在程辉的一篇博客中，有Glance的架构介绍，其中有上面的图。作者将Glance-API和Glance-Registry解释为调用关系是不正确的。这两个服务是独立运行的服务，在sbin目录下，看过glance部署文章的同学知道，glance部署的最后一步就是启动glance-api和glance-registry这两个服务。这两个服务作为WSGI，会分别响应来自用户的RESTful请求，而不是图上所暗示的glance-api响应请求，然后调用glance-registry进行image元数据在数据库的注册。（2013-4-15删除）

E版本代码中，Glance-api和Glance-Registry两个服务还没有进行合并。查看KeyStone的endpoint可知，系统和外界进行交互的接口是绑定了端口号9292的glance-api服务，而绑定端口号为9191的glance-registry只在系统内部使用。

glance-api作为glance对外的服务入口，接受客户端的所有命令，分发并响应，如果命令操作涉及到数据库的增删改查等操作，glance会创建一个RegistryClient实例，往下向glance-registry转发restful命令。

Glance对外服务的入口主要有2个（2013-4-15删除）

Glance有两个WSGI服务模块

1、Glance-API：主要负责接收响应镜像管理命令的Restful请求，分析消息请求信息并分发其所带的命令（如新增，删除，更新等）。（2013/4/15新增）涉及到数据库的操作会调用registry-clinet生成响应的http命令转发给Glance-Registry服务。默认绑定端口是9292。

2、Glance-Registry：主要负责接收响应镜像元数据命令的Restful请求。分析消息请求信息并分发其所带的命令（如获取元数据，更新元数据等），进行数据库相关的增删改查工作。默认绑定的端口是9191。

在/etc/glance目录下有两个文件glance-api-paste.ini和glance-registry-paste.ini，两个入口服务启动后，会用配置文件分析模块读取这两个文件，执行其文件中标注的需要执行的WSGIapp和middleware。简述paste文件中的概念：

app：实际处理REST API请求的python类。
filter:一种装饰器，为app提供一层封装，在app处理请求之前会先调用filter的对象。
pipeline:所对应的对象是对filter和app的的封装，他将多个filter和某个app绑在一起，在app处理请求之前要先通过pipline指定的在app之前的filter的处理。

在glance-registry中有

[app:registryapp]
paste.app_factory = glance.registry.api.v1:API.factory

证明这是一个独立的服务程序

我们以glance-api为例，分析其服务入口程序

"""
Glance API Server
"""

import gettext
import os
import sys

# If ../glance/__init__.py exists, add ../ to Python search path, so that
# it will override what happens to be installed in /usr/(local/)lib/python...
possible_topdir = os.path.normpath(os.path.join(os.path.abspath(sys.argv[0]),
                                   os.pardir,
                                   os.pardir))
if os.path.exists(os.path.join(possible_topdir, 'glance', '__init__.py')):
    sys.path.insert(0, possible_topdir)

gettext.install('glance', unicode=1)

from glance.common import config
from glance.common import wsgi
from glance.common import exception
from glance.openstack.common import log
import glance.store


def fail(returncode, e):
    sys.stderr.write("ERROR: %s\n" % e)
    sys.exit(returncode)


if __name__ == '__main__':
    try:
        config.parse_args()
        log.setup('glance')

        glance.store.create_stores()
        glance.store.verify_default_store()

        server = wsgi.Server()
        server.start(config.load_paste_app(), default_port=9292)
        server.wait()
    except exception.WorkerCreationFailure, e:
        fail(2, e)
    except RuntimeError, e:
        fail(1, e)

首先程序会调用glance.store.create_stores，注册与后端存储（swift、s3、filesystem等）相关的控制模块，并校验默认存储方式。

紧接着启动一个Http Server，openstack的WSGI SERVER用到了eventlet这个绿色线程（协程）的组件，这个我们后面一章会介绍到。

通过config.load_paste_app()方法，会从上面提到的glance-api-paste.ini配置文件中读取要启动的WSGI app，并在server中启动，并让server线程等待接收http rest查询响应。

下一章将为大家分析openstack所有服务共同用到的WSGI Server组件eventlet和Restful查询请求的分发器Routes组件。