What is Ansible Handlers?

Ansible handlers are a way to run tasks only when notified by another task. Handlers allow you to centrally manage the behavior of multiple tasks and ensure that only the necessary actions are executed. In Ansible, a handler is a task that is defined in the same way as a regular task, with a name and a list of actions to be executed.

Handlers are executed only when they are notified, and they are notified by tasks that set the changed_when or failed_when conditions to True. A task can notify multiple handlers, and a handler can be notified by multiple tasks.

To use a handler, you need to first define the handler in your playbook and then notify it from a task using the notify keyword. The syntax for defining a handler is as follows:

PHP
- name: Example handler
 
action: <module_name> <module_arguments>
 
notify: <handler_name>

And to notify the handler of a task:

- name: Example task
 
<module_name>: <module_arguments>
 
changed_when: <condition_when_task_changes_state>
 
notify: <handler_name>

For example, consider a scenario where you want to restart a service only when its configuration file changes. To achieve this, you can define a handler to restart the service and notify the handler only when the configuration file changes:

- name: Ensure configuration file is present
 
src: config.conf
   
dest: /etc/config.conf
 
notify:
   
- restart service


- name: restart service
 
service:
   
name: myservice
   
state: restarted

In this example, the restart service handler is notified only when the configuration file is changed. This way, the service is restarted only when necessary, and not every time the playbook is run.

NOTE:

Handlers are executed only once, even if multiple tasks notify them. This means that if you have multiple tasks that notify the same handler, the handler will only be executed once, after the last task that notified it has been completed.

Ansible handlers provide a flexible and efficient way to manage the behavior of multiple tasks and ensure that only necessary actions are executed. They can be used to perform actions such as restarting services, reloading configurations, and more, and they are a crucial aspect of managing infrastructure with Ansible.

How are Facts done in Handlers?

Facts in Ansible refer to information gathered about the target system(s) before executing tasks. This information can be used to make decisions in playbooks and templates based on the current state of the target system(s).

In the context of handlers, facts can be used to determine if a handler should be executed or not. For example, you might want to restart a service only if a specific condition is met. To achieve this, you can use them when a keyword in the handler definition specifies a condition based on facts, and the handler will only be executed if the condition is True:

- name: restart service
 
service:
   
name: myservice
   
state: restarted
 
when: "'my service in ansible_services"

In this example, the handler will only be executed if the string 'myservice' is present in the ansible_services fact, which is a list of all services on the target system.

You can access facts by using the ansible_facts dictionary in your playbooks and templates. For example, if you want to access the hostname of the target system, you can use ansible_facts['hostname'].

Facts can be used in handlers to make decisions about whether a handler should be executed. By using facts, you can make your playbooks and templates more dynamic and adaptable to different environments and target systems.

Ansible Playbooks

Ansible Playbooks are files that define the automation jobs that Ansible should execute. They are written in YAML format and use a specific syntax and structure to define the tasks and actions that should be performed.

Handlers are a special type of task that can be included in Ansible Playbooks. They are used to perform tasks that should only be executed if a change has been made to the system, for example, restarting a service after a configuration file has been updated. Handlers are defined in the playbooks and can be triggered by other tasks using the "notify" directive. Handlers are executed at the end of the playbook run, regardless of whether they have changed the state of the system.

In Ansible Playbooks, handlers are defined as tasks, and their execution order is determined by the order in which they are defined in the playbook. Handlers can be called by multiple tasks, and once a handler has been notified, it will be executed only once, at the end of the playbook run.

Handlers are a powerful tool for managing the state of a system and ensuring that the correct actions are taken in response to changes. They can be used to perform actions such as restarting services, flushing firewall rules, or performing other system-level operations. When used effectively, they can greatly simplify the management and maintenance of systems, making it easier to automate and manage complex configurations.

Ansible-Pull

Ansible Pull is a method of running Ansible playbooks on a remote host, instead of running them from a centralized control machine, as is the typical method. In this mode, the remote host will periodically "pull" the playbook from a version control repository, such as Git, and execute it locally.

Handlers are a type of task in Ansible that are only executed if called, usually by other tasks. Handlers are defined in the playbooks and can be triggered by multiple tasks. Handlers are executed at the end of a playbook, after all, tasks have been completed, regardless of whether they have changed the state of the system.

When using Ansible Pull, handlers can be triggered just like any other task, however, it's important to note that handlers will only be executed on the host that is running Ansible Pull, and not on any other remote hosts that may have been managed by the playbook.

In general, Ansible Pull can be a useful method for distributing playbooks and making sure that remote hosts are kept in a desired state. It's often used in scenarios where a centralized control machine is not feasible, such as in small branch offices or on individual workstations. However, it's important to note that this method is less scalable and less secure compared to using a centralized control machine, as the playbooks are pulled and executed on each host individually.