My previous two blog posts (YAML Ain’t Markup Language and Ansible Inventory Files) have been leading up to this. In the YAML post I mentioned that .yml files can be used to make Ansible Playbooks and that’s what we’ll be going over in this blog. If you’ve heard about tools like Chef, for example, it has the concept of “recipes.” Ansible has a similar concept called Playbooks, which are just single YAML files. You can use them to restart machines, start/stop services, execute scripts and so on. All the same YAML rules apply, including indentation.
Example Playbook
*Not a real life playbook, for example purposes only
Let’s pick the above playbook apart so we can better understand how it works. At the top we have a commented out title just documenting what the playbook is for using: #Web Upgrade Playbook.
Beyond that we have actual plays. Of course we can have several plays in a playbook and I have two shown here. A play consists of a play name, hosts, and tasks. Notice a play is actually a dictionary (again refer back to the YAML blog post for more information). This means that it’s unordered, or really that order doesn’t matter. So I could have hosts listed above name and it would still be able to read it. Though it’s always good to make it human readable as well.
The play name in the top case is “Upgrade Web1”, and in the second case is “Upgrade Web2”. These are descriptive of what the actual play will be doing.
The hosts are simply the machines or devices where the tasks will be performed. These hosts must be listed in the Ansible Inventory File (see previous blog post for more information). You can see I have “web1” and “web2” listed, but these could be groups of servers or devices, multiple groups, individual machines, just as long as it’s specified in the Ansible Inventory File.
Finally we have the actual tasks. These are the activities that are going to be performed. Above I’ve only used command and script but there are multiple tasks we can perform. As you can see, command actually runs a command as if you were typing into the terminal or CLI. Script actually runs a script.
*On your Ansible controller, if you were to type ‘ansible-doc -l’ (that’s a lowercase L) you would get several tasks from all different sources, including device vendors.
Tasks are actually lists and if you’ll remember, lists are ordered. Notice that I have mine in order of shutting down the service, running a script, and then restarting the server. It wouldn’t make any sense to do that in any other order. These tasks will be performed in order listed.
*A side note or tip really, as I’ve been jumping more into automation and reliability, before you start creating any really involved playbooks it would be a great idea to create these in some sort of pseudo-code somewhere. Meaning, before you create the playbooks, really document and spell out what you want to do and how you want to achieve it in layman’s terms. Then create your playbooks from that. It will be easier for the whole team, including you as time passes, to understand what you were trying to achieve and how it may need to change with time.
Finally to run a playbook just type:
ansible-playbook playbook.yml
(where “playbook.yml” is the name of your playbook).
No egos here, please let me know if I got anything wrong or any other constructive criticism you might have for me. @malhoit