摘要：模板中的頂級，定義實例化后將返回的數(shù)據(jù)。通過如此的解析和協(xié)作，最終完成請求的處理。服務(wù)接受請求，讀入模板信息，處理后利用請求發(fā)送給。首先，調(diào)用拿到對應(yīng)的。

Heat 是由AWS的EC2 Cloud Formation 演化而來，是openstack中負(fù)責(zé)Orchestration的service， 用于openstack 中資源的編排，它通過將OpenStack中的資源（resource）以模版（template）的形式組織起來。例如我們可以將一組資源，比如虛擬機(jī)實例的啟動、IP綁定、軟件部署等寫在一個template里面，heat 通過讀取配置文件來完成模版規(guī)定的動作：創(chuàng)建虛擬機(jī)，associate floatingip，deploy application 等等。Heat 將從這個template中創(chuàng)建出來的一組資源稱之為“資源?！保╯tack）。當(dāng)對這一組資源進(jìn)行操作時，只需要對stack進(jìn)行操作，所以heat很適合批量資源的創(chuàng)建和銷毀，它將一系列繁瑣的人工操作自動化了起來。

Orchestration 可以理解為自動化部署、配置（provisioning and deployment）。除了資源的部署之外，還有一方面是server上應(yīng)用軟件的安裝配置。當(dāng)需要部署多個節(jié)點的時候，節(jié)點之間的依賴關(guān)系，部署順序和配置都可以交給heat來管理。

除此之外， heat 還可以和open stack的監(jiān)控（telemetry）服務(wù)Ceilometer一起實現(xiàn)自動伸縮，所以我們可以在heat的模版中定義一個scaling group作為一個資源。

本文將對以上內(nèi)容做一個簡單的介紹。

什么是Heat？

Heat向開發(fā)人員和系統(tǒng)管理員提供了一種簡便地創(chuàng)建和管理一批相關(guān)的OpenStack資源的方法，并通過有序且可預(yù)測的方式對其進(jìn)行資源配置和更新。用戶可以使用Heat的示例模板或自己創(chuàng)建模板來描述OpenStack資源以及應(yīng)用程序運行時所需的任何相關(guān)依賴項或運行時參數(shù)。

當(dāng)設(shè)置完成后，可通過按授權(quán)控制、可預(yù)測的方式修改和更新OpenStack資源。用戶可以通過OpenStack管理控制臺、Heat命令行工具或 API對模板及其相關(guān)的資源集進(jìn)行設(shè)置和更新。

為什么需要heat

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

云平臺系統(tǒng)在相對比較穩(wěn)定的情況下，管理成本逐漸變成首要的解決問題。云上自動化能力是一個云平臺的剛需，可以有效降低維護(hù)難度。

OpenStack原生提供命令行和Horizon 來供用戶管理資源。然而命令行和在瀏覽器中的點擊，費時費力，不利于用戶使用Openstack 來進(jìn)行大批量的管理以支撐IT 應(yīng)用。如下圖所示，openstack中有眾多的資源，對應(yīng)了很多繁瑣的操作。

Heat 在這種情況下應(yīng)運而生． 如下圖所示，我們可以將一些零散的資源操作都定義在heat的模版中，通過一個創(chuàng)建stack的操作，就能創(chuàng)建出我們要的資源。Heat 采用模板方式來設(shè)計或者定義編排。為方便用戶使用，Heat 還提供了大量的模板例子，使用戶能夠方便地得到想要的編排。

更小的研發(fā)成本

引入Heat，對于不了解OpenStack的研發(fā)者來說，可以更快的接入現(xiàn)有的業(yè)務(wù)系統(tǒng)。開發(fā)者更關(guān)心的是授權(quán)認(rèn)證和對虛擬資源的增刪改，而對于底層的狀態(tài)并不用太多了解。

術(shù)語

1． stack

Stack概念來源于AWS，是OpenStack中用來管理一組資源的基本單位。一個stack往往對應(yīng)一個應(yīng)用程序。Stack管理的是resource，而resource是個抽象的概念，它可以是虛擬機(jī)，可以是網(wǎng)絡(luò)等。

Stack就是在單個模板中定義的實例化資源的集合，是Heat管理應(yīng)用程序的邏輯單元。

2． template

heat的template描述了所用的所有組件資源以及組件資源之間的關(guān)系。heat模版是heat的核心。

2．1 resource

資源是底層服務(wù)的抽象，CPU、memory、disk、網(wǎng)絡(luò)等都可以看作是資源。一個stack可以擁有很多資源。資源和資源之間會存在依賴關(guān)系。Heat在創(chuàng)建棧的時候會自動解析依賴關(guān)系，按順序創(chuàng)建資源。在heat的template中，resources用于模板中資源的聲明，在HOT模板中，應(yīng)該至少有一個資源的定義，否則在實例化模板時將不會做任何事情。

2．2 parameters

heat模板中的參數(shù)，定義在創(chuàng)建或更新stack時可以傳遞哪些參數(shù)來定制模板。

2．3 parameter＿groups

用于指定如何對輸入?yún)?shù)進(jìn)行分組，以及提供參數(shù)的順序。

？2．4 outputs

heat模板中的頂級key，定義實例化后stack將返回的數(shù)據(jù)。

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

Heat架構(gòu)

Heat 是openstack 中上層的一個服務(wù)，如下圖所示：

它位于其它基礎(chǔ)組件的上層，可以將其它組件的資源以模版的形式組織起來， 如下圖：

Heat 由以下組件組成：

－ Heat－api：實現(xiàn)openstack天然支持的REST API。該組件通過把API請求經(jīng)由AMQP傳送給Heat engine 來處理API請求。

－ Heat－api－cfn：提供兼容AWSCloudFormation的API，同時也會把API請求通過AMQP轉(zhuǎn)發(fā)給Heat engine。

－ Heat－engine： heat－engine是heat中的核心模塊，處理主要的邏輯業(yè)務(wù)。此模塊提供heat最主要的功能，執(zhí)行模板內(nèi)容，最終完成應(yīng)用系統(tǒng)的創(chuàng)建和部署，并把執(zhí)行結(jié)果返回給API調(diào)用者。當(dāng)heat engine 拿到請求后，會把請求解析為各種類型的資源，每種資源都對應(yīng)OpenStack 其它的服務(wù)客戶端，然后通過發(fā)送REST 的請求給其它服務(wù)。通過如此的解析和協(xié)作，最終完成請求的處理。

－ heatclient：CLI通過與heat－api通信，來調(diào)用API實現(xiàn)相關(guān)功能。終端開發(fā)者可以直接使用編排REST API。

－ heat－cfntools：獨立于heat組件的一個的工具，需要多帶帶下載。這個工具用來完成虛擬機(jī)實例內(nèi)部的操作配置任務(wù)。在創(chuàng)建虛擬機(jī)鏡像時，需要在鏡像中安裝heat－cfntools工具。

Heat 中各個組件調(diào)用邏輯如下圖所示：

Heat client 接受輸入命令，參數(shù)和模板，處理信息后轉(zhuǎn)為REST API，請求發(fā)送到heat－api服務(wù)。Heat API服務(wù)接受請求，讀入模板信息，處理后利用rpc請求發(fā)送給heat－engine。heat－engine解析template數(shù)據(jù)，調(diào)用各種資源插件，然后各種資源插件通過openstack的clients發(fā)送指令給OpenStack服務(wù)。

Heat使用

5．1 對基礎(chǔ)架構(gòu)的編排

對于不同的資源，Heat 都提供了對應(yīng)的資源類型。比如對于VM，Heat 提供了OS：：Nova：：Server。OS：：Nova：：Server 有一些參數(shù)，比如key、image、flavor 等，這些參數(shù)可以直接指定，可以由客戶在創(chuàng)建Stack 時提供，也可以由上下文其它的參數(shù)獲得。創(chuàng)建一個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

在上面創(chuàng)建VM 的例子中，我們選擇從輸入?yún)?shù)獲得OS：：Nova：：Server 所需的值。其中利用user＿data 做了一些簡單的配置。

5．2 對軟件配置和部署的編排

Heat提供了多種資源類型來支持對于軟件配置和部署的編排，如下所列：

OS：：Heat：：CloudConfig：VM 引導(dǎo)程序啟動時的配置，由OS：：Nova：：Server 引用

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

OS：：Heat：：SoftwareDeployment：執(zhí)行軟件部署

OS：：Heat：：SoftwareDeploymentGroup：對一組VM 執(zhí)行軟件部署

OS：：Heat：：SoftwareComponent：針對軟件的不同生命周期部分，對應(yīng)描述軟件配置

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

OS：：Heat：：StructuredDeployment：執(zhí)行OS：：Heat：：StructuredConfig 對應(yīng)的配置

OS：：Heat：：StructuredDeploymentsGroup：對一組VM 執(zhí)行OS：：Heat：：StructuredConfig 對應(yīng)的配置

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

OS：：Heat：：SoftwareConfig

下面是OS：：Heat：：SoftwareConfig 的用法，它指定了配置細(xì)節(jié)。

resources：

install＿db＿sofwareconfig

type： OS：：Heat：：SoftwareConfig

properties：

group： script

outputs：

－ name： result

config： ｜

＃?。痓in／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 的用法，它指定了在哪臺服務(wù)器上做哪項配置。另外SofwareDeployment 也指定了以何種信號傳輸類型來和Heat 進(jìn)行通信。

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 執(zhí)行流程

OS：：Heat：：SoftwareConfig和OS：：Heat：：SoftwareDeployment協(xié)同工作，需要一系列Heat工具的自持。這些工具都是OpenStack的子項目。

首先，os－collect－config調(diào)用Heat API拿到對應(yīng)VM的metadata。當(dāng)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

每個文件夾都應(yīng)對了軟件不同的階段，比如預(yù)先配置階段、配置階段、后配置階段和遷移階段。如果任一階段的腳本執(zhí)行出現(xiàn)問題，它會運行error．d目錄里的錯誤處理腳本。os－refresh－config 在配置階段會調(diào)用一定預(yù)先定義的工具，比如heat－config，這樣就觸發(fā)了heat－config的應(yīng)用，調(diào)用完heat－config后，又會調(diào)用os－apply－config。存在在heat－config或者os－apply－config里的都是一些腳本，也叫鉤子。Heat對于各種不同的工具提供了不同的鉤子腳本。用戶也可以自己定義這樣的腳本。

等一切調(diào)用完成無誤后，heat－config－notify 會被調(diào)用，它用來發(fā)信號給Heat，告訴這個軟件部署的工作已經(jīng)完成。當(dāng)Heat 收到heat－config－notify 發(fā)來的信號后，它會把OS：：Heat：：SoftwareConfig 對應(yīng)資源的狀態(tài)改為Complete。如果有任何錯誤發(fā)生，就會改為CREATE＿FAILED 狀態(tài)。

OS：：Heat：：SoftwareConfig 和OS：：Heat：：SoftwareDeployment 執(zhí)行流程如下：

Heat ?AutoScalling

基礎(chǔ)架構(gòu)的自動伸縮是一個很高級的功能。Heat提供自動伸縮組OS：：Heat：：AutoScalingGroup 和伸縮策略O(shè)S：：Heat：：ScalingPolicy，結(jié)合基于Ceilometer 的OS：：Ceilometer：：Alarm 實現(xiàn)了可以根據(jù)各種條件，比如負(fù)載，進(jìn)行資源自動伸縮的功能。

Heat 自動伸縮的流程圖如下：

定義自動伸縮組如下：

auto＿scale＿group：

type： OS：：Heat：：AutoScalingGroup

properties：

min＿size： 1

max＿size： 4

定義伸縮規(guī)則如下：

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＿h(yuǎn)igh：

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

互動區(qū)

＊ 你對以上內(nèi)容有什么看法？你最關(guān)注云計算哪個趨勢？如果你還有想了解的技術(shù)話題，歡迎留言分享。

啟迪云－高級網(wǎng)絡(luò)工程師 邸小麗