9.2 : Stratégies et parallélisme (serial, forks)

Jusqu’ici, nos playbooks tournaient sur deux ou trois machines à la fois — la différence de vitesse entre du séquentiel et du parallèle ne se voyait pas vraiment. Mais imaginez Nordika avec cinquante serveurs à mettre à jour : si Ansible traitait chaque machine une par une, l’exécution prendrait un temps considérable. Voyons comment Ansible gère ça par défaut, et comment ajuster ce comportement.

Le comportement par défaut : déjà parallèle

Bonne nouvelle : Ansible exécute déjà ses tâches en parallèle sur plusieurs hôtes, par défaut, sans rien configurer. Le nombre de machines traitées simultanément est piloté par le paramètre forks, avec une valeur par défaut de 5.

ansible-playbook playbook_nordika.yaml -i inventaire.yaml --forks 20

Ici, jusqu’à 20 machines sont traitées en même temps, plutôt que 5. Sur un parc de cinquante serveurs, ça peut diviser le temps total d’exécution par quatre.

Où régler forks durablement

Plutôt que de le retaper à chaque commande, direction ansible.cfg (déjà croisé en 1.3 et 8.2) :

# ansible.cfg
[defaults]
forks = 20

La stratégie linear : le comportement par défaut, à comprendre en détail

Par défaut, Ansible utilise la stratégie linear : toutes les machines avancent tâche par tâche, ensemble. Concrètement, Ansible attend que tous les hôtes du lot en cours aient terminé la tâche 1 avant de passer à la tâche 2 pour l’ensemble du lot.

Tâche 1 : nrd-web1 ✓  nrd-web2 ✓  nrd-web3 ✓  (Ansible attend les 3)
Tâche 2 : nrd-web1 ✓  nrd-web2 ✓  nrd-web3 ✓  (Ansible attend les 3)

C’est prévisible et facile à suivre dans les logs, mais ça a un coût : si nrd-web2 est nettement plus lent que les autres sur une tâche (un disque plus lent, une connexion réseau moins bonne), tout le lot attend après lui avant de continuer.

La stratégie free : chaque machine à son rythme

---
- name: Déployer sans attendre les machines lentes
  hosts: webservers
  strategy: free
  become: yes

  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present

Avec free, chaque hôte avance à son propre rythme, à travers toutes les tâches du play, sans attendre les autres. Plus rapide globalement sur un parc hétérogène, mais les logs deviennent moins lisibles : les tâches de différentes machines s’entremêlent dans l’affichage, puisqu’elles ne sont plus synchronisées entre elles.

serial : traiter la flotte par petits lots, pas tous à la fois

C’est le paramètre le plus important pour un vrai déploiement en production, et il répond à une question différente de forks : pas « combien de machines en même temps », mais « combien de machines je risque en même temps si quelque chose tourne mal« .

---
- name: Déployer une mise à jour risquée, par petits lots
  hosts: webservers
  serial: 2
  become: yes

  tasks:
    - name: Mettre à jour l'application
      ansible.builtin.apt:
        name: nordika-app
        state: latest

Avec serial: 2, sur un groupe webservers de dix machines, Ansible traite 2 machines à la fois, termine complètement ce lot (toutes les tâches du play), puis passe aux 2 suivantes, et ainsi de suite. Si quelque chose casse sur le premier lot, l’exécution s’arrête avant même de toucher aux huit machines restantes — plutôt que d’avoir mis à jour (et potentiellement cassé) les dix machines d’un coup.

serial avec des pourcentages, et des lots progressifs

serial accepte aussi un pourcentage, ou même une liste de valeurs progressives — un déploiement prudent qui s’élargit au fur et à mesure qu’on gagne en confiance :

---
- name: Déploiement progressif
  hosts: webservers
  serial:
    - 1        # d'abord une seule machine, pour valider
    - 3        # puis 3 machines
    - "50%"    # puis la moitié du reste
  become: yes

C’est une stratégie qu’on retrouve couramment appelée « canary deployment » dans le vocabulaire DevOps plus large : tester sur un tout petit nombre de machines avant d’élargir, plutôt que de tout risquer d’un coup.

forks vs serial : ne pas confondre

Un point de confusion fréquent chez les débutants :

Les deux peuvent se combiner : serial: 2 avec forks: 20 limite quand même l’exécution à 2 machines par lot, même si forks autoriserait techniquement bien plus de connexions simultanées.

Ce qu’il faut retenir

• forks (par défaut 5) contrôle le nombre de connexions simultanées — l’augmenter accélère l’exécution sur un grand parc.
• linear (par défaut) synchronise toutes les machines tâche par tâche ; free laisse chacune avancer à son rythme.
• serial limite le nombre de machines traitées par lot successif — essentiel pour un déploiement prudent qui ne risque pas tout le parc d’un coup.
• Un déploiement en production sensible combine souvent serial avec des valeurs progressives, façon canary deployment.

Dans la prochaine leçon, on reprend et on enrichit le lab découverte de cette formation : Apache et MariaDB déployés en un seul run orchestré, avec tout ce qu’on vient d’apprendre.