Module `service` ou `systemd` : gérer l'état des services

La gestion des services : un pilier de l'administration système automatisée

Les services, ou démons, sont des programmes qui s'exécutent en arrière-plan pour fournir des fonctionnalités essentielles au système d'exploitation ou aux applications. La capacité à démarrer, arrêter, redémarrer, recharger leur configuration, et contrôler leur activation au démarrage du système est une tâche fondamentale pour tout administrateur. Ansible simplifie et automatise ces opérations grâce à des modules dédiés.

Historiquement, différentes distributions Linux ont utilisé divers systèmes d'initialisation (init systems) comme System V init, Upstart. Plus récemment, Systemd est devenu le standard de facto pour la majorité des distributions modernes (Debian, Ubuntu, RHEL/CentOS 7+, Fedora, SUSE, etc.). Ansible propose le module générique service qui tente de détecter le système d'init sous-jacent et d'agir en conséquence. Pour un contrôle plus fin et spécifique à Systemd, le module systemd est souvent préféré sur les systèmes compatibles.

Ces modules sont idempotents : demander de démarrer un service déjà en cours d'exécution n'entraînera aucune action, de même pour l'arrêt d'un service déjà arrêté. Cela garantit que vos playbooks maintiennent l'état désiré des services de manière fiable et efficace.

Le module générique `service` : une interface unifiée

Le module service a pour objectif de fournir une interface commune pour la gestion des services, quel que soit le système d'init utilisé par le noeud géré. Il essaie d'utiliser l'outil approprié (systemctl pour systemd, update-rc.d/invoke-rc.d pour System V sur Debian, chkconfig/service pour System V sur RHEL, etc.).

Principaux paramètres du module service :

• name : (Chaîne de caractères, requis) Le nom du service à gérer (ex: nginx, sshd, apache2, crond).
• state : (Chaîne de caractères) L'état désiré pour le service. Valeurs courantes :
  • started : S'assure que le service est démarré et en cours d'exécution.
  • stopped : S'assure que le service est arrêté.
  • restarted : Arrête puis redémarre le service. Utile après une modification de configuration qui nécessite un redémarrage complet.
  • reloaded : Demande au service de recharger sa configuration sans interrompre son fonctionnement. Tous les services ne supportent pas cette action. Si le service ne le supporte pas, cette action peut échouer ou être équivalente à un redémarrage.
• enabled : (Booléen, yes/no) Contrôle si le service est activé pour démarrer automatiquement au lancement du système. yes l'active, no le désactive. Ce paramètre ne change pas l'état actuel du service (démarré/arrêté), seulement son comportement au prochain boot.
• arguments (ou args) : (Chaîne de caractères) Permet de passer des arguments supplémentaires à la commande de gestion du service. Son utilisation est moins fréquente et dépend du système d'init.
• runlevel : (Chaîne de caractères) Spécifique à certains systèmes d'init plus anciens (comme System V) pour indiquer le runlevel. Généralement non nécessaire avec Systemd.
• pattern : (Chaîne de caractères) Utilisé dans certains cas pour identifier un service si son nom n'est pas exact (par exemple, pour vérifier via ps). Usage rare.

Exemple : S'assurer que le service Nginx est démarré et activé au démarrage sur un serveur web.

- name: Démarrer et activer Nginx
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: yes

Cette tâche utilisera systemctl start nginx et systemctl enable nginx sur un système Systemd, ou les commandes équivalentes sur d'autres systèmes d'init.

Le module `systemd` : contrôle précis pour les systèmes modernes

Pour les systèmes utilisant Systemd, le module systemd offre un contrôle plus direct et plus riche que le module service générique. Il interagit directement avec l'API D-Bus de Systemd ou via la commande systemctl.

Le module systemd partage de nombreux paramètres avec le module service (name, state, enabled), mais en ajoute d'autres spécifiques à Systemd :

• daemon_reload : (Booléen, défaut: no) Si yes, exécute systemctl daemon-reload avant d'effectuer l'action sur le service. C'est nécessaire si vous avez modifié un fichier unit de Systemd (par exemple, via le module copy ou template) pour que Systemd prenne en compte les changements.
• masked : (Booléen) Si yes, le service est "masqué" (systemctl mask ), ce qui le rend impossible à démarrer, même manuellement ou en tant que dépendance d'un autre service. Un service masqué est lié à /dev/null. Si no, le service est démasqué.
• scope : (Chaîne de caractères) Permet de spécifier une unité Systemd non-service (ex: une unité de type scope, slice, target).
• no_block : (Booléen, défaut: no) Si yes, la commande systemctl est exécutée de manière asynchrone sans attendre sa complétion.
• force : (Booléen, défaut: no) Force certaines opérations, par exemple pour arrêter une unité qui a des dépendances.

Exemple : Recharger la configuration d'un service après avoir modifié son fichier unit.

- name: Copier un nouveau fichier unit pour myapp.service
  ansible.builtin.template:
    src: myapp.service.j2
    dest: /etc/systemd/system/myapp.service
  notify: Reload systemd and restart myapp

# ... dans les handlers ...
- name: Reload systemd and restart myapp
  listen: "Reload systemd and restart myapp"
  block:
    - name: Recharger la configuration de Systemd
      ansible.builtin.systemd:
        daemon_reload: yes
    - name: Redémarrer le service myapp
      ansible.builtin.systemd:
        name: myapp
        state: restarted

Dans cet exemple, si le fichier unit est modifié, un handler est notifié. Ce handler recharge d'abord la configuration de Systemd avec daemon_reload: yes, puis redémarre le service.

Exemple : Masquer le service avahi-daemon.

- name: Masquer le service Avahi
  ansible.builtin.systemd:
    name: avahi-daemon
    masked: yes
    # state: stopped # Optionnel, pour s'assurer qu'il est aussi arrêté
    # enabled: no    # Optionnel, pour le désactiver aussi au démarrage

Quand utiliser `service` vs `systemd` et bonnes pratiques

Choix du module :

• Si vous gérez une infrastructure hétérogène avec différents systèmes d'init et que vous avez besoin de portabilité, le module service est un bon choix pour les opérations de base (start, stop, enable, disable).
• Si tous vos noeuds gérés utilisent Systemd (ce qui est le cas pour la plupart des environnements Linux modernes), il est généralement préférable d'utiliser le module systemd. Il offre un contrôle plus fin, des fonctionnalités spécifiques à Systemd (comme daemon_reload, masked), et est souvent plus direct et potentiellement plus performant car il évite la couche d'abstraction.

Bonnes pratiques :

• Idempotence : Faites confiance à l'idempotence de ces modules. N'ajoutez pas de conditions superflues pour vérifier si un service est déjà démarré avant de demander son démarrage.
• Handlers pour le redémarrage/rechargement : Lorsque la configuration d'un service est modifiée (par exemple, avec les modules copy, template, lineinfile), utilisez des handlers Ansible pour déclencher le redémarrage (restarted) ou le rechargement (reloaded) du service. Cela garantit que le service n'est relancé que si sa configuration a effectivement changé.
• daemon_reload avec systemd : N'oubliez pas d'utiliser daemon_reload: yes (souvent dans un handler, avant de redémarrer le service) si vous modifiez les fichiers unit de Systemd.
• enabled vs state : Comprenez bien la différence. enabled: yes assure que le service démarrera au prochain boot, mais ne le démarre pas immédiatement. state: started démarre le service maintenant, mais ne garantit pas qu'il démarrera au prochain boot (sauf si enabled: yes est aussi spécifié). Il est courant d'utiliser les deux ensemble :

- name: S'assurer que cron est démarré et activé
  ansible.builtin.systemd: # ou ansible.builtin.service
    name: cron # ou crond selon la distribution
    state: started
    enabled: yes

• Utilisation de reloaded avec précaution : Tous les services ne supportent pas correctement le rechargement de configuration. Testez attentivement. Si un service ne supporte pas reloaded ou si vous n'êtes pas sûr, un restarted est souvent plus sûr, bien que potentiellement plus disruptif.

En maîtrisant les modules service et systemd, vous pouvez gérer avec assurance l'état de tous les services de votre infrastructure, une composante essentielle de toute stratégie d'automatisation et de gestion de configuration robuste.