Gestion des services avec Ansible

La gestion des services est une tâche quotidienne pour tout administrateur système. Que ce soit pour démarrer, arrêter, redémarrer ou vérifier l’état des services sur plusieurs serveurs, l’automatisation devient essentielle pour gagner du temps et éviter les erreurs humaines. C’est là qu’Ansible intervient, en fournissant des outils simples et puissants pour gérer efficacement ces services sur des systèmes Linux.

Dans ce guide, je vais te montrer comment utiliser les modules Ansible pour contrôler tes services de manière automatisée. Nous allons voir comment démarrer ou arrêter un service, vérifier son état et même comment redémarrer automatiquement un service lorsque sa configuration est modifiée. Nous utiliserons les modules principaux comme service et systemd_service, avec des exemples pratiques que tu pourras directement appliquer dans ton environnement.

Tu apprendras également à utiliser le module service_facts, qui te permet de récupérer des informations détaillées sur les services en cours d’exécution. Cela te permettra d’adapter tes tâches Ansible en fonction de l’état actuel des services, par exemple en démarrant un service uniquement s’il est arrêté.

Le module service

Le module ansible.builtin.service est l’un des plus utilisés pour gérer les services sur des systèmes basés sur Linux. Il permet d’effectuer des actions simples comme démarrer, arrêter, redémarrer ou vérifier l’état d’un service. Le module est conçu pour fonctionner avec des gestionnaires de services classiques comme SysVinit et Upstart. C’est un outil polyvalent qui peut être utilisé dans des environnements variés où systemd n’est pas nécessairement la norme.

Principales options du module ansible.builtin.service

Voici quelques-unes des principales options que tu peux utiliser avec le module ansible.builtin.service pour contrôler un service sur un serveur distant :

• name : le nom du service que tu veux gérer (par exemple, nginx, apache2, mysql).
• state : l’état dans lequel tu veux que le service se trouve. Les valeurs possibles sont :
  • started : démarrer le service.
  • stopped : arrêter le service.
  • restarted : redémarrer le service.
  • reloaded : recharger le service (souvent utilisé pour recharger la configuration sans arrêter complètement le service).
• enabled : indiquer si le service doit être activé ou désactivé au démarrage du système (true ou false).

Exemple d’utilisation basique

Voici un exemple simple pour démarrer le service nginx sur un serveur distant :

- name: Démarrer le service nginx
  ansible.builtin.service:
    name: nginx
    state: started

Dans cet exemple, Ansible vérifie si le service nginx est en cours d’exécution. Si ce n’est pas le cas, il le démarre. Si le service est déjà en marche, Ansible ne fait rien. Cela garantit une gestion idempotente, c’est-à-dire que l’état final du système sera toujours celui spécifié dans la tâche, sans répéter des actions inutiles.

Exemple avec l’activation automatique d’un service

Il est courant de vouloir qu’un service soit activé au démarrage du système. Avec l’option enabled, tu peux spécifier si le service doit démarrer automatiquement avec le système. Voici comment tu peux activer et démarrer nginx :

- name: Activer et démarrer le service nginx
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: true

Cet exemple assure que nginx est non seulement démarré immédiatement, mais qu’il sera également configuré pour se lancer automatiquement lors des futurs redémarrages du serveur.

Recharger la configuration d’un service

Parfois, après avoir modifié la configuration d’un service, tu n’as pas besoin de le redémarrer complètement, mais simplement de recharger sa configuration. C’est le cas pour des services comme nginx ou apache. L’option reloaded permet cela :

- name: Recharger la configuration de nginx
  ansible.builtin.service:
    name: nginx
    state: reloaded

Cela envoie un signal de rechargement au service, qui prendra en compte les changements de configuration sans nécessiter une interruption de service.

Cas d’usage typique : automatisation après mise à jour de configuration

Un cas d’usage fréquent avec Ansible est de redémarrer ou recharger un service automatiquement après la modification de son fichier de configuration. Voici un exemple où la configuration de nginx est mise à jour via un template et où le service est ensuite redémarré :

tasks:
  - name: Déployer le fichier de configuration nginx
    ansible.builtin.template:
      src: templates/nginx.conf.j2
      dest: /etc/nginx/nginx.conf
    notify: Redémarrer nginx

handlers:
  - name: Redémarrer nginx
    ansible.builtin.service:
      name: nginx
      state: restarted
    listen: Redémarrer nginx

Dans cet exemple, Ansible utilise un handler Ansible pour redémarrer automatiquement le service nginx uniquement si le fichier de configuration a été modifié. Cela permet de garantir que des redémarrages inutiles ne se produisent pas si la configuration reste inchangée.

Le module systemd_service

Le module ansible.builtin.systemd_service permet de gérer les unités systemd sur des systèmes Linux utilisant systemd. Il remplace l’ancien module systemd pour clarifier son rôle, tout en offrant des fonctionnalités similaires. Ce module te permet de démarrer, arrêter, redémarrer, recharger des services et bien plus encore, avec une gestion fine de l’activation automatique au démarrage, du masquage de services et du rechargement des démons systemd.

Principales options du module

• name : Spécifie le nom du service ou de l’unité à gérer, par exemple, nginx.service. Si aucune extension n’est fournie, .service est sous-entendu.
• state : Contrôle l’état du service. Les valeurs possibles sont :
  • started : démarrer le service s’il n’est pas déjà en cours d’exécution.
  • stopped : arrêter le service.
  • restarted : redémarrer le service, même s’il est déjà en marche.
  • reloaded : recharger la configuration sans arrêter le service.
• enabled : Définit si le service doit démarrer automatiquement au démarrage du système (true ou false).
• masked : Masque un service, le rendant impossible à démarrer manuellement ou automatiquement (true ou false).
• daemon_reload : Recharge les démons systemd pour prendre en compte des changements de configuration (true ou false).

Exemple d’utilisation basique

Voici un exemple pour démarrer le service nginx et le configurer pour qu’il soit activé au démarrage :

- name: Activer et démarrer le service nginx
  ansible.builtin.systemd_service:
    name: nginx.service
    state: started
    enabled: true

Dans cet exemple, Ansible démarre le service nginx s’il n’est pas déjà en cours d’exécution et l’active pour qu’il se lance automatiquement lors des prochains redémarrages du système.

Arrêter un service

Pour arrêter un service et désactiver son démarrage automatique :

- name: Arrêter et désactiver le service nginx
  ansible.builtin.systemd_service:
    name: nginx.service
    state: stopped
    enabled: false

Redémarrer un service avec rechargement du démon

Tu peux redémarrer un service et recharger systemd pour qu’il prenne en compte des changements de configuration avec daemon_reload :

- name: Redémarrer nginx et recharger systemd
  ansible.builtin.systemd_service:
    name: nginx.service
    state: restarted
    daemon_reload: true

Recharger la configuration d’un service

Si tu veux appliquer des changements de configuration sans redémarrer le service, tu peux utiliser reloaded :

- name: Recharger la configuration de nginx
  ansible.builtin.systemd_service:
    name: nginx.service
    state: reloaded

Masquer un service

Le masquage d’un service empêche son démarrage, même manuellement :

- name: Masquer le service nginx
  ansible.builtin.systemd_service:
    name: nginx.service
    masked: true

Le module sysvinit

Le module ansible.builtin.sysvinit permet de gérer les services sur des systèmes utilisant SysV init, un système d’initialisation plus ancien que systemd. Ce module est utile pour administrer des services sur des distributions Linux qui n’ont pas encore migré vers systemd. Il te permet de démarrer, arrêter, redémarrer et recharger des services, ainsi que de contrôler leur activation au démarrage.

Principales options du module

• name : Spécifie le nom du service à gérer. Ce paramètre est obligatoire.
• state : Définit l’état souhaité du service. Les valeurs possibles sont :
  • started : démarre le service s’il n’est pas déjà en cours d’exécution.
  • stopped : arrête le service.
  • restarted : redémarre le service en le stoppant et le redémarrant.
  • reloaded : recharge la configuration sans arrêter le service.
• enabled : Indique si le service doit être activé ou désactivé au démarrage du système (true ou false).
• daemonize : Si le service ne se détache pas correctement, cette option permet au module de le daemonize (true ou false).
• runlevels : Permet de définir les niveaux d’exécution où le service doit être activé ou désactivé. Cela remplace les paramètres par défaut du script init.
• sleep : Définit un délai (en secondes) entre l’arrêt et le redémarrage lors de l’utilisation de restarted ou reloaded. Cela aide à gérer les services qui peuvent mal se comporter.

Exemple d’utilisation

Voici un exemple pour démarrer le service apache2 et l’activer au démarrage du système :

- name: Assurer que le service apache2 est démarré
  ansible.builtin.sysvinit:
    name: apache2
    state: started
    enabled: true

Dans cet exemple, le service apache2 sera démarré s’il ne l’est pas déjà et il sera configuré pour se lancer automatiquement au démarrage.

Gestion des niveaux d’exécution

Si tu veux démarrer le service uniquement sur des niveaux d’exécution spécifiques, tu peux spécifier les runlevels :

- name: Démarrer apache2 sur les runlevels 3 et 5
  ansible.builtin.sysvinit:
    name: apache2
    state: started
    enabled: true
    runlevels:
      - 3
      - 5

Ce playbook garantit que apache2 sera démarré uniquement dans les niveaux d’exécution 3 et 5.

Le module service_facts

Le module ansible.builtin.service_facts est un outil extrêmement utile pour collecter des informations sur les services en cours d’exécution sur un système Linux. Contrairement aux autres modules qui agissent directement sur l’état des services (comme service ou systemd_service), service_facts se concentre sur la collecte d’informations, fournissant des faits sur les services, tels que leur état actuel, s’ils sont activés ou non au démarrage, ou encore s’ils sont masqués.

Ces informations peuvent ensuite être utilisées dans tes playbooks pour prendre des décisions basées sur l’état actuel des services, par exemple pour éviter de redémarrer un service déjà actif ou pour démarrer un service uniquement s’il est arrêté.

Le module service_facts collecte des données sur les services sous forme de facts Ansible. Ces facts sont stockés dans la variable ansible_facts.services, qui est un dictionnaire contenant des informations détaillées sur chaque service.

Les informations recueillies par service_facts sont stockées dans un dictionnaire organisé de la manière suivante :

ansible_facts:
  services:
    nginx.service:
      state: running
      enabled: true
      masked: false
    apache2.service:
      state: stopped
      enabled: false
      masked: false

Chaque entrée contient des détails comme :

• state : l’état actuel du service (par exemple, running, stopped).
• enabled : si le service est configuré pour démarrer automatiquement (true ou false).
• masked : si le service est masqué (true ou false).

Exemples d’utilisation

Le premier usage du module service_facts est simplement de récupérer les informations sur l’ensemble des services d’un hôte cible. Voici un exemple basique pour obtenir ces informations :

- name: Collecter les faits sur les services
  ansible.builtin.service_facts:

- name: Afficher l'état du service nginx
  ansible.builtin.debug:
    msg: "L'état de nginx est : {{ ansible_facts.services['nginx.service'].state }}"

Dans cet exemple, Ansible collecte d’abord les informations sur les services via service_facts, puis utilise une tâche debug pour afficher l’état du service nginx. La variable ansible_facts.services contient une entrée pour chaque service détecté sur le système. Tu peux y accéder en utilisant le nom complet du service, ici nginx.service.

L’un des avantages de service_facts est de permettre des actions conditionnelles basées sur l’état des services. Par exemple, tu peux décider de démarrer un service seulement s’il est arrêté :

- name: Collecter les faits sur les services
  ansible.builtin.service_facts:

- name: Démarrer nginx si le service est arrêté
  ansible.builtin.systemd_service:
    name: nginx.service
    state: started
  when: ansible_facts.services['nginx.service'].state != 'running'

Dans cet exemple, Ansible démarre nginx uniquement si le service n’est pas déjà en cours d’exécution, évitant ainsi un redémarrage inutile.

Tu peux également utiliser service_facts pour vérifier si un service est configuré pour démarrer automatiquement avec le système et le corriger si nécessaire :

- name: Collecter les faits sur les services
  ansible.builtin.service_facts:

- name: Activer nginx au démarrage si nécessaire
  ansible.builtin.systemd_service:
    name: nginx.service
    enabled: true
  when: ansible_facts.services['nginx.service'].enabled == false

Ce playbook vérifie si le service nginx est activé pour démarrer automatiquement. Si ce n’est pas le cas, il le configure pour qu’il soit activé au démarrage du système.

Conclusion

La gestion des services sur des systèmes Linux est un aspect essentiel de l’administration système et Ansible fournit des outils puissants pour automatiser ces tâches. Grâce aux modules ansible.builtin.service, ansible.builtin.systemd_service et ansible.builtin.sysvinit, il est possible de gérer des services sous différents systèmes d’initialisation, qu’il s’agisse de démarrer, arrêter, redémarrer ou configurer leur activation au démarrage.

Ces modules garantissent une gestion idempotente, ce qui signifie qu’Ansible effectuera les actions nécessaires uniquement si l’état du service ne correspond pas à ce qui est défini dans les tâches. Cette approche minimise les interventions inutiles et évite les interruptions de service intempestives.

Avec ces outils, l’administration des services devient plus simple, fiable et automatisée, permettant aux administrateurs de se concentrer sur d’autres tâches critiques tout en garantissant la stabilité et la disponibilité des systèmes.