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.

# wait_for : attendre qu'un port soit accessible (préféré au pause)
- ansible.builtin.wait_for:
    host: localhost
    port: 8080
    state: started     # ou stopped
    timeout: 60        # 60 s max — au-delà, échec explicite
    delay: 2           # délai avant 1er sondage

# wait_for : attendre une chaîne dans un fichier (utile pour démarrage applicatif)
- ansible.builtin.wait_for:
    path: /var/log/myapp/server.log
    search_regex: 'Server started'
    timeout: 120

# pause : confirmation manuelle avant migration BDD critique
- ansible.builtin.pause:
    prompt: "Migration BDD irréversible. Sauvegarde validée ? Tapez ENTRÉE pour continuer"

# pause : délai fixe (à éviter — préférer wait_for sur condition)
- ansible.builtin.pause:
    seconds: 5    # uniquement si vraiment aucune condition observable

Sécurité non négociable :

wait_for: avec timeout: explicite, sans ça, le play peut bloquer indéfiniment si le service ne démarre jamais.
Préférer wait_for: à pause: seconds:, sondage actif est plus rapide (sort dès que la condition est vraie) et plus sûr (échec explicite si timeout).
pause: prompt: sur les actions destructives en prod (migrations, suppressions), un humain valide avant. Ne pas oublier que ça bloque la CI/CD : prévoir un --extra-vars confirm=true pour les pipelines.

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 ) &

- 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 :

- 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
- ansible.builtin.systemd_service:
    name: myapp
    state: started

- 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
`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).

Pratiquer dans le lab

Cette page a un lab d'accompagnement : labs/modules-diagnostic/wait-for-pause/ dans stephrobert/ansible-training.

Challenge, sur db1.lab :

Lancer en arrière-plan une commande qui crée un fichier après 3s.
wait_for: path: pour attendre.
pause: 1s pour stabilisation.
wait_for: port: 22 (sshd, TCP).

Validation pytest+testinfra :

ansible-playbook solution.yml
pytest -v labs/modules-diagnostic/wait-for-pause/challenge/tests/

4 tests vérifient marker, succès, et écoute sshd.

Prochaines étapes

Module uri Pour des healthchecks HTTP plus précis que wait_for: port: (status code, body)

Module systemd_service Le module qui démarre les services à attendre via wait_for:

Module assert Compléter wait_for: par assert: pour valider l'état après synchronisation

Pivot Modules Vue d'ensemble des modules diagnostic, fichiers, paquets