Introduction
Les handlers sont des tâches Ansible spéciales qui ne s'exécutent que lorsqu'elles sont notifiées par une tâche ayant entraîné un changement. Ils sont couramment utilisés pour recharger ou redémarrer des services.
Dans ce laboratoire, vous déploierez une unité systemd de démonstration sécurisée, notifierez les handlers lorsque le fichier d'unité est modifié, et vérifierez que le service est bien actif et activé.
Créer un projet d'automatisation de service
Dans cette étape, vous allez créer un projet pour l'automatisation de services. Ce laboratoire utilise un alias d'hôte local car le service représente un état réel du système sur la machine virtuelle RHEL 10.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,files,playbooks,reports}
cd rhce-ansible
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
EOF
cat > inventory/hosts <<'EOF'
[service_hosts]
host ansible_connection=local
EOF
Même avec une connexion locale, le playbook gérera l'état réel de systemd sur la machine virtuelle. C'est pourquoi ce laboratoire utilise un alias d'hôte unique et become: true plus tard, plutôt que de simuler plusieurs hôtes de service indépendants.
Créer un fichier d'unité systemd de démonstration
Dans cette étape, vous allez créer le fichier d'unité source qu'Ansible copiera dans /etc/systemd/system. Le service exécute /usr/bin/sleep infinity, ce qui le rend sûr et facile à vérifier.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible. Cela garantit la stabilité des commandes, même si LabEx exécute chaque étape séparément.
cd /home/labex/project/rhce-ansible
cat > files/rhce-handler-demo.service <<'EOF'
[Unit]
Description=RHCE handler demo service
[Service]
Type=simple
ExecStart=/usr/bin/sleep infinity
Restart=always
RestartSec=1
[Install]
WantedBy=multi-user.target
EOF
Cette unité est volontairement inoffensive : elle démarre un processus sleep de longue durée et le redémarre s'il s'arrête. La section [Install] permet à Ansible d'activer le service pour multi-user.target.
sed -n "1,12p" files/rhce-handler-demo.service
Vérifiez les lignes ExecStart et WantedBy avant de continuer. Si le fichier d'unité source est incorrect, Ansible déploiera fidèlement une définition de service erronée.
Écrire un playbook avec des handlers
Dans cette étape, vous allez rédiger un playbook qui copie le fichier d'unité et notifie les handlers. La tâche meta: flush_handlers exécute les handlers en attente avant la tâche de service, afin que systemd prenne en compte la nouvelle unité.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
cat > playbooks/manage-service.yml <<'EOF'
---
- name: Deploy and manage the demo service
hosts: service_hosts
become: true
gather_facts: false
tasks:
- name: Install demo systemd unit
ansible.builtin.copy:
src: ../files/rhce-handler-demo.service
dest: /etc/systemd/system/rhce-handler-demo.service
mode: '0644'
notify:
- Reload systemd
- Restart demo service
- name: Run handlers before enabling the service
ansible.builtin.meta: flush_handlers
- name: Ensure demo service is active and enabled
ansible.builtin.systemd:
name: rhce-handler-demo.service
state: started
enabled: true
handlers:
- name: Reload systemd
ansible.builtin.systemd:
daemon_reload: true
- name: Restart demo service
ansible.builtin.systemd:
name: rhce-handler-demo.service
state: restarted
EOF
La tâche copy ne notifie les deux handlers que lorsque le fichier d'unité est modifié. meta: flush_handlers exécute tous les handlers en attente avant que la tâche systemd ne démarre et n'active le service, ce qui est crucial car systemd doit recharger les fichiers d'unité avant de reconnaître un nouveau service.
ansible-playbook playbooks/manage-service.yml --syntax-check
La vérification de syntaxe doit réussir avant que le playbook n'écrive dans /etc/systemd/system. Elle permet de détecter les erreurs d'indentation dans la liste des tâches et dans la section handlers sans modifier l'état du service.
Exécuter le playbook et vérifier le service
Dans cette étape, vous allez exécuter le playbook du service. La première exécution doit installer l'unité, recharger systemd, démarrer le service et l'activer au démarrage. Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/manage-service.yml | tee reports/service-first-run.txt
La première exécution doit copier le fichier d'unité, recharger systemd, redémarrer le service de démonstration via le handler, puis s'assurer que le service est activé. Enregistrer la sortie vous permet de vérifier si le chemin du handler a été exécuté.
systemctl is-active rhce-handler-demo.service
systemctl is-enabled rhce-handler-demo.service
is-active vérifie l'état d'exécution pour le démarrage actuel, tandis que is-enabled vérifie si le service est lié à une cible de démarrage. Les tâches de service RHCE nécessitent souvent les deux.
Modifier le fichier d'unité et déclencher à nouveau le handler
Dans cette étape, vous allez effectuer une modification contrôlée du fichier d'unité source. Lorsque la tâche de copie détectera le changement, elle notifiera à nouveau les handlers. Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Le module lineinfile peut également modifier des fichiers locaux via une commande ad hoc. Ici, il ne modifie qu'une seule ligne dans l'unité source.
ansible localhost -c local -m ansible.builtin.lineinfile -a 'path=files/rhce-handler-demo.service regexp=^RestartSec= line=RestartSec=3'
Cela modifie le fichier source, et non l'unité installée sous /etc/systemd/system. La prochaine exécution du playbook devrait détecter le changement de la source, copier l'unité mise à jour et notifier à nouveau les handlers.
ansible-playbook playbooks/manage-service.yml | tee reports/service-second-run.txt
grep -F RestartSec /etc/systemd/system/rhce-handler-demo.service
L'unité installée devrait maintenant afficher RestartSec=3. Le service doit rester actif et activé, car les handlers ont rechargé systemd et redémarré le service de démonstration après la modification du fichier.
Résumé
Vous avez déployé une unité systemd sécurisée, utilisé des handlers pour le rechargement de systemd et le redémarrage du service, vérifié l'état actif et activé du service, et déclenché le handler par une modification contrôlée du fichier d'unité.
