kantver - Fotolia


OpenStack Heat template sets private IaaS in motion

Understanding how the OpenStack Heat template works is key in the deployment of your private IaaS.

Orchestration is an important component of an IaaS cloud to help administrators make deployment easier.

An IaaS cloud such as OpenStack should be dynamic. If administrators create resources such as cloud nodes, instances and networking manually, that takes away from the flexibility of the cloud.

As is the case for most of the functionality that is considered essential for an OpenStack cloud environment, orchestration is included in OpenStack as a separate component, known as Heat. If you choose the open source OpenStack cloud architecture, expect most of the functionality to be available in this manner. Heat is designed to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within the cloud.

Heat implements an orchestration engine that is based on templates.

A physical data center converting to an OpenStack cloud would require a physical-to-virtual migration plan and tools. Heat technically could be used, but it is not the orchestration engine's intended purpose. Heat templates work best for implementation of similar machines. They do allow IT shops to make a transitional migration from their old data center to a software defined data center: This normally means that a completely new architecture comes in to enable cloud flexibility.

While an OpenStack Heat template is compatible with the de facto industry standard AWS CloudFormation template format, the instances in the OpenStack data center are configured with typical properties. As long as there is feature compatibility between AWS and OpenStack instances, a hybrid public-private cloud migration is possible. However, OpenStack is not 100% feature-compatible with AWS.

The Heat template describes what needs to be done in a text file so that is readable and writable by humans (see the example). Options include different types of infrastructure resources, such as servers, floating IP addresses, volumes, users and mores. The template also manages relationships between these resources, which allows it to handle complex configurations in an automated way.

Heat doesn't just create resources; it manages the entire resource lifecycle. To do so, it integrates tightly with DevOps-proven automation services such as Puppet and Chef, which manage the state of different software components.

A sample OpenStack Heat template.

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance with parameters



type: string

label: Key Name

description: Name of key-pair to be used for compute instance


type: string

label: Image ID

description: Image to be used for compute instance


type: string

label: Instance Type

description: Type of instance (flavor) to be used



type: OS::Nova::Server


key_name: { get_param: key_name }

image: { get_param: image_id }

flavor: { get_param: instance_type }

A single virtual instance is deployed in this example. The Heat template consists of two sections. The first part defines the parameters, which are the key_name, image_id and instance_type. The second part defines the resources that are managed through this template, which in this example is my_instance. To manage this resource, the three parameters defined in the beginning are referred to as properties. Here, the get_param statement defines that the values of all of these properties should be requested.

This OpenStack Heat template example is usable, but won't be very effective if the administrator needs to define stacks of hundreds of OpenStack instances. The parameter values are requested one by one, which makes a large deployment, as is often the goal for cloud resources, a slow process. To make it faster, use environment files in your template. These include sets of values for all the parameters that can be used.

Is OpenStack Heat user-friendly?

Though Heat's organization is effective and easily managed through automated tools, it's not particularly user-friendly. Administrators don't like manually working through large ASCII files containing the required configurations. They have various options to make cloud orchestration easier.

The purpose of these cloud orchestration tools is to make managing large clouds easier. Many companies have tried to fill the gaps in cloud management, including Cloudyn, Dell and RightScale.

Is something more accessible is to be expected from the OpenStack community? Probably not. Though not very intuitive, Heat does provide efficient templates in a tool to manage cloud deployments. It is a functional back-end foundation for anyone who wants to build a flexible front-end interface on top of it.

There is an issue with front ends that are developed to make orchestration in a cloud easier: To be efficient, the front-end tool must provide access to the same number of parameters and configurations options seen in the OpenStack Heat template, meaning that those solutions probably won't be that much easier.

About the author:
Sander van Vugt is an independent trainer and consultant based in the Netherlands. He is an expert in Linux high availability, virtualization and performance. He has authored many books on Linux topics, including Beginning the Linux Command LineBeginning Ubuntu LTS Server Administration and Pro Ubuntu Server Administration.

Next Steps

A conservative approach to cloud conversion

One user's praise of OpenStack in the data center

The possibilities for OpenStack networking

Dig Deeper on Scripting, Scheduling and IT Orchestration