如何开始使用OpenStack命令行和API

Posted 2023-05-05

当你开始使用OpenStack，基本上都是从一个已搭建好的环境入手，别人(operator)会告诉你horizon登录的租户名、用户名和密码。

horizon登陆页
但毕竟horizon不会封装OpenStack的所有特性，当你已经玩腻了页面上那些功能时，你想尝试更多更丰富的功能，那么恭喜你，你已经向中级玩家迈进了一步。中级玩家对OpenStack的使用基本上有 四种方式 ：

OpenStack client
cURL
Rest API
OpenStack SDK
我个人比较倾向于使用client和API，因为cURL的用法其实跟发送RestAPI相似，但cURL不太方便操作(因为我们普遍都喜欢在可视化页面点击按钮)；而SDK则更多是基于OpenStack做应用时会用到，这些人一般不会关注OpenStack的内部机制。

好，你费尽心机跟operator讲好话，跟他说：哥，求求你，让我登陆后台玩玩吧! 当operator吃完你送的冰激凌，抹了一下嘴角，然后潇洒的扔了一个IP给你，“拿去耍吧”。你反复背诵着节点登陆的用户名和密码(注意，这跟horizon登陆的用户名密码不是一个东西)，小心谨慎的进了让每个程序员都感到神秘的后台，然后，快速敲了一个命令并回车：

[root@node-2 ~]# nova list
ERROR: You must provide a username via either --os-username or env[OS_USERNAME]
shit! 怎么回事？!一个ERROR可能让你慌了神。你平复了一下心情，心想：一定是老子敲命令的姿势不对，再试一次，这次用其他命令：

[root@node-2 ~]# keystone tenant-list
Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]
天呐! 呜呼一声，你已然跪了……眼角斜了斜operator，他匆忙的背影让你失去了打扰他的信心，又摸了摸兜里仅剩的1块硬币，准备打退堂鼓。

等等! 请看完我的blog，会让你起死回生的。

找到rc文件

找了半天资料，你可能已经知道你需要的就是一个文件，然后source一下。但文件的内容从哪里来？因为你到目前为止只知道horizon登录的用户名和密码。好，我现在告诉你：

第一步，登录horizon，进入下图所示的页面。

看到那个“下载OpenStack RC文件”的按钮了么？看到了么？看到了么？别光顾着点头了，还等啥？!

打开下载的文件(这里举个例子，我以admin用户登录的)，对内容稍作修改(主要是最后那个password，改成你登录horizon的密码，其他内容不要改)：

#!/bin/bash

# With the addition of Keystone, to use an openstack cloud you should
# authenticate against keystone, which returns a **Token** and **Service
# Catalog**. The catalog contains the endpoint for all services the
# user/tenant has access to - including nova, glance, keystone, swift.
#
# *NOTE*: Using the 2.0 *auth api* does not mean that compute api is 2.0. We
# will use the 1.1 *compute api*
export OS_AUTH_URL=http://119.81.159.110:5000/v2.0

# With the addition of Keystone we have standardized on the term **tenant**
# as the entity that owns the resources.
export OS_TENANT_ID=6d0dff68ecd24215bd971a8d1935ba03
export OS_TENANT_NAME="admin"

# In addition to the owning entity (tenant), openstack stores the entity
# performing the action as the **user**.
export OS_USERNAME="admin"
export OS_PASSWORD="tUWkuBpN"
好了，现在你可以登录后台，新建一个文件，然后把上面的内容复制进去，执行久违的source，然后再次运行命令：

[root@node-2 ~]# vi ~/openrc
[root@node-2 ~]# source ~/openrc
[root@node-2 ~]# nova list

[root@node-2 ~]# keystone tenant-list
+----------------------------------+----------+---------+
| id | name | enabled |
+----------------------------------+----------+---------+
| 6d0dff68ecd24215bd971a8d1935ba03 | admin | True |
| d1f2d43d358743eda4e37bfd489c1163 | services | True |
+----------------------------------+----------+---------+
[root@node-2 ~]#
呵呵，别亲我？！别动我！！

Rest API

虽然使用命令行已经很接近OpenStack的本质了，但别忘了，命令行毕竟也是一种封装，如果你想玩的再透一些，Rest API是个不错的选择，使用Rest API之后，OpenStack在你面前基本上就是裸奔了。

关于API的使用我不做过多说明，因为在我之前的blog和topic里面已经说过太多次了，看一看下面的截图，你自己再稍微google一下，就什么都明白了。 参考技术A 您好，我来为您解答：
　　当你开始使用OpenStack，基本上都是从一个已搭建好的环境入手，别人(operator)会告诉你horizon登录的租户名、用户名和密码。

　　horizon登陆页
　　但毕竟horizon不会封装OpenStack的所有特性，当你已经玩腻了页面上那些功能时，你想尝试更多更丰富的功能，那么恭喜你，你已经向中级玩家迈进了一步。中级玩家对OpenStack的使用基本上有 四种方式 ：

　　OpenStack client
　　cURL
　　Rest API
　　OpenStack SDK
　　我个人比较倾向于使用client和API，因为cURL的用法其实跟发送RestAPI相似，但cURL不太方便操作(因为我们普遍都喜欢在可视化页面点击按钮)；而SDK则更多是基于OpenStack做应用时会用到，这些人一般不会关注OpenStack的内部机制。转载，仅供参考。
　　如果我的回答没能帮助您，请继续追问。

OpenStack 通用设计思路 - 每天5分钟玩转 OpenStack（25）

API 前端服务

每个 OpenStack 组件可能包含若干子服务，其中必定有一个 API 服务负责接收客户请求。

以 Nova 为例，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。
当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。
这里的客户包括终端用户、命令行和 OpenStack 其他组件。

设计 API 前端服务的好处在于：
1. 对外提供统一接口，隐藏实现细节
2. API 提供 REST 标准调用服务，便于与第三方系统集成
3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程

Scheduler 调度服务

对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。

在前面的例子中，Nova 有多个计算节点。
当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。

调度服务就好比是一个开发团队中的项目经理，当接到新的开发任务时，项目经理会评估任务的难度，考察团队成员目前的工作负荷和技能水平，然后将任务分配给最合适的开发人员。

除了 Nova，块服务组件 Cinder 也有 scheduler 子服务，后面我们会详细讨论。

Worker 工作服务

调度服务只管分配任务，真正执行任务的是 Worker 工作服务。

在 Nova 中，这个 Worker 就是 nova-compute 了。
将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展：

1. 当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）
2. 当客户的请求量太大调度不过来时，可以增加 Scheduler

Driver 框架

OpenStack 作为开放的 Infrastracture as a Service 云操作系统，支持业界各种优秀的技术。
这些技术可能是开源免费的，也可能是商业收费的。
这种开放的架构使得 OpenStack 能够在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。

那 OpenStack 的这种开放性体现在哪里呢？
一个重要的方面就是采用基于 Driver 的框架。

以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。
包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。

Nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。
下面是 nova driver 的架构示意图

在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver

在我们的环境中因为是 KVM，所以配置的是 Libvirt 的 driver。

不知大家是否还记得我们在学习 Glance 时谈到：
OpenStack 支持多种 backend 来存放 image。
可以是本地文件系统，Cinder，Ceph，Swift 等。

其实这也是一个 driver 架构。
只要符合 Glance 定义的规范，新的存储方式可以很方便的加入到 backend 支持列表中。

再后面 Cinder 和 Neutron 中我们还会看到 driver 框架的应用。

Messaging 服务

在前面创建虚机的流程示意图中，我们看到 nova-* 子服务之间的调用严重依赖 Messaging。
Messaging 是 nova-* 子服务交互的中枢。

以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler，或是让Scheuler 直接调用 Compute，而是非要通过 Messaging 进行中转。
这里做一些解释。

程序之间的调用通常分两种：同步调用和异步调用。

同步调用
API 直接调用 Scheduler 的接口就是同步调用。
其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。

异步调用
API 通过 Messaging 间接调用 Scheduler 就是异步调用。
其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。
Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。

在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是：

1. 解耦各子服务
   子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。

2. 提高性能
   异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。

3. 提高伸缩性
   子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

在后面各章节，我们都能看到 Messaging 的应用。

Database

OpenStack 各组件都需要维护自己的状态信息。
比如 Nova 中有虚机的规格、状态，这些信息都是在数据库中维护的。
每个 OpenStack 组件在 MySQL 中有自己的数据库。

小结

Nova 是 OpenStack 中最重要的组件，也是很典型的组件。
Nova 充分体现了 OpenStack 的设计思路。
理解了这种思路，再来学习 OpenStack 的其他组件就能够举一反三，清晰容易很多。

我们在后面 Cinder 和 Neutron 的学习中还会回顾这些设计思路。