Bus d'événements Salt : Reactor et beacons

C'est la fonctionnalité qui distingue Salt : un bus d'événements où tout ce qui se passe est publié, et un moteur qui peut réagir automatiquement. Les beacons détectent, le Reactor agit. Ce module construit une réaction automatique : redémarrer un service dès qu'il tombe. Public visé : avancés maîtrisant states et orchestration.

Ce que vous allez apprendre

Comprendre l'architecture du bus d'événements.
Détecter un état avec un beacon.
Déclencher une action avec le Reactor.
Construire une réaction automatique de bout en bout.

Prérequis

Maîtriser states et orchestration.

Le bus d'événements

Le master expose un bus sur lequel transitent des événements : un minion qui s'authentifie, un job qui se termine, une alerte remontée. Chaque événement porte un tag et des données JSON. On l'observe en direct depuis le master, première étape pour comprendre ce qui circule :

sudo salt-run state.event

Un événement ressemble à ceci : un tag hiérarchique, puis les données. Ici, un beacon de service signale que nginx tourne sur web1 :

salt/beacon/web1/service/nginx  {"nginx": {"running": true}, "service_name": "nginx", "id": "web1"}

C'est ce flux que le Reactor va écouter pour déclencher des actions.

Les beacons : détecter

Un beacon est un capteur côté minion qui surveille quelque chose (un service, un fichier, une charge) et émet un événement quand une condition est remplie. Sans beacon, le Reactor n'a rien à écouter. On le déclare dans la configuration du minion, ici dans /etc/salt/minion.d/beacons.conf :

# /etc/salt/minion.d/beacons.conf sur le minion
beacons:
  service:
    - services:
        nginx:
          onchange_only: true
    - interval: 5

Le beacon service sonde nginx toutes les 5 secondes ; onchange_only limite l'émission aux changements d'état. Après modification, le minion doit recharger ses beacons :

sudo salt web1 saltutil.refresh_beacons

On vérifie qu'il est bien chargé avec salt web1 beacons.list.

Le Reactor : agir

Le Reactor écoute le bus et associe un tag d'événement à une action (appliquer un state, lancer une orchestration). C'est le chaînon qui transforme une détection en réaction automatique. Il se configure côté master, ici dans /etc/salt/master.d/reactor.conf :

# /etc/salt/master.d/reactor.conf sur le master
reactor:
  - 'salt/beacon/*/service/nginx':
    - /srv/reactor/restart-nginx.sls

Le fichier réacteur est un SLS rendu par Jinja : il lit les données de l'événement et ne déclenche l'action que si nginx est effectivement tombé (running à False). L'action local.service.start relance le service sur le minion émetteur, identifié par data['id'] :

{# /srv/reactor/restart-nginx.sls #}
{% set d = data.get('nginx', {}) %}
{% if d.get('running') == False %}
relancer-nginx:
  local.service.start:
    - tgt: {{ data['id'] }}
    - arg:
      - nginx
{% endif %}

Après modification, le master doit être redémarré (systemctl restart salt-master) pour prendre en compte le réacteur.

Travaux pratiques : nginx qui se relève seul

Beacon posé, Reactor branché : la boucle est prête. Pour la déclencher, on arrête nginx sur web1 pendant qu'on observe le bus depuis le master (salt-run state.event). Voici la séquence réelle capturée, tags et horodatages à l'appui :

salt/beacon/web1/service/nginx   {"nginx": {"running": false}, "id": "web1", "_stamp": "...20:30:50.886"}
salt/job/20260711203050949172/new   {"fun": "service.start", "arg": ["nginx"], "tgt": "web1", "user": "salt", "_stamp": "...20:30:50.949"}
salt/beacon/web1/service/nginx   {"nginx": {"running": true}, "id": "web1", "_stamp": "...20:30:55.894"}

La causalité est lisible à la milliseconde. À 20:30:50.886, le beacon détecte l'arrêt (running: false). 63 millisecondes plus tard, à 20:30:50.949, un job service.start nginx apparaît, lancé par l'utilisateur salt : c'est le Reactor qui agit, pas un opérateur. À 20:30:55, le beacon suivant confirme running: true. Personne n'est intervenu.

sudo salt web1 cmd.run 'systemctl is-active nginx'

web1:
    active

Vous venez de construire une infrastructure réactive : un service surveillé se relève seul quelques secondes après une panne. C'est le genre d'automatisme que le bus d'événements et le Reactor rendent naturel, et que peu d'outils de gestion de configuration savent faire nativement.

À retenir

Le bus d'événements publie tout ce qui se passe sur l'infrastructure.
Les beacons détectent et émettent des événements côté minion.
Le Reactor associe un événement à une action automatique.
Cette boucle détecter-réagir est la signature de Salt ; attention aux boucles de réaction.

Prochaines étapes

Orchestration Déclencher une orchestration multi-machines en réaction à un événement.

Formation Salt Revenir au parcours complet et poursuivre les modules suivants.