以前一直想写博客，但因各种因素一直没写。最近在做OpenStack，而OpenStack对外提供REST API，今天就简要介绍一下OpenStack REST API 使用，关于什么是REST API可以参考以下两篇博文：
简单的来说，一切都是资源，每个资源对应一个URI。
我们可以使用linux curl命令使用REST API向OpenStack发送请求，例如根据用户名、密码和tenant得到token：
curl -i 'http://127.0.0.1:/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json"
-d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "secretsecret"}}}'
但是我觉得用curl命令不太方便，而且有时候返回结果很长很长的时候不太好看，所以就使用了RESTClient，因为是在CentOS环境下工作，于是在火狐下装了个RESTClient插件，像上面的请求可以轻松搞定，加入两个Header，如果要访问其他资源，则还另外需要一个Header：x-auth-token，选择一个Method，然后在Body里面写下需要的东西，截图如下：
"passwordCredentials":{
"username":"admin",
"password":"123456"
"tenantName":"admin"
OpenStack的API大多都在官方文档中写了，为什么说大多，而不是全部，是因为有些真没写，我觉得其中没写的分两类：
没有及时更新。
觉得没必要写，认为大家可以猜到，或者可以从源码中找到蛛丝马迹。毕竟搞OpenStack还是得要两把刷子。
举几个目前API文档中没写或者没有详细说明用法的API，比如：
OpenStack中的admin用户如何获得所有tenant(project)下的虚机信息。具体的做法是加上query参数all_tenants，即：/v2/{tenant_id}/servers/detail?all_tenants=true
延伸第一条，admin如何获取某个tenant下的虚机。/v2/{tenant_id}/servers/detail?all_tenants=true&project_id=XXX
还有好多可以加query参数的API，就不一一列举了。
还有一个问题，在API文档中只有URL的后半部分，那么前半部分去哪了，前半部分就在当初安装OpenStack时创建的endpoint中，我们可以使用以下命令找到：
keystone endpoint-list
keystone endpoint-get --service=XXX
在实际的编码中我们当然不能在代码里把URL写死，应该通过查数据表得到各个服务的endpoint，然后生成完整的URL。细心的同学就会发现，在每次认证的时候不仅会返回token而且会返回serviceCatalog，里面就有我们想要的endpoint，就不必再单独再去查一次数据库了。
有个问题没太弄懂，不知是否有人解答一下：
keystone两个端口，一个是5000，一个是35357(adminURL)。两个权限不一样，创建用户什么的必须用35357。我知道OpenStack采用Policy来管理某个用户在某个tenant下的权限。但后台具体是如何区分的呢，怎样让35357可以创建用户而5000创建不了用户。
阅读(...) 评论()openstack（14）
新浪微博：；&
博客地址：
当你开始使用OpenStack，基本上都是从一个已搭建好的环境入手，别人(operator)会告诉你horizon登录的租户名、用户名和密码。
但毕竟horizon不会封装OpenStack的所有特性，当你已经玩腻了页面上那些功能时，你想尝试更多更丰富的功能，那么恭喜你，你已经向中级玩家迈进了一步。中级玩家对OpenStack的使用基本上有：
OpenStack clientcURLRest APIOpenStack SDK
我个人比较倾向于使用client和API，因为cURL的用法其实跟发送RestAPI相似，但cURL不太方便操作(因为我们普遍都喜欢在可视化页面点击按钮)；而SDK则更多是基于OpenStack做应用时会用到，这些人一般不会关注OpenStack的内部机制。
好，你费尽心机跟operator讲好话，跟他说：哥，求求你，让我登陆后台玩玩吧! 当operator吃完你送的冰激凌，抹了一下嘴角，然后潇洒的扔了一个IP给你，“拿去耍吧”。你反复背诵着节点登陆的用户名和密码(注意，这跟horizon登陆的用户名密码不是一个东西)，小心谨慎的进了让每个程序员都感到神秘的后台，然后，快速敲了一个命令并回车：
[root@node-2 ~]# nova listERROR: You must provide a username via either --os-username or env[OS_USERNAME]
shit! 怎么回事？!一个ERROR可能让你慌了神。你平复了一下心情，心想：一定是老子敲命令的姿势不对，再试一次，这次用其他命令：
[root@node-2 ~]# keystone tenant-listExpecting 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:# With the addition of Keystone we have standardized on the term **tenant**# as the entity that owns the resources.export OS_TENANT_ID=6d0dff68ecd2d1935ba03export 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+----------------------------------+----------+---------+|
| enabled |+----------------------------------+----------+---------+| 6d0dff68ecd2d1935ba03 |
|| d1f2d43d358743eda4e37bfd489c1163 | services |
|+----------------------------------+----------+---------+[root@node-2 ~]#
呵呵，别亲我？！别动我！！
虽然使用命令行已经很接近OpenStack的本质了，但别忘了，命令行毕竟也是一种封装，如果你想玩的再透一些，Rest API是个不错的选择，使用Rest API之后，OpenStack在你面前基本上就是裸奔了。
关于API的使用我不做过多说明，因为在我之前的blog和topic里面已经说过太多次了，看一看下面的截图，你自己再稍微google一下，就什么都明白了。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：44571次
排名：千里之外
原创：11篇
转载：73篇
(1)(4)(2)(8)(10)(8)(12)(13)(10)(1)(3)(1)(1)(4)(2)(1)(3)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'标签：至少1个，最多5个
使用OpenStack服务的方式
OpenStack项目作为一个IaaS平台，提供了三种使用方式：
通过Web界面，也就是通过Dashboard（面板）来使用平台上的功能。
通过命令行，也就是通过keystone, nova, neutron等命令，或者通过最新的openstack命令来使用各个服务的功能（社区目前的发展目标是使用一个单一的openstack命令替代过去的每个项目一个命令的方式，以后会只存在一个openstack命令）。
通过API，也就是通过各个OpenStack项目提供的API来使用各个服务的功能。
上面提到的三种方式中，通过API这种方式是基础，是其他两种方式可行的基础。
通过Web界面使用OpenStack服务这种方式是通过OpenStack的Horizon项目提供的。Horizon项目是一个Django应用，实现了一个面板功能，包含了前后端的代码（除了Python，还包括了CSS和JS）。Horizon项目主要是提供一种交互界面，它会通过API来和各个OpenStack服务进行交互，然后在Web界面上展示各个服务的状态；它也会接收用户的操作，然后调用各个服务的API来完成用户对各个服务的使用。
通过命令行是用OpenStack服务的方式是由一系列项目来提供的，这些项目一般都命名为python-projectclient，比如python-keystoneclient，python-novaclietn等。这些命令行项目分别对应到各个主要的服务，为用户提供命令行操作界面和Python的SDK。比如python-keystoneclient对应到keystone，为用户提供了keystone这个命令，同时也提供了keyston项目的SDK（其实是在SDK的基础上实现了命令行）。这些client项目提供的SDK其实也是封装了对各自服务的API的调用。由于每个主要项目都有一个自己的命令行工具，社区觉得不好，于是又有了一个新的项目python-openstackclient，用来提供一个统一的命令行工具openstack（命令的名字就叫做openstack），这个工具实现了命令行，然后使用各个服务的client项目提供的SDK来完成对应的操作。
通过API使用OpenStack的方式是由各个服务自己实现的，比如负责计算的nova项目实现了计算相关的API，负责认证的keystone项目实现了认证和授权相关的API。这些API都是有统一的形式的，都是采用了HTTP协议实现的符合REST规范的API。OpenStack中如何实现这些API就是本文重点要将的内容。
基于HTTP协议的RESTful API
REST的全称是Representational State Transfer，中文翻译过来是表征状态转移，是Roy Fielding在他的博士论文提出的一种软件架构风格。可以先到页面了解一下这个风格的特点。一般会把满足这种设计风格的API成为RESTful API。由于这种软件设计风格非常适合采用HTTP协议来实现，因此HTTP协议是目前实现RESTful API的主要方案。
OpenStack就是基于HTTP协议和JSON来实现自己的RESTful API（之前OpenStack还有采用XML来表示数据的，现在都已经转到JSON了）。当一个服务要提供API时，它就会启动一个HTTP服务端，用来对外提供RESTful API。
OpenStack的API都是有详细的文档记录的，可以在看到所有的API的文档。每个API的文档形式如下：
当然，你可以点开detail看到详细的说明。从上面这个API的文档来看，你会觉得这个和开发网站时使用的GET方法和POST方法差不多，实际上也是差不多的，只不过对HTTP协议的使用方法做了满足REST风格的规定而已。
Python如何实现RESTful API
因为Python能够进行Web开发，所以用来开发RESTful API也就不成问题，这两者的技术基础是一样。在Python下开发RESTful API应用，无非是解决两个问题：
服务如何部署？
用什么框架开发？
服务如何部署？
说到Python的Web服务部署这个问题，就不得不提到WSGI。目前Python有两种方式来开发和部署一个Web应用：用WSGI和不用WSGI。如果你不了解WSGI，那么你需要先看下另外这篇关于WSGI的文章：。
OpenStack的API服务都是使用WSGI的方式来部署的。在生产环境中部署WSGI，一般会考虑使用Web服务器 + 应用服务器 + 应用(框架)的方案。OpenStack官方推荐的是使用Apache + mod_wsgi的方案，不过这个要换成其他方案也很容易，你也可以选nginx + uWSGI。对于开发调试的目的，有些项目也会提供使用eventlet的单进程部署方案，比如Keystone项目的keystone-all命令。采用eventlet这种异步架构来进行应用开发也是一个比较大的话题，本文不覆盖这方面的内容。
当然，也可以不用WSGI。在Python中，如果不使用WSGI的化，一般开发者会选择一些专门的服务器和框架，比如，或者最新最潮的。不过在OpenStack的项目中我还没见过不使用WSGI的。
用什么框架开发
Python的Web开发框架很多，最出名自然是Django了。基本上，还活跃的框架都支持RESTful API的开发，有些框架还专门为RESTful API的开发提供了便利的功能（比如Pecan），有些框架则通过第三方模块来提供这种便利，比如Django和Flask都有不少和REST相关的第三方库。
对于框架选择，也没有什么特别好的标准，一般都是比较性能、文档、社区是否活跃等。在我看来，选择流行的一般就不会错。
OpenStack中的RESTful API开发
上面已经谈到了OpenStack都是使用WSGI，也提到了部署方式。这一章来说一下OpenStack中使用的框架。
OpenStack项目倾向于不重新发明轮子，一般都会选择现有的库和框架来使用，除非现有的框架不满足需求。因为Web框架的选择很多，而且都满足需求，所以OpenStack项目到目前为止都是使用现成的Web框架。
OpenStack早期的项目并没有使用一个框架，而是使用了几个不同的模块来组合出一个框架：Paste + PasteDeploy + Routes + WebOb，这几个不同的模块分别负责应用的WSGI化、URL路由和请求处理等功能。Nova, Glance, Neutron, Keystone等早期的项目都是使用这样的架构来实现RESTful API的。
早期的这种技术选型带来的好处是"框架"具备足够的灵活性，缺点则是要把这几个模块组合起来实现一个REST服务，需要写很多代码，连WSGI的入口函数都要自己实现（比如Keystone项目的keystone/common/wsgi.py文件中的class Application）。因为灵活性的好处不是很明显，而代码量大的坏处很明显，比如上面那个class Application需要在每个项目中复制一遍，所以社区的新项目就开始使用新的Web框架Pecan。
Pecan是一个基于对象路由的框架，即灵活又简单。Pecan主要实现了URL路由功能，支持RESTful API。Pecan没有实现模板、session管理和ORM等功能，但是这些功能可以通过其他的模块来实现。对于OpenStack来说，Pecan是一个很好的选择，因为OpenStack项目中统一使用sqlalchemy来实现ORM，API的实现也不需要模板功能，安全控制则基于Keystone体系。使用Pecan来开发REST服务，代码量很少，代码结构也清晰。Ceilometer项目就是使用了Pecan。
1 收藏&&|&&35
你可能感兴趣的文章
12 收藏，1.8k
30 收藏，4.2k
15 收藏，1.9k
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可
分享到微博？
技术专栏，帮你记录编程中的点滴，提升你对技术的理解收藏感兴趣的文章，丰富自己的知识库
明天提醒我
我要该，理由是：在安装时OpenStack会加载配置信息。有不同的虚拟机模板而且与在Amazon EC2以及其他平台上看到的完全一样。这些配置是内存、vCPU、磁盘容量等的组合，定义了虚拟机的大小及容量。可以使用如下命令列出配置信息： nova flavor-list +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name & & &| Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | 1 &| m1.tiny & | 512 & & & | 1 & &| 0 & & & & | & & &| 1 & & | 1.0 & & & & | True & & &| | 2 &| m1.small &| 2048 & & &| 20 & | 0 & & & & | & & &| 1 & & | 1.0 & & & & | True & & &| | 3 &| m1.medium | 4096 & & &| 40 & | 0 & & & & | & & &| 2 & & | 1.0 & & & & | True & & &| | 4 &| m1.large &| 8192 & & &| 80 & | 0 & & & & | & & &| 4 & & | 1.0 & & & & | True & & &| | 5 &| m1.xlarge | 16384 & & | 160 &| 0 & & & & | & & &| 8 & & | 1.0 & & & & | True & & &| +----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ 我们使用代码创建一个OpenStack虚拟机，在源头进行修改。我对必须进行修改的部分进行了加粗显示： #!/usr/bin/env python import time import os execfile('credentials.py') from novaclient.client import Client try: & & & &credentials = get_nova_credentials_v2() & & & &nova_client = Client(**credentials) & & & &image = nova_client.images.find(name="cirros-0.3.3-x86_64") & & & &flavor = nova_client.flavors.find(name="m1.tiny") & & & &net = nova_client.networks.find(label="demo-net") & & & &nics = [{'net-id': net.id}] & & & &instance = nova_client.servers.create(name="vm2", image=image, & & & & & & & & & & & & & & & & & & & & &flavor=flavor, key_name="demo-key",nics=nics) & & & &print("Sleeping for 5s after create command") & & & &time.sleep(5) & & & &print("List of VMs") & & & &print(nova_client.servers.list()) finally: & & & &print("Execution Completed") 以下内容取决于设置时使用了什么值： & & flavor = nova_client.flavors.find(name="m1.tiny") & & net = nova_client.networks.find(label="demo-net") key_name="demo-key" 现在你可以运行Python代码并查看是否创建了一个虚拟机。显然如果没有成功，那么必须回退到OpenStack安装过程以查看哪部分有问题。基于个人经验，可能要尝试几次才能成功，因为配置有很多部分构成。TechTarget中国原创内容，原文链接：&& TechTarget中国：.cn
阅读(...) 评论()}