Heat, which allows you to perform cloud orchestration within the OpenStack ecosystem, is my favorite OpenStack service, but it’s also one of the most overlooked.
It’s a great way to get started with infrastructure automation code or, as I’ve called it, “DevOps with training wheels.”
While widespread adoption of Heat is not yet in full swing, mark my words, it will be soon. It’s been described as a main line project of the OpenStack Orchestration program, which tells me there is definitely more to come around Heat as well as orchestration in general.
As of version 9 of Rackspace Private Cloud powered by OpenStack, the orchestration capability has been included in the list of available services.
I hope you’ve been able to give it a try, but if not, don’t worry — after you read this, you’ll be ready to get your Heat on. Before we jump into all the fun Heat has to offer, let’s establish some baseline principles used to develop it.
What is orchestration?
Orchestration is the function of automating the manual steps necessary to install supporting application software and/or provisioning infrastructure resources to support your applications.
Imagine your business team asking IT to stand up servers, with each one needing to run on separate support software (Apache, JBoss and MySQL). The next request from the business team is they need this done for every new code release and for multiple test environments. This one simple task just turned into an infrastructure support engineer’s nightmare.
As we know (myself included after 15 years of production support), most engineers do not have the time to reproduce this task, and would much rather give the business team the ability to do it themselves (with IT control of course). The solution is to create scripts/templates to automate the business request, and develop it to be consumed in a self-service model. This, in essence, is the definition of orchestration.
What is a stack?
A technology stack is similar to Lego blocks; it’s the layering on technology components to create a collection of objects. In our case, these components could be instances (VMs), networks, subnets, routers, ports, router interfaces, security groups, autoscaling rules, etc. Stacks can also include software dependencies and/or the custom applications themselves.
Every Lego block design has to have a base. From a private cloud perspective, that base will always be the computing resources from your OpenStack cloud. This is where Heat can give you an automation edge as you begin your orchestration journey.
What is Heat?
Heat is a main line project part of OpenStack composed of an orchestration engine used to launch multiple composite cloud applications based on templates in the form of text files.
These text files should be treated like code — this is how the term “infrastructure as code” was born. The template format supported by Heat is called HOT (Heat Orchestration Template), which was originally derived from a concept developed by AWS called CloudFormation.
Both formats are interchangeable, enabling a smooth transition to or from either OpenStack and AWS. As with all other OpenStack components, the functionality offered by Heat is available via a REST API and/or Python CLI. We have already seen further service improvements to Heat, such as those found in the Mitaka release, including optimizing the orchestration engine processes, stack snapshot/restoration features and software-specific configuration options, just to name a few.
The HOT template standard is built around a template definition called YAML, the data serialization code that takes concepts from programming languages.” Honestly, it’s one of the easiest template formats to read and learn.
Once a template is executed within your RPC-O environment, it is defined as a stack. Execution of that stack will provision the resources configured in the template and report on the status. Please keep in mind that removing a stack will also remove the resources provisioned, such as instances created, unless you tell Heat to abandon that stack. Below is a simple example of how to create a new Heat stack via the CLI:
heat stack-create <name of stack> --template-file=vm_with_cinder.yaml --parameters=“key_name=<pub key name>;flavor=m1.medium;image=<glance image id>;network=<neutron network id>;vol_size=20”
Or, you can provide an environment file with all the parameters pre-populated in it. Such an example would look like this:
heat stack-create <name of stack> --template-file=openstack_hot_demo.yaml --environment-file=<path/name of env file>
Heat resource types
One area of caution I have discovered when creating my nifty new Heat templates surrounds available resource types within my cloud. This is where you call the different resource types (not limited to any specific amount) you will use to create the stack.
The “brains” of your Heat template live in the resources section of the template and it’s where the templates for actual resources, which will make up a stack deployed from the Heat template (compute instances, networks, storage volumes) are defined. Each resource is defined as a separate block in the resources section.
Before beginning to create Heat automation code, make sure to do a quick inventory of the available resource types available to your cloud. You can do this via the Horizon dashboard under the “Orchestration” sub-menu on the “Project” menu item on the left navigation bar. You can also execute the following command below using the Heat CLI:
A complete list of resource types and how to use them can be found here.
Different resource types are made available based on the OpenStack release you’re running. That information is available in the link above, corresponding to the Resource Type in question.
Using Heat you can quickly bridge the gap around automating many infrastructure needs within your RPC-O environment. Within one HOT script, an engineer could create the three-tiered stack and hand that template over to the business units to be executed within their designated project(s). Or even better, they could use external automation tools such as Ansible Tower to expose that template for execution.
Thus far, working with Heat has been very positive and dependable. It even has an added quality assurance feature in which it pre-qualifies the template before officially executing it. I’m looking forward to seeing what additional functionality will be built into Heat going forward, and highly suggest giving it a try soon!
More information about the Heat API and CLI can be found below:
Example Heat templates can be found on my GitHub repository: