Dynamic Inventory – An Ansible and Openstack Lovestory

by | Jun 2, 2023

For those of you that may not be too familiar with Ansible, it is a great tool to get started in the world of automation and making your life with configuration management a whole lot easier. In this tutorial we will be going through a basic playbook that you can use with OpenStack and looking into the use of dynamic inventories.


Getting to know each other

Dynamic inventories are great as you don’t need to update the file every time you set up a new server in your project. When using Ansible with OpenStack, you can utilize a dynamic inventory plugin to generate a list of servers running in your OpenStack environment. The plugin works by connecting to the OpenStack API and collecting information about instances that match specific criteria, such as those with a particular tag or running a certain image.

By using a dynamic inventory, you can streamline the process of discovering and managing hosts in your environment without needing to manually update a static inventory file. This is especially useful in larger or more dynamic environments where the number of hosts is constantly changing.

The only requirements for this tutorial are a basic knowledge of Ansible and OpenStack and even if you are a total beginner, you should still be able to get the gist of what we are trying to accomplish. We will be using the servers my project in the demonstration, but realistically it could be any number of servers to your liking. For this example we will be just checking the uptime of all of our servers. So let’s get started!

The main two components we will need are Ansible (of course) and the OpenStack SDK in order to control the API.
Caution! Depending on your system you may need to use “pip3” as pip will refer to “pip2” which is no longer in use.

First of we will install Ansible using pip from python. Let’s check to see if pip is installed.

python3 -m pip -V

If you get the message “No module named pip” then you can install it using these commands:

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py --user

And afterwards you can install Ansible.

python3 -m pip install --user ansible

We can check to see if it has been installed correctly with this command.

ansible —-version

Now that we have Ansible installed we can move onto the OpenStack SDK. Now we definitely have pip installed we can use the following:

pip install openstacksdk


Moving in together

Now that we have both programs and the plugin installed we can move onto to writing a simple playbook. This playbook as previously mentioned with be very simple and we will just be checking the uptime of the servers. Obviously you can make this a lot more complex or add your own playbooks, but the principle it the same. We will need the following files in our folder where we will be running the Ansible code.

This file is where all of our login credentials for OpenStack are, Ansible will need this in order to gain access to our project. You can obtain this by downloading the file from your OpenStack, this is what mine looks like:
auth_url: https://cloud.netways.de:5000/v3/
username: “openstack-user"
password: “super-secret-password“
project_id: 12495myproject-id65684
project_name: "1234-openstack-15def5"
user_domain_name: "Default"
region_name: "HetznerNBG4"
interface: “public"
identity_api_version: 3

Here I have included a server that acts as a jumphost and a user that will be used once trying to connect to our servers.

ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p user1@jumpserver"'
remote_user: ubuntu

In this file we state the plugin we are using and what variables we want to include, like “private: false” makes sure that we are using public IP addresses. This also links our cloud.yaml file as well so we don’t need to include it in our command.This is the file I used:

plugin: 'openstack.cloud.openstack'
expand_hostvars: yes
fail_on_errors: yes
all_projects: false
private: false
clouds_yaml_path: ["./clouds.yml"]

This is the simple playbook that I used to just get the uptime of all of my servers.

- name: Print uptime of servers in OpenStack project
hosts: all
gather_facts: no
- name: Print server uptime
command: uptime
register: uptime

– debug: msg=”{{ uptime.stdout }}”

Now we have everything ready it is time to run our playbook and check the output.

ansible-playbook -i openstack.yml playbook.yml



Now the playbook has finished running we can check to see if it has worked correctly. We should see the results like above printed out on the terminal. If your playbook is a lot more complex and fails, you can just your error messages and see where it went wrong. That is the great thing with Ansible, you can run the playbook as many times as you like and you will get the same result. This is otherwise known as idempotent.

Although this is a very basic tutorial of the possibilities of a dynamic inventory, you can quite easily apply this to a lot more complex playbooks. If your project has 100 servers, this would be ideal as you don’t need to manually write each server into the config. Also by smaller projects this is helpful when you destroy old servers and set-up new ones, as you won’t have to retype the details of the new servers.

If you would like to find out more about IaaS or more tutorials about various other Dev-Ops topics why not check out our blogs and other posts here. Getting started with your own setup couldn’t be easier, one of our MyEngineers would be happy to help make your project ideas come to life.

More about Cloud
Using Terraform with OpenStack

Using Terraform with OpenStack

Many of you may already be familiar using Terraform with Azure or AWS. Although these may be the most used platforms, there is still a need for variety of other options due to local regulations (GDPR). As our systems are geared towards Open-Source, we will be looking...

Creating and Using S3 Object Storage

Creating and Using S3 Object Storage

In times of high availability and multiple web servers, the balancing act between central data storage, data security and fast access times must somehow be achieved. This is precisely why more and more users are now using technologies that entice them with buzzwords...

Corosync Cluster with Failover IP

Corosync Cluster with Failover IP

One of the first customer requirements you usually read is High availability. For a long time now, it has been more the norm that the project is still accessible without problems even in the event of partial failures and that "single points of failure" are avoided. A...