OpenStack中的Heat分析

问题导读：
1、OpenStack中的组件之一Heat是什么 ？
2、Heat和ovf的区别是什么 ？
3、如何理解AutoScaling的架构？




版本：2013.2

Heat
Heat是一套业务流程平台，旨在帮助用户更轻松地配置以OpenStack为基础的云体系。利用Heat应用程序，开发人员能够在程序中使用模板以实现资源的自动化部署。Heat能够启动应用、创建虚拟机并自动处理整个流程。它还拥有出色的跨平台兼容性，能够与Amazon Web Services业务流程平台CloudFormation相对接——这意味着用户完全可以将AWS模板引入OpenStack环境当中。

所以，在分析Heat的时候，不可避免的要与AWS的CloudFormation作对比。


Template
关于template，可以参考Amazon的文档，毕竟heat源于CloudFormation。 其实把Amazon CloudFormation的文档仔细读一遍，基本就能玩转Heat了。

需要说的就一点，虽然heat目前兼容CloudFormation，但openstack社区已经在慢慢支持自研的模板结构，叫HOT(heat orchestration template，本文暂不关注)，所以目前有两种template解释器，依据模板文件开头是否是heat_template_version字段识别。

目前CloudFormation Template中，Heat仅支持如下的字段：
'AWSTemplateFormatVersion', 'Description', 'Mappings', 'Parameters', 'Resources', 'Outputs'
而CloudFormation中的'Conditions'字段目前还不支持。


Function Reference
在CloudFormation中，支持如下的函数：
Fn::Base64, Fn::FindInMap, Fn::GetAtt, Fn::GetAZs, Fn::Join, Fn::Select, Ref，目前Heat都支持。因为尚不支持Conditions字段，所以也不支持Fn::And, Fn::Equals, Fn::If, Fn::Not, Fn::Or，这些条件判断函数。

Resource Attributes: DeletionPolicy
定义资源时，可以定义DeletionPolicy属性，表示在删除stack时，资源的删除策略，默认是Delete。在CloudFormation中，可以指定Retain，表示不删除该资源，对于有快照功能的资源（比如AWS::EC2::Volume），也可以指定Snapshot，表示在删除前先做快照。

Resource Attributes: DependsOn
显式的定义资源的依赖关系。在资源定义时已经有一些函数（比如Ref或Fn::GetAtt）可以判定依赖关系，但除了这些，可能还需要手工指定依赖。一个典型的用法就是配合AWS::CloudFormation::WaitCondition(关于WaitCondition一个使用示例可以参见这里)，它的作用是暂停stack的创建，等待某个信号，然后再恢复执行。比如在虚拟机创建完后，需要等待应用的下载和配置结束，然后才能真正认为该虚拟机创建完毕。一个例子：

"myWaitCondition" : {
    "Type" : "AWS::CloudFormation::WaitCondition",
    "DependsOn" : "Ec2Instance",
    "Properties" : {
        "Handle" : { "Ref" : "myWaitHandle" },
         "Timeout" : "4500"
    }
}    
"myWaitHandle" : {
     "Type" : "AWS::CloudFormation::WaitConditionHandle",
     "Properties" : {
     }
}
复制代码

在定义虚拟机资源时，可以指定userdata：

"UserData" : {
   "Fn::Base64" : {
       "Fn::Join" : [ "", [
            "curl -X PUT -H 'Content-Type:' --data-binary '{"Status" : "SUCCESS",",
                                                           ""Reason" : "The application myapp is ready",",
                                                           ""UniqueId" : "myapp",",
                                                           ""Data" : "Done"}' ",
             """, {"Ref" : "myWaitHandle"},""\n" ]]
   }
}
复制代码

当然，其他资源也可以依赖于WaitCondition，例如绑定弹性IP之前，需要确保应用程序部署完毕。


Resource Attributes: UpdatePolicy(AWS)
在CloudFormation中，仅AWS::AutoScaling::AutoScalingGroup支持UpdatePolicy属性，表示group内的虚拟机数目发生变化的约束，目前Heat还不支持。


Resource Attributes: Metadata
这个比较容易理解，为资源设置一些键值对。


Environment
The environment is used to map resource names to templates, and optionally can be used to define common stack parameters, so that they don't need to be passed every time you create a stack.


environment在heat中代表了创建stack的运行时环境。里面包含了两种资源：
1、parameters. 一个参数集，会覆盖template中的参数定义。一般从创建stack的入参environment中获取，但如果创建stack时同时指定了environment文件和parameters参数，那么后者的优先级高。

2、resource_registry. 表示映射关系，有以下几种形式：


资源名称和资源类的映射
这种映射关系一般不需要创建时指定，系统初始化时会预定义很多资源的映射关系(可以参考heat/engine/resources目录)，比如虚拟机这个对象，'OS::Nova::Server'就对应于Server类。当然，你也可以根据自己的虚拟化系统中的对象模型，自定义你自己的映射关系。比如Rackspace就在contrib/rackspace/heat/engine/plugins定义了自己的映射关系。

旧名称和新名称的映射
一个很简单的例子就是，neutron以前叫quantum，那么在新的系统中，就需要使用包含neutron的名称，这样的话对于已经在使用中的template，就需要将所有包含OS::Quantum字段的类型都转换成OS::Neutron

重新定义资源类型，例如：
resource_registry: "AWS::EC2::Instance": file:///home/mine/my_instance_with_better_defaults.yaml

只想重新定义template中某一资源的类型，其他资源保持不变
还是举个例子：
resource_registry: resources: my_db_server: "OS::DBInstance": file:///home/mine/all_my_cool_templates/db.yaml
environment除了在参数指定外，也可以在系统中预定义，相关的配置项environment_dir，默认的位置是/etc/heat/environment.d


Stack
整个heat就是围绕stack在玩，管理stack的生命周期。下面逐个分析一下stack中的一些属性。
parameters
这个属性就是管理stack中的参数集。参数来源有三个：template文件中；environment中；命令行参数中。前者主要定义参数的schema，那么就要保证后两者中的参数是第一个的子集。目前heat支持的参数类型：String, Number, CommaDelimitedList, Json.

resources
维护了stack中所有的资源对象. 那么资源对象是如何初始化的？

template中每个资源对象定义时都有一个Type字段, 是资源的类型名称。还记得environment对象么？environment中的registry中保存了系统中所有类型的映射关系, 那么就很容易的根据资源的类型初始化资源对象了。template中对于资源的定义, 可能会有一些依赖。要么依赖于某个参数(比如ref, find-in-map, join等函数), 要么依赖于其他对象。对于前者, 很容易做静态解析, 即在对象创建前就能根据参数的传递确定, 但对于对象间的依赖, 只能是在创建期间动态解析。

dependencies
表示stack中的资源关联关系，heat在处理dependencies时使用了大量的内置函数，以至于这块代码看起来很费劲，可读性差。但原理其实很简单, 依据template中的资源定义, 可以知道每个资源依赖于谁, 又被谁依赖, 最终得到一个类似于树状的结构。对dependencies属性的迭代，默认会先找到叶子节点，也就是依赖关系的最底端（可能有多个），对该资源进行创建操作，该操作是同步的，也就是说第二个资源的创建会等到前一个资源创建成功后才开始创建。


Deploying applications
在Amazon中，通常使用Ubuntu的cloud-init工具进行应用的部署（OpenStack也支持），在定义虚拟机资源时传递Userdata作为开机启动脚本，内容以#!开头，可以回顾一下Resource Attributes: DependsOn章节的例子。

基于cloud-init，CloudFormation还提供了一些帮助工具（在虚拟机内运行）来加速应用的自动部署：cfn-init, cfn-signal, cfn-get-metadata, and cfn-hup.

为什么使用帮助工具？
如果没有这些工具，那么只能在UserData中写入大量的脚本进行软件的下载、安装、配置等，远没有配置来的灵活简单，并且无法做到应用的自动更新。

cfn-init
cfn-init会读取虚拟机资源中的Metadata属性（主要关注类型为AWS::CloudFormation::Init的数据），根据配置

安装软件包
写文件
配置服务启动
cfn-init的运行通常放在UserData脚本中，一个例子：

"UserData": { 
      "Fn::Base64" : { "Fn::Join" : ["", [
      "#!/bin/bash -v\n",
      "yum update -y aws-cfn-bootstrap\n",
      "# Install LAMP packages\n",
      "/opt/aws/bin/cfn-init -s ", { "Ref" : "AWS::StackName" }, " -r WebServer ",
      "    --region ", { "Ref" : "AWS::Region" }, " || error_exit 'Failed to run cfn-init'\n"
      ]]}}        
  }
复制代码

cfn-signal
还记得在Resource Attributes: DependsOn章节中的UserData例子么，CloudFormation提供了cfn-signal工具来方便的完成同样的功能。如果cfn-init失败或软件安装失败，都可以调用cfn-signal来通知失败，否则，通知成功：

"# All is well so signal success\n",
"/opt/aws/bin/cfn-signal -e 0 -r "LAMP Stack setup complete" '", { "Ref" : "WaitHandle" }, "'\n"
复制代码

cfn-get-metadata
一个用来获取metadata块的帮助脚本，不需要证书就能调用。cfn-init应该就是调用了cfn-get-metadata来获取数据。

cfn-hup
默认情况下，cfn-hup守护进程每隔10分钟运行一次，用来监听虚拟机资源中metadata的变化，启动用户自定义脚本，以便更新应用程序（修改配置，新增软件，更新软件版本等），通常配合UpdateStack使用。

Heat中的client
我们都知道heat是openstack中的组件，那么云平台组件理所应当是nova/cinder/neutron/ceilometer这些。但是，heat绝不仅仅只用于openstack平台，假如你是cloudstack，或者是eucalyptus，只要能搞定对象建模的映射，那你也能使用heat，相关配置项cloud_backend。
Heat与AutoScaling、CloudWatch
AWS中有AutoScaling和CloudWatch，所以Heat也不好意思不支持。

AutoScaling

Havana中的Heat没有对外实现AWS AutoScaling API，要在IceHouse实现（初步定在I-2实现），相关的BP和wiki：
目前仅仅实现了支持template中定义autoscaling group和alarm资源而已。机制图：



Heat与OVF
不知道为什么，在看Heat的时候，突然想到了OVF，也是模板，也是应用(vApp)的快速部署。有什么区别呢？

OVF模板是模板的一种压缩格式，用来虚拟平台之间交换虚拟设备，它极大地方便了虚拟机跨平台的操作，无论是VMware vShphere、XenServer还是Hyper-v，都可以通过OVF模板来相互转移平台。OVF 软件包将虚拟机或 vApp 的状况捕获到独立的软件包中。磁盘文件以压缩、稀疏格式存储。

Heat是一套流程，你能看到的实体就是一个template文件，该文件是可以跨平台使用的，定义资源更加的灵活，支持的资源类型比OVF要多得多，功能也比OVF强大很多，特别是资源之间的依赖关系，使用不同的云平台时，需要以不同的模板参数区别；而OVF是相对独立的东西，你能看到的东西是一个ovf包，可以跨平台使用。