An important component of a cloud environment is orchestration. In OpenStack, there’s a program dedicated exclusively to Orchestration within the platform and the main project in this program is Heat. In this blog post, we’ll learn a little bit about OpenStack Heat and how to create simple orchestrations with it.
According to the OpenStack Foundation, Heat is an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated as code. In simple terms, Heat provides the OpenStack users with a way to automate the creation of cloud components like networks, instances, storage devices and much more.
Heat architecture components
There are four main components of the Heat project, each performing a unique function:
- heat: is the CLI that communicates with the heat-api.
- heat-api: is the component that provides an OpenStack-native ReST API that processes the requests and sends them to the heat-engine.
- heat-api-cfn: this component provides an AWS-style Query API that is compatible with AWS CloudFormation and process the requests and send them to the heat-engine.
- heat-engine: is the brains of the operation and does the main work of orchestrating the launch of templates and providing events back to the API consumer.
We now know what the Heat components entail, but before we analyze how it works, we need to introduce a couple more concepts surrounding Heat.
- Resources: They are objects that will be created or modified during the orchestration. Resources can be networks, routers, subnets, instances, volumes, floating IPs, security groups and more.
- Stack: In Heat, a stack is a collection of resources.
- Parameters: Allow the user to provide input to the template during deployment. For example, if you want to input the name for a instance in an orchestration, that name could be input as a parameter in the template and change during each run time.
- Templates: How a Stack is defined and described with code.
- Output: As the name indicates, outputs provide information back to the user.
Now that we understand the basic concepts around Heat, we can better understand how it works.
- The orchestration is defined in a template by describing the objects (resources) in a human readable format.
- The user creates the “stack” by pointing the heat cli tool to the template file and parameters.
- The heat-cli tool communicates with the heat-api.
- The heat-api sends the request to the heat-engine.
- The heat-engine process the request by talking to the other OpenStack APIs and provides output back to the user.
Now that we understand how it works in terms of components and architecture, let’s dive into the templates. A Heat template is usually a YAML file and contains the following fields:
Only three of the aforementioned fields are required to get a basic template: version, description and resources. Here’s an example of a basic template that can create a simple nova flavor:
heat_template_version: 2016-10-14 description: Template to create a Nova custom flavor. resources: nova_flavor: type: OS::Nova::Flavor properties: ephemeral: 1 is_public: true name: custom-tiny.m1 ram: 512 vcpus: 1
As you may have noticed, we did not declare either parameters or outputs and this template will be able to run and create a stack with one resource (nova_flavor).
To understand more on the template creation and best practices, you should visit the template guide.
And for more on Heat and OpenStack resources, check out the OpenStack Heat Developer Guide.
I hope that this introduction been useful to you and please remember to comment if you have any questions and share this post if you found it helpful.
Superuser is always interested in community content, email: [email protected]