【译】OpenStack Heat基础介绍

 

原文：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的其余方面，因此保持联系。若是有任何问题，更正，或者澄清，请不吝赐教。