Heat is the primary project which deals with the orchestration of the OpenStack services. It was first released on May 23’ 2013. The major purpose to orchestrate OpenStack services was to manage the complete lifecycle of applications as well as infrastructure with the help of machine-human accessible services within the OpenStack clouds. Heat is primarily used to manage the infrastructure but with the help of templates, the software can be managed too. For this purpose, sometimes Puppet and Ansible (configuration management tools) are used. Since Heat comes in different plug-ins, therefore it can be customized by installing the correct plug-in.
Using Heat, the users can describe their applications in templates which are text files. The heat engine then parses and executes these templates. The templates can be easily managed using the tools dedicated for version controlling. The templates can specify which resources are interconnected, i.e. the template can specify how the resources are connected (e.g. volume ‘A’ is connected to server ‘N’). Specifying the connection helps the user to launch the applications correctly without any visibility faults. Also, the templates help in the creation of numerous OpenStack resource types such as security groups, volumes, instances, etc along with providing the users with some advanced functionality such as nested stacks, autoscaling, etc.
Terminology Encountered while Using Heat Service
- Resources: Networks, volumes, subnet, security groups, etc constitute the resources. During orchestration, these objects are created or modified and are worked upon.
- Stack: A collection of resources is known as a stack.
- Parameters: During deployment, input to the template is provided using the parameters. The value of inputs can be changed during the runtime also.
- Template: It is a text file consisting of how the resources (stack) are described with the code.
-
Output: It provides the processed information to the customer.
Primary Components of Heat Architecture
There are four primary components which constitute the heat architecture. All of them are unique and are dedicated to particular tasks. The components are stated below:
- Heat: It is the Command Line Interface that is used to communicate with the heat-API. The users don’t need to use heat to communicate with the heat-API. The API can be used directly.
- Heat-API: It processes all the requests and then sends the processed requests to the heat engine for further usage using OpenStack-native REST API.
- Heat-API-cfn: It provides the user with a query API. This type of API is compatible with the AWS Cloud Formation. It processes the API requests and then sends them to the heat engine.
-
Heat-engine: It the core element of Heat architecture and is dedicated to orchestrating the services by launching the templates. It also provides events to the API customers.
Working of Heat
Following steps describe the basic working of the Heat service:
Step 1) First of all, the template is designed which consists of resource description. This is written in a human-readable format.
Step 2) Now the stack is created by the user. This is considered to be successfully created when the Heat CLI tool points to the parameters and the template.
Step 3) Now the Heat API and the Heat cli tool communicate with each other.
Step 4) After, the communication is done, the Heat API starts to send requests to the Heat engine.
Step 5) The requests are finally processed by the Heat engine and the output is sent to the user.