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:
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
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
- name: Update apt cache
- hosts: testcluster
- name: Dist upgrade
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
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:
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.
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.