Etape 2 : Ecrire un playbook qui :

Objectif du Playbook : un déploiement web complet

Maintenant que notre fichier index.html est prêt localement (Etape 1), l'objectif de cette deuxième étape est de construire le coeur de notre automatisation : un playbook Ansible. Ce playbook sera responsable de transformer un serveur cible (un de nos noeuds gérés) en un serveur web fonctionnel capable de servir notre page d'accueil.

Pour atteindre cet objectif, notre playbook devra accomplir séquentiellement plusieurs actions clés :

1. Installer le serveur web Nginx : S'assurer que Nginx est présent sur le noeud géré. S'il ne l'est pas, Ansible devra l'installer.
2. Gérer le service Nginx : Une fois Nginx installé, il faut s'assurer que son service est démarré et qu'il est configuré pour se lancer automatiquement au démarrage du système.
3. Déployer la page d'accueil : Copier le fichier index.html que nous avons créé de notre noeud de contrôle vers le répertoire approprié sur le serveur web distant.

Ce playbook illustrera l'utilisation de plusieurs modules Ansible fondamentaux et la manière de structurer un ensemble de tâches pour réaliser un déploiement complet.

Nous allons détailler chaque partie de ce playbook, en expliquant les modules utilisés et leurs paramètres. Supposons que ce playbook sera nommé deploy_nginx_site.yml et qu'il sera placé à la racine de notre projet, au même niveau que le répertoire files contenant notre index.html.

Structure initiale du Playbook et ciblage des hôtes

Tout playbook Ansible commence par définir à quels hôtes il s'applique et peut inclure des paramètres globaux pour le "jeu" (play). Notre playbook ciblera un groupe d'hôtes spécifiques de notre inventaire (par exemple, webservers) ou un hôte unique si nous testons sur une seule machine.

---
- name: Déployer un site Nginx avec une page d'accueil
  hosts: webservers # Ou le nom d'un hôte spécifique, ex: node1
  become: true      # La plupart des actions nécessiteront des privilèges root (sudo)
  vars:
    nginx_doc_root_debian: /var/www/html
    nginx_doc_root_redhat: /usr/share/nginx/html
    nginx_user_debian: www-data
    nginx_user_redhat: nginx

  tasks:
    # Les tâches seront définies ici

Analysons cette structure :

• --- : Début du document YAML.
• - name: Déployer un site Nginx... : Nom descriptif du jeu.
• hosts: webservers : Cible les hôtes du groupe webservers (à adapter selon votre inventaire).
• become: true : Demande à Ansible d'utiliser une élévation de privilèges pour toutes les tâches de ce jeu.
• vars: : Section où nous définissons quelques variables pour rendre le playbook plus adaptable. Nous définissons les chemins du document root de Nginx et les utilisateurs/groupes typiques pour les familles Debian et RedHat. Cela nous aidera à rendre les tâches de copie de fichiers plus portables.
• tasks: : Marque le début de la liste des actions à effectuer.

Tâche 1 : Installer Nginx

La première tâche concrète est d'installer Nginx. Nous utiliserons le module ansible.builtin.package pour sa portabilité, mais nous pourrions aussi utiliser ansible.builtin.apt ou ansible.builtin.yum/ansible.builtin.dnf si nous ciblions une famille d'OS spécifique.

# Suite de la section tasks:
    - name: Installer Nginx
      ansible.builtin.package:
        name: nginx
        state: present
        update_cache: yes # Essentiel pour les systèmes basés sur apt avant une installation
      # Note: update_cache est principalement pertinent pour 'apt'.
      # Le module 'package' essaie d'être intelligent, mais pour 'apt' c'est une bonne pratique.
      # Pour yum/dnf, 'update_cache' peut ne pas avoir d'effet ou être géré différemment.

Cette tâche s'assure que le paquet nginx est à l'état present (installé). L'option update_cache: yes est particulièrement importante pour les gestionnaires de paquets comme apt (utilisé sur Debian/Ubuntu) pour s'assurer que la liste locale des paquets est à jour avant de tenter l'installation. Pour yum ou dnf (utilisés sur RHEL/CentOS/Fedora), le module package gère cela un peu différemment, mais inclure update_cache ne cause généralement pas de problème et peut être conditionné avec une clause when: ansible_os_family == "Debian" si l'on veut être très précis.

Tâche 2 : S'assurer que le service Nginx est démarré et activé

Une fois Nginx installé, il faut que son service soit en cours d'exécution et qu'il soit configuré pour démarrer automatiquement si le serveur redémarre. Le module ansible.builtin.service est utilisé pour cela.

# Suite de la section tasks:
    - name: S'assurer que Nginx est démarré et activé au boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes

Ici :

• name: nginx : Spécifie le nom du service.
• state: started : Assure que le service est démarré. S'il est arrêté, Ansible le démarrera.
• enabled: yes : Assure que le service est activé pour démarrer au boot.

Tâche 3 : Copier le fichier index.html

C'est ici que nous déployons notre contenu. Nous utilisons le module ansible.builtin.copy. Grâce aux variables définies plus tôt, nous pouvons rendre cette tâche plus adaptable aux différentes distributions.

# Suite de la section tasks:
    - name: Déterminer le chemin du document root et l'utilisateur Nginx
      ansible.builtin.set_fact:
        nginx_doc_root: "{{ nginx_doc_root_debian if ansible_os_family == 'Debian' else nginx_doc_root_redhat }}"
        nginx_user: "{{ nginx_user_debian if ansible_os_family == 'Debian' else nginx_user_redhat }}"

    - name: Copier le fichier index.html vers la racine web de Nginx
      ansible.builtin.copy:
        src: files/index.html  # Chemin relatif au playbook (notre fichier local)
        dest: "{{ nginx_doc_root }}/index.html"
        owner: "{{ nginx_user }}"
        group: "{{ nginx_user }}"
        mode: '0644'
      notify:
        - Restart Nginx # Nom du handler à appeler si ce fichier change

Explications :

• Tâche set_fact : Avant de copier, nous utilisons une tâche set_fact pour définir dynamiquement les variables nginx_doc_root et nginx_user en fonction de ansible_os_family. Cela utilise une expression ternaire Jinja2 : valeur_si_vrai if condition else valeur_si_faux.
• Tâche copy :
  • src: files/index.html : Notre fichier local. Ansible le cherche par défaut dans un sous-répertoire files/ au même niveau que le playbook.
  • dest: "{{ nginx_doc_root }}/index.html" : Le chemin de destination sur le serveur distant, utilisant notre variable dynamique.
  • owner: "{{ nginx_user }}" et group: "{{ nginx_user }}" : Propriétaire et groupe du fichier, utilisant notre variable dynamique.
  • mode: '0644' : Permissions standards pour un fichier web.
  • notify: Restart Nginx : Si cette tâche de copie modifie le fichier index.html sur le serveur, elle notifiera un "handler" nommé "Restart Nginx".

Définition des Handlers pour le redémarrage du service

Les handlers sont des tâches spéciales qui ne sont exécutées que si elles sont notifiées par une autre tâche et seulement à la fin du jeu. C'est idéal pour redémarrer un service après un changement de configuration ou de contenu.

# A la fin du playbook, après la section tasks:
handlers:
  - name: Restart Nginx
    ansible.builtin.service:
      name: nginx
      state: restarted

Ce handler, nommé "Restart Nginx", redémarrera simplement le service Nginx. Il ne sera exécuté que si la tâche de copie du fichier index.html a effectivement apporté une modification.

Avec toutes ces sections combinées, notre playbook deploy_nginx_site.yml est maintenant complet et prêt à être exécuté. Il prend en charge l'installation, la configuration du service et le déploiement du contenu de manière automatisée et idempotente.