S'assure que le service Nginx est démarré et activé au démarrage système

La gestion des services : une étape cruciale post-installation

Après avoir installé un logiciel serveur comme Nginx (ou Apache), il ne suffit pas qu'il soit présent sur le disque. Pour qu'il soit fonctionnel, son service doit être en cours d'exécution. De plus, pour assurer la disponibilité continue de votre application web, il est essentiel que ce service soit configuré pour démarrer automatiquement à chaque redémarrage du système.

Ansible excelle dans la gestion de l'état des services grâce à des modules dédiés. Cette partie de notre playbook se concentre sur l'utilisation de ces modules pour garantir que le service Nginx (ou celui du serveur web que vous avez choisi) est non seulement démarré (started) mais aussi activé pour le démarrage système (enabled).

Comme l'installation, la gestion des services requiert généralement des privilèges administratifs, donc la directive become: true sera nécessaire si elle n'est pas déjà définie au niveau du jeu (play).

Utilisation du module `ansible.builtin.service`

Le module ansible.builtin.service est un module polyvalent conçu pour interagir avec le système d'initialisation du noeud géré (qu'il s'agisse de systemd, SysVinit, Upstart, etc.). Il permet de contrôler l'état des services de manière abstraite.

Pour s'assurer que le service Nginx est démarré et activé, la tâche Ansible sera la suivante :

- name: S'assurer que le service Nginx est démarré et activé
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: yes

Décortiquons les paramètres clés :

• name: nginx : Spécifie le nom du service tel qu'il est connu par le système d'initialisation. Pour Apache sur Debian/Ubuntu, ce serait apache2. Pour Apache sur CentOS/RHEL, ce serait httpd.
• state: started : C'est l'état désiré pour le service. Si le service Nginx est arrêté, Ansible le démarrera. S'il est déjà en cours d'exécution, Ansible ne fera rien. D'autres états possibles incluent stopped, restarted, reloaded.
• enabled: yes : Ce paramètre booléen indique si le service doit être configuré pour démarrer automatiquement au boot. Si yes, Ansible s'assurera qu'il est activé. Si no, il s'assurera qu'il est désactivé.

L'idempotence est ici encore fondamentale. Si vous exécutez cette tâche plusieurs fois et que le service est déjà démarré et activé, Ansible ne fera aucune modification et la tâche sera marquée comme ok.

Alternative avec le module `ansible.builtin.systemd`

Si vous savez que tous vos noeuds gérés utilisent systemd comme système d'initialisation (ce qui est le cas pour la plupart des distributions Linux modernes), vous pouvez utiliser le module ansible.builtin.systemd. Ce module offre un contrôle plus direct et parfois plus d'options spécifiques à systemd.

La tâche équivalente pour gérer le service Nginx serait :

- name: S'assurer que le service Nginx est démarré et activé (avec systemd)
  ansible.builtin.systemd:
    name: nginx
    state: started
    enabled: yes
    daemon_reload: yes # Optionnel: utile si vous avez modifié des unit files systemd

Le module ansible.builtin.systemd partage les mêmes paramètres name, state, et enabled que le module service pour les cas d'usage courants. Il ajoute des fonctionnalités comme daemon_reload: yes, qui est utile si votre playbook modifie des fichiers de configuration des unités systemd (par exemple, /etc/systemd/system/nginx.service), car cela force systemd à relire sa configuration.

Pour la plupart des cas simples de démarrage et d'activation d'un service, le module ansible.builtin.service est suffisant et plus portable si vous avez un parc hétérogène de systèmes d'initialisation. Cependant, si vous avez besoin de fonctionnalités spécifiques à systemd, le module ansible.builtin.systemd est le bon choix.

Intégration dans le Playbook et importance de l'ordre

Cette tâche de gestion du service doit logiquement suivre la tâche d'installation du serveur web. Il est impossible de démarrer un service qui n'est pas encore installé.

Voici comment elle s'insère dans la séquence des tâches de notre playbook de déploiement :

- hosts: webservers
  become: true
  vars:
    web_server_package: nginx # ou apache2/httpd selon le choix
    web_server_service: nginx # ou apache2/httpd
  tasks:
    - name: Installer le serveur web {{ web_server_package }}
      ansible.builtin.package:
        name: "{{ web_server_package }}"
        state: present
        update_cache: yes
      # ... (conditions 'when' pour update_cache si nécessaire)

    - name: S'assurer que le service {{ web_server_service }} est démarré et activé
      ansible.builtin.service:
        name: "{{ web_server_service }}"
        state: started
        enabled: yes

    # ... autres tâches (copie de la page d'accueil, etc.)

Dans cet exemple, nous avons utilisé des variables (web_server_package et web_server_service) pour rendre le playbook facilement adaptable si l'on décide de changer de serveur web. Ces variables seraient définies au niveau du jeu ou dans un fichier de variables séparé.

En s'assurant que le service est démarré et activé, Ansible garantit que, dès la fin de l'exécution du playbook, votre serveur web est non seulement prêt à servir du contenu mais qu'il le restera même après un redémarrage du serveur. C'est une étape essentielle pour la fiabilité de toute application web.