Automating IT Processes with Ansible Playbooks: A Guide by Rackspace

Denise Irvin

How to Deploy With Ansible: An Accessible Explanation

Let’s say you're the proud owner of a fleet of Rackspace servers. For deployment, you can manually set up configurations, installations and applications for every server. Or, you can do something infinitely more scalable: you can use a free, open source configuration management and orchestration tool that is both simple and easy to learn.

An overly general overview

There are several popular programs for configuration/orchestration, including Chef, Puppet and Salt, but Ansible is a great choice for its simplicity and scalability. With Ansible, you have an “Ansible server," which is the computer running your commands, and your remote hosts, which are the computers being configured (although you can run Ansible tasks on your local machine). Ansible uses SSH to communicate between the Ansible server and the remote hosts, so when you run a playbook, commands are executed on your remote host. Ansible owes its high scalability to its agent-less design and high potential for playbook reuse.

So how can I use Ansible?

In the simplest form, you need three components: an Ansible server, remote hosts and a playbook. When you run your Ansible playbook (the set of instructions that configures your cloud instances), your Ansible server will need to connect with each instance. Setting up remote connection is as easy as setting up password-less login with SSH keys between your Ansible server and your remote hosts. If you have a use case where you cannot (or will not) use SSH keys, you can still use passwords, and either have Ansible prompt you for passwords at runtime or store them in a file — although this is not recommended for security or, honestly, convenience. The tasks you want executed are defined separately from the list of computers you want configured: you provide Ansible with a standalone inventory file of hostnames. An inventory file is a simple text file that lists the IP address or hostnames of the servers where you're deploying code.

Ansible host file
A host file can be as simple as this.

You can group your hosts in your inventory under headings, if you want to run certain certain Ansible tasks for certain host groups. You can specify your servers in the default hosts location (/etc/ansible/hosts), or feed your file it to Ansible when you deploy, with “-i inventory.txt”


How do you tell Ansible what actions to take on the server? You write a playbook. An Ansible playbook is written in a simplified subset of YAML, which is highly readable and easy to pick up. A sample playbook looks like this: Ansible sample playbook You can declare variables in your playbook, run loops and use conditionals. Playbooks are divided into sections. For example, tasks are defined in a special “tasks” section, while variables are declared in a special “vars” section, and handlers are defined in a special “handlers” section. The tasks section is a list of commands, to be run on the remote computers, or if specified as a local action, on the Ansible server. Handlers are special tasks that, if signaled with a notify statement, are run at the end of a play. Every task runs a corresponding Ansible module. For example, I can run the push code from GitHub by calling the git module: ansible github This task invokes Ansible’s git module, grabs code from the specified git url and pushes it in the destination directory. The module cleans up after itself — Ansible does not leave any cruft from executing the module on your server. When you install Ansible, it ships with over 500 modules, which more than covers most basic needs. There are preexisting modules that execute bash commands, push code and config files, deploy and manage Docker containers, install packages, and yes, specifically manage your Rackspace account. A complete list of modules is found on the Ansible docs website. If you want to develop your own modules, you can — the modules can be written in any language; the only hard and fast requirement is that it must return a JSON object. To run your playbook, use the command “sudo Ansible-playbook –i inventory.txt main.yml” and watch your playbook run.


Ansible lets you use one playbook to manage different roles. That means you can, in your inventory, designate different servers into groups like webservers, or databases. In your playbook, you can specify plays to be run by your different groups, and deploy everything in a single stroke. Ansible also works with Windows. You will need a Linux or Mac machine to use as an Ansible server, but Windows computers can be managed with Ansible. You can dynamically generate your hosts file. There is a command that generates a standard file structure. For non-trivial deployments, you can separate the sections of your Ansible playbook into separate text files. The command “ansible-galaxy init name_of_directory” generates the following file structure: fileStructureImproved As a side note, Ansible-galaxy is Ansible’s official community for sharing roles. You can upload your own roles or install others roles with ansible-galaxy commands. Ansible is a great choice for automating deployments and executing commands on any number of servers. After you write a few playbooks, you get a feel good feel for the tool and have a solid go to solution for deployment and orchestration.

Learn More On How to Configure On Your Servers