以一个典型的业务弹性伸缩流程为例来讲解Heat的整体工作流程。
1.定义模板
heat_template_version: 2013-05-23description: Simple template to deploy a autoscaling demoparameters: image:type: stringdescription: Image used for serversdefault: cirros-0.3.1-x86_64-disk flavor:type: stringdescription: flavor used by the serversdefault: m1.tinyresources: web_server_scaleup_policy:type: OS::Heat::ScalingPolicyproperties:adjustment_type: change_in_capacityauto_scaling_group_id: {get_resource: web_server_group}cooldown: 60scaling_adjustment: 1 cpu_alarm_high:type: OS::Ceilometer::Alarmproperties: meter_name : "cpu_util" statistic : "avg"period : "60"evaluation_periods: "1"threshold : "90"repeat_actions: truealarm_actions : - {get_attr: [web_server_scaleup_policy, alarm_url]}comparison_operator : "ge" web_server_group:type: OS::Heat::AutoScalingGroupproperties: min_size: 1 max_size: 3 desired_capacity: 1 resource: type: OS::Nova::Serverproperties: flavor: {get_param: flavor} image: {get_param: image} networks: [{"network": "b83cbae8-0db0-433c-a47a-374d0077cec7"}]
模板中定义了3个资源：
1）web_server_scaleup_policy用于定义超过阈值时的伸缩策略。
2）cpu_alarm_high用于定义超过阈值时的告警动作。
3）web_server_group用于定义一个虚拟机的弹性伸缩组资源，其中cpu_alarm_high中依赖了web_server_scaleup_policy的告警URL，而web_server_scaleup_policy依赖了web_server_group资源组。
此外，web_server_group使用了OS：：Heat：：AutoScalingGroup资源类型定义了一个弹性伸缩组，参数中的flavor指定云主机类型，image指定云主机使用的镜像，networks指定了云主机的网络归属。
2.执行模板
将以上模板保存到autoscaling.hts文件中，再调用Heat-tools工具执行模板部署操作。
#heat stack-create –f autoscaling.hts autoscaling
3.模板执行结果
可以通过Heat-tools查看新创建的heat stack-list的状态，如果stack的状态为CREATE_COMPLETE，则说明栈已经创建成功；如果为CREATE_FAILED，则表示栈创建失败。
4.模板执行分析
现在来分析整个模板的执行和资源自动化过程：
当模板执行成功后，会自动完成一台新的云主机的创建，登录这台云主机，执行cat/dev/urandom|md5sum&模拟CPU满负荷的情况，因为Ceilometer告警资源cpu_alarm_high定义了对属于弹性伸缩组资源web_server_group中的云主机的资源采集规则，当CPU升高且满足了cpu_alarm_high资源所定义的告警周期period：“60s”内超过告警阈值threshold：“90%”的条件时，告警资源会通过signal方式触发执行弹性策略资源web_server_scaleup_policy中的回调接口。又因为伸缩策略中实际上绑定了web_server_group弹性伸缩组中的updatePolicy触发器，从而触发了web_server_group弹性伸缩组自身的伸缩操作，生成了一台新的云主机。模板执行流程如图6-3所示。
图6-3 模板执行流程