Le déclenchement manuel des services après des changements peut être fastidieux et sujet à erreurs.
Oublier de redémarrer un service peut entraîner des dysfonctionnements ou des pertes de service, compromettant la fiabilité du système.
L’utilisation des handlers Ansible permet d’automatiser ces actions, assurant une réponse rapide et fiable aux changements de configuration.
Devenez un expert d'Ansible et simplifiez vos tâches d'administration.
En Ansible, les handlers sont des actions déclenchées en réponse à des événements spécifiques qui surviennent pendant l’exécution des playbooks.
Principe des Handlers Ansible
Les handlers en Ansible sont conçus pour répondre à des événements spécifiques et exécuter des actions en réaction à des changements ou des modifications dans l’environnement cible. Voici les principes clés des handlers :
- Déclenchement Sélectif :Les handlers sont déclenchés en réponse à des événements spécifiques, généralement après l’exécution de tâches qui modifient l’état du système. Par exemple, un handler pourrait être invoqué pour redémarrer un service après que sa configuration a été mise à jour.
- Référencé par Plusieurs Tâches :Un handler peut être référencé par plusieurs tâches dans un playbook Ansible. Cela permet de centraliser et de standardiser les actions à effectuer en réponse à un changement, assurant ainsi une cohérence dans la gestion des événements.
- Exécution Unique :Chaque handler est exécuté une seule fois par playbook, peu importe le nombre de fois où il est invoqué par les tâches. Cela garantit que les actions déclenchées en réponse à un événement ne sont pas répétées de manière inutile, ce qui est crucial pour maintenir la stabilité et la prévisibilité des opérations.
- Ordre d’Exécution :Les handlers sont exécutés dans un ordre prédéfini, tel qu’ils sont définis dans le playbook. Cela permet de contrôler la séquence dans laquelle les actions sont effectuées après la modification de l’état du système, assurant ainsi que les dépendances entre les différentes opérations sont respectées.
Voici un visuel explicatif pour clarifier ce principe :
Tâches du Playbook : Incluent des tâches qui peuvent notifier des handlers lorsqu’un changement est détecté.
Handlers : Tâches spéciales qui se déclenchent uniquement lorsqu’elles sont notifiées par d’autres tâches. Utilisées pour des actions comme le redémarrage de services.
Notification des Handlers : Les handlers sont appelés pour effectuer des actions lorsque leur nom est référencé dans les tâches.
Voici un exemple de contrôle de l’éxécution des handlers :
tasks:
- name: Some tasks go here
ansible.builtin.shell: ...
- name: Flush handlers
meta: flush_handlers
- name: Some other tasks
ansible.builtin.shell: ...
– name: Some tasks go here
Cette ligne définit une tâche nommée « Some tasks go here ».
ansible.builtin.shell: …
C’est un exemple générique de l’utilisation d’un module Ansible (ansible.builtin.shell dans ce cas) pour exécuter une commande shell sur les hôtes cibles. Le … représente ici la commande spécifique que nous souhaitons exécuter.
– name: Flush handlers
Cette tâche nommée » Flush handlers » est spécifique aux handlers. Elle utilise le module meta avec l’argument flush_handlers . Cette action est utilisée pour déclencher tous les handlers définis jusqu’à ce point dans le playbook. Le fonctionnement d’exécution de ces deux taches est similaire.
Variables dans Handlers Playbooks
L’utilisation de variables avec les handlers dans Ansible permet de rendre les playbooks plus flexibles et modulaires. Voici comment cela fonctionne :
- Écouter des sujets génériques (listen) :Dans Ansible, nous pouvons définir des sujets génériques à écouter (listen) pour déclencher des actions spécifiques. Par exemple, nous pourrions définir un sujet comme « restart web services » et configurer des handlers pour redémarrer tous les services web concernés lorsqu’ils sont notifiés de ce sujet.
Exemple.
handlers:
- name: Restart memcached
ansible.builtin.service:
name: memcached
state: restarted
listen: "restart web services"
- name: Restart apache
ansible.builtin.service:
name: apache
state: restarted
listen: "restart web services"
Nous avons utilisé le module service pour pouvoir exécuter ce playbook.
listen: « restart web services » : Cette ligne définit quel événement ou sujet ce handler écoute (listen). Dans cet exemple, le handler « Restart memcached » est configuré pour écouter le sujet générique « restart web services ». Cela signifie que lorsque ce sujet est notifié dans le playbook, ce handler sera déclenché pour redémarrer le service memcached.
– name: Restart apache : Définit un autre handler nommé » Restart apache « . Comme pour le handler précédent, il utilise le module ansible.builtin.service pour redémarrer le service Apache (name: apache) lorsque invoqué.
La deuxième tache fonctionne comme la première tâche.
- Notifier des sujets génériques (notify) :Pour déclencher des handlers à partir de différentes parties de votre playbook, vous utilisez notify. Cela permet de centraliser les actions à effectuer en réponse à des événements spécifiques, comme le redémarrage de services après des mises à jour de configuration ou des changements d’état des systèmes.
Exemple :
tasks:
- name: Restart everything
ansible.builtin.command: echo "this task will
restart the web services"
notify: "restart web services"
ansible.builtin.command:
C’est le module Ansible utilisé pour exécuter des commandes shell sur les hôtes cibles. Il permet d’effectuer des opérations directes via la ligne de commande.
notify: « restart web services » : Cette ligne spécifie que lorsque la tâche » Restart everything » est exécutée avec succès, elle notifie le sujet (ou handler) » restart web services « . Cela signifie que le sujet « restart web services » sera déclenché, et tous les handlers associés à ce sujet seront exécutés.
Pratique des Handlers Ansible
Dans cette pratique, nous allons élaborer un playbook pour notifier le redémarrage d’Apache2 sur notre nœud distant Ubuntu. Voici le playbook:
---
- name: Example playbook with handlers
hosts: noeudG
become: yes
tasks:
- name: Copy Apache configuration file
ansible.builtin.copy:
src: /etc/ansible/httpd.config
dest: /etc/apache2/apache2.conf
remote_src: yes
notify: restart apache
- name: Install Apache package
ansible.builtin.apt:
name: apache2
state: present
notify: restart apache
handlers:
- name: restart apache
ansible.builtin.service:
name: apache2
state: restarted
Ce playbook permet de copier un fichier de configuration Apache ( httpd.config) depuis /etc/ansible sur l’hôte Ansible vers /etc/apache2/apache2.conf sur l’hôte distant ( noeudG : nous avons spécifier l’hôte car nous avons deux nœuds dans l’inventaire). Ensuite, il installe le paquet Apache ( apache2 ) sur cet hôte. À la fin de chaque tâche (Copy Apache configuration file et Install Apache package), le handler restart apache est déclenché pour s’assurer que le service Apache redémarre afin d’appliquer les configurations ou les mises à jour nécessaires.
Pour exécuter ce playbook, il faut le copier dans un fichier handler.yml et exécuter avec la commande : ansible-playbook -i inventory.yaml playbook.yml –become et nous avons le résultat comme ceci.
Bravo, nous avons nos résultats attendus. Cela confirme que les tâches du playbook ont été exécutées avec succès. Nous pouvons vérifier ce résultat dans le nœud géré en tapant la commande : sudo systemctl status apache2 , cette commande notifie le statut d’apache2 .
Parfait, tout fonctionne bien maintenant.
Formez-vous gratuitement avec Alphorm !
Maîtrisez les compétences clés en IT grâce à nos formations gratuites et accélérez votre carrière dès aujourd'hui.
FAQ
Qu'est-ce qu'un handler en Ansible ?
Comment fonctionnent les handlers dans Ansible ?
Quelle est l'utilité des variables avec les handlers ?
Comment notifier un handler dans un playbook Ansible ?
Quelle est la structure d'un playbook avec des handlers ?
Conclusion
Les handlers sont essentiels pour une gestion efficace des playbooks Ansible. Comment pourriez-vous utiliser ces principes pour optimiser vos propres configurations système ?
