Posted on by Cloudinfrastack Team Member

Openstack Heat Orchestration

On hot summer days when the heat is in the air, my mind starts to think about vacation and the time passing by, but business never stops and it’s nice to have all things nicely prepared before you leave the office. Especially when you can use OpenStack instrument called Heat. So, let’s take look at it a bit.

Heat is a very useful orchestration tool for OpenStack users as it provides a way to automate the process of cloud components creations. Such are networks, instances, storage devices, etc.

Heat on a beach

Huge complexity in technologies, platforms, tools, software, and infrastructure mixed together is today’s standard for business. That brings out a lot of frustration and is time-consuming when building up such solution. Do not forget about automatization and provide, manage, and configure services connected to it.

Daily struggles; like when you deploy more resources than is really needed or the opposite situation – not enough resources. A client calling you anytime about creating a new environment for their development or that they don’t want to have their resources allocated on a project anymore. Heat is here to get resources on-demand with automated provisioning infrastructure. To clean or to allocate whole environments.

The main reason to use Heat Orchestration is to save time since creating and setting up cloud services is very time-consuming. It provides quick and very open solution to configure your infrastructure and deployment. Imagine building and managing cloud like a conductor in front of their orchestra.

The body of the heat contains four main components:

  • heat CLI
  • heat-api
  • heat-api-cfn
  • heat-engine
Heat Basic Workflow

An orchestration engine is designed to run multiple composite cloud applications from its own custom-created templates in a text form. Basically, we use Heat in our infrastructure as a code. This means producing entire environments simply like a wrapper in a whole.

Heath template is in the text. The file must be enabled for writing and it should be possible to check the difference between the versions. The key word is the resource group where the user can define infrastructure: volumes, servers, autoscaling users or groups, etc.

If it is specified (the relationship between the resources in the template) it is enabled to call out any of OpenStack API to create your whole infrastructure in one run.

When it comes to life cycles, Heat manages everything – infrastructure upgrade can be done in seconds. All that is needed is the modification of the template and one can use it to update their existing stack.

When it comes to configuration with puppet, Heat integrates perfectly. The whole process with Heat Orchestration is focused on OpenStack. Heat Orchestration’s purpose is to reduce IT cost and save an engineer’s time. In general, it improves the delivery time.

The template in this process is called Heat Orchestration Template (HOT) and is often written in YAML or JSON format.

heat_template_version: xxxx-xx-xx
    This indicate which template version we are using for orchestration 
Description:
  # a description of the template
    This is optional description filed, gives information about work load that can be deployed using this template
Parameters:
  # Declaration of input parameters
    Input parameters needed during initiating template
Resources:
  # Declaration of template resources
    This define resource information
Outputs:
  # Declaration of output parameters
    This specify how to pass information back to user

Structure of the HOT

Command for create stack using stack

heat stack-create my_first_stack -f custom.yaml

heat_template_version: '20xx-xx-xx'

parameters:
custom_get_param {....}
resources:
  server_with_volume:
    properties:
      availability_zone: {get_param: availability_zone}
      volume_id: {get_resource: server_with_volume_volume}
      flavor: {get_param: flavor}
      networks:
      - network: {get_param: project}
    wait_condition:
      type: OS::Heat::WaitCondition
      depends_on: server_with_volume
      properties:
        handle: {get_resource: wait_handle}
        # Note, count of 5 vs 6 is due to duplicate signal ID 5 sent below
        count: 1
        timeout: 10000
      wait_handle:
        type: OS::Heat::WaitConditionHandle
      outputs:
        wait_condition:
          value: {get_resource: wait_condition}

Real example of a part of HOT

Sources:

https://blog.calsoftinc.com/2017/03/openstack-cloud-orchestration-automation-cloud-infrastructure-deployment.html
https://wiki.openstack.org/wiki/Heat
https://www.quora.com/What-is-Openstack-Heat-Orchestration

The original autor: Standa, DevOps Engineer, cloudinfrastack

Cloudinfrastack Team Member