Démystifier les gestionnaires Ansible : garantir des redémarrages de service idempotents
Apprenez comment les handlers Ansible redémarrent ou rechargent les services uniquement lorsque les tâches changent, avec des exemples pour les playbooks, les rôles et le vidage des handlers.
Démystifier les Handlers Ansible : Assurer des Redémarrages de Services Idempotents
Les handlers Ansible résolvent un problème courant de déploiement : votre fichier de configuration peut être vérifié à chaque exécution, mais votre service ne doit redémarrer que lorsque ce fichier change réellement. Sans handlers, votre playbook peut redémarrer des services sains sans raison.
Ce guide explique comment fonctionnent les handlers, où les définir et quand les vider tôt. Les exemples utilisent des services web, mais le même modèle fonctionne pour les workers d'applications, les planificateurs et les démons système.
Que sont les Handlers Ansible ?
Dans Ansible, un handler est une tâche qui s'exécute uniquement après qu'une autre tâche l'a notifié. Lorsqu'une tâche modifie quelque chose et inclut notify, Ansible met en file d'attente le handler correspondant.
Caractéristiques clés des handlers :
- Déclenché par notification : Un handler s'exécute lorsqu'une tâche modifiée utilise
notify. - Exécuté une fois par play : Si cinq tâches notifient le même handler, Ansible l'exécute toujours une fois à la fin du play.
- Idéal pour les redémarrages et rechargements : Les handlers sont parfaits pour les actions de service qui ne doivent se produire qu'après des modifications de configuration.
Pourquoi utiliser des Handlers pour les Redémarrages de Services ?
Le cas d'utilisation principal des handlers Ansible est la gestion des services. Lorsque vous mettez à jour un fichier de configuration Apache, Nginx ou d'application, le service nécessite souvent un redémarrage ou un rechargement. Vous ne voulez cette action que lorsque le fichier déployé diffère du fichier actuel.
Considérez l'alternative :
- Sans handlers : Une tâche de redémarrage direct s'exécute à chaque fois que le playbook l'atteint, sauf si vous ajoutez des conditions supplémentaires.
- Avec handlers : La tâche de template ou de copie notifie un redémarrage uniquement lorsqu'elle signale
changed.
Par exemple, un playbook Nginx de production peut s'exécuter toutes les heures pour corriger la dérive de configuration. Avec les handlers, les fichiers de configuration inchangés n'entraînent pas de rechargements horaires.
Comment implémenter les Handlers Ansible
Les handlers résident dans une section handlers d'un playbook ou dans handlers/main.yml à l'intérieur d'un rôle. Le nom du handler doit correspondre au nom utilisé par notify.
Syntaxe de base du Handler
Les handlers sont déclarés dans un bloc handlers au niveau du playbook ou dans un rôle.
---
- name: Configurer et redémarrer le serveur web
hosts: webservers
become: yes
tasks:
- name: Assurer que la configuration Apache est présente
template:
src: templates/httpd.conf.j2
dest: /etc/httpd/conf/httpd.conf
notify:
- Redémarrer Apache
handlers:
- name: Redémarrer Apache
service:
name: httpd
state: restarted
Dans cet exemple :
- Une tâche
templateest utilisée pour déployer un nouveau fichier de configuration Apache (httpd.conf). - Le mot-clé
notifyest défini surRedémarrer Apache. Cela signifie que si la tâchetemplatemodifie avec succès le fichierhttpd.conf, Ansible signalera le handler nomméRedémarrer Apache. - La section
handlersdéfinit le handlerRedémarrer Apache, qui utilise le moduleservicepour redémarrer le servicehttpd.
Notifier plusieurs Handlers
Une seule tâche peut notifier plusieurs handlers. Cela est utile si la modification d'une configuration nécessite le redémarrage de plusieurs services ou l'exécution de plusieurs actions de nettoyage.
---
- name: Déployer l'application avec les mises à jour de la base de données et du serveur web
hosts: app_servers
become: yes
tasks:
- name: Mettre à jour la configuration de l'application
copy:
src: files/app.conf
dest: /etc/app/app.conf
notify:
- Redémarrer le service d'application
- Recharger Nginx
handlers:
- name: Redémarrer le service d'application
service:
name: myapp
state: restarted
- name: Recharger Nginx
service:
name: nginx
state: reloaded
Dans ce scénario, si app.conf est mis à jour, les handlers Redémarrer le service d'application et Recharger Nginx seront tous deux déclenchés.
Utiliser les Handlers dans les Rôles
Les handlers sont couramment utilisés dans les rôles Ansible. Ils sont définis dans le fichier handlers/main.yml d'un rôle. Lorsqu'une tâche dans le rôle (ou d'un playbook qui inclut le rôle) notifie un handler défini dans le rôle, Ansible l'exécutera.
Supposons que vous ayez un rôle nommé apache avec la structure suivante :
apache/
├── handlers/
│ └── main.yml
└── tasks/
└── main.yml
apache/tasks/main.yml :
---
- name: Déployer la configuration Apache
template:
src: httpd.conf.j2
dest: /etc/httpd/conf/httpd.conf
notify:
- Redémarrer Apache
apache/handlers/main.yml :
---
- name: Redémarrer Apache
service:
name: httpd
state: restarted
Ensuite, dans votre playbook, vous incluriez le rôle :
---
- name: Configurer le serveur web en utilisant le rôle Apache
hosts: webservers
become: yes
roles:
- apache
Lorsque la tâche Déployer la configuration Apache dans le rôle apache s'exécute et modifie la configuration, le handler Redémarrer Apache défini dans apache/handlers/main.yml sera déclenché.
Meilleures pratiques pour l'utilisation des Handlers
- Gardez chaque handler concentré sur une seule action.
- Utilisez des noms qui correspondent à l'action, comme
Recharger Nginx. - Préférez
state: reloadedlorsque le service prend en charge les rechargements et qu'un redémarrage complet n'est pas nécessaire. - Évitez les tâches de redémarrage direct après les tâches de configuration.
- N'oubliez pas que les handlers notifiés s'exécutent à la fin du play, sauf si vous les videz.
Concepts avancés : Vider les Handlers
Par défaut, les handlers s'exécutent une fois à la fin d'un play. Parfois, vous avez besoin d'un redémarrage avant que les tâches suivantes ne continuent. Par exemple, vous devrez peut-être redémarrer une application après avoir écrit sa configuration principale avant d'exécuter une vérification de santé ou une migration.
---
- name: Effectuer des mises à jour de configuration séquentielles nécessitant des redémarrages de service immédiats
hosts: servers
become: yes
tasks:
- name: Mettre à jour le fichier de configuration principal
copy:
src: files/primary.conf
dest: /etc/myapp/primary.conf
notify:
- Redémarrer Myapp
- name: Vider les handlers pour appliquer le redémarrage immédiat
meta: flush_handlers
- name: Mettre à jour le fichier de configuration secondaire
copy:
src: files/secondary.conf
dest: /etc/myapp/secondary.conf
notify:
- Redémarrer Myapp
handlers:
- name: Redémarrer Myapp
service:
name: myapp
state: restarted
Ici, la première modification de configuration déclenche Redémarrer Myapp, et meta: flush_handlers l'exécute immédiatement. Une tâche ultérieure peut notifier à nouveau le même handler si elle modifie un autre fichier.
Quand consulter un professionnel
Demandez une révision lorsqu'un handler redémarre des bases de données de production, des équilibreurs de charge ou des services en cluster. Certains systèmes nécessitent des redémarrages progressifs, des vérifications de quorum ou des étapes de vidange qui ne doivent pas être cachées derrière un simple handler.
À retenir
Utilisez les handlers Ansible chaque fois qu'une tâche modifiée doit déclencher un redémarrage de service, un rechargement ou un rechargement de démon. Ils maintiennent vos playbooks idempotents, réduisent les redémarrages inutiles et facilitent la compréhension des modifications de service.