TREllisNet logo

Random musings on life & free software

Spin Up a Rackspace Cloud Server With Ansible


“Everything should be made as simple as possible, but no simpler”

— Albert Einstein

Ansible is a configuration management, provisioning and work flow automation tool that is written in python. I’ve been playing around with for a little while and it’s a rather refreshing change from the other configuration management tools I’ve spent time with (Puppet & Chef). Ansible is extremely simple to use and understand, so I thought it was time to write up some of my notes to help anyone getting to grips with using it on the Rackspace Public Cloud.


Firstly, you need to install it. You can use your own distributions package manager or alternatively just pull it with the python package manager – pip:

pip install ansible

Create an inventory file, which lists the servers you will be managing. We’re going to add the local system first as we are calling the Rackspace API remotely, so this is carried out from our local machine.

mkdir -p /etc/ansible
cat <<EOF >/etc/ansible/hosts
localhost ansible_connection=local

This simple inventory file just adds the local system and sets the connection type to local so that Ansible knows it doesn’t need to SSH to the server.

Let’s test it!

ansible -m ping local

This ‘ping’ test simply runs an Ansible connection ping (not a TCP ping) to test the connection to the server, in most cases this would SSH into the server to test the connection but as this is local it’s a lot more simple.

You should see something like this:

root@ansible-bastion:~# ansible -m ping local 
localhost | success >> {
    "changed": false,
    "ping": "pong"

See Getting Started for more info.

Spinning up a Rackspace cloud server

Ansible is not just a configuration management tool, in fact if you use it only for configuration, you are missing a trick.

There are hundreds of pre-built modules and some of these modules can enable you to provision and orchestrate servers in many of the well known public cloud platforms such as AWS and Rackspace Public Cloud. By linking Configuration Management and Provisioning together, you can achieve a very powerful deployment model for your applications.

In this example, we’ll use a playbook to spin up a Rackspace Cloud server. A playbook is a YAML file written in Ansible’s own configuration management language and the way you orchestrate multiple tasks, much like a Chef cookbook or Puppet module/recipe, it contains ‘plays’ and underneath a play you also have a tasks and actions.

Setting up the Rackspace SDK

First we need to install pyrax, the Rackspace Cloud Python SDK. This allows Ansible to use native python modules to control Rackspace cloud resources. Why a Rackspace specific SDK and not the Python OpenStack/nova-client equivilent? Well, underneath it uses similar API calls but at the same time there are quite a few Rackspace cloud specific items that are not part of OpenStack either due to API differences or augmented services that were around before OpenStack equivalents (for example ). The SDK bundles the common bits but then all the additional extras required for other Rackspace services.

Install pyrax:

pip install pyrax

Setup your “~/.rackspace_cloud_credentials” file, all of these details are available from the Cloud Control Panel:

username=<your username>
api_key=<your API key>
region=<your region>

Now to create the playbook, here’s one I made earlier which I’ve added a ton of comments to:

- name: Build a Cloud Server # The name of this play
  hosts: localhost # Target local host
  connection: local # No remote connections, run actions locally
  gather_facts: False # This gathers useful facts from remote hosts, not required on localhost
  tasks: # All of the separate tasks we are going to carry out, in this case just one
    - name: Server build request # The name of the task
      local_action: # Always run this on the local machine not a remote machine
        module: rax # Rackspace Cloud module which is part of ansible core
        credentials: ~/creds # Rackspace cloud credentials file we created above
        name: test-server # Name of the cloud server 
        flavor: general1-1 # 1GB server - see for a list of flavors
        image: 892b9bab-a11e-4d16-b4bd-ab9494ed7b78 # Image ID for Debian Sid, pulled from 'nova image-list'
        region: LON # London Region
        key_name: ansible-bastion # SSH Keypair, use 'nova keypair-add' to upload one to RS Cloud
        wait: no # Do not wait for server to build, return immediately
        state: present # Create the server
        networks: # These are the two different default networks on Rackspace cloud
          - private # Rackspace service net
          - public # Rackspace public net
      register: rax # Save the result of the command in the rax variable for use in a later tasks

To run the playbook, we use the ansible-playbook command, not the Ansible command:

ansible-playbook launch-server.yaml

The output should look something like:

root@ansible-bastion:~# ansible-playbook launch-server.yaml

PLAY [Build a Cloud Server] ***************************************************

TASK: [Server build request] **************************************************
changed: [localhost ->]

PLAY RECAP ********************************************************************
localhost                  : ok=1    changed=1    unreachable=0    failed=0


Whoo! We launched our first instance with Ansible! However, we don’t have the IP of the server, so this isn’t particularly useful yet.

If you login to the Rackspace Cloud Control Panel, you should be able to see that it has successfully been launched.

In my next post I’ll tie it all together to configure a simple service on the instance.

In the meantime, a ton of information is covered in the Ansible Rackspace Guide.

Road Warrior 101

I’ve been very fortunate enough to have travelled a lot in the past 6 years in my roles as a Consultant at both Red Hat, Canonical and now Eucalyptus, but also for holidays. Those countries have included: Philippines, India, Australia, USA (San Francisco, Santa Barbara, Boston, New York, Washington DC, Florida), Canada (Montreal), South Africa, Finland, Sweden, Netherlands, Spain, Germany, Italy, Belgium, Ireland, Poland… to name a few!

Suffice to say, when you spend a bit of time “on the road”, you learn a few tricks to help make life a bit easier. This blog post is a break from my technical posts to impart a few of those tricks on you, the public.

do you have any tips? I’d love to hear them, stick them in the comment box below!

Adventures in NoSQL, Part 2

In Part 1 of this blog series, “Adventures in NoSQL”, I deployed a single instance of MongoDB and used Python’s tweetstream module to fill a collection with a data feed from Twitter.

In the real world you wouldn’t ever use a single instance of MongoDB (or twitter data :–) ) as there is no redundancy if an instance fails, all your data is gone or you need to take some time to restore it from a backup.

However, we can harness the power of a private Eucalyptus IaaS Cloud to use as our infrastructure, this means we can quickly scale out resources using direct EC2 API calls, the euca2ools command line utilities or the Eucalyptus Web interface.

In this post, I’ll explore using Replication to spread your data across multiple MongoDB servers for redundancy.

Backing Up a Eucalyptus Cloud Controller


When you first start using Eucalyptus, you are concerned with the intricacies of building images, configuring virtual instances and using all the variety of API features and tools that Eucalyptus offers.

However, when Eucalyptus becomes a tool your business relies on you need to consider making sure you can recover the system from a catastrophic failure. In the enterprise this usually means making adequate backups and being able to restore the whole system from those backups using an automated procedure perhaps with tools such as Ansible, Puppet and Chef or via a documented manual restore procedure.

Of course, like most things – it’s never as easy as it seems it should be! :–)

This article will cover backing up and manually restoring the Eucalyptus Cloud Controller (CLC) to a known state.


This last weekend I was over at FOSDEM 2013, where 5,000 geeks descended onto the ULB university in Brussels, Belgium for a huge free and open source software conference.

It was my first time at FOSDEM after many years of nearly attending and the first thing that struck me was the size. 5,000 people in attendance over the two days, 390hrs of talks and every talk was absolutely packed. It reminded me of the Ubuntu Developer Summit (UDS), but on steroids.

Adventures in NoSQL, Part 1

You’ve deployed and setup a private Cloud platform but now what? You need an application!

I’ve been experimenting with a number of technologies to generate workloads and give some demos to prospective Eucalyptus customers. A NoSQL database seems like a great use-case to demo as the technology benefits from being designed for scale-out workloads and this happens to be exactly what an IaaS Cloud does best.

There are an abundance of NoSQL implementations (Cassandra, MongoDB, Couchbase, Neo4j…), written in different programming languages and with slightly different takes on which two parts of the CAP theorem they choose to implement and which method they will use to store and display data.

For this post I’m going to be using MongoDB, which is in the “CP” camp, it handles Consistency and Partition Tolerance whilst forgoing Availability (Every request may not see a response), although MongoDB still provides some great availability options.

A Keepalived VIP for Eucalyptus Node Controllers


In a Eucalyptus HA configuration there are two Cluster Controllers’s (CC) which are in an active-passive state. One is in “ENABLED” mode and one is “DISABLED” mode. If a failure occurs, the active CC services moves to the secondary CC system.

If you combine this with Eucalyptus MANAGED or MANAGED-NOVLAN networking configuration with a private back-end network your Node Controllers (NC) will require a default gateway for access to external networks and to the Walrus service to download Eucalyptus Machine Images.

Eucalyptus Sosreport Plugin

After some discussion on the Eucalyptus Community Mailing list, I’m happy to annouce I’ve had a crack at a python based plugin for sosreport.

Sosreport is a cool support data collection utility written in python and availble for RHEL/CentOS, Fedora, Ubuntu & Debian. It can collect lots of useful system files and stats that you might use to debug a server or send to a support organisation to help you.

I’ve packaged up my plugin for review by the community before I submit upstream to the sosreport project.

Monitoring Eucalyptus IaaS Availability With Nagios

This article describes one way to monitor your Eucalyptus cloud with Eutester, a framework for testing clouds and Nagios, a popular open source infrastructure monitoring tool. I’ve also posted this over on the Eucalyptus wiki for future reference.

We use a simple instance testcase from Eutester to spin up an instance in Eucalyptus with a custom ssh key and security group, ping the instance, ssh into it and then terminate the instance. We then report to Nagios on the overall success of the test.

It’s Alive!

I’ve decided to bring back my blog from near death.

I’ve had a blog for the past 10 years with very little content, so time to publish some things I’ve been working on.

I have a ton of small articles written as notes, I’ll try to write some of these up as I go along. For some reason I’ve never managed to get around to posting them online. I blame actually working with customers to solve problems.

This blog is powered by Octopress and hosted on Amazon S3 storage as I like cloudy services. I’ve even moved my DNS over to Route 53.

There are plently of docs out there if you are interested…