Modules wait_for et pause Ansible : synchronisation

Deux modules pour la synchronisation temporelle dans un play :

ansible.builtin.wait_for: = attendre une condition (port ouvert, fichier créé, regex dans un fichier, machine SSH-prête). Sondage actif.
ansible.builtin.pause: = attendre un délai fixe (secondes/minutes) ou demander une confirmation interactive à l'opérateur.

wait_for: est le bon choix dans 90% des cas, sondage actif jusqu'à condition vraie. pause: est utile pour des délais incompressibles ou des confirmations humaines.

Ce que vous allez apprendre

Attendre l'ouverture d'un port TCP (cas le plus courant).
Attendre la fermeture d'un port (state: stopped).
Attendre l'apparition d'un fichier ou d'une regex dans un fichier.
Pause simple (seconds:) ou interactive (prompt:).
Diagnostiquer un timeout wait_for: (mauvais host, port firewallé, race condition).

Prérequis

Notion de port TCP (le module wait_for: port: ne teste que TCP, pas UDP).

`wait_for: port:`, le pattern n°1

Cas typique : après démarrage d'un service, attendre que le port soit prêt avant les tâches qui en dépendent.

- name: Demarrer chronyd
  ansible.builtin.systemd_service:
    name: chronyd
    state: started

- name: Attendre que sshd reponde sur 22
  ansible.builtin.wait_for:
    port: 22
    host: 127.0.0.1
    timeout: 10

Comportement : wait_for: polle (par défaut toutes les secondes) jusqu'à ce que le port soit ouvert, ou échoue après timeout: secondes.

host: par défaut = 127.0.0.1. Pour tester un port d'un autre host depuis le managed node, spécifier host: 10.10.20.21.

`state: stopped`, attendre la fermeture

- name: Verifier que le port 9999 est BIEN libre
  ansible.builtin.wait_for:
    port: 9999
    host: 127.0.0.1
    state: stopped
    timeout: 5

state: stopped = succès si le port est libre. Pratique avant de démarrer un service, vérifier que rien d'autre n'utilise le port.

`wait_for: path:`, apparition d'un fichier

- name: Lancer une commande qui crée un fichier en arriere-plan
  ansible.builtin.shell: |
    ( sleep 3 && touch /tmp/marker.txt ) &
  changed_when: true

- name: Attendre que le fichier apparaisse
  ansible.builtin.wait_for:
    path: /tmp/marker.txt
    timeout: 10

Utile pour synchroniser avec un process asynchrone qui crée un flag-file en fin de traitement.

`wait_for: search_regex:`, chercher une regex

- name: Verifier qu un service a logge "Ready"
  ansible.builtin.wait_for:
    path: /var/log/messages
    search_regex: 'systemd.*Started.*chronyd'
    timeout: 30

Cas d'usage : attendre le log "Server ready" d'une app, "Database initialized", etc.

Limitation : wait_for: search_regex: lit le fichier à chaque poll, sur un log de plusieurs Go, c'est lent.

`pause: seconds:`, délai fixe

- name: Demarrer le service
  ansible.builtin.systemd_service:
    name: chronyd
    state: restarted

- name: Pause de 5 secondes pour stabilisation
  ansible.builtin.pause:
    seconds: 5

pause: seconds: = sleep simple. Pas adaptatif (5s même si le service est prêt en 1s). Préférer wait_for: quand une condition précise existe.

Quand préférer pause: :

Pas de condition précise mesurable.
Délai imposé par un système externe (cool-down API).

`pause: prompt:`, confirmation interactive

- name: Confirmation manuelle avant migration BDD
  ansible.builtin.pause:
    prompt: |
      Vous allez lancer la migration de la base de production.
      Tapez ENTER pour continuer, Ctrl+C pour annuler.

Ansible bloque le play en attendant une touche. Cas d'usage : opérations critiques où un humain doit valider.

Pattern CI/CD : conditionner la pause au mode interactif :

- name: Attendre la condition
  ansible.builtin.pause:
    prompt: "Confirmer la migration ?"
  when: confirm_required | default(false) | bool

En CI : --extra-vars "confirm_required=false" saute la pause. En manuel : on demande confirmation.

Le piège : race condition au démarrage

Ansible peut lancer un service via systemd_service: et passer immédiatement à wait_for: port:, sans attendre que systemd ait réellement démarré le binaire.

# ❌ Race condition possible
- name: Piloter le service myapp
  ansible.builtin.systemd_service:
    name: myapp
    state: started

- name: Attendre la condition
  ansible.builtin.wait_for:
    port: 8080
    timeout: 30
  # Si myapp met 35s a demarrer → wait_for failed

Mitigation :

Augmenter timeout: : si l'app peut prendre 60s, mettre timeout: 90.
Combiner avec until: sur uri: : tester un endpoint HTTP plutôt qu'un port TCP brut (cf. module uri).

Sondage espacé sur services lents

- name: Attendre un service lent (poll moins frequent)
  ansible.builtin.wait_for:
    port: 8080
    timeout: 300
    delay: 10        # Attendre 10s avant le 1er sondage
    sleep: 5         # 5s entre chaque sondage

Par défaut, wait_for: sonde toutes les secondes dès le départ. Sur un service très lent (Docker registry, base de données), c'est trop. delay: retarde le 1er sondage. sleep: espace les sondages suivants.

Pièges courants

Symptôme	Cause	Fix
`Timeout when waiting for port 323`	UDP testé en TCP	`wait_for: port:` ne teste que TCP
Race condition au démarrage	`wait_for:` lancé trop tôt	Augmenter `timeout:`, ou utiliser `uri: until:`
`pause:` bloque la CI	Pas de mode non-interactif	Conditionner avec `when: confirm_required \| bool`
`search_regex` lent	Gros log lu à chaque poll	Utiliser un fichier dédié plus petit

À retenir

wait_for: = sondage actif jusqu'à condition vraie.
port: + state: started/stopped = test de port TCP (pas UDP).
path: = attendre l'apparition d'un fichier.
search_regex: = chercher une chaîne dans un fichier (lent sur gros logs).
pause: seconds: = sleep simple, non adaptatif.
pause: prompt: = confirmation interactive humaine.
timeout: sur wait_for: = à dimensionner avec marge (× 2 ou × 3 du temps attendu).

Mettre en pratique

Une race condition ne se reproduit pas à la demande sur un poste de travail, elle se met en scène. Le lab vous fait déclencher sur db1.lab une tâche de fond qui crée un fichier après quelques secondes, attendre son apparition avec wait_for: path:, insérer une pause: de stabilisation, puis sonder le port 22 avec wait_for: port:. Les tests vérifient le témoin laissé par la séquence et l'écoute effective de sshd, ce qu'un simple sleep ne garantirait pas.

Modules wait_for et pause : synchronisation

$ dsoxlab run modules-diagnostic-wait-for-pause

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-diagnostic-wait-for-pause
dsoxlab check modules-diagnostic-wait-for-pause

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

raw, command, shell, script : Le module raw, seul recours sur une machine qui redémarre et n'a pas encore Python.
debug, setup, add_host, group_by : Recollecter les facts après un reboot, une fois la reconnexion obtenue.
Handlers et meta : Redémarrer un service par notify puis attendre son port : les deux briques se complètent dans un rôle.