OpenStack – Heat Orchestration Template

Heat Orchestration Template

Heat provides us with a powerful orchestration engine where we can specify infrastructure in a declarative way. A heat orchestration template is easy to get the hang of and in this article we are going to look at an example of how we can deploy infrastructure using it.

When working with heat orchestration templates, we are writing simply writing declarative YAML (YAML Ain’t Markup Language) files where we specify infrastructure that we want Heat to create for us via the OpenStack API.


In this quick tutorial, the end goal is to deploy a minimal instance (VM) with a floating IP. How to get started with OpenStack is considered out of scope for this article. The article assumes that you already have the following.

  • An OpenStack API account at a provider with the Heat service enabled.
  • Sourced the Openstack API environment variales.
  • OpenStack client installed.

Heat Orchestration Template

An heat orchestration template contains of 4 sections.

  • Version
  • Parameters
  • Resources
  • Output


Heat Orchestration is an evolving project, and new releases are being made from time to time. Therefore, you need to specify which version you are going to use in the template. Check with your cloud provider which versions they support.


Parameters are where you can specify input to the template, variables that should be dynamic for re-usability. A good example is an SSH key name and a public network ID. Variables that will be different for different users of the template. It is also popular to have flavors (size of instances in processor cores, ram, and disk size) as a parameter.


Resources is the section where you specify what types of infrastructure that you want to get, for example, a network, an instance (VM) and a floating IP.


Similar to how a template can have input, it can also have output, for example, IPs.

Template Example

heat_template_version: 2015-04-30
description: |
  A basic example of a template used for HEAT Orchestration in OpenStack.
  The template deploys a single instance (VM) with an external ip.

    type: string
    type: string
    type: string
    default: 1C-1GB
    type: string
    default: CentOS 7 1602

  # The router where network traffic will pass through.
    type: OS::Neutron::Router
      name: router
        network: { get_param: public_net_id }

  # Associates a router with a subnet or a port.
    type: OS::Neutron::RouterInterface
      router: { get_resource: my_router }
      subnet: { get_resource: my_subnet }

  # The network that will contain one, or many subnets.
    type: OS::Neutron::Net
      name: testnet
  # Subnet that the instance will be connected to and receive a ip address from.
    type: OS::Neutron::Subnet
      network: { get_resource: my_network }

  # A Port that our instance will attach it's interface on to.
    type: OS::Neutron::Port
      network: { get_resource: my_network }

  # A resource where Floating IPs will be taken from.
    type: OS::Neutron::FloatingIP
      floating_network: { get_param: public_net_id }

  # Creates the association from an Floating IP to the Port
    type: OS::Neutron::FloatingIPAssociation
      floatingip_id: { get_resource: floating_ip }
      port_id: { get_resource: my_port }

  # The Instance (VM)
    type: OS::Nova::Server
      name: test-instance
      key_name: { get_param: key_name }
      flavor: { get_param: flavor }
      image: { get_param: image }
        - subnet: { get_resource: my_subnet }
          port: { get_resource: my_port }

    description: The IP address of the deployed instance
    value: { get_attr: [ my_instance, first_address ]}
    description: The floating IP to the deployed instance
    value: { get_attr: [ floating_ip, floating_ip_address ]}


The template above takes four parameters; the first is a key_name which is the name of a KeyPair resource if you haven’t created one yet you can do it with the command below.

openstack keypair create --public-key ~/.ssh/ my_key_name

The second parameter it takes is a public network. Each user in an OpenStack environment is assigned a unique public network. This is the network which makes it reachable over the web, and it is also what enables you to SSH into it. You can figure out the ID of your public network with the command below (usually it is named ext-net or something similar).

openstack network list

The third parameter is flavor which is the size of the instance that is to be deployed. Unfortunately, flavors have different names in different cloud environment. You can find out available flavors with the command below.

openstack flavor list

The fourth parameter is the OS that is to be deployed on the instance, similar to flavor the names is likely to be different depending on your cloud provider. You can find out available with the command below.

openstack image list

You might have noticed as well that I specified a default value for flavor and instance.


The template declares a couple of different resources. An instance is specified which is connected to an OS::Neutron::Subnet and an OS::Neutron::Port. Which is why we also specify those resources as well as an OS::Neutron::Net that the subnet resides in. We also specify an OS::Neutron::Router as well as an OS::Neutron::RouterInterface which connects our subnet to the router. And lastly, an OS::Neutron::FloatingIP to provide us with a floating IP so that we can connect to the instance, and an OS::Neutron::FloatingIPAssociation to connect it to our port.


The template when deployed will also output the IP of the instance and the floating IP associated with it.


The template is easy to deploy with the following command.

openstack stack create -t template.yaml --parameter public_net_id=ext-net --parameter key_name=planevik --parameter flavor=1C-1GB --parameter image="CentOS 7 1602" test

Give it a couple of seconds to deploy and then we can check the output of the template with the command below.

openstack stack output show --all test

Now we should be able to SSH into it using the private key associated with the public key that you created in your KeyPair.

When you are done with the instance, you can bring down it and all the other resources with a simple command.

openstack stack delete test.

Final Words

We have looked a heat orchestration template example deployment and it really is that easy to deploy infrastructure. Because everything is done in YAML everything is declarative and easy to read.

There are really loads of cool stuff that you can do with Heat and I recommend checking out the official OpenStack Documentation for the Template Guide. In future articles we will dive a bit deeper with heat orchestration.

Leave a Reply

Your email address will not be published. Required fields are marked *