🔧 Ansible – Automatisation, Playbooks & Déploiement Django

Les 3 Composants Clés

1. Control Node (Nœud de Contrôle) : Votre machine (ex: votre PC ou un bastion) où Ansible est **installé**. C'est d'ici que vous lancez les commandes ansible-playbook.
2. Managed Nodes (Nœuds Gérés) : Vos serveurs cibles (Web, BDD...). Ils n'ont *rien* d'installé, juste un accès SSH.
3. Inventory (Inventaire) : Un simple fichier (INI ou YAML) sur le Control Node qui liste les IPs/DNS des Managed Nodes et les organise en groupes (ex: [webservers], [dbservers]).

Schéma de flux (SSH)

[Image d'une architecture Ansible]

+-----------------------+
| Control Node          |
| (Votre PC / Bastion)  |
|                       |
| - Ansible (Installé)  |
| - Inventory (fichier) |
| - Playbook.yml        |
+-----------------------+
      |
      | (ansible-playbook -i inventory playbook.yml)
      |
      | (Connexion SSH, Port 22)
      |
      +-----------------+-----------------+
      |                 |                 |
      ▼                 ▼                 ▼
+-----------+     +-----------+     +-----------+
| Managed 1 |     | Managed 2 |     | Managed 3 |
| (Web 1)   |     | (Web 2)   |     | (DB 1)    |
| (Python)  |     | (Python)  |     | (Python)  |
+-----------+     +-----------+     +-----------+

Le "Livre de Recettes"

Un Playbook (fichier .yml) est le cœur d'Ansible. Il décrit un état désiré (idempotent) pour un groupe d'hôtes.

Idempotent : Si vous lancez le playbook 100 fois, le résultat est le même. S'il est déjà à l'état désiré, Ansible ne fait rien (Statut: "OK"). S'il doit changer quelque chose, (Statut: "Changed").

deploy_nginx.yml (Anatomie)

---
# (Un Playbook est une liste de "Plays")
- name: Play 1 - Configurer les serveurs Web
  
  # 1. Cible (Groupe de l'inventaire)
  hosts: webservers
  
  # 2. Devenir 'root' (sudo)
  become: true
  
  # 3. Liste des tâches
  tasks:
    - name: "Tâche 1 - Installer Nginx (Debian)"
      apt:
        name: nginx
        state: present
      when: ansible_facts['os_family'] == "Debian"
      
    - name: "Tâche 2 - Installer Nginx (RHEL)"
      dnf:
        name: nginx
        state: present
      when: ansible_facts['os_family'] == "RedHat"
      
    - name: "Tâche 3 - Démarrer le service"
      systemd:
        name: nginx
        state: started
        enabled: true

Concept

Problème : Vous modifiez 10 fichiers de config Nginx. Vous ne voulez pas recharger Nginx 10 fois (lent), mais 1 seule fois, à la fin, et *seulement* si un fichier a changé.

Solution : Un "Handler" (gestionnaire) est une tâche qui n'est exécutée que si elle est "notifiée" par une autre tâche (qui a eu le statut "changed").

Exemple (Reload Nginx)

---
- hosts: webservers
  become: true
  tasks:
    - name: "Copier la config Nginx"
      copy:
        src: files/nginx.conf
        dest: /etc/nginx/nginx.conf
      # 1. Notifier le handler
      notify: Reload Nginx
      
    - name: "Copier le VHost Django"
      copy:
        src: files/django.conf
        dest: /etc/nginx/sites-available/django
      # 2. Notifier le MÊME handler
      notify: Reload Nginx
      
  # 3. Définir le Handler (à la fin du play)
  handlers:
    - name: Reload Nginx
      systemd:
        name: nginx
        state: reloaded

Factoriser (DRY)

Les Playbooks deviennent illisibles. Un **Role** est une structure de dossiers standardisée pour regrouper des tâches (tasks), des variables (vars), des handlers, et des templates.

Initialiser un Role (ansible-galaxy)

ansible-galaxy init roles/nginx
# (Crée l'arborescence)

Structure (roles/nginx/)

roles/nginx/
├── tasks/
│   └── main.yml  (Tâches: apt, copy, systemd)
├── handlers/
│   └── main.yml  (Handler: "Reload Nginx")
├── templates/
│   └── nginx.conf.j2
├── vars/
│   └── main.yml  (Variables par défaut)
└── defaults/
    └── main.yml

Utiliser le Role (Playbook principal)

Le playbook devient une simple "liste de courses".

# deploy_stack.yml
---
- name: Configurer les serveurs Web
  hosts: webservers
  become: true
  
  # 1. Appliquer les Rôles
  roles:
    - common   # (Installe vim, git, fail2ban...)
    - nginx    # (Installe et configure Nginx via le template)
    - django   # (Installe Gunicorn, code, .env)
    
- name: Configurer les serveurs BDD
  hosts: dbservers
  become: true
  roles:
    - common
    - postgresql

Stocker les Secrets

⚠️ Ne **jamais** commiter (git) de mots de passe (BDD, API) en clair dans vars/main.yml.

Ansible Vault est un outil (inclus) pour chiffrer (AES-256) des fichiers YAML contenant des secrets.

Commandes ansible-vault

# 1. Créer un fichier de secrets chiffré
ansible-vault create vars/secrets.yml
# (Demande un mot de passe)

# 2. Éditer le fichier
ansible-vault edit vars/secrets.yml

# 3. Lancer le playbook (en demandant le mot de passe)
ansible-playbook deploy.yml --ask-vault-pass

# (Utiliser un fichier de mdp)
ansible-playbook deploy.yml --vault-password-file .vault_pass

Contenu de vars/secrets.yml (chiffré)

$ANSIBLE_VAULT;1.1;AES256
386634... (Données chiffrées)

Contenu (déchiffré)

db_password: "mon_pass_db"
api_key: "sk_live_..."

Commandes Ad-Hoc (ansible)

# ( -i = inventaire, -m = module, -a = args, -b = become/sudo)

# Ping (vérifie la connexion)
ansible all -i inventory.ini -m ping

# Commande Shell
ansible webservers -i inv -m shell -a "df -h"

# Utiliser un module (ex: reboot)
ansible all -i inv -m reboot -b

Playbooks (ansible-playbook)

# Lancer un playbook
ansible-playbook -i inventory.ini deploy.yml

# Limiter à un groupe (ex: web)
ansible-playbook -i inv deploy.yml -l webservers

# Limiter à un host
ansible-playbook -i inv deploy.yml -l web1.ideolab.com

# (Dry Run) Voir ce qui *changerait* (ne fait rien)
ansible-playbook -i inv deploy.yml --check

# Voir les changements (diff)
ansible-playbook -i inv deploy.yml --diff

# Demander le mot de passe Vault
ansible-playbook -i inv deploy.yml --ask-vault-pass