The wind blows wherever it pleases. You hear its sound, but you cannot tell where it comes from or where it is going.
When dealing with extensive playbooks, it is easier to split the tasks into roles. This also helps in reusing the roles in the future. Roles are a collection of tasks, which can be moved from one playbook to another, can be run independently but only through a playbook file. In other words, roles are a feature of Ansible that facilitate reuse and further promote modularization of configuration.
Ansible evaluates the return codes of modules and commands to determine whether a task succeeded or failed. Normally, when a task fails Ansible immediately aborts the plays, skipping all subsequent tasks.
However, sometimes an administrator may want to have playbook execution continue even if a task fails. For example, it may be expected that a particular command will fail.
For long playbooks, it is useful to be able to run subsets of the tasks in the playbook. To do this, tags can be set on specific resources as a text label. Tagging a resource only requires that the tags keyword be used, followed by a list of tags to apply. When plays are tagged, the –tags option can be used with ansible-playbook to filter the playbook to only execute specific tagged plays.
Handlers are tasks that respond to a notification triggered by other tasks. Each handler has a globally-unique name, and is triggered at the end of a block of tasks in a playbook. If no task notifies the handler by name, it will not run. If one or more tasks notify the handler, it will run exactly once after all other tasks in the play have completed. Because handlers are tasks, administrators can use the same modules in handlers that they would for any other task.
Normally, handlers are used to reboot hosts and restart services.
Continue reading “Ansible Handlers”
