Thomas

Before we start with the playbooks that define how things are done, some words on the ad-hoc administration. Ansible can also be used to do ad-hoc administration based on the inventory I discussed in part 2 of this blog series This gives an administrator the ability to perform activities based on the region or the datacenter or on all hosts at once. Let’s assume we’ve updated an alias (CNAME) on our central DNS server. Before we use the updated alias everywhere in our landscape we would like to know if every host is already linked to the updated alias. Instead of logging into each and every host, executing dig, we can do it in one rush with Ansible:

ansible -i staging all -a "/bin/dig updated-cname.local.domain +short"

Another task would be to check if all servers in the inventory are reachable or if a specific service is running on the server. This will more or less look like this:

ansible -i staging all -m ping
ansible -i staging all -m shell -a "/bin/ps aux | /bin/grep chronyd"

The playbooks itself can be seen as a grouping for the ad-hoc tasks. Instead of doing action after action manually, playbooks gives you the ability to group and combine several activities and execute it step by step as a whole instruction set. It’s a kind of automating the things the administrator did previously with checklists. A sample playbook that could be used to first install glances and then reboot a host one minute after the execution of the playbook looks like this:

---
- hosts:        all
  become:       yes
  become_user:  root
  gather_facts: false

  tasks:
    # Install glances
    - name: Install glances
      yum: name=glances state=latest
    # Reboot the target host
    - name:    Reboot the target host
      command: /sbin/shutdown --no-wall -r +1 "Reboot was triggered by Ansible"

The file is based on the YAML format and contains one or more activities based on a scope. It can be executed like this:

ansible-playbook -i staging ./example_playbook.yml

For the time being, this is already sufficient to transition the widely used checklist approach to an automated approach. But this is only the tip of the iceberg, automation, once it is in place, can do a lot more for you which brings us finally back to the folder structure from the second blog post. In the next blog post, I will dive a little bit deeper into the automation possibilities, especially into the playbooks and roles.