云计算openstack核心组件--glance-镜像服务（6）
glance做什么
OpenStack 由 Glance 提供 Image 服务
获取镜像位置
https://docs.openstack.org/image-guide/obtain-images.html#centos
理解 Image
要理解 Image Service，先得搞清楚什么是 Image 以及为什么要用 Image？
在传统 IT 环境下，安装一个系统要么从安装 CD 从头安装，要么用 Ghost 等克隆工具恢复。这两种方式有如下几个问题：
- 如果要安装的系统多了效率就很低
- 时间长，工作量大
- 安装完还要进行手工配置，比如安装其他的软件，设置 IP 等
- 备份和恢复系统不灵活
云环境下需要更高效的方案，这就是 Image。 Image 是一个模板，里面包含了基本的操作系统和其他的软件。
举例来说，有家公司需要为每位员工配置一套办公用的系统，一般需要一个 Win7 系统再加 MS office 软件。 OpenStack 是这么玩的：
- 先手工安装好这么一个虚机
- 然后对虚机执行 snapshot，这样就得到了一个 image
- 当有新员工入职需要办公环境时，立马启动一个或多个该 image 的 instance（虚机）就可以了
在这个过程中，第 1 步跟传统方式类似，需要手工操作和一定时间，但第 2、3 步非常快，全自动化，一般都是秒级别。而且 2、3 步可以循环做。 比如公司新上了一套 OA 系统，每个员工的 PC 上都得有客户端软件。 那么可以在某个现有虚机中先手工安装好 OA 客户端，然后执行 snapshot 操作，得到新的 image，以后可以就直接使用新 image 创建虚机了。另外，snapshot 还有备份的作用，能够非常方便的恢复系统。
理解Image Service
Image Service 的功能是管理 Image，让用户能够发现、获取和保存 Image。在 OpenStack 中，提供 Image Service 的是 Glance，其具体功能如下：
- 提供 REST API 让用户能够查询和获取 image 的元数据和 image 本身
- 支持多种方式存储 image，包括普通的文件系统、Swift、Amazon S3 等
- 对 Instance 执行 Snapshot 创建新的 image
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，包括
（1）RAW即常说的裸格式，它其实就是没有格式，最大的特点就是简单，数据写入什么就是什么，不做任何修饰，所以在性能方面很不错，甚至不需要启动这种镜像的虚拟机，只需要把文件挂载，即可直接读写内部数据。并且由于RAW格式简单，因此RAW和其他格式之间的转换也更容易。在KVM的虚拟化环境下，有很多使用RAW格式的虚拟机。
（2）qcow2
qcow2是qcow的升级版本，它是QEMU的CopyOn Write特性的磁盘格式，主要特性是磁盘文件大小可以随着数据的增加而增长。譬如创建一个10GB的虚拟机，实际虚拟机内部只用了5GB，那么初始的qcow2磁盘文件大小就是5GB。与RAW相比，使用这种格式可以节省一部分空间资源。
（3）VHD
VHD也是一种通用的磁盘格式。微软公司的Virtual PC和Hyper-V使用的就是VHD格式。VirtualBox也提供了对VHD格式的支持。如果要在OpenStack上使用Hyper-V的虚拟化，就应该上传VHD格式的镜像文件。
（4）VMDK
VMware创建的一个虚拟机磁盘格式，目前也是一个开放的通用格式，除了VMware自家的产品外，QEMU和VirtualBox也提供了对VMDK格式的支持。
（5）VDI
Oracle公司的VirtualBox虚拟软件所使用的格式。
（6）ISO
ISO是指一种存档数据文件在光盘上的格式。
（7）AKI、ARI、AMI
Amazon公司的AWS所使用的镜像格式。
Database
Image 的 metadata 会保持到 database 中，默认是 MySQL。 在控制节点上可以查看 glance 的 database 信息
Store backend
Glance 自己并不存储 image。 真正的 image 是存放在 backend 中的。 Glance 支持多种 backend，包括：
- A directory on a local file system（这是默认配置）
- GridFS
- Ceph RBD
- Amazon S3
- Sheepdog
- OpenStack Block Storage (Cinder)
- OpenStack Object Storage (Swift)
- VMware ESX
具体使用哪种 backend，是在 /etc/glance/glance-api.conf 中配置的
在我们的 devstack 环境中，image 存放在控制节点本地目录 /var/lib/glance/images/中
其他 backend 的配置可参考http://docs.openstack.org/liberty/config-reference/content/configuring-image-service-backends.html
查看目前已经存在的 image
查看保存目录
[root@controller ~]# ls /var/lib/glance/images/ a86d1a0c-c388-4702-aaa6-be045cb234c1
每个 image 在目录下都对应有一个文件，文件以 image 的 ID 命名
通过 Web GUI 和 CLI 两种方法创建 Image
OpenStack 为终端用户提供了 Web UI（Horizon）和命令行 CLI 两种交换界面。
可能有些同学觉得既然有更友好的 Web UI 了，干嘛还要用 CLI？ 这里 给出下面的理由：
- Web UI 的功能没有 CLI 全，有些操作只提供了 CLI。 即便是都有的功能，CLI 可以使用的参数更多
- 一般来说，CLI 返回结果更快，操作起来更高效
- CLI 可放在脚本中进行批处理
- 有些耗时的操作 CLI 更合适，比如创建镜像（后面将涉及）
Web UI 创建 image
第一步：admin 登录后，Project -> Compute -> Images
第二步:创建镜像
- 这里我们上传一个 image。 点击浏览，选择镜像文件 cirros-0.3.5-x86_64-disk.img。 cirros 是一个很小的 linux 镜像，非常适合测试用。 大家可以到 http://download.cirros-cloud.net/ 下载。
- 格式选择 QCOW2。
如果勾选共有，该 image 可以被其他 Project 使用 如果勾选受保护的是，该 image 不允许被删除。
第三步：查看创建的镜像
第四步：查看cirros详细信息，点击cirros
CLI 创建 image
cirros 这个 linux 镜像很小，通过 Web UI 上传很快，操作会很顺畅。但如果我们要上传的镜像比较大（比如好几个 G ），那么操作会长时间停留在上传的 Web 界面，我们也不知道目前到底处于什么状态。 对于这样的操作，CLI 是更好的选择。
- 将 image 上传到控制节点的文件系统中，例如 /tmp/cirros-0.3.5-x86_64-disk.img
- 执行创建命令
[root@controller tmp]# glance image-create --name cirros1 --file /tmp/cirros-0.3.5-x86_64-disk.img --disk-format qcow2 --container-format bare --progress
[=============================>] 100% +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | f8ab98ff5e73ebab884d80c9dc9c7290 | | container_format | bare | | created_at | 2019-06-07T16:19:58Z | | disk_format | qcow2 | | id | a218e386-bd4d-43df-a7d4-2128cb906f51 | | min_disk | 0 | | min_ram | 0 | | name | cirros1 | | owner | 3c48d267eaa14f44a7cacd7e88bb46b7 | | protected | False | | size | 13267968 | | status | active | | tags | [] | | updated_at | 2019-06-07T16:19:59Z | | virtual_size | None | | visibility | shared | +------------------+--------------------------------------+
在创建 image 的 CLI 参数中我们用 –progress 让其显示文件上传的百分比 %，是不是比 Web UI更直观呢？
在 /var/lib/glance/images/ 下查看新的 Image
[root@controller tmp]# ls /var/lib/glance/images/ a218e386-bd4d-43df-a7d4-2128cb906f51 fe4bca11-d413-4282-9dd6-08941cae5ba8
web查看
如何使用 OpenStack CLI
OpenStack 服务都有自己的 CLI。
命令很好记，就是服务的名字，比如 Glance 就是 glance，Nova 就是 nova。
但 Keystone 比较特殊，现在是用 openstack 来代替老版的 keystone 命令。
不同服务用的命令虽然不同，但这些命令使用方式却非常类似，可以举一反三。
1. 执行命令之前，需要设置环境变量。
这些变量包含用户名、Project、密码等； 如果不设置，每次执行命令都必须设置相关的命令行参数
2. 各个服务的命令都有增、删、改、查的操作
其格式是
CMD <obj>-create [parm1] [parm2]… CMD <obj>-delete [parm] CMD <obj>-update [parm1] [parm2]… CMD <obj>-list CMD <obj>-show [parm
例如 glance 管理的是 image，那么:
CMD 就是 glance，obj 就是 image，对应的命令就有
glance image-create glance image-delete glance image-update glance image-list glance image-show
再比如 neutron 负责管理网络和子网，那么：
CMD 就是 neutron；obj 就是 net 和 subnet 对应的命令就有
网络相关操作
neutron net-create neutron net -delete neutron net -update neutron net -list neutron net –show
子网相关操作
neutron subnet-create neutron subnet -delete neutron subnet -update neutron subnet -list neutron subnet–show
有的命令 <obj> 可以省略，比如 nova 下面的操作都是针对 instance
nova boot
nova delete
nova list
nova show
3. 每个对象都有 ID
delete，show 等操作都以 ID 为参数，例如
4. 可用 help 查看命令的用法
除了 delete，show 等操作只需要 ID 一个参数，其他操作可能需要更多的参数，用 help 查看所需的参数，格式是
CMD help [SUB-CMD]
例如查看 glance 都有哪些 SUB-CMD
查看 glance image-update 的用法
OpenStack 排查问题的方法
OpenStack 排查问题的方法主要是通过日志，Service 都有自己单独的日志。Glance 主要有两个日志，glance_api.log 和 glance_registry.log，保存在/var/log/glance 目录里。
[DEFAULT] [cors] [cors.subdomain] [database] connection = mysql+pymysql://glance:GLANCE_DBPASS@controller/glance [glance_store] stores = file,http default_store = file filesystem_store_datadir = /var/lib/glance/images/ [image_format] [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = controller:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = glance password = glance [matchmaker_redis] [oslo_concurrency] [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] [paste_deploy] flavor = keystone [profiler] [store_type_location_strategy] [task] [taskflow_executor]
vim /etc/glance/glance-registry.conf
[DEFAULT] [database] connection = mysql+pymysql://glance:GLANCE_DBPASS@controller/glance [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = controller:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = glance password = glance [matchmaker_redis] [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_policy] [paste_deploy] flavor = keystone [profiler]
