OpenStack is chosen as a platform for many reasons, but one that frequently tops the list is orchestration. Without an element of orchestration in your OpenStack environment, you have a powerful turbo engine car that is just used for the school-run. As with any cloud environment, there are various tools to help with your orchestrated workloads, but out of the box, OpenStack provides Heat, the orchestration engine.

With Heat, you can define rich environments in a template, such as a multi-tier web application, which allows users consistency in launching these relatively complex deployments. I view the Heat orchestration templates (known as HOT (Heat Orchestration Template) – get it?) as a recipe that is written in YAML (Yet Another Markup Language). You define your ingredients that make up the environment. In a cooking recipe, this would be listing the amount of chocolate, flour, and sugar that is required for something like a cake. In a HOT ()file, this is the parameters section. You define the flavor of instances, the images used, and what networks the instances should launch against.

Like any good recipe, you can override these defaults—so if you fancy experimenting with jam instead of chocolate sauce, or varying the amount of sugar required—you can adjust these. Also, with Heat you do this in an environment file. This file is laid out as though you're assigning values to the parameters. For example, an input parameter in the HOT file might be image_name, and in an environment file, you assign image_name=ubuntu-image.

The next section in the HOT file is the largest and most complex as it is the method section of the recipe – the "how all the ingredients create a cake" section. In Heat, this is the start of the resources section. The resources section describes how the instances interact with each other. For example, a load balancer might get created during the Heat run that includes three web servers. The load balancer resources would have a method to attach these three unknown web servers to the load balance pool for that resource to be complete.

The final section is the output section. In a cooking recipe, you'd be taking the cake out of the oven. In OpenStack, this will be the end result—your multi-tier web application. However, with OpenStack and the nature of launching a number of instances into an environment that may not have even had a network created at that point, it would be hard to know the IP addresses that have been used, which may be needed in order to access the deployed stack. So, for this, we have the output section where a user of OpenStack can interrogate the stack and get useful information so that the launched stack is usable.

However, we are not limited to using the Heat orchestration engine within OpenStack when it comes to instance and application life cycle management. As introduced in Chapter 1, Installing OpenStack with Ansible, Ansible is a great example of a platform independent tool that we can use to help orchestrate tasks. Using Ansible modules specific to the target environment, such as OpenStack, we can launch instances and perform software installations in a structured way that may suit users of both OpenStack and other cloud environments.

The basic structure of Ansible is quite straightforward. In its simplest form, it has a notion of playbooks, plays, and tasks. If you study the OpenStack-Ansible playbooks that were described in Chapter 1, Installing OpenStack with Ansible you'll get an insight into advanced features not covered in this chapter, which allow you to extend your OpenStack-based cloud environments into fully orchestrated masterpieces!