Ansible comes with modules for carrying out a variety of tasks, and if there is no module for what you need to do you can use the command or shell module to execute the raw commands. Or you could create your own module (and share it with the community).

Install and setup Ansible

The easiest way to install ansible is through your native packagemanager.

CentOS / RHEL / Yum

# yum install ansible

Ubuntu / Debian / Apt

# apt-get install ansible

Mac OSX / Homebrew

$ brew install ansible

After the packages is installed you have to look into the configuration files that is placed in "/etc/ansible/".

There are two interesting files I will mention in this quick introduction:

• ansible.cfg
• hosts

The ansible.cfg file is well documented inside the file itself, so read the file and adjust parameters as needed.

The hosts file contains all the host you want to do actions on, and is also well documented.

• You can specify groups of hosts
• You can specify multiple hosts by doing ranges
• You can specify hosts by fqdn or ip-addresses

[testcluster]
cluster-test-01.domain.tld
cluster-test-02.domain.tld

[prodcluster]
cluster-01.domain.tld
cluster-07.domain.tld
cluster-[10:30].tld

This will give us the ability to do stuff on either our testcluster or prodcluster later on.

Doing stuff with Ansible, also known as Ansible playbooks

To do tasks, ansible employes the concept of playbooks, which is a recipe on what action should be carried out, and on what hosts.

The playbooks are written in YAML and consist of play(s) and task(s).

• A playbook can contain multiple play's
• A play can contain multiple task's.

---
- hosts: testcluster
  remote_user: root
  tasks:
    - name: Update apt cache
      apt: update-cache=yes
- hosts: testcluster
  remote_user: root
  tasks:
    - name: Dist upgrade
      apt: upgrade=dist

The above playfile contains two plays, one that "apt-get update" and one that "apt-get dist upgrade". Each play contains a single task, which calls the Ansible apt-module.

To do a playbook you call the ansible-playbook command and point it to the YAML file:

$ ansible-playbook ~/ansible-playbooks/update.yaml

Ansible will now take care of update and upgrading all your testcluster machines to the latest and greatest software. That was easy!

Quirks and tips

SSH keys

To make the ansible-playbooks as smooth as possible I decided to deploy my ssh-keys to the administrator user on the machines.

When ssh-keys are deployed, I can unlock the key on my machine and forward the agent. This removes the need for entering my password on each host ansible is connecting to.

The Ansible documentation also encourage the use of ssh-keys instead of password. If you want to use password instead of keys you can add "--ask-pass" where needed.

Strict hostkey checking

My known_hosts file had all the previous hostkeys for the servers, so to get rid of the "are you sure you want to connect" prompt I had to disable the hostkeychecking.

$ export ANSIBLE_HOST_KEY_CHECKING=False

or add this to your ansible.cgf file:

[defaults]
host_key_checking = False

A more correct solution would have been updating my known_hosts file with new and correct hostkeys for all the servers, but for testing purposes, I went the lazy route.

Running commands without a playbook

Check the uptime of your servers? Or some other simple task?

$ ansible testcluster -m command -a "uptime" -u username -i ~/ansible/hosts
10.11.12.13 | success | rc=0 >>
 14:56:26 up 24 days,  6:09, 12 users,  load average: 0.33, 0.30, 0.25
10.11.12.14 | success | rc=0 >>
 14:56:26 up 55 days,  5:09, 12 users,  load average: 0.53, 0.50, 0.55

Take note of the -i , an override of the inventory / hosts file.

Conclusion

This was just a quicklook at Ansible and some trick on how to get started. I will hopefully write some more on ansible later. I will try describe how to do some common tasks on osx, and at a future point a comparison (pros and cons) with Puppet.