云计算与openstack学习（六）

理解 Keystone 核心概念 

作为 OpenStack 的基础支持服务，Keystone 做下面这几件事情：

1. 管理用户及其权限

2. 维护 OpenStack Services 的 Endpoint

3. Authentication（认证）和 Authorization（鉴权）

学习 Keystone，得理解下面这些概念：

User

User 指代任何使用 OpenStack 的实体，可以是真正的用户，其他系统或者服务。

当 User 请求访问 OpenStack 时，Keystone 会对其进行验证。

Horizon 在 Identity->Users 管理 User

除了 admin 和 demo，OpenStack 也为 nova、cinder、glance、neutron 服务创建了相应的 User。 admin 也可以管理这些 User。

Credentials

Credentials 是 User 用来证明自己身份的信息，可以是： 1. 用户名/密码 2. Token 3. API Key 4. 其他高级方式

Authentication

Authentication 是 Keystone 验证 User 身份的过程。

User 访问 OpenStack 时向 Keystone 提交用户名和密码形式的 Credentials，Keystone 验证通过后会给 User 签发一个 Token 作为后续访问的 Credential。

Token

Token 是由数字和字母组成的字符串，User 成功 Authentication 后由 Keystone 分配给 User。

1. Token 用做访问 Service 的 Credential

2. Service 会通过 Keystone 验证 Token 的有效性

3. Token 的有效期默认是 24 小时

Project

Project 用于将 OpenStack 的资源（计算、存储和网络）进行分组和隔离。 根据 OpenStack 服务的对象不同，Project 可以是一个客户（公有云，也叫租户）、部门或者项目组（私有云）。

这里请注意：

1. 资源的所有权是属于 Project 的，而不是 User。

2. 在 OpenStack 的界面和文档中，Tenant / Project / Account 这几个术语是通用的，但长期看会倾向使用 Project

3. 每个 User（包括 admin）必须挂在 Project 里才能访问该 Project 的资源。 一个User可以属于多个 Project。

4. admin 相当于 root 用户，具有最高权限

Horizon 在 Identity->Projects 中管理 Project

通过 Manage Members 将 User 添加到 Project 中

Service

OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。

每个 Service 都会提供若干个 Endpoint，User 通过 Endpoint 访问资源和执行操作。

Endpoint

Endpoint 是一个网络上可访问的地址，通常是一个 URL。 Service 通过 Endpoint 暴露自己的 API。 Keystone 负责管理和维护每个 Service 的 Endpoint。

可以使用下面的命令来查看 Endpoint。

root@devstack-controller:~# source devstack/openrc admin admin 

root@devstack-controller:~# openstack catalog list

Role

安全包含两部分：Authentication（认证）和 Authorization（鉴权） Authentication 解决的是“你是谁？”的问题 Authorization 解决的是“你能干什么？”的问题

Keystone 是借助 Role 来实现 Authorization 的：

1. Keystone定义Role

2. 可以为 User 分配一个或多个 Role Horizon 的菜单为 Identity->Project->Manage Members

3. Service 决定每个 Role 能做什么事情 Service 通过各自的 policy.json 文件对 Role 进行访问控制。 下面是 Nova 服务 /etc/nova/policy.json 中的示例

6. 

上面配置的含义是：对于 create、attach_network 和 attach_volume 操作，任何Role的 User 都可以执行； 但只有 admin 这个 Role 的 User 才能执行 forced_host 操作。

OpenStack 默认配置只区分 admin 和非 admin Role。 如果需要对特定的 Role 进行授

通过例子学习 Keystone 

上一节介绍了 Keystone 的核心概念。
本节我们通过“查询可用 p_w_picpath”这个实际操作让大家对这些概念建立更加感性的认识。 

User admin 要查看 Project 中的 p_w_picpath 

第 1 步 登录

当点击时，OpenStack 内部发生了哪些事情？请看下面 

Token 中包含了 User 的 Role 信息 

第 2 步 显示操作界面

请注意，顶部显示 admin 可访问的  Project 为 “admin” 和 “demo”。 其实在此之前发生了一些事情： 

同时，admin 可以访问 Intance, Volume, Image 等服务 

这是因为 admin 已经从 Keystone 拿到了各 Service 的 Endpoints 

第 3 步 显示 p_w_picpath 列表

点击 “Images”，会显示 p_w_picpath 列表 

背后发生了这些事： 

首先，admin 将请求发送到 Glance 的 Endpoint 

Glance 向 Keystone 询问 admin 身份的有效性。 

接下来 Glance 会查看 /etc/glance/policy.json。 判断 admin 是否有查看 p_w_picpath 的权限 

权限判定通过，Glance 将 p_w_picpath 列表发给 admin。 

Troubleshoot

OpenStack 排查问题的方法主要是通过日志。 每个 Service 都有自己的日志文件。 

Keystone 主要有两个日志： keystone.log 和 keystone_access.log 保存在 /var/log/apache2/ 目录里。 

devstack 的 screen 窗口已经帮我们打开了这两个日志。 可以直接查看： 

如果需要得到最详细的日志信息，可以在 /etc/keystone/keystone.conf 中打开 debug 选项 

在非 devstack 安装中，日志可能在 /var/log/keystone/ 目录里。

理解 Glance 

OpenStack 由 Glance 提供 Image 服务。

理解 Image

要理解 Image Service 先得搞清楚什么是 Image 以及为什么要用 Image？ 

在传统 IT 环境下，安装一个系统是要么从安装 CD 从头安装，要么用 Ghost 等克隆工具恢复。这两种方式有如下几个问题： 

1. 如果要安装的系统多了效率就很低

2. 时间长，工作量大

3. 安装完还要进行手工配置，比如安装其他的软件，设置 IP 等

4. 备份和恢复系统不灵活

云环境下需要更高效的解决方案，这就是 Image。 Image 是一个模板，里面包含了基本的操作系统和其他的软件。 

举例来说，有家公司需要为每位员工配置一套办公用的系统，一般需要一个 Win7 系统再加 MS office 软件。 OpenStack 是这么玩的： 

1. 先手工安装好这么一个虚机

2. 然后对虚机执行 snapshot，这样就得到了一个 p_w_picpath

3. 当有新员工入职需要办公环境时，立马启动一个或多个该 p_w_picpath 的 instance（虚机）就可以了

在这个过程中，第 1 步跟传统方式类似，需要手工操作和一定时间。
但第 2、3 步非常快，全自动化，一般都是秒级别。 

而且 2、3 步可以循环做。 比如公司新上了一套 OA 系统，每个员工的 PC 上都得有客户端软件。 那么可以在某个员工的虚机中手工安装好 OA 客户端，然后执行 snapshot ，得到新的 p_w_picpath，以后就直接使用新 p_w_picpath 创建虚机就可以了。 

另外，snapshot 还有备份的作用，能够非常方便的恢复系统。 

理解 Image Service

Image Service 的功能是管理 Image，让用户能够发现、获取和保存 Image。 

在 OpenStack 中，提供 Image Service 的是 Glance，其具体功能如下： 

1. 提供 REST API 让用户能够查询和获取 p_w_picpath 的元数据和 p_w_picpath 本身

2. 支持多种方式存储 p_w_picpath，包括普通的文件系统、Swift、Amazon S3 等

3. 对 Instance 执行 Snapshot 创建新的 p_w_picpath

Glance 架构

上面是 Glance 的架构图 

glance-api

glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 p_w_picpath 查询、获取和存储的调用。 

glance-api 不会真正处理请求。 如果是与 p_w_picpath metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry； 如果是与 p_w_picpath 自身存取相关的操作，glance-api 会把请求转发给该 p_w_picpath 的 store backend。 

在控制节点上可以查看 glance-api 进程 

glance-registry

glance-registry 是系统后台运行的服务进程。 负责处理和存取 p_w_picpath 的 metadata，例如 p_w_picpath 的大小和类型。 

在控制节点上可以查看 glance-registry 进程 

Glance 支持多种格式的 p_w_picpath，包括 

Database

Image 的 metadata 会保持到 database 中，默认是 MySQL。 在控制节点上可以查看 glance 的 database 信息 

Store backend

Glance 自己并不存储 p_w_picpath。 真正的 p_w_picpath 是存放在 backend 中的。 Glance 支持多种 backend，包括 

1. A directory on a local file system（这是默认配置）

2. GridFS

3.  Ceph RBD

4. Amazon S3

5. Sheepdog

6. OpenStack Block Storage (Cinder)

7. OpenStack Object Storage (Swift)

8. VMware ESX

具体使用哪种 backend，是在 /etc/glance/glance-api.conf 中配置的在我们的 devstack 环境中，p_w_picpath 存放在控制节点本地目录 /opt/stack/data/glance/p_w_picpaths/ 中 

其他 backend 的配置可参考http://docs.openstack.org/liberty/config-reference/content/configuring-p_w_picpath-service-backends.html 

查看目前已经存在的 p_w_picpath 

查看保存目录 

每个 p_w_picpath 在目录下都对应有一个文件，文件以 p_w_picpath 的 ID 命名。