|
|
|
@ -73,10 +73,9 @@ For starters, here's a playbook that contains just one play::
|
|
|
|
|
- name: restart apache
|
|
|
|
|
service: name=httpd state=restarted
|
|
|
|
|
|
|
|
|
|
We can also break task items out over multiple lines using the YAML dictionary
|
|
|
|
|
types to supply module arguments. This can be helpful when working with tasks
|
|
|
|
|
that have really long parameters or modules that take many parameters to keep
|
|
|
|
|
them well structured. Below is another version of the above example but using
|
|
|
|
|
When working with tasks that have really long parameters or modules that take
|
|
|
|
|
many parameters, you can break tasks items over multiple lines to improve the
|
|
|
|
|
structure. Below is another version of the above example but using
|
|
|
|
|
YAML dictionaries to supply the modules with their ``key=value`` arguments.::
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
@ -259,8 +258,8 @@ which is totally ok if the command is something like
|
|
|
|
|
be used to make these modules also idempotent.
|
|
|
|
|
|
|
|
|
|
Every task should have a ``name``, which is included in the output from
|
|
|
|
|
running the playbook. This is output for humans, so it is
|
|
|
|
|
nice to have reasonably good descriptions of each task step. If the name
|
|
|
|
|
running the playbook. This is human readable output, and so it is
|
|
|
|
|
useful to have provide good descriptions of each task step. If the name
|
|
|
|
|
is not provided though, the string fed to 'action' will be used for
|
|
|
|
|
output.
|
|
|
|
|
|
|
|
|
@ -365,9 +364,9 @@ The things listed in the ``notify`` section of a task are called
|
|
|
|
|
handlers.
|
|
|
|
|
|
|
|
|
|
Handlers are lists of tasks, not really any different from regular
|
|
|
|
|
tasks, that are referenced by a globally unique name. Handlers are
|
|
|
|
|
what notifiers notify. If nothing notifies a handler, it will not
|
|
|
|
|
run. Regardless of how many things notify a handler, it will run only
|
|
|
|
|
tasks, that are referenced by a globally unique name, and are notified
|
|
|
|
|
by notifiers. If nothing notifies a handler, it will not
|
|
|
|
|
run. Regardless of how many tasks notify a handler, it will run only
|
|
|
|
|
once, after all of the tasks complete in a particular play.
|
|
|
|
|
|
|
|
|
|
Here's an example handlers section::
|
|
|
|
|