In the previous tutorial we covered Ansible setup and some basic ad-hoc commands. It’s time to get organised and introduce the ability to easily repeat ourselves consistently. This tutorial will focus on playbooks…
Ansible playbooks are a way to define orchestration, configuration management and settings in an easy to read format. This also means that they can be easily stored in a version control system (such as Git) or shared amongst coworkers.
An Example Playbook
AN EXAMPLE PLAYBOOK
First, assume that our
/etc/ansible/hosts file looks like this:
[webservers] 10.0.0.2 10.0.0.3 [payment-service] 10.0.0.4 10.0.0.5 10.0.0.6 [database] 10.0.0.7 10.0.0.8
See if you can guess what the following playbook does and to which machines. Ansible really is that simple. Scroll down for the full explanation in case you’re stuck.
--- - hosts: webservers become: true tasks: - name: Install apache2 webserver package: name: apache2 state: latest - name: Ensure apache2 is started service: name: apache2 state: started
In case you hadn’t guessed, let’s walk through that playbook and explain:
- A playbook executes top down, in order.
- We specify the hosts that will be affected by this playbook. Our webservers group (
- We specify that ansible can
becomeanother user. By default this means that the script will
- We specify a task. The
nameof the task is purely for us humans. The first task uses the
packagemodule to install latest available version of the
- The next task uses the
servicemodule to ensure that
Notice something too, we installed
apache2 to two webservers with a single playbook. Even if our infrastructure scaled up to hundreds of thousands of webservers – all we’d need to do is add new IP addresses to our host file. Simple!
Indentation & Idempotence
Indentation is extremely important to ansible because it uses the YAML format. Check your playbooks by adding the
--syntax-check flag (eg.
ansible-playbook ~/myPlaybook.yml --syntax-check)
Idempotence is a key concept in Ansible. If something is idempotent it means the same operation can be executed multiple times without (necessarily) changing the result.
What this means in terms of Ansible is that the same playbook should be able to be executed multiple times without necessarily affecting the result.
Think about that for a second. It’s extremely powerful. It means you can write a playbook to define the state of your infrastructure then run it continuously (say in a
cron job). Ansible will ensure that your infrastructure is always in your desired state. If anything changes, Ansible will fix it for you.
Take the example above. We could run that playbook every 30 seconds. In essence, Ansible first checks whether
apache2 is installed. If it is, Ansible knows not to do anything. Ansible then checks whether
apache2 is running. If it is, Ansible does nothing. In other words, if everything is running as it should, nothing will happen (as, by definition, nothing needs to happen). After all, you wouldn’t want your web servers being re-installed and restarted every 30 seconds, would you!?