How do I use Ansible with OpenStack

Ansible offers great flexibility. Because of this, the community has figured out many useful ways to leverage Ansible modules and playbook structures to automate frequent operations on multiple layers, including using it with OpenStack.

In this blog we’ll cover the many use-cases for Ansible, the most popular automation software, with OpenStack, the most popular cloud infrastructure software. We’ll help you understand here how and why you should use Ansible to make your life easier, in what we like to call Full-Stack Automation.

Let’s begin by analyzing the layers of Full-Stack Automation, shown in the diagram above. At the bottom, we have the hardware resources (servers, storage area networks, and networking gear). Above, is the operating system (Linux or Windows). On the Linux side, you can install OpenStack to abstract all of your datacenter resources and offer a software-defined version of your compute, network, and storage resources. On top of OpenStack, are the tenant-defined services needed to create the virtual machines where the applications will reside. Finally, you have to manage the operating system (Linux or Windows) to deploy the actual applications and workloads that you really care about (databases, web servers, mobile application backends, etc.). If you use containers (like Docker or Rkt), you’ll package those applications in images that will be deployed on top of your Guest OS. In addition to that, some languages introduce the concept of application servers, which adds another layer (i.e. J2EE).

Ansible Management Possibilities

With Ansible, you have a module to manage every layer. This is true even for the networking hardware, although technically speaking it’s for the network operating system, like IOS or NXOS (see the full list of Ansible network modules here).

  1. General interaction with the OS: Install packages, change or enforce file content or permissions, manage services, create/remove users and groups, etc.
  2. IaaS software: Install the IaaS software and its dependencies (databases, load balancers, configuration files, services, and other helper tools)
    1. OpenStack-ansible installer, as used in some upstream-based OpenStack distributions from other vendors. Note that the Red Hat OpenStack Platform does not use Ansible, but Heat and Puppet. Future releases will leverage Ansible to perform certain validations and to help operators perform their updates and upgrades.
    2. CloudStack installer is also an Ansible-based project.
  3. Virtual resources: Define the resource, like a Virtual Machine or Instance, in terms of how big it is, who can access it, what content should it have, what security profile and network access it requires, etc.
  4. Guest OS: the same components as described for the Host OS. But how do you discover how many Guests you have?
    1. Ansible Dynamic Inventory will dynamically interrogate the IaaS/VM layer and discover which instances are currently available. It detects their hostname, IPs, and security settings and replaces the static Inventory concept. This is especially useful if you leverage Auto Scaling Groups in your cloud infrastructure, which makes your list of instances very variable over time.
  5. Container Engine (optional).
  6. Tenant software: Databases, web servers, load balancers, data processing engines, etc.
    1. Ansible Galaxy is the repository of recipes (playbooks) to deploy the most popular software, and it’s the result of the contributions of thousands of community members.
    2. You can also manage web Infrastructure such as JBoss, allowing Ansible to define how an app is deployed in the application server.

Installing Ansible on a Python Virtual Environment

As you have seen, some features are only available with very recent Ansible versions, like 2.2. However, your OS may not ship it yet. For example, RHEL 7 or CentOS 7 only comes with Ansible 1.9.

Given that Ansible is a command-line tool written in Python, which supports multiple versions on a system, you may not need the security hardening in Ansible that your distribution offers, and you may want to try the latest version instead.

However, as any other Python software, there are many dependencies, and it’s very dangerous to mix untested upstream libraries with your system-provided ones. Those libraries may be shared and used in other parts of your system, and untested newer libraries can break other applications. The quick solution is to install the latest Ansible version, with all its dependencies, in an isolated folder under your non-privileged user account. This is called a Python Virtual Environment (virtualenv), and if done properly, allows you to safely play with the latest Ansible modules for a full-stack orchestration. Of course, we do not recommend this practice for any production use-case; consider it a learning exercise to improve your DevOps skills.

1) Install Prerequisites

The only system-wide python library we need here is “virtualenvwrapper”. Other than that, you should not do “sudo pip install” as it will replace system python libraries with untested, newer ones. We only trust one here, “virtualenvwrapper”. The virtual environment method is a good mechanism for installing and testing newer python modules in your non-privileged user account.

2) Setup

First, create a directory to hold the virtual environments.

Then, add a line like “export WORKON_HOME=$HOME/.virtualenvs” to your .bashrc. Also, add a line like “source /usr/bin/” to your .bashrc. Now source it.

At this point, wrapper links are created, but only the first time you run it. To see the list of environments, just execute “workon”. Next, we’ll create a new virtualenv named “ansible2” , which will be automatically enabled, with access to the default RPM-installed packages.

To exit the virtualenv, type “deactivate”, and to re-enter again, use “workon”.

3) Enter the New Virtualenv and Install Ansible2 via PIP (as Regular User, not Root)

You can notice your shell prompt has changed and it shows the virtualenv name in brackets.

The above command will install just the ansible 2 dependencies, leveraging your system-wide RPM-provided python packages (thanks to the –system-site-packages flag we used earlier). Alternatively, if you want to try the development branch:

If you ever want to remove the virtualenv, and all its dependencies, just use use “rmvirtualenv ansible2”.

4) Install OpenStack Client Dependencies

The first command below ensures you have the latest stable OpenStack API versions, although you can also try a pip install to get the latest CLI. The second command provides the latest python “shade” library to connect to latest OpenStack API versions using ansible, regardless of the CLI tool.

5) Test It

Note: You cannot run this version of ansible outside the virtualenv, so always remember to do “workon ansible2”.

Using Ansible to Orchestrate OpenStack

Our savvy readers will notice that using Ansible to orchestrate OpenStack seems to ignore the fact that Heat is the official orchestration module for OpenStack. Indeed, an Ansible Playbook will do almost the same as a HOT template (HOT is the YAML-based syntax for Heat, an evolution of AWS CloudFormation). However, there are many DevOps professionals out there who don’t like to learn new syntax, and they are already consolidating all their process for their hybrid infrastructure.

The Ansible team recognized that and leveraged Shade, the official library from the OpenStack project, to build interfaces to OpenStack APIs. At the time of this writing, Ansible 2.2 includes modules to call the following APIs

  • Keystone: users, groups, roles, projects
  • Nova: servers, keypairs, security-groups, flavors
  • Neutron: ports, network, subnets, routers, floating IPs
  • Ironic: nodes, introspection
  • Swift Objects
  • Cinder volumes
  • Glance images

From an Ansible perspective, it needs to interact with a server where it can load the OpenStack credentials and open an HTTP connection to the OpenStack APIs. If that server is your machine (localhost), then it will work locally, load the Keystone credentials, and start talking to OpenStack.

Let’s see an example. We’ll use Ansible OpenStack modules to connect to Nova and start a small instance with the Cirros image. But we’ll first upload the latest Cirros image, if not present. We’ll use an existing SSH key from our current user. You can download this playbook from this github link.

After the execution, we see the IP of the instance. We write it down, and we can now use Ansible to connect into it via SSH. We assume Nova’s default network allows connections from our workstation, in our case via a provider network.

Comparison With OpenStack Heat

Using Ansible instead of Heat has it’s advantages and disadvantages. For instance, with Ansible you must keep track of the resources you create, and manually delete them (in reverse order) once you are done with them. This is especially tricky with Neutron ports, floating IPs and routers. With Heat, you just delete the stack, and all the created resources will be properly deleted.

Compare the above with a similar (but not equivalent) Heat Template, that can be downloaded from this GitHub gistt:

Combining Dynamic Inventory With OpenStack Modules

Now let’s see what happens when we create many instances, but forget to write down their IP’s. The perfect example to leverage Dynamic Inventory for OpenStack is to learn the current state of our tenant virtualized resources, and gather all server IP’s so we can check their kernel version, for instance. This is transparently done by Ansible Tower, for instance, which will periodically run the inventory and collect the updated list of OpenStack servers to manage.

Before you execute this, ensure you don’t have stale cloud.yaml files in either ~/.config/openstack, /etc/openstack, or /etc/ansible. The Dynamic Inventory script will look for environment variables first (OS_*), and then it will search for those files.

You can have fun by looking at all the information that the Inventory script above returns if you just executed as follows:


Even though Heat is very useful, some people may prefer to learn Ansible to do their workload orchestration, as it offers a common language to define and automate the full stack of IT resources. I hope this article has provided you with a practical example, with a very basic use case for Ansible to launch OpenStack resources. If you are interested in trying Ansible and Ansible Tower, please visit A good starting point would be connecting Heat with Ansible Tower callbacks, as described in this other blog post

Also, if you want to learn more about Red Hat OpenStack Platform, you’ll find lots of valuable resources (including videos and whitepapers) on our website.