OpenStack入门以及一些资料之（四、Heat）

注：本文内容均来自网络，我只是在此做了一些摘抄和整理的工作，来源均有注明。

1、AWS CloudFormation

“AWS CloudFormation 向开发人员和系统管理员提供了一种简便地创建和管理一批相关的 AWS 资源的方法，并通过有序且可预测的方式对其进行资源配置和更新。您可以使用AWS CloudFormation 的示例模板或自己创建模板来介绍 AWS 资源以及应用程序运行时所需的任何相关依赖项或运行时参数。

Heat的设计与实现基本与CloudFormation一致。

What is an AWS CloudFormation Template?

• A template is a declaration of the AWS resources that make up a stack.模板是构成一个栈的AWS的资源的声明。，使用JSON格式存储。
• 一个AWS CloudFormation模板由一个大括号开始，结束于同级的另一个大括号
• 在这些大括号中，你可以声明6个顶级的JSON对象：AWSTemplateFormatVersion，Description，Parameters，Mappings，Resources，和 Outputs。其中Resources对象是必填的，必须包括至少一项资源。(模板的格式版本、其说明和参数，以及创建堆栈所需的映射、条件、资源和输出。格式版本、说明、参数、映像和输出都是可选项。)
• • 格式版本(AWSTemplateFormatVersioin)：模板格式版本指定了编写模板时依据的 AWS CloudFormation 模板版本。
  • 可选说明(Description)：通过可选说明属性，您可以将免费有效的 JSON 文本字符串与模板相关联。您可以记录模板的说明。该说明字符数最多为 4000 个字符。
  • 可选参数(Parameters)：可选参数将在参数部分列出。通过参数，您可以在运行时将数值传输至您的模板，同时也可以在模板的资源和输出部分解除参考。 参数中对参数进行了更全面的说明。另外，有关 Parameters 部分格式的技术详细信息，请参阅参数声明。
  • 可选映像(Mappings)：通过可选映像部分，您可以声明条件值。可在 Resources 和 Outputs 部分使用内部函数 Fn::FindInMap 取消映射引用。 映像中对映射进行了更全面的说明。另外，有关 Mappings 部分格式的技术详细信息，请参阅映射声明。
  • 可选条件(Conditions):在可选的“条件”部分，您可以定义用于控制是否创建某些资源或者是否在堆栈创建或更新过程中为某些资源属性分配值的条件。例如，您可以根据堆栈是用于生产环境还是用于测试环境来按照条件创建资源。 有关定义条件的更多信息，请参阅条件。
  • 资源(Resources):资源部分将列出堆栈的成员资源。每项资源将予以分别列明，并指定创建此特定资源所必需的资源属性。可在资源和输出部分取消资源参考。它们的属性将基于文本、资源、参数、和内部函数。 资源中对资源进行了更全面的说明。有关 Resources 部分格式的技术详细信息，请参阅资源声明。
  • 资源属性(Properties):如果资源无需声明任何属性，那么您可以忽略此资源的属性部分。资源属性将基于文本、资源、参数、和内部函数。 资源属性中对资源属性进行了更全面的说明。另外，有关 Properties 部分格式的技术详细信息，请参阅属性声明。
  • 可选输出(Outputs): 在 Outputs 部分，您可以选择对响应 aws cloudformation describe-stacks 命令而返回的自定义值进行定义。这些输出值将包括基于文本、资源、参数、虚拟参数和内部函数的信息。 输出中对输出进行了更全面的说明。另外，有关 Outputs 部分格式的技术详细信息，请参阅输出声明。
  • 参考(Ref):  内部函数 Ref 返回指定的参数或资源的值。 使用 Ref 函数，您可以指定任何资源的逻辑名称，以取消对其他资源、输出、参数或内部函数的值的引用。
  • 固有功能（内建函数）:

    名称	目的
    Fn::Base64	实参 base64 编码。
    Fn::FindInMap	从指定映像返回密钥数值。
    Fn::GetAtt	返回指定资源的属性值。
    Fn::GetAZs	获取可以创建 AWS CloudFormation 堆栈的可用区。
    Fn::Join	第二实参元素的串联，由第一实参进行分离。
    Ref	返回基于逻辑名称或参数的资源或数值。

    
    

---

2、Heat介绍

Heat包括以下组件：

Heat Client： CLI工具， Heat commands官方文档

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工具

---

3、模板

• Heat templates支持多种模板内容展示格式，如 HOT syntax, YAML Syntax, JSON Syntax；每种格式表达的内容都一样。模板配置选项官方文档
• 支持多种资源格式，如OpenStack自身的资源格式，Amazon的资源格式和RackSpace的资源格式。

a) cloudformation模板：

• CloudFormation中的'Conditions'字段目前还不支持。
• Resource Attributes: DeletionPolicy:  定义资源时，可以定义DeletionPolicy属性，表示在删除stack时，资源的删除策略，默认是Delete。在CloudFormation中，可以指定Retain，表示不删除该资源，对于有快照功能的资源（比如AWS::EC2::Volume），也可以指定Snapshot，表示在删除前先做快照。
• Resource Attributes: DependsOn:  显式的定义资源的依赖关系。在资源定义时已经有一些函数（比如Ref或Fn::GetAtt）可以判定依赖关系，但除了这些，可能还需要手工指定依赖。一个典型的用法就是配合AWS::CloudFormation::WaitCondition(关于WaitCondition一个使用示例可以参见这里)，它的作用是暂停stack的创建，等待某个信号，然后再恢复执行。比如在虚拟机创建完后，需要等待应用的下载和配置结束，然后才能真正认为该虚拟机创建完毕。
• Resource Attributes: UpdatePolicy(AWS):  在CloudFormation中，仅AWS::AutoScaling::AutoScalingGroup支持UpdatePolicy属性，表示group内的虚拟机数目发生变化的约束，目前Heat还不支持。
• Resource Attributes: Metadata:  为资源设置一些键值对。

b) HOT(Heat Orchestration Template):

c) Environment:

environment在heat中代表了创建stack的运行时环境。里面包含了两种资源：

1、 parameters. 一个参数集，会覆盖template中的参数定义。一般从创建stack的入参environment中获取，但如果创建stack时同时指定了environment文件和parameters参数，那么后者的优先级高。

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

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

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

3. 重新定义资源类型，例如：

   resource_registry: "AWS::EC2::Instance": file:///home/mine/my_instance_with_better_defaults.yaml

4. 只想重新定义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

---

4、简单流程

     1）预处理，需要在虚拟机镜像中安装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的具体选项

     2）创建应用

• 调用heat-api来创建，例如heat stack-create myApplication
• heat-engine生成cloud-init将会使用到的multipart data
• heat-engine调用nova-api，创建虚拟机实例，将cloud-init用到的数据随nova-api的调用传递
• nova选择一个计算节点创建虚拟机实例，使用cloud-init的数据
• 当虚拟机实例启动时，将会执行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目录，这些脚本可以是任何一种脚本（如bash，python，etc.），且必须调用cfn-init
• • cfn-init loads /var/lib/cloud/data/cfn-init-data (a copy of the Metadata->AWS::CloudFormation::Init->Config attribute from the AWS template) and can install packages, setup users & groups, create files, etc.
• 注意heat-cfntools leverage（会影响到？）boto，boto的配置文件放在虚拟机的/var/lib/heat-cfntools/cfn-boto-cfg上。

---

5、 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属性的迭代，默认会先找到叶子节点，也就是依赖关系的最底端（可能有多个），对该资源进行创建操作，该操作是同步的，也就是说第二个资源的创建会等到前一个资源创建成功后才开始创建。

---

6、 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使用。

---

7、Heat中的Client:

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

---

8、Heat与AutoScaling、CloudWatch

AWS中有AutoScaling和CloudWatch，所以Heat也不好意思不支持。

AutoScaling

Havana中的Heat没有对外实现AWS AutoScaling API，要在IceHouse实现（初步定在I-2实现），相关的BP和wiki：
https://blueprints.launchpad.net/heat/+spec/autoscaling-api
https://blueprints.launchpad.net/heat/+spec/autoscaling-api-resources
https://wiki.openstack.org/wiki/Heat/AutoScaling
目前仅仅实现了支持template中定义autoscaling group和alarm资源而已。机制图：

AWS的AutoScaling有以下特性：

• 一般与CloudWatch和Load Balancer配合使用
• 伸缩内的虚拟机都是同质虚拟机
• 伸缩的触发：手动调整group大小；手动执行策略；根据监控指标自动执行策略（与alarm关联）；定时触发
• 分为水平伸缩（个数）和垂直伸缩（配置）
• 根据伸缩组内的虚拟机的状态（可以集成自己的健康检查系统）进行自动的删除创建
• 伸缩组可以跨AZ（实现业务的HA），并且实现AZ间的均衡，但不能跨region
• 策略可以是按数目扩缩、指定扩缩后的总数、按照比例扩缩
• 貌似目前AWS尚不支持启动/停止、休眠/唤醒的方式扩缩

Cooldown Time(AWS)

AutoScaling中的默认冷却时间是300s，表示连续两次alarm触发伸缩动作的最小执行间隔，与某个scaling group相关联。而冷却时间与scaling policy相关联，优先级高于默认冷却时间，表示一个策略连续两次被触发的最小执行间隔。

增加一个虚拟机：

增加多个虚拟机：

当然，可以通过改变group的capacity或手动执行策略，绕过cooldown的时间限制。

CloudWatch

AWS CloudWatch（API文档）中的alarm是一个监控特定指标的对象。alarm的三种状态：
1、OK。表示指标正常
2、ALARM。表示指标异常
3、INSUFFICIENT_DATA。表示数据不可用。
如果连续几个周期都处于ALARM状态，那么就会触发一个或多个policy，进而触发scaling group的扩缩。

AWS中alarm, group, policy的关系：

Havana中的Heat中并没有完全实现CloudWatch API，仅实现了describe_alarms，list_metrics，put_metric_data，set_alarm_state四个API。在早期的Heat的实现中，在autoscaling group内的每个虚拟机里都会运行agent获取数据，保存到Heat的数据库里，同样，数据库也会保存alarm数据。随着时间的推移，借助Ceilometer的功能，不再需要虚拟机中的agent，而由Ceilometer进行数据的获取和策略的触发，之前的流程估计到Icehouse会被移除。

---

9、Heat与OVF：

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

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

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

---

10、Troubleshooting

• /var/log/cloud-init.log => cloud-init logs
• /var/log/part-handler.log => logs of the Heat-specific script managing data with content-type=text/x-cfninitdata
• /var/log/heat-provision.log => logs of the user's script including cfn-init logs

同时，还可以向metadata server查询heat生成的用户数据。

---

---

参考：

1. cloudformation官方文档：http://docs.aws.amazon.com/zh_cn/AWSCloudFormation/latest/UserGuide/CHAP_Intro.html
2. OpenStack Heat Project介绍： http://www.choudan.net/2013/11/25/OpenStack-Heat-Project%E4%BB%8B%E7%BB%8D.html
3. OpenStack中的Heat进阶： http://blog.csdn.net/lynn_kong/article/details/17195047
4. OpenStack Template Guide： http://docs.openstack.org/developer/heat/template_guide/index.html
5. Heat/ApplicationDeployment： https://wiki.openstack.org/wiki/Heat/ApplicationDeployment

 

OpenStack中的Heat进阶：

http://blog.csdn.net/lynn_kong/article/details/17195047