Learn OpenStack - Heat (Orchestration Service): Infrastructure as Code

#Introduction

For eleven episodes, you created resources one by one: network, subnet, instance, volume, security group. In production, that pattern isn't sustainable — infrastructure must be defined as code that's repeatable, versionable, and rollback-able. That's the job of Heat, OpenStack's Orchestration Service and the native answer to Infrastructure as Code.

Episode 12 covers Heat from concept to practice: what a HOT template is, the anatomy of its YAML, how to define a web server plus database plus network in a single stack, managing the stack lifecycle, and Heat's position alongside Terraform and OpenTofu as modern alternatives.

#The OpenStack Heat Concept

#Native IaC Built into OpenStack

Heat lets you describe your entire infrastructure — instances, networks, volumes, security groups, even load balancers — in a single declarative template, then materialize it into a stack. One stack is one unit: created, updated, and deleted together.

HOT template (YAML) → heat stack create → real resources in OpenStack
   instance  → nova
   network   → neutron
   volume    → cinder
   security  → neutron

Heat's main advantage: all resources have a single lifecycle. You don't need to delete things one by one; delete the stack and every resource goes with it. Updating a stack produces an orchestrated change, not manual chaos.

#Heat Orchestration Template (HOT)

#Template Anatomy

The HOT format is YAML with four main sections:

heat_template_version: 2023-04-14
description: Template web server sederhana
parameters:
  image:
    type: string
    default: ubuntu-jammy
  flavor:
    type: string
    default: m1.small
resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      image: { get_param: image }
      flavor: { get_param: flavor }
outputs:
  instance_ip:
    description: IP instance
    value: { get_attr: [my_instance, first_address] }

Notice get_param: image inside the resource block — that's a reference to the parameter the user provides at deploy time. That's how a template becomes reusable: one template, many different values.

#A Complete Web Server Template

A real template that auto-provisions a web server with cloud-init:

heat_template_version: 2023-04-14
parameters:
  key_name:
    type: string
  network_id:
    type: string
resources:
  security_group_web:
    type: OS::Neutron::SecurityGroup
    properties:
      rules:
        - protocol: tcp
          port_range_min: 22
          port_range_max: 22
        - protocol: tcp
          port_range_min: 80
          port_range_max: 80
  web_server:
    type: OS::Nova::Server
    properties:
      image: ubuntu-jammy
      flavor: m1.small
      key_name: { get_param: key_name }
      networks: [ { network: { get_param: network_id } } ]
      user_data: |
        #!/bin/bash
        apt-get update
        apt-get install -y nginx
      security_groups: [ { get_resource: security_group_web } ]
outputs:
  server_id:
    value: { get_resource: web_server }

{ get_resource: security_group_web } connects the instance resource to the security group created by the same template. With this single file you get network attachment, firewall, and automatic provisioning — without a single manual command.

#Stack Lifecycle

#Creating and Managing Stacks

openstack stack create -t web-server.yaml --parameter key_name=mykey web-stack
openstack stack show web-stack -f value -c stack_status
openstack stack output show web-stack server_id -f value -c output_value

openstack stack create -t web-server.yaml creates a stack from the template. Monitor its status until CREATE_COMPLETE, then grab the outputs. To change the infrastructure, update the template and run:

openstack stack update -t web-server-v2.yaml web-stack
openstack stack delete --yes web-stack

openstack stack update applies changes only to the resources that changed, while openstack stack delete cleans up every resource in one command — far safer than deleting manually one by one.

#Handling Stack Failures

If a stack fails to create, don't panic — check the events:

openstack stack event list web-stack -f value -c resource_name -c resource_status_reason

The output of openstack stack event list shows which resource failed and why. This is the main diagnostic path when IaC automation fails in production.

#Modern Alternatives: Terraform and OpenTofu

#The OpenStack Provider

Heat isn't the only way. Terraform and its open-source fork OpenTofu provide an official OpenStack provider. Many organizations choose Terraform because one language covers many clouds — AWS, GCP, and OpenStack at once.

resource "openstack_compute_instance_v2" "web" {
  name      = "web-1"
  image_id  = data.openstack_images_image_v2.ubuntu.id
  flavor_id = "m1.small"
}

When choosing between Heat and Terraform: Heat is more native and concise for pure OpenStack, while Terraform/OpenTofu excel at multi-cloud. Many production teams use Terraform for cross-cloud orchestration and Heat as the native option.

#Summary

Episode 12 changes how you think about infrastructure: Heat defines instances, networks, volumes, and security groups in a single declarative HOT template, with a stack lifecycle that's safe to update and roll back, while Terraform and OpenTofu offer multi-cloud alternatives with official OpenStack providers.

Key takeaways:

• Heat is OpenStack's native IaC based on declarative templates.
• A HOT template contains heat_template_version, parameters, resources, and outputs.
• One stack is one unit: create, update, delete together.
• { get_param } and { get_resource } make templates reusable.
• openstack stack event list is the failure diagnostic path.
• Terraform and OpenTofu are modern multi-cloud alternatives.

In episode 13, we'll cover Octavia (Load Balancer as a Service) — distributing traffic to many backend instances, understanding the VM-based Amphora architecture, and creating load balancers, HTTP/HTTPS listeners, pools, members, and health monitors with round-robin, least-connections, and source-IP algorithms.