原文：http://blog.scottlowe.org/2014/05/01/an-introduction-to-openstack-heat/
本文將簡要地介紹OpenStack Heat. Heat項目提供協作服務，允許我們可以自動地創建多個計算實例，邏輯網絡，以及對其他的雲服務的操作。請注意，這只是一個簡要介紹—我不是Heat的專家，我只是想要分享一些基本信息以便讀者可以更快的使用Heat.
為了在以下的具體的例子中不至於產生困擾，我們先從術語開始。
- Stack（棧）： 在Heat領域，Stack是多個由Heat創建的對象或者資源的集合。它包含實例（虛擬機），網絡，子網，路由，端口，路由端口，安全組（Security Group）,安全組規則，自動伸縮等。
- Template（模板）: Heat使用template的概念來定義一個Stack. 如果你想要一個由私有網連接的2個實例，那么你的template需要包括2個實例，一個網絡，一個子網和2個網絡端口的定義。既然template是Heat工作的中心點，本文在后面將會展示一些例子。
- Parameters(參數)：Heat template有三個部分，而其中的一個就是要定義template的參數。參數包含一些基本信息，比如具體的鏡像ID，或者特定網絡ID。他們將由用戶輸入給template. 這種參數機制允許用戶創建一個一般的template，它可能潛在使用不同的具體資源。
- Resources(資源)：Resource就是由Heat創建或者修改的具體的資源。它是Heat template的第二個重要部分。
- Output(輸出)：Heat template的第三個和最后一個重要部分就是Output(輸出)。它是通過OpenStack Dashboard或者Heat stack-list/stack-show命令來顯示給用戶。
- HOT: Heat Orchestration Template的縮寫，是Heat template使用的兩種格式的一種。HOT並不與AWS CloudFormation template格式兼容，只能被OpenStack使用。HOT格式的template，通常但不是必須使用YAML。
- CFN：AWS CloudFormation的縮寫，Heat支持的第二種格式。CFN格式的template通常使用JSON。
以后這些介紹應該足以支持我們下面的介紹。（OpenStack Heat文檔有一個優秀的術語介紹）
從架構來看，Heat有一些重要的組件：
Heat-api組件實現OpenStack天然支持的REST API。該組件通過把API請求經由AMQP傳送給Heat engine來處理API請求。
Heat-api-cfn組件提供兼容AWS CloudFormation的API，同時也會把API請求通過AMQP轉發給heat engine。
Heat-engine組件提供Heat最主要的協作功能。
所有這些組件通常安裝在OpenStack的控制節點上，該節點同時也是Nova, Glance，Neutron等其他服務的API服務器。然而，據我所知，並沒有客觀要求必要安裝這些服務在同一個節點上。與其他多數的OpenStack服務類似，Heat也使用后台數據庫來維護狀態信息。
既然現在你已經對Heat的架構也有一個大概了解，讓我們來看一個我在自己的OpenStack環境里創建並測試過的一個Heat template的例子（在Ubuntu 12.04上運行OpenStack Havana版本，使用KVM和VMware NSX）。下面是完整的template。
| { "AWSTemplateFormatVersion" : "2010-09-09", "Description" : "Sample Heat template that spins up multiple instances and a private network (JSON)", "Resources" : { "heat_network_01" : { "Type" : "OS::Neutron::Net", "Properties" : { "name" : "heat-network-01" } },
"heat_subnet_01" : { "Type" : "OS::Neutron::Subnet", "Properties" : { "name" : "heat-subnet-01", "cidr" : "10.10.10.0/24", "dns_nameservers" : ["172.16.1.11", "172.16.1.6"], "enable_dhcp" : "True", "gateway_ip" : "10.10.10.254", "network_id" : { "Ref" : "heat_network_01" } } },
"heat_router_01" : { "Type" : "OS::Neutron::Router", "Properties" : { "admin_state_up" : "True", "name" : "heat-router-01" } },
"heat_router_01_gw" : { "Type" : "OS::Neutron::RouterGateway", "Properties" : { "network_id" : "604146b3-2e0c-4399-826e-a18cbc18362b", "router_id" : { "Ref" : "heat_router_01" } } },
"heat_router_int0" : { "Type" : "OS::Neutron::RouterInterface", "Properties" : { "router_id" : { "Ref" : "heat_router_01" }, "subnet_id" : { "Ref" : "heat_subnet_01" } } },
"instance0_port0" : { "Type" : "OS::Neutron::Port", "Properties" : { "admin_state_up" : "True", "network_id" : { "Ref" : "heat_network_01" }, "security_groups" : ["b0ab35c3-63f0-48d2-8a6b-08364a026b9c"] } },
"instance1_port0" : { "Type" : "OS::Neutron::Port", "Properties" : { "admin_state_up" : "True", "network_id" : { "Ref" : "heat_network_01" }, "security_groups" : ["b0ab35c3-63f0-48d2-8a6b-08364a026b9c"] } },
"instance0" : { "Type" : "OS::Nova::Server", "Properties" : { "name" : "heat-instance-01", "image" : "73669ac0-8677-498d-9d97-76af287bcf32", "flavor": "m1.xsmall", "networks" : [{ "port" : { "Ref" : "instance0_port0" } }] } },
"instance1" : { "Type" : "OS::Nova::Server", "Properties" : { "name" : "heat-instance-02", "image" : "73669ac0-8677-498d-9d97-76af287bcf32", "flavor": "m1.xsmall", "networks" : [{ "port" : { "Ref" : "instance1_port0" } }] } } } } |
view rawheat-json-example.json hosted with ❤ by GitHub
下面我們一起快速地過一下這個template。
- 首先，注意我指定該template的版本為”AWSTemplateFormatVersion”。這邊有個讓我一開始感到困惑的事情是template格式（CFN和HOT）以及資源類型的之間的關系。事實證明，他們相互獨立。就像我在這里所做，你可以在一個CFN template里使用HOT資源類型（例如OS::Neutron::Net）。顯然，如果你一旦使用HOT資源類型，你的template將不會跟AWS兼容。如我前面所指出的，CFN template通常使用JSON格式。Heat的確在CFN里支持YAML，但是你需要犧牲AWS兼容性。
- 你將會注意到我的template跳過參數的使用而直接到Resource（資源）部分。這么做沒有任何問題，但是這也意味着直接把一些可變的參數的值（如邏輯路由器向上級聯的共享公共網和安全組（Security Group））直接寫到template里。
- Template格式限制某些句法。例如，你注意到例子中使用了”Resources”，“Type”，“Properties”。在其他的一些格式中，這些關鍵字通常指定為小寫字母。
- 該template定義的第一個資源是邏輯網絡，類型為OS::Neutron::Net。
- 接下來的資源是子網（類型為OS::Neutron::Subnet）。它通過使用內建函數Ref與之前所定義的邏輯網絡進行關聯。內建函數是template格式的另一個關鍵。所以當你想引用一個CFN template里的其他對象時，你就可以像我這樣使用內建函數Ref。它將改子網的network ID同之前所定義的邏輯網絡進行關聯。你應該也已經注意到子網資源(subnet)有很多個與之關聯的屬性：CIDR，DNS Name Server，DHCP，網關IP地址。
- 第三個資源是邏輯路由器。
- 緊隨邏輯路由器定義之后，該template通過一個OS::Neutron::RouterGateway類型的資源把邏輯路由器連接到已經創建好的邏輯網絡上。這里列出的UUID是已經創建好的邏輯網絡的UUID。請注意又使用了Ref函數把改資源連接到邏輯路由器。
- 接下來該template在邏輯路由器上創建2個interface，並使用2次Ref把路由器interface連接到邏輯路由器和之前創建的子網。這意味着我們正在給制定子網上的路由器添加interface(而且該interface將使用Subnet里的gateway_ip所定義的IP地址。
- 然后該template創建了2個Neutron端口（Port），把它們連接到默認的安全組（security group）。請注意如果你再創建Neutron端口時不指定security group，它將沒有任何東西，而且沒有數據從該端口通過。
- 最后，Heat template創建了2個實例（類型為OS::Nova::Server），它使用了m1.xsmall的flavor和寫好的 Glance Image ID. 這些實例又一次通過Ref函數連接到之前創建的Neutron端口。
如果你想使用JSON，那么我推薦你收藏一個JSON檢查的網站，比如jsonlint.com
一旦你定義好Heat template，你可以使用這個template通過Heat CLI或者dashboard來創建一個stack. 下面是我的一個stack在dashboard上的截圖。
還是不錯的吧？你覺得呢？我希望這個Heat介紹對你有所幫助。我確實有計划想在最近介紹一個OpenStack Heat的其他方面，所以保持聯系。如果有任何問題，更正，或者澄清，請不吝賜教。