云计算与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 的核心概念。
本节我们通过“查询可用 image”这个实际操作让大家对这些概念建立更加感性的认识。
User admin 要查看 Project 中的 image
第 1 步 登录

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

Token 中包含了 User 的 Role 信息
第 2 步 显示操作界面

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

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

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

第 3 步 显示 image 列表
点击 “Images”，会显示 image 列表

背后发生了这些事：
首先，admin 将请求发送到 Glance 的 Endpoint

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

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

权限判定通过，Glance 将 image 列表发给 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，这样就得到了一个 image
3. 当有新员工入职需要办公环境时，立马启动一个或多个该 image 的 instance（虚机）就可以了
在这个过程中，第 1 步跟传统方式类似，需要手工操作和一定时间。
但第 2、3 步非常快，全自动化，一般都是秒级别。
而且 2、3 步可以循环做。 比如公司新上了一套 OA 系统，每个员工的 PC 上都得有客户端软件。 那么可以在某个员工的虚机中手工安装好 OA 客户端，然后执行 snapshot ，得到新的 image，以后就直接使用新 image 创建虚机就可以了。
另外，snapshot 还有备份的作用，能够非常方便的恢复系统。
理解 Image Service
Image Service 的功能是管理 Image，让用户能够发现、获取和保存 Image。
在 OpenStack 中，提供 Image Service 的是 Glance，其具体功能如下：
1. 提供 REST API 让用户能够查询和获取 image 的元数据和 image 本身
2. 支持多种方式存储 image，包括普通的文件系统、Swift、Amazon S3 等
3. 对 Instance 执行 Snapshot 创建新的 image
Glance 架构

上面是 Glance 的架构图
glance-api
glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。
glance-api 不会真正处理请求。 如果是与 image metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry； 如果是与 image 自身存取相关的操作，glance-api 会把请求转发给该 image 的 store backend。
在控制节点上可以查看 glance-api 进程

glance-registry
glance-registry 是系统后台运行的服务进程。 负责处理和存取 image 的 metadata，例如 image 的大小和类型。
在控制节点上可以查看 glance-registry 进程

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

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

Store backend
Glance 自己并不存储 image。 真正的 image 是存放在 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 环境中，image 存放在控制节点本地目录 /opt/stack/data/glance/images/ 中

其他 backend 的配置可参考http://docs.openstack.org/liberty/config-reference/content/configuring-image-service-backends.html
查看目前已经存在的 image

查看保存目录

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