Ansible: Up and Running, 3rd Edition

Chapter 10. Complex Playbooks

In the preceding chapter, we went over a fully functional Ansible playbook for deploying the Mezzanine CMS. That example used some common Ansible features, but it didn’t cover all of them. This chapter touches on those other features, which makes it a bit of a grab bag.

Dealing with Badly Behaved Commands

Recall that in Chapter 7, we avoided invoking the custom createdb manage.py command, shown in Example 10-1, because the call wasn’t idempotent.

Example 10-1. Calling django manage.py createdb

- name: Initialize the database
  django_manage:
    command: createdb --noinput --nodata
    app_path: "{{ proj_path }}"
    virtualenv: "{{ venv_path }}"

We got around this problem by invoking several django manage.py commands that were idempotent, and that did the equivalent of createdb. But what if we didn’t have a module that could invoke equivalent commands? The answer is to use changed_when and failed_when clauses to change how Ansible detects that a task has changed state or failed.

Let’s make sure you understand the output of this command the first and second times it’s run.

Recall from Chapter 5 that to capture the output of a failed task, you add a register clause to save the output to a variable and a failed_when: false clause so that the execution doesn’t stop even if the module returns failure.  Then you add a debug task to print out the variable, and finally a fail clause so that the playbook stops executing, as shown in Example 10-2.

Example 10-2. Viewing ...