2015-07-17 19:53:13 +02:00
Blocks
======
In 2.0 we added a block feature to allow for logical grouping of tasks and even
in play error handling. Most of what you can apply to a single task can be applied
at the block level, which also makes it much easier to set data or directives common
2017-01-16 16:12:57 +01:00
to the tasks. This does not mean the directive affects the block itself, but is inherited
by the tasks enclosed by a block. i.e. a `when` will be applied to the tasks, not the block itself.
2015-07-17 19:53:13 +02:00
2015-08-05 01:09:06 +02:00
.. code-block :: YAML
2017-08-02 22:36:17 +02:00
:emphasize-lines: 3
2015-08-05 01:09:06 +02:00
:caption: Block example
2015-07-17 19:53:13 +02:00
tasks:
2017-08-02 22:36:17 +02:00
- name: Install Apache
block:
2015-07-17 19:53:13 +02:00
- yum: name={{ item }} state=installed
with_items:
- httpd
- memcached
- template: src=templates/src.j2 dest=/etc/foo.conf
- service: name=bar state=started enabled=True
when: ansible_distribution == 'CentOS'
become: true
become_user: root
2015-08-05 01:09:06 +02:00
2016-10-21 14:30:11 +02:00
In the example above, each of the 3 tasks will be executed after appending the `when` condition from the block
2016-02-03 20:33:25 +01:00
and evaluating it in the task's context. Also they inherit the privilege escalation directives enabling "become to root"
for all the enclosed tasks.
2015-07-17 19:53:13 +02:00
2017-08-14 02:14:03 +02:00
.. versionadded :: 2.3
2017-09-05 17:48:00 +02:00
The `` name: `` keyword for `` blocks: `` was added in Ansible 2.3.
2015-07-17 19:53:13 +02:00
.. _block_error_handling:
Error Handling
`` ` ` ` ` ` ` ` ` ` ` ``
2015-08-05 01:09:06 +02:00
Blocks also introduce the ability to handle errors in a way similar to exceptions in most programming languages.
.. code-block :: YAML
2017-08-02 22:36:17 +02:00
:emphasize-lines: 3,7,11
2015-08-05 01:09:06 +02:00
:caption: Block error handling example
2015-07-17 19:53:13 +02:00
2017-08-02 22:36:17 +02:00
tasks:
- name: Attempt and gracefull roll back demo
block:
- debug: msg='I execute normally'
- command: /bin/false
- debug: msg='I never execute, due to the above task failing'
rescue:
- debug: msg='I caught an error'
- command: /bin/false
- debug: msg='I also never execute :-('
always:
- debug: msg="this always executes"
2015-07-17 19:53:13 +02:00
The tasks in the `` block `` would execute normally, if there is any error the `` rescue `` section would get executed
2015-07-19 23:27:13 +02:00
with whatever you need to do to recover from the previous error. The `` always `` section runs no matter what previous
2017-09-27 23:57:42 +02:00
error did or did not occur in the `` block `` and `` rescue `` sections. It should be noted that the play continues if a
`` rescue `` section completes successfully as it 'erases' the error status (but not the reporting), this means it won't trigger `` max_fail_percentage `` nor `` any_errors_fatal `` configurations but will appear in the playbook statistics.
2015-07-17 19:53:13 +02:00
2016-04-18 23:18:20 +02:00
Another example is how to run handlers after an error occurred :
.. code-block :: YAML
2017-08-02 22:36:17 +02:00
:emphasize-lines: 5,9
2016-04-18 23:18:20 +02:00
:caption: Block run handlers in error handling
tasks:
2017-08-02 22:36:17 +02:00
- name: Attempt and gracefull roll back demo
block:
- debug: msg='I execute normally'
notify: run me even after an error
- command: /bin/false
rescue:
- name: make sure all handlers run
meta: flush_handlers
handlers:
- name: run me even after an error
debug: msg='this handler runs even on error'
2015-07-17 19:53:13 +02:00
.. seealso ::
:doc: `playbooks`
An introduction to playbooks
2017-06-06 23:39:48 +02:00
:doc: `playbooks_reuse_roles`
2015-07-17 19:53:13 +02:00
Playbook organization by roles
`User Mailing List <http://groups.google.com/group/ansible-devel> `_
Have a question? Stop by the google group!
`irc.freenode.net <http://irc.freenode.net> `_
#ansible IRC chat channel