深度解码超实用的OpenStack Heat

摘要：模板中的顶级，定义实例化后将返回的数据。通过如此的解析和协作，最终完成请求的处理。服务接受请求，读入模板信息，处理后利用请求发送给。首先，调用拿到对应的。

Heat 是由AWS的EC2 Cloud Formation 演化而来，是openstack中负责Orchestration的service， 用于openstack 中资源的编排，它通过将OpenStack中的资源（resource）以模版（template）的形式组织起来。例如我们可以将一组资源，比如虚拟机实例的启动、IP绑定、软件部署等写在一个template里面，heat 通过读取配置文件来完成模版规定的动作：创建虚拟机，associate floatingip，deploy application 等等。Heat 将从这个template中创建出来的一组资源称之为“资源栈”（stack）。当对这一组资源进行操作时，只需要对stack进行操作，所以heat很适合批量资源的创建和销毁，它将一系列繁琐的人工操作自动化了起来。

Orchestration 可以理解为自动化部署、配置（provisioning and deployment）。除了资源的部署之外，还有一方面是server上应用软件的安装配置。当需要部署多个节点的时候，节点之间的依赖关系，部署顺序和配置都可以交给heat来管理。

除此之外， heat 还可以和open stack的监控（telemetry）服务Ceilometer一起实现自动伸缩，所以我们可以在heat的模版中定义一个scaling group作为一个资源。

本文将对以上内容做一个简单的介绍。

什么是Heat？

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

当设置完成后，可通过按授权控制、可预测的方式修改和更新OpenStack资源。用户可以通过OpenStack管理控制台、Heat命令行工具或 API对模板及其相关的资源集进行设置和更新。

为什么需要heat

？更快更有效的管理OpenStack的资源

云平台系统在相对比较稳定的情况下，管理成本逐渐变成首要的解决问题。云上自动化能力是一个云平台的刚需，可以有效降低维护难度。

OpenStack原生提供命令行和Horizon 来供用户管理资源。然而命令行和在浏览器中的点击，费时费力，不利于用户使用Openstack 来进行大批量的管理以支撑IT 应用。如下图所示，openstack中有众多的资源，对应了很多繁琐的操作。

Heat 在这种情况下应运而生． 如下图所示，我们可以将一些零散的资源操作都定义在heat的模版中，通过一个创建stack的操作，就能创建出我们要的资源。Heat 采用模板方式来设计或者定义编排。为方便用户使用，Heat 还提供了大量的模板例子，使用户能够方便地得到想要的编排。

更小的研发成本

引入Heat，对于不了解OpenStack的研发者来说，可以更快的接入现有的业务系统。开发者更关心的是授权认证和对虚拟资源的增删改，而对于底层的状态并不用太多了解。

术语

1． stack

Stack概念来源于AWS，是OpenStack中用来管理一组资源的基本单位。一个stack往往对应一个应用程序。Stack管理的是resource，而resource是个抽象的概念，它可以是虚拟机，可以是网络等。

Stack就是在单个模板中定义的实例化资源的集合，是Heat管理应用程序的逻辑单元。

2． template

heat的template描述了所用的所有组件资源以及组件资源之间的关系。heat模版是heat的核心。

2．1 resource

资源是底层服务的抽象，CPU、memory、disk、网络等都可以看作是资源。一个stack可以拥有很多资源。资源和资源之间会存在依赖关系。Heat在创建栈的时候会自动解析依赖关系，按顺序创建资源。在heat的template中，resources用于模板中资源的声明，在HOT模板中，应该至少有一个资源的定义，否则在实例化模板时将不会做任何事情。

2．2 parameters

heat模板中的参数，定义在创建或更新stack时可以传递哪些参数来定制模板。

2．3 parameter＿groups

用于指定如何对输入参数进行分组，以及提供参数的顺序。

？2．4 outputs

heat模板中的顶级key，定义实例化后stack将返回的数据。

模版中包括七个部分：heat＿template＿version、description、parameter＿groups、parameters、resources、outputs、conditions。除了heat＿template＿version和resources，其它都是可选部分。

Heat架构

Heat 是openstack 中上层的一个服务，如下图所示：

它位于其它基础组件的上层，可以将其它组件的资源以模版的形式组织起来， 如下图：

Heat 由以下组件组成：

－ Heat－api：实现openstack天然支持的REST API。该组件通过把API请求经由AMQP传送给Heat engine 来处理API请求。

－ Heat－api－cfn：提供兼容AWSCloudFormation的API，同时也会把API请求通过AMQP转发给Heat engine。

－ Heat－engine： heat－engine是heat中的核心模块，处理主要的逻辑业务。此模块提供heat最主要的功能，执行模板内容，最终完成应用系统的创建和部署，并把执行结果返回给API调用者。当heat engine 拿到请求后，会把请求解析为各种类型的资源，每种资源都对应OpenStack 其它的服务客户端，然后通过发送REST 的请求给其它服务。通过如此的解析和协作，最终完成请求的处理。

－ heatclient：CLI通过与heat－api通信，来调用API实现相关功能。终端开发者可以直接使用编排REST API。

－ heat－cfntools：独立于heat组件的一个的工具，需要多带带下载。这个工具用来完成虚拟机实例内部的操作配置任务。在创建虚拟机镜像时，需要在镜像中安装heat－cfntools工具。

Heat 中各个组件调用逻辑如下图所示：

Heat client 接受输入命令，参数和模板，处理信息后转为REST API，请求发送到heat－api服务。Heat API服务接受请求，读入模板信息，处理后利用rpc请求发送给heat－engine。heat－engine解析template数据，调用各种资源插件，然后各种资源插件通过openstack的clients发送指令给OpenStack服务。

Heat使用

5．1 对基础架构的编排

对于不同的资源，Heat 都提供了对应的资源类型。比如对于VM，Heat 提供了OS：：Nova：：Server。OS：：Nova：：Server 有一些参数，比如key、image、flavor 等，这些参数可以直接指定，可以由客户在创建Stack 时提供，也可以由上下文其它的参数获得。创建一个VM的部分模板如下：

resources：

server：

type： OS：：Nova：：Server

properties：

key＿name： ｛ get＿param： key＿name ｝

image： ｛ get＿param： image ｝

flavor： ｛ get＿param： flavor ｝

user＿data： ｜

＃！／bin／bash

echo “10．10．10．10 testvm”＞＞ ／etc／hosts

在上面创建VM 的例子中，我们选择从输入参数获得OS：：Nova：：Server 所需的值。其中利用user＿data 做了一些简单的配置。

5．2 对软件配置和部署的编排

Heat提供了多种资源类型来支持对于软件配置和部署的编排，如下所列：

OS：：Heat：：CloudConfig：VM 引导程序启动时的配置，由OS：：Nova：：Server 引用

OS：：Heat：：SoftwareConfig：描述软件配置

OS：：Heat：：SoftwareDeployment：执行软件部署

OS：：Heat：：SoftwareDeploymentGroup：对一组VM 执行软件部署

OS：：Heat：：SoftwareComponent：针对软件的不同生命周期部分，对应描述软件配置

OS：：Heat：：StructuredConfig：和OS：：Heat：：SoftwareConfig 类似，但是用Map 来表述配置

OS：：Heat：：StructuredDeployment：执行OS：：Heat：：StructuredConfig 对应的配置

OS：：Heat：：StructuredDeploymentsGroup：对一组VM 执行OS：：Heat：：StructuredConfig 对应的配置

其中最常用的是OS：：Heat：：SoftwareConfig 和OS：：Heat：：SoftwareDeployment。

OS：：Heat：：SoftwareConfig

下面是OS：：Heat：：SoftwareConfig 的用法，它指定了配置细节。

resources：

install＿db＿sofwareconfig

type： OS：：Heat：：SoftwareConfig

properties：

group： script

outputs：

－ name： result

config： ｜

＃！／bin／bash －v

yum －y install mariadb mariadb－server httpd wordpress

touch ／var／log／mariadb／mariadb．log

chown mysql．mysql ／var／log／mariadb／mariadb．log

systemctl start mariadb．service

OS：：Heat：：SoftwareDeployment

下面是OS：：Heat：：SoftwareDeployment 的用法，它指定了在哪台服务器上做哪项配置。另外SofwareDeployment 也指定了以何种信号传输类型来和Heat 进行通信。

sw＿deployment：

type： OS：：Heat：：SoftwareDeployment

properties：

config： ｛ get＿resource： install＿db＿sofwareconfig ｝

server： ｛ get＿resource： server ｝

signal＿transport： HEAT＿SIGNAL

OS：：Heat：：SoftwareConfig 和OS：：Heat：：SoftwareDeployment 执行流程

OS：：Heat：：SoftwareConfig和OS：：Heat：：SoftwareDeployment协同工作，需要一系列Heat工具的自持。这些工具都是OpenStack的子项目。

首先，os－collect－config调用Heat API拿到对应VM的metadata。当metadata更新完毕后os－refresh－config开始工作了，它主要是运行下面目录所包含的脚本：

／opt／stack／os－config－refresh／pre－configure．d

／opt／stack／os－config－refresh／configure．d

／opt／stack／os－config－refresh／post－configure．d

／opt／stack／os－config－refresh／migration．d

／opt／stack／os－config－refresh／error．d

每个文件夹都应对了软件不同的阶段，比如预先配置阶段、配置阶段、后配置阶段和迁移阶段。如果任一阶段的脚本执行出现问题，它会运行error．d目录里的错误处理脚本。os－refresh－config 在配置阶段会调用一定预先定义的工具，比如heat－config，这样就触发了heat－config的应用，调用完heat－config后，又会调用os－apply－config。存在在heat－config或者os－apply－config里的都是一些脚本，也叫钩子。Heat对于各种不同的工具提供了不同的钩子脚本。用户也可以自己定义这样的脚本。

等一切调用完成无误后，heat－config－notify 会被调用，它用来发信号给Heat，告诉这个软件部署的工作已经完成。当Heat 收到heat－config－notify 发来的信号后，它会把OS：：Heat：：SoftwareConfig 对应资源的状态改为Complete。如果有任何错误发生，就会改为CREATE＿FAILED 状态。

OS：：Heat：：SoftwareConfig 和OS：：Heat：：SoftwareDeployment 执行流程如下：

Heat  AutoScalling

基础架构的自动伸缩是一个很高级的功能。Heat提供自动伸缩组OS：：Heat：：AutoScalingGroup 和伸缩策略OS：：Heat：：ScalingPolicy，结合基于Ceilometer 的OS：：Ceilometer：：Alarm 实现了可以根据各种条件，比如负载，进行资源自动伸缩的功能。

Heat 自动伸缩的流程图如下：

定义自动伸缩组如下：

auto＿scale＿group：

type： OS：：Heat：：AutoScalingGroup

properties：

min＿size： 1

max＿size： 4

定义伸缩规则如下：

server＿scaleup＿policy：

type： OS：：Heat：：ScalingPolicy

properties：

adjustment＿type： change＿in＿capacity

auto＿scaling＿group＿id： ｛get＿resource： auto＿scale＿group｝

cooldown： 60

scaling＿adjustment： 1

定义警报如下：

cpu＿alarm＿high：

type： OS：：Ceilometer：：Alarm

properties：

description： Scale－up if the average CPU ＞ 50％ for 1 minute

meter＿name： cpu＿util

statistic： avg

period： 60

evaluation＿periods： 1

threshold： 50

alarm＿actions：

－ ｛get＿attr： ［server＿scaleup＿policy，alarm＿url］｝

matching＿metadata： ｛＇metadata．user＿metadata．stack＇： ｛get＿param： ＂OS：：stack＿id＂｝｝

comparison＿operator： gt

互动区

＊ 你对以上内容有什么看法？你最关注云计算哪个趋势？如果你还有想了解的技术话题，欢迎留言分享。

启迪云－高级网络工程师 邸小丽