Heat架构

2024-06-20 19:38
文章标签 架构 heat

本文主要是介绍Heat架构,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

背景

在虚拟化环境下已有VMVare联合其他大产商推出的应用打包发布标准格式OVF,VMVare的vSphere和IBM的虚拟化产品对此都有一系列的支持。OVF解决了应用在虚拟化平台自动部署的问题,可是在面对现在的云平台环境下,还是有些不足,需要将OVF格式更进一步推进。Amazon对复杂应用系统的部署给出了自己的解决方案AWS CloudFormation, OpenStack社区也给出了自己对应的项目Heat。
________________________________________

AWS CloudFormation

Amazon 在云计算早期,提供了Amazon Machine Images即AMI的一站式展示,这些AMI都是单个虚拟机镜像模板,通过使用Amazon的EC2服务,可以依赖于这些镜像模板迅速的创建出单一服务器上的应用。当然,创建出来的单一实例还需要用户手动去设置,完成实现服务可用的最后一步。
直接的使用AMI的方式,在面对复杂的集群应用面前就显得更加无力。Amazon为了解决此问题,推出了Amazon CloudFormation Templates。CloudFormation Templates 专门为大规模集群应用而生,通过使用这样的模板,来简化AWS资源的准备和部署,解决了传统方式上需要手动管理各项资源之间依赖的问题,实现了在EC2中迅速创建大量实例部署集群应用。
CloudFormation的推出,让Amazon更好的拥抱了企业IT领域。

OpenStack Heat

OpenStack Heat 是由RedHat公司在Grizzly版放出的孵化项目。Heat项目直接对应于AWS的CloudFormation,在目前来看,还只是CloudFormation功能的一个子集。Heat可以对Amazon CloudFormation Templates进行配置,并运行在任何一个OpenStack生态环境上。
对于Heat的认识,我们可以直接从CloudFormation入手,Amazon在其官网上给出的CloudFormation介绍如下:
“AWS CloudFormation 向开发人员和系统管理员提供了一种简便地创建和管理一批相关的 AWS 资源的方法,并通过有序且可预测的方式对其进行资源配置和更新。您可以使用AWS CloudFormation 的示例模板或自己创建模板来介绍 AWS 资源以及应用程序运行时所需的任何相关依赖项或运行时参数。您可以不需要了解 AWS 服务需要配置的顺序,也不必弄清楚让这些依赖项正常运行的细枝末节。CloudFormation 为您妥善处理。当设置完成后,您可通过按受控制、可预测的方式修改和更新 AWS 资源,您可像执行软件版本控制一样对您的 AWS 基础结构进行版本控制。您可以通过 AWS 管理控制台、CloudFormation 命令行工具或 API 对模板及其相关的资源集(称为“堆栈”)进行设置和更新。”
总之,Heat是来自于AWS的CloudFormation,设计与实现上都基本和Amazon保持一致。
对于Heat的功能和实现,简单来说就是用户可以预先定义一个规定格式的任务模版,任务模版中定义了一连串的相关任务(例如用某配置开几台虚拟机,然后在其中一台中安装一个mysql服务,设定相关数据库属性,然后再配置几台虚拟机安装web服务群集等等),然后将模版交由Heat执行,就会按一定的顺序执行heat模版中定义的一连串任务。






Heat介绍

 Openstack 对应于云计算的概念,是实现了IaaS(Infrastructure as a Service),即基础设施即服务,提供对云的基础设施运行环境的管理。有了基础设施就可以在其上部署和运行相关的应用,如web群集,paas,数据库等等相关的服务和应用。对于这些软件运行环境的构建需要进行相关的部署过程,当然部署的过程可以手工的完成,但是面对于快速构建应用的普遍需求来说,手工部署并不能满足要求,并且云环境下的群集部署对于普通的非专业的用户来说是很困难的,所以就需要实现一种自动化的通过简单定义和配置就能实现部署的云部署方式。Heat项目就是提供了一种通过模版定义的协同部署方式,实现云基础设施软件运行环境的自动化部署。
        Heat项目其实是和Amazon的AWS CloudFormation相对应的,就是为了实现对等的功能。为了更好的解释Heat的功能,我在这里就直接从aws的官网直接引用对AWS CloudFormation的介绍:“AWS CloudFormation 向开发人员和系统管理员提供了一种简便地创建和管理一批相关的 AWS 资源的方法,并通过有序且可预测的方式对其进行资源配置和更新。您可以使用AWS CloudFormation 的示例模板或自己创建模板来介绍 AWS 资源以及应用程序运行时所需的任何相关依赖项或运行时参数。您可以不需要了解 AWS 服务需要配置的顺序,也不必弄清楚让这些依赖项正常运行的细枝末节。CloudFormation 为您妥善处理。当设置完成后,您可通过按受控制、可预测的方式修改和更新 AWS 资源,您可像执行软件版本控制一样对您的 AWS 基础结构进行版本控制。您可以通过 AWS 管理控制台、CloudFormation 命令行工具或 API 对模板及其相关的资源集(称为“堆栈”)进行设置和更新“。
      对于Heat的功能和实现,简单来说就是用户可以预先定义一个规定格式的任务模版,任务模版中定义了一连串的相关任务(例如用某配置开几台虚拟机,然后在其中一台中安装一个mysql服务,设定相关数据库属性,然后再配置几台虚拟机安装web服务群集等等),然后将模版交由Heat执行,就会按一定的顺序执行heat模版中定义的一连串任务。
       Heat对于虚拟机内部操作的控制是需要利用heat-cfntools这个工具。其实质是,通过向实例镜像中注入heat-cfntools,然后实例利用heat-cfntools同heat交互,进而实现相关的对于实例内部的相关操作(如安装和配置mysql数据库等)。
     官方还给了一个用heat部署openshift(redheat的开源paas)的具体例子,这个例子其实很有意义, 这就表明利用包含heat的openstack就可以完整的实现一个,从IaaS到paas,从云基础设施硬件环境,到云应用的软件运行环境的整体的部署和运行。






Heat架构



Heat 服务包含以下重要的组件:
Heat-api 组件实现 OpenStack 天然支持的 REST API。该组件通过把 API 请求经由 AMQP 传送给 Heat engine 来处理 API 请求。
Heat-api-cfn 组件提供兼容 AWS CloudFormation 的 API,同时也会把 API 请求通过 AMQP 转发给 heat engine。
Heat-engine 组件提供 Heat 最主要的协作功能。
用户在 Horizon 中或者命令行中提交包含模板和参数输入的请求,Horizon 或者命令行工具会把请求转化为 REST 格式的 API 调用,然后调用 Heat-api 或者是 Heat-api-cfn。Heat-api 和 Heat-api-cfn 会验证模板的正确性,然后通过 AMQP 异步传递给 Heat Engine 来处理请求。
图Heat 架构
 
当 Heat Engine 拿到请求后,会把请求解析为各种类型的资源,每种资源都对应 OpenStack 其它的服务客户端,然后通过发送 REST 的请求给其它服务。通过如此的解析和协作,最终完成请求的处理。
基于预先定义的模板,Heat通过自身的orchestration Engine来实现复杂应用的创建启动。Heat原生的模板格式目前还在不停地演进中,但是对CloudFormation的格式具有良好的支持。存在的CloudFormation的模板可以在OpenStack平台通过heat来启动。
Heat Client
Heat client是Heat project 提供的CLI工具,类似于其他项目的client。对于heat tools的使用,可以通过安装后查看,或者通过此链接来查看。
heat-api
Heat-api 类似于nova-api,提供了原生的restful API对外使用。用户对API的调用,由heat-api处理之后,最终通过RPC传递给Heat-engine来进一步处理。
heat-api-cfn
heat-api-cfn组件则提供了Amazon style 的查询 API,因此可以完全兼容于Amazon的CloudFormation,对于API的请求,同heat-api类似,处理之后,通过RPC传递给heat-engine进一步处理。
heat-engine
heat-engine是heat中的核心模块,主要的逻辑业务处理模块。此模块最终完成应用系统的创建和部署。
heat-cfntools
这个工具是一个单独的工具,代码没在heat project里面,可以单独下载。这个工具主要用来完成虚拟机实例内部的操作配置任务。在创建虚拟机竟像时,需要在镜像中安装heat-cfntools工具。




heat api

heat-api
Heat-api 类似于nova-api,提供了原生的restful API对外使用。用户对API的调用,由heat-api处理之后,最终通过RPC传递给Heat-engine来进一步处理。
heat-api-cfn
heat-api-cfn组件则提供了Amazon style 的查询 API,因此可以完全兼容于Amazon的CloudFormation,对于API的请求,同heat-api类似,处理之后,通过RPC传递给heat-engine进一步处理。


heat engine

Heat Engine 在这里的作用分为三层: 第一层处理 Heat 层面的请求,就是根据模板和输入参数来创建 Stack,这里的 Stack 是由各种资源组合而成。 第二层解析 Stack 里各种资源的依赖关系,Stack 和嵌套 Stack 的关系。第三层就是根据解析出来的关系,依次调用各种服务客户段来创建各种资源。
图Heat Engine 结构
 


整个heat的实现最为关键的代码在heat-engine,heat-engine的实现没令人失望,充满了趣味。前面提到,heat就是来操作stack,管理stack的整个生命周期: create,update,delete。
重点看create的过程,查看heat stack-create命令:




usage: heat stack-create [-f <FILE>] [-e <FILE or URL>]
                         [--pre-create <RESOURCE>] [-u <URL>] [-o <URL>]
                         [-c <TIMEOUT>] [-t <TIMEOUT>] [-r]
                         [-P <KEY1=VALUE1;KEY2=VALUE2...>] [-Pf <KEY=FILE>]
                         [--poll [SECONDS]] [--tags <TAG1,TAG2>]
                         <STACK_NAME>


Create the stack.


Positional arguments:
  <STACK_NAME>          Name of the stack to create.


Optional arguments:
  -f <FILE>, --template-file <FILE>
                        Path to the template.
  -e <FILE or URL>, --environment-file <FILE or URL>
                        Path to the environment, it can be specified multiple
                        times.
  --pre-create <RESOURCE>
                        Name of a resource to set a pre-create hook to.
                        Resources in nested stacks can be set using slash as a
                        separator: nested_stack/another/my_resource. You can
                        use wildcards to match multiple stacks or resources:
                        nested_stack/an*/*_resource. This can be specified
                        multiple times
  -u <URL>, --template-url <URL>
                        URL of template.
  -o <URL>, --template-object <URL>
                        URL to retrieve template object (e.g. from swift).
  -c <TIMEOUT>, --create-timeout <TIMEOUT>
                        Stack creation timeout in minutes. DEPRECATED use
                        --timeout instead.
  -t <TIMEOUT>, --timeout <TIMEOUT>
                        Stack creation timeout in minutes.
  -r, --enable-rollback
                        Enable rollback on create/update failure.
  -P <KEY1=VALUE1;KEY2=VALUE2...>, --parameters <KEY1=VALUE1;KEY2=VALUE2...>
                        Parameter values used to create the stack. This can be
                        specified multiple times, or once with parameters
                        separated by a semicolon.
  -Pf <KEY=FILE>, --parameter-file <KEY=FILE>
                        Parameter values from file used to create the stack.
                        This can be specified multiple times. Parameter value
                        would be the content of the file
  --poll [SECONDS]      Poll and report events until stack completes. Optional
                        poll interval in seconds can be provided as argument,
                        default 5.
  --tags <TAG1,TAG2>    A list of tags to associate with the stack.


三个关键的optional arguments:
template-file: 模板文件
environment-file: 环境文件
parameters: 设置模板文件中的parameters




environment-file

What is an Environment?

https://wiki.openstack.org/wiki/Heat/Environments


I see an Environment as a container for anything that affects the behavior of the Template (kinda like structured parameters).
1. So parameters can be written into an environment file or automatically inserted if you pass them on the cli.
2. You define any non-default Providers in the Environment
3. You can define any extra/non-keystone credentials in the Environment
Template Static architectural design of your application
Environment Specific details that affect the instantiation of the Template
Stack Template + Environment
Example
 parameters:
   InstanceType: m1.xlarge
   DBUsername: angus
   DBPassword: verybadpass
   KeyName: heat_key
 credentials:
   rackspace_creds:
       username: myusername
       api_key: 012345abcdef67890
 resources:
   provider: rackspace.com
   DatabaseServer:
       ImageId: this_image_please
       credentials: rackspace_creds






Heat Environment详解

http://blog.csdn.net/u010305706/article/details/54289663
使用heat client命令创建或者更新stack,其中有一个可选选项-e/--environment-file,用于指定环境文件。
目前环境文件主要有两个方面的作用:
1. 配置模板需要的参数值
2. 资源注册
environment文件内容格式可以参考heat源码包中的environment.rst文件,其中有详细描述。


这篇文章就先来探讨一下怎么利用environment文件来配置参数。


我们知道在heat模板中可以通过parameters字段配置模板的输入参数,例如下面的模板文件mytemplate.yaml:
[plain] view plain copy
1. heat_template_version: 2013-05-23  
2. description: create cinder volume  
3.  
4. parameters:  
5.  volsize:  
6.    type: number  
7.    description: Size of volume to create  
8.  
9. resources:  
10.  myres:  
11.    type: OS::Cinder::Volume  
12.    properties:  
13.      name: volname  
14.      size: { get_param: volsize }  
其中volsize就是一个可定制的输入参数,比较常用的方式是在创建stack命令行中通过-P选项输入,例如:
[plain] view plain copy
1. heat stack-create -f mytemplate.yaml -P vol_size=1 mystack  


通过environment文件也能达到指定参数值的目的,编写myenv.yaml文件,设置parameters配置段,内容如下:
[plain] view plain copy
1. parameters:  
2.  volsize: 2  


在执行stack-create命令时,通过-e/--environment-file选项指定myenv.yaml文件,如下:
[plain] view plain copy
1. heat stack-create -f mytemplate.yaml -e myenv.yaml mystack  
效果跟前面通过-P选项指定参数值是一样的。


通过environment文件来配置参数值,个人觉得主要是针对参数较多,或者需要创建的多个stack具有类似参数的场景。
想想如果参数较多,在命令行上一个一个敲还是很费劲的。


除了parameters配置段,还有一个parameter_defaults配置段也可以用来指定参数值,如下:
[plain] view plain copy
1. parameter_defaults:  
2.  volsize: 2  
效果跟parameters一样。




那么问题来了,既然最终的效果一样,为什么heat要设计这两种方式呢?
这个问题我也有一些困惑。看了help的提示信息,有一些个人看法。
-e/--environment-file选项的帮助信息如下:
[plain] view plain copy
1. -e <FILE or URL>, --environment-file <FILE or URL>  
2.                      Path to the environment, it can be specified multiple  
3.                      times.  
可以看到,environment文件可以被指定多次。
那么在创建多个类似stack的时候,就可以把默认的参数配置到一个environment文件的parameter_defaults段。
而如果某些stack需要特殊的参数配置,就可以配置在另外一个environment文件的parameters段中。
这样的好处就是,公共参数不需要在每个stack的环境文件中重复配置。


还是用前面的模板为例,增加一个参数volname:
[plain] view plain copy
1. parameters:  
2.  volname:  
3.    type: string  
4.    description: Name of volume to create  
5.  volsize  
6.    type: number  
7.    description: Size of volume to create  




配置一个默认参数环境文件default.yaml如下:
[plain] view plain copy
1. parameter_defaults:  
2.  volname: MyVolName  
3.  volsize: 2  


那么就可以通过如下命令创建默认stack:
[plain] view plain copy
1. heat stack-create -f mytemplate.yaml -e default.yaml defaultstack  




这时候如果需要创建另一个stack,而stack的卷名字想改为NewName,就可以另外编写一个定制环境文件custom.yaml:
[plain] view plain copy
1. parameters:  
2.  volname: NewName  
然后使用如下命令创建:
[plain] view plain copy
1. heat stack-create -f mytemplate.yaml -e default.yaml -e custom.yaml customstack  


如果参数很多的话,就更能够体现出以上方式的好处。


最后,还有一个问题,现在知道参数可以通过parameter_defaults和parameters来指定,也可以通过命令行-p选项指定。
那如果一个参数通过上面三种方式都指定了,最终会用哪个方式指定的值呢?
优先级如下:
-P选项配置 > parameters配置 > parameter_defaults配置
例如,如果myenv.yaml文件内容如下:
[plain] view plain copy
1. parameters:  
2.    volsize: 1  
3.      
4. parameter_defaults:  
5.    volsize: 2  


使用如下命令行创建stack:
[plain] view plain copy
1. heat stack-create -f mytemplate.yaml -e myenv.yaml -P volsize=3 mystack  
最后创建出来的卷大小会是3GB,因为实际使用的是优先级最高的-P选项指定的值。


利用environment文件实现heat资源注册

http://blog.csdn.net/wifeisboss/article/details/47811213
原创 2015年08月20日 17:32:27
527
前面一篇文章提到了,environment环境文件可以用来指定参数值,还有一个作用是用来实现资源注册。
下面就来探讨一下环境文件在这方面的作用。
资源注册配置段关键字为resource_registry。


资源注册主要分为两种类型:
资源映射
资源构建和重载
资源映射是将一种资源类型映射为另一种资源类型,主要用于提升模板在各heat版本之间的适用性。
例如,某模板配置了IP资源,类型是“OS::Networking::FloatingIP”。
现在想直接利用此模板,但是IP资源类型改为“OS::Nova::FloatingIP”,就可以通过资源映射的方式来实现。
环境文件配置如下:
[plain] view plain copy
1. resource_registry:  
2.  "OS::Networking::FloatingIP": "OS::Nova::FloatingIP"  
创建stack时,通过-e/--environment-file选项指定此环境文件,就可以实现IP资源类型的替换,省去了大范围模板改动的麻烦。


下面举个例子予以演示。
编辑模板文件template.yaml,内容如下:
[plain] view plain copy
1. heat_template_version: 2013-05-23  
2. description: create cinder volume  
3.  
4. resources:  
5.  myres:  
6.    type: OS::ForTest::TestVolType  
7.    properties:  
8.      name: volname  
9.      size: 10  
很明显,上面模板指定的资源类型“OS::ForTest::TestVolType”不是一个有效的heat资源类型。
如果直接使用该模板创建stack,结果肯定是创建失败。


这时候就可以使用环境文件的资源映射配置,将上面无效的资源类型映射到实际有效的资源类型。
编辑环境文件env.yaml内容如下:
[plain] view plain copy
1. resource_registry:  
2.  "OS::ForTest::TestVolType": "OS::Cinder::Volume"  
然后使用传入环境文件的命令行创建stack:
[plain] view plain copy
1. heat stack-create -f template.yaml -e env.yaml mystack  
这样,heat服务实际会以映射后的OS::Cinder::Volume类型创建myres资源。
不过通过命令行查看资源,仍然会显示模板配置的资源类型:
[plain] view plain copy
1. +---------------+--------------------------------------+--------------------------+-----------------+---------------------+  
2. | resource_name | physical_resource_id                 | resource_type            | resource_status | updated_time        |  
3. +---------------+--------------------------------------+--------------------------+-----------------+---------------------+  
4. | myres         | de072612-94e5-43a0-b448-e5e830de27f8 | <span style="color:#ff0000;">OS::ForTest::TestVolType</span> | CREATE_COMPLETE | 2015-08-24T02:34:55 |  
5. +---------------+--------------------------------------+--------------------------+-----------------+---------------------+  


资源构建和重载包含两重意思,一是构建一个新的资源类型,另一个是替换现有资源类型。
都使用类似的配置方式:
[plain] view plain copy
1. resource_registry:  
2.  "OS::ForTest::TestVolType": file:///root/custom_res.yaml  
[plain] view plain copy
1. resource_registry:  
2.  "OS::Cinder::Volume": file:///root/custom_res.yaml  
其中,“:”前的字符串表示资源类型,可以是自定义的新资源,也可以是heat自带的资源类型。
“:”后是资源的定义文件,其实内容就是一个模板。


下面看一个例子。
编辑模板文件template.yaml如下:
[plain] view plain copy
1. heat_template_version: 2013-05-23  
2. description: create cinder volume  
3.  
4. resources:  
5.  myres:  
6.    type: OS::ForTest::TestVolType  
7.    properties:  
8.      volsize: 10  
9.  
10. outputs:  
11.  voltypeofnestres:  
12.    value: { get_attr: [myres, voltype] }  
编辑环境文件env.yaml如下:
[plain] view plain copy
1. resource_registry:  
2.    "OS::ForTest::TestVolType": file:///root/custom_template.yaml  
再编辑定制资源模板文件custom_template.yaml如下:
[plain] view plain copy
1. heat_template_version: 2013-05-23  
2. description: volume template  
3.  
4. parameters:  
5.  volsize:  
6.    type: number  
7.    description: Size of volume to create  
8.  
9. resources:  
10.  nestres:  
11.    type: OS::Cinder::Volume  
12.    properties:  
13.      name: volname  
14.      size: { get_param: volsize }  
15.  
16. outputs:  
17.  voltype:  
18.    value: { get_attr: [nestres, volume_type] }  
最后,通过命令行创建stack:
[plain] view plain copy
1. heat stack-create -f template.yaml -e env.yaml stack222  
创建成功后,查看stack列表:
[plain] view plain copy
1. #heat stack-list -n  
2. +--------------------------------------+-----------------------------+-----------------+---------------------+--------------------------------------+  
3. | id                                   | stack_name                  | stack_status    | creation_time       | parent                               |  
4. +--------------------------------------+-----------------------------+-----------------+---------------------+--------------------------------------+  
5. | 74b3d8f9-579e-4683-b6b6-0e7d35360486 | stack222                    | CREATE_COMPLETE | 2015-08-24T03:47:59 | None                                 |  
6. | 1017317d-7b91-47af-a1ea-dab888750b30 | stack222-myres-by6l4uwboidx | CREATE_COMPLETE | 2015-08-24T03:48:06 | 74b3d8f9-579e-4683-b6b6-0e7d35360486 |  
7. +--------------------------------------+-----------------------------+-----------------+---------------------+--------------------------------------+  
可以看到,实际创建了两个stack。
其中,stack222是以template.yaml模板创建的stack,而stack222-myres-by6l4uwboidx是以custom_template.yaml模板创建的stack。
stack222-myres-by6l4uwboidx是stack222的nested stack(嵌套栈)。


再看看stack资源:
[plain] view plain copy
1. # heat resource-list stack222 -n 1  
2. +---------------+--------------------------------------+--------------------------+-----------------+---------------------+-----------------+  
3. | resource_name | physical_resource_id                 | resource_type            | resource_status | updated_time        | parent_resource |  
4. +---------------+--------------------------------------+--------------------------+-----------------+---------------------+-----------------+  
5. | myres         | 1017317d-7b91-47af-a1ea-dab888750b30 | OS::ForTest::TestVolType | CREATE_COMPLETE | 2015-08-24T03:48:05 |                 |  
6. | nestres       | 4c2bdba8-2ba8-4970-a5f5-e385164b7833 | OS::Cinder::Volume       | CREATE_COMPLETE | 2015-08-24T03:48:06 | myres           |  
7. +---------------+--------------------------------------+--------------------------+-----------------+---------------------+-----------------+  


实际在heat代码实现中,自定义的资源类型实际是被转换为了TemplateResource(模板资源),而模板资源实例化的对象就是stack。
模板资源的stack(如stack222-myres-by6l4uwboidx)与命令行模板创建的stack(如stack222)形成嵌套关系。


最后回过头来再看看前面的模板定义。
细心的朋友可能已经发现了,自定义资源类型OS::ForTest::TestVolType的property,其实就是定制模板的parameter,如volsize。
而OS::ForTest::TestVolType的attribute,是定制模板导出的outputs,如voltype。
通过这种方式,就实现了自定义资源和定制模板之间输入和输出的关联。


heat管理工具

在OpenStack上安装并启用之后,可以通过管理界面上的“编配-栈”对Stack进行创建和删除。另外我们也可以使用heat-client提供的命令行工具进行管理。OpenStack使用Python进行开发,先需要安装Python的包管理工具pip,接下来使用pip安装heat-client.
pip install heat-client
如果使用的是Mac Yosemite并且没有为Python创建虚拟环境的话,需要删除 heat-client 并使用easy_install重新安装相关的依赖包,否则调用 heat 时会出现 no module named xmlrpc_client 的错误。

命令行工具

安装好后,先需要配置OpenStack的API认证信息到环境变量中,然后可以使用以下命令查看帮助、创建或删除Stack:
export OS_PASSWORD=password
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://openstack.example.org/v2.0
export OS_USERNAME=ADMIN


heat --help
heat list
heat stack-create -f hello_world.yaml mytest
heat stack-delete mytest
如果遇到找不到Controller机器的错误,还需要在本地机器hosts中添加Controller的DNS解析,这算是开源项目的一个Bug:
10.10.0.1    Controller
创建或删除Stack后Heat都会返回当前Stacks的状态,同时在OpenStack的仪表板中可以看到被创建的Stack和虚拟机实例:
+--------------------------------------+--------------+--------------------+----------------------+
| id                                   | stack_name   | stack_status       | creation_time        |
+--------------------------------------+--------------+--------------------+----------------------+
| 8d874f5c-6c6d-430a-8b9e-695be68e5972 | test-stack   | CREATE_IN_PROGRESS | 2015-01-21T06:21:19Z |
| bfbaea3b-185e-41d3-941b-f329aeb3425e | ansible-heat | DELETE_IN_PROGRESS | 2015-01-21T06:31:30Z |
+--------------------------------------+--------------+--------------------+----------------------+

使用编程方式访问API

Heat本身提供了Naive API可通过Http进行请求,默认端口是8004,在通过身份认证取得tenat_id后,通过以下Url进行请求:
http://heat.example.org:8004/v2/{tenant_id}
官方提供的Python Client类只提供了通过token的方式调用,先需要解决KeyStone身份认证的问题,在身份认证之后,可以在返回的Auth对象中取得Heat的API Url。示例代码如下:
from heatclient.client import Client as heatClient
from keystoneclient.v2_0 import client as keyStoneClient


username = 'admin'
password = 'password'
tenant_name = 'ADMIN'
auth_url = 'http://heat.example.org:35357/v2.0'
keystone = keyStoneClient.Client(username=username, password=password, 
                                 tenant_name=tenant_name, auth_url=auth_url)


auth_token = keystone.auth_ref['token']['id']
heat_url = ''
services = keystone.auth_ref['serviceCatalog']
for service in services:
    if service['name'] == 'heat':
        heat_url = service['endpoints'][0]['publicURL']


heat = heatClient('1', endpoint=heat_url, token=auth_token)
创建一个Stack
from heatclient.common import template_utils
path = "/var/tmp/hello_world.yaml"
tpl_files, template = template_utils.get_template_contents(path)
create_fields = {
    'stack_name': 'test_stack',
    'disable_rollback': 'false',
    'parameters': '',
    'template': template,
    'files': dict(list(tpl_files.items()))
}
heat.stacks.create(**create_fields)
删除Stack
delete_fields = {
    'stack_id': 'test_stack'
}
heat.stacks.delete(**delete_fields)


简单流程

________________________________________
现在简单的描述heat是迅速创建一个复杂的应用并且完成最终的配置工作的整个流程。
预处理
第一步,需要在虚拟机镜像中安装cloud-init和heat-cfntools两个工具。前者cloud-init是用来处理虚拟机实例早期的一些配置工作的,主要完成以下几方面的配置:
设置默认的locale
设置hostname
生成ssh private keys
添加ssh keys到用户的.ssh/authorized_keys文件中,方便用户登录。
设置ephemeral mount points
整个cloud-init可以通过创建应用时指定—user-data-file或者—user-data选项来设置。User-data的具体选项可以通过此链接来查看。
创建应用
调用heat-api来创建,例如heat stack-create myApplication
heat-engine生成cloud-init将会使用到的multipart data
heat-engine调用nova-api,创建虚拟机实例,将cloud-init用到的数据随nova-api的调用传递。
nova创建虚拟机实例。
当虚拟机实例启动时,将会执行cloud-init脚本,该脚本将做以下几件事: ** 从nova metadata server下载数据 ** 将下载来的multipart data划分到/var/lib/cloud目录去 ** 运行不同的cloud-init部分,例如resize the root filesystem, set the hostname ** 运行用户的脚本,脚本位于/var/lib/cloud/data/cfn-userdata目录,这些脚本必须调用cfn-init

模板

Heat的目的之一就是致力于应用系统的自动化部署,那么若要自动化部署,则需要存在某个语言规范来描述应用系统,并且解决应用系统在不同场合下的配置适应问题。Heat模板文件则是用来对前者的支持。


模板文件的格式多种多样,例如,Heat的鼻祖Amazon提供的cloudformation格式,Heat自有的格式HOT, Json等等,格式之间的差别在于表现形式。

这篇关于Heat架构的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1079069

相关文章

MySQL 缓存机制与架构解析(最新推荐)

《MySQL缓存机制与架构解析(最新推荐)》本文详细介绍了MySQL的缓存机制和整体架构,包括一级缓存(InnoDBBufferPool)和二级缓存(QueryCache),文章还探讨了SQL... 目录一、mysql缓存机制概述二、MySQL整体架构三、SQL查询执行全流程四、MySQL 8.0为何移除查

微服务架构之使用RabbitMQ进行异步处理方式

《微服务架构之使用RabbitMQ进行异步处理方式》本文介绍了RabbitMQ的基本概念、异步调用处理逻辑、RabbitMQ的基本使用方法以及在SpringBoot项目中使用RabbitMQ解决高并发... 目录一.什么是RabbitMQ?二.异步调用处理逻辑:三.RabbitMQ的基本使用1.安装2.架构

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

创业者该如何设计公司的股权架构

本文来自七八点联合IT橘子和车库咖啡的一系列关于设计公司股权结构的讲座。 主讲人何德文: 在公司发展的不同阶段,创业者都会面临公司股权架构设计问题: 1.合伙人合伙创业第一天,就会面临股权架构设计问题(合伙人股权设计); 2.公司早期要引入天使资金,会面临股权架构设计问题(天使融资); 3.公司有三五十号人,要激励中层管理与重要技术人员和公司长期走下去,会面临股权架构设计问题(员工股权激

【系统架构设计师】黑板架构详解

黑板架构(Blackboard Architecture)是一种软件架构模式,它模仿了多个专家系统协作解决问题的场景。在这种架构中,“黑板”作为一个中央知识库,存储了问题的当前状态以及所有的解决方案和部分解决方案。黑板架构特别适合于解决那些没有确定算法、需要多个知识源(或称为“专家”)共同作用才能解决的复杂问题。 一、黑板架构的组成 黑板架构主要由以下几个部分组成: 黑板(Blackboa

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

Arch - 演进中的架构

文章目录 Pre原始分布式时代1. 背景与起源2. 分布式系统的初步探索3. 分布式计算环境(DCE)4. 技术挑战与困境5. 原始分布式时代的失败与教训6. 未来展望 单体时代优势缺陷单体架构与微服务架构的关系总结 SOA时代1. SOA架构及其背景1. 烟囱式架构(Information Silo Architecture)2. [微内核架构](https://www.oreilly.c