摘要：模板中的頂級，定義實例化后將返回的數據。通過如此的解析和協作，最終完成請求的處理。服務接受請求，讀入模板信息，處理后利用請求發送給。首先，調用拿到對應的。

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

互動區

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

啟迪云－高級網絡工程師 邸小麗