Heat架构

女爷i 2022-06-05 21:12 266阅读 0赞

# 背景 #

在虚拟化环境下已有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等等，格式之间的差别在于表现形式。