You are on page 1of 4

OpenStack Orchestration with Heat

Zane Bitter
24 October 2013
An introduction to the OpenStack Orchestration project, Heat, and
an explanation of how orchestration can help simplify the deployment and management of your cloud application by allowing you to
represent infrastructure as code. Some of the major new features in
Havana are also covered, along with a preview of development plans
for Icehouse.

What is Heat?
Heat Templates
Providers & Environments

What is Heat?

Future Developments

Orchestration is for infrastructure essentially what configuration
management is for software applications. Instead of manipulating
elements of your (virtual) infrastructure by hand, or with scripts,
Heat allows you to work with a declarative model that represents the
infrastructure resources and the relationships between them directly.
Heat itself then works out the correct sequence of actions to perform
to bring reality in line with your model.
The model takes the form of a Heat template, and the resulting
collection of infrastructure resources is known as a stack. Orchestration enables you to treat your infrastructure like code—you can store
the template in a version control system to track changes to it. When
you do make changes, just update the stack with the new template
and Heat performs the necessary actions.

More Information

The main interface to Heat is an OpenStack-native Rest API. As
shown in Figure 1, Heat sits between the user and the APIs of the
core OpenStack services in much the same way that the Dashboard
(Horizon) does. If you prefer, you can also interact with Heat through
the Dashboard.

















Figure 1: OpenStack architecture from
a user’s perspective, showing how
Orchestration interacts with other

2 Heat Templates Heat templates usually take the form of simple Yaml documents.) A template has four key elements: • An optional Parameters section. Parameters: ssh_key_name: Type: String Description: ssh keypair name image_name: Type: String Description: The image to boot Resources: my_server: Type: OS::Nova::Server Properties: flavor: m1. 1 In much the same way as the OpenStack Compute service provides an EC2 compatibility API. launching CloudFormation templates on OpenStack was the initial goal of the project. and the IP address of the server is available as an output. • An optional Outputs section. However Heat also provides a fair degree of compatibility with CloudFormation. configuration and infrastructure. The user can specify the image to boot from and the name of the ssh public key to install on the server. which describes the resources and relationships which define the application. Heat (for now) adheres closely to the CloudFormation template model. Figure 2: A simple example template that creates a Nova server and an attached Cinder volume. its functional equivalent in Amazon Web Services. One of the resource types available is a Heat stack.2 2 In fact. Heat even has a CloudFormation compatibility API. so Json is still fully supported and templates can be converted between the two formats with no loss of fidelity. because it is much easier for humans to read and write—and a diff between two versions of a Yaml template is usually trivial to interpret. Heat resource types are native representations of the underlying OpenStack Rest APIs. which may be referenced elsewhere in the template using the Fn::GetAtt function. "first_address"]} All resources have a common interface: • A number of optional or mandatory Properties which specify inputs that affect how the resource is configured. which describes the output values to be returned to the user. • A number of output attributes. A resource may reference any other resource or its attributes. (An example template is shown in Figure 2 at right.1 If you have workloads running on AWS that are defined with CloudFormation templates. which causes Heat to infer an ordering dependency between them. • A mandatory Resources section. so you can access the full power and flexibility of OpenStack. • An optional Mappings section. Other than the serialisation format. . so multiple templates can be composed into hierarchical structures.small key_name: {"Ref": "ssh_key"} block_device_mapping: device_name: vda volume_id: {"Ref": "my_vol"} my_vol: Type: OS::Cinder::Volume Properties: size: 20 image: {"Ref": "image_name"} Outputs: server_ip: Description: The server IP Value: {"Fn::GetAtt": ["my_server". We chose this over Json. which CloudFormation uses. it may be possible to move them to OpenStack with few or no changes in many cases. Yaml is a strict superset of Json though.openstack orchestration with heat Increasingly. which allows key/value lookup of predefined constants. which allows user-definable inputs to be specified.

and scaling policies. they are implemented internally as stacks. An environment allows the user to override parts of the template—for example.5 By selecting the appropriate template and environment.4 Heat has also added environments. and a scaling policy will make adjustments to a scaling group based on this input and its own configuration. any application could be launched on any cloud without modification. Lifecycle operations3 occur in parallel to the maximum extent possible given the dependencies between resources. 4 This is not a particularly realistic scenario. OpenStack Metering (Ceilometer) alarms. an organisation could keep both a library of templates (one per application) and an orthogonal library of environments (one per cloud). Scaling groups can also update a load balancer configuration when their membership changes. this is accessible only by creating a Heat template containing the relevant resources (there is no separate Rest API). A number of functions are available which allow some limited manipulation of data within the template. for example to combine parameter data with static data in the template. a scaling group. For example. You could define an environment for your test cloud that specifies that the DBaaS resource is supplied by a provider template 3 In fact. deleting or updating a stack. to make providers easier to consume. operations such as creating. This helps mitigate the issue that users are at the mercy of their cloud providers for native (Python) resource type plugins. Ceilometer alarms call a webhook—typically the one provided by the scaling policy resource in Heat—under defined circumstances. but testing on a local OpenStack installation with just the basics. Currently. Policy Scaling Group Load Balancer Launch Config Figure 3: The reference relationships between resources used to automatically scale a group of servers. Providers & Environments Heat has added features in the Havana release aimed at making templates more portable throughout the diverse OpenStack ecosystem. 3 Alarm Autoscaling Heat also provides an autoscaling service for groups of virtual servers. The resources involved are shown in Figure 3: a launch configuration (for new servers being added to the group). In the ideal scenario. environment files are likely to be tailored to templates in many cases. Provider resources are simply constructed out of native resources and are expressed using the exact same template syntax as stacks. 5 . you may be deploying your application to an OpenStack cloud that features a DBaaS (and the appropriate Heat plugin for it). That is to say. The Providers feature allows users to effectively define their own resource types. In practice.openstack orchestration with heat The template may also specify explicit dependencies where necessary. by specifying a provider template to implement a particular resource type.

or reliance on any particular tool. openstack orchestration with heat Figure 4: The relative positioning of Heat compared with other categories of software: configuration management systems (such as Puppet or Chef) and configuration managment–orchestration hybrids (such as Juju). Note that support for the CloudFormation template format will be maintained indefinitely. Future Developments The Heat Orchestration Template (or Hot) format is an effort to develop a native template language for Heat. Thus. Work on Hot will continue in the upcoming Icehouse development cycle to close the gap (illustrated in Figure 4) between orchestration and configuration managment..Software (Configuration Management) Puppet. to allow access to autoscaling for users who are not using Heat templates. in the main template you would only need to supply configuration data for your configuration management tool rather than configure the tool itself on every server.. This will enable Heat to handle far more complex application topologies than are currently feasible.7 Likely changes involve handling dependencies and passing data between software components installed on the virtual servers that Heat configures.6 A number of cosmetic changes have been prototyped already. That means you could. Providers are a powerful . create a provider template for a server resource that is specialised for a particular configuration management system or PaaS. Chef &c. and it is likely we will see more advanced uses of them in the future. such as rolling updates and the ability to scale whole templates. 7 More Information • ‘Heat’ page on the OpenStack Wiki • Getting Started guides • RDO Documentation • Ask OpenStack • @zerobanana • zerobanana. 6 The Heat team is working very hard to avoid any overlap with configuration management. Infrastructure (Orchestration) Juju . You can override a native resource type plugin with a provider template. with the aim of taking advantage of a Yaml-native format to improve the readability of templates. for example. which are complementary technologies. Development is also planned on a separate Autoscaling API. That allows you to test your application on your local cloud without DBaaS and still deploy the self same template to staging or production. We expect it to gain many more capabilities in the process. Database Network Object Storage Block Storage Heat Compute 4 containing a Nova server running MySQL.