In the world of cloud, there are several forms of automation that make your life easier when deploying virtual infrastructure. Most of you are probably familiar with configuration management platforms like Puppet or Chef. Those are great for customizing virtual machines or instances that are up and running, but what orchestrating the launching of the virtual infrastructure itself? For that, we turn to OpenStack Heat. Heat is very much like Amazon AWS Cloud Formations. You use templates to define what to spin up in the cloud and how. A great use case here is spinning up an entire application stack, such as a scalable web application, in an automated fashion. Let Heat spin up and configure all of the infrastructure components, then let Puppet or Chef install and configure the application stack at the instance level. This is the ultimate one-two punch for cloud automation.
Here are a couple of things to become familiar with as you learn to use Heat:
- Stack – A group of connected cloud resources such as instances (virtual machines), cinder volumes, networks, routers, security groups, etc.
- Template – Defines a stack by listing everything that composes the stack.
- Parameters – Defines information which can be passed to Heat from the user like Image IDs or Network IDs. One of three main sections of a Heat template.
- Resources – the specific objects that Heat will launch and configure from the templates. Second of three main sections of a Heat template.
- Output – Information that is passed back to the user at the end of the process.
Since Heat is much like AWS Cloud Formations, it is no surprise that Heat can use a CF template as well. Native Heat templates that are not compatible with AWS CF templates are called Heat Orchestration Templates (HOT). These are often written in YAML as opposed to Cloud Formations Native (CFN) templates which are written in JSON. HOT templates can only be used with OpenStack which CFN templates can be used with AWS and OpenStack. More information on Heat templates can be found here.
Should you want to wade further into the waters of Heat terminology, visit the Heat Glossary.
Architecturally, you have the heat-api and heat-engine that work all of the Heat ‘magic’ behind the scenes. You ‘talk’ to the Heat API, which then sends requests via a message queue (AMQP) to the Heat Engine. The Heat Engine actually handles all of the orchestration. Note that Heat also uses its own database to maintain state information.
Here is the main Heat Wiki, which has a ton of information about Heat along with Getting Started Guides. Knock yourself out there and let me know if you have any questions.