Chapter 8. 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 additional features, which makes it a bit of a grab bag.
Dealing with Badly Behaved Commands: changed_when and failed_when
Recall that in Chapter 6, we avoided invoking the custom createdb manage.py
command, shown in Example 8-1, because the call wasn’t idempotent.
Example 8-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 identifies that a
task has changed state or failed.
First, we need to understand the output of this command the first time it’s run, and the output when it’s run the second time.
Recall from Chapter 4 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 add a debug
task to print out the variable, and finally a fail
clause so that the playbook stops ...
Get Ansible: Up and Running, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.