原文：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的其他方面，所以保持联系。如果有任何问题，更正，或者澄清，请不吝赐教。