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).

How to install the latest 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 a 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 (pip, virtualenv)

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.

$ sudo yum install python-pip $ sudo pip install virtualenvwrapper $ sudo yum install python-heatclient python-openstackclient python2-shade

Alternatively, if your account is not a "sudoer", you can use these commands

wget https://bootstrap.pypa.io/get-pip.py python get-pip.py --user .local/bin/pip install virtualenvwrapper --user export PATH=$PATH:~/.local/bin #Remember to include this in your .bashrc

2) Setup a fresh virtualenv, where we’ll install the latest Ansible release

First, create a directory to hold the virtual environments.

$ mkdir $HOME/.virtualenvs

Then, add the following lines to your .bashrc

export WORKON_HOME=$HOME/.virtualenvs

source /usr/bin/virtualenvwrapper.sh

Now source it.

$ source ~/.bashrc

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

$ mkvirtualenv ansible2 --system-site-packages

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

$ deactivate $ workon ansible2

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.

(ansible2) $ pip install ansible

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:

(ansible2) $ pip install git+git://github.com/ansible/ansible.git@devel

(ansible2) $ ansible --version

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

NOTE: if the above commands don't work, make sure you have installed GCC and OpenSSL libraries in your systems, as some python dependencies involve recent cryptography modules

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.

(ansible2) $ yum install python-openstackclient python-heatclient

(ansible2) $ pip install shade --upgrade

5) Test it

(ansible2) $ ansible -m ping localhost localhost | SUCCESS => { "changed": false, "ping": "pong" }

NOTE: you cannot run this version of ansible outside the virtualenv, so always remember to do “workon ansible2” before usi.

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.

--- # Setup according to Blogpost "Full Stack automation with Ansible and OpenStack". Execute with "ansible-playbook ansible-openstack-blogpost.yml -c local -vv" # # # # # # - name: Execute the Blogpost demo tasks hosts: localhost tasks: - name: Download cirros image get_url: url: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img dest: /tmp/cirros-0.3.4-x86_64-disk.img - name: Upload cirros image to openstack os_image: name: cirros container_format: bare disk_format: qcow2 state: present filename: /tmp/cirros-0.3.4-x86_64-disk.img - name: Create new keypair from current user's default SSH key os_keypair: state: present name: ansible_key public_key_file: "{{ '~' | expanduser }}/.ssh/id_rsa.pub" - name: Create the test network os_network: state: present name: testnet external: False shared: False #provider_network_type: vlan #provider_physical_network: datacentre register: testnet_network - name: Create the test subnet os_subnet: state: present network_name: "{{ testnet_network.id }}" name: testnet_sub ip_version: 4 cidr: 192.168.0.0/24 gateway_ip: 192.168.0.1 enable_dhcp: yes dns_nameservers: - 8.8.8.8 register: testnet_sub - name: Create the test router ignore_errors: yes #for some reasons, re-running this task gives errors os_router: state: present name: testnet_router network: nova external_fixed_ips: - subnet: nova interfaces: - testnet_sub - name: Create a new security group os_security_group: state: present name: secgr - name: Create a new security group allowing any ICMP os_security_group_rule: security_group: secgr protocol: icmp remote_ip_prefix: 0.0.0.0/0 - name: Create a new security group allowing any SSH connection os_security_group_rule: security_group: secgr protocol: tcp port_range_min: 22 port_range_max: 22 remote_ip_prefix: 0.0.0.0/0 - name: Create server instance os_server: state: present name: testServer image: cirros flavor: m1.small security_groups: secgr key_name: ansible_key nics: - net-id: "{{ testnet_network.id }}" register: testServer - name: Show Server's IP debug: var=testServer.openstack.public_v4

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 gist:

heat_template_version: 2015-04-30 description: > Node template. Launch with "openstack stack create --parameter public_network=nova --parameter ctrl_network=default --parameter secgroups=default --parameter image=cirros --parameter key=ansible_key --parameter flavor=m1.small --parameter name=myserver -t openstack-blogpost-heat.yaml testStack" parameters: name: type: string description: Name of node key: type: string description: Name of keypair to assign to server secgroups: type: comma_delimited_list description: List of security group to assign to server image: type: string description: Name of image to use for servers flavor: type: string description: Flavor to use for server availability_zone: type: string description: Availability zone for server default: nova ctrl_network: type: string label: Private network name or ID description: Network to attach instance to. public_network: type: string label: Public network name or ID description: Network to attach instance to. resources: ctrl_port: type: OS::Neutron::Port properties: network: { get_param: ctrl_network } security_groups: { get_param: secgroups } floating_ip: type: OS::Neutron::FloatingIP properties: floating_network: { get_param: public_network } port_id: { get_resource: ctrl_port } instance: type: OS::Nova::Server properties: name: { get_param: name } image: { get_param: image } flavor: { get_param: flavor } availability_zone: { get_param: availability_zone } key_name: { get_param: key } networks: - port: { get_resource: ctrl_port }

Combining Dynamic Inventory with the 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.

#ensure you are using latest ansible version $ workon ansible2 $ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/openstack.py

$ chmod +x openstack.py

$ ansible -i openstack.py all -m ping

bdef428a-10fe-4af7-ae70-c78a0aba7a42 | SUCCESS => { "changed": false, "ping": "pong" } 343c6e76-b3f6-4e78-ae59-a7cf31f8cc44 | SUCCESS => { "changed": false, "ping": "pong" }

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

$ ./openstack.py --list

{ "": [ "777a3e02-a7e1-4bec-86b7-47ae7679d214", "bdef428a-10fe-4af7-ae70-c78a0aba7a42", "0a0c2f0e-4ac6-422d-8d9b-12b7a87daa72", "9d4ee5c0-b53d-4cdb-be0f-c77fece0a8b9", "343c6e76-b3f6-4e78-ae59-a7cf31f8cc44" ], "_meta": { "hostvars": { "0a0c2f0e-4ac6-422d-8d9b-12b7a87daa72": { "ansible_ssh_host": "172.31.1.42", "openstack": { "HUMAN_ID": true, "NAME_ATTR": "name", "OS-DCF:diskConfig": "MANUAL", "OS-EXT-AZ:availability_zone": "nova", "OS-EXT-SRV-ATTR:host": "compute-0.localdomain", "OS-EXT-SRV-ATTR:hypervisor_hostname": "compute-0.localdomain", "OS-EXT-SRV-ATTR:instance_name": "instance-000003e7", "OS-EXT-STS:power_state": 1, "OS-EXT-STS:task_state": null, "OS-EXT-STS:vm_state": "active", "OS-SRV-USG:launched_at": "2016-10-10T21:13:24.000000", "OS-SRV-USG:terminated_at": null, "accessIPv4": "172.31.1.42", "accessIPv6": "", (....)

Conclusion

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 I.T. 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 https://www.ansible.com/openstack. 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. https://www.redhat.com/en/technologies/linux-platforms/openstack-platform