Rabbitmq definitions

Previous Next

How-to pour toute modification de queues, exchanges ou bindings dans article1-connect/rabbitmq-defs.json.

Alerte MEP : pousser ce fichier dans Git ne met pas à jour le RabbitMQ de staging/prod. Une action manuelle (ou un import de defs sur le cluster RMQ) est obligatoire après merge / tag.

Source de vérité

Fichier Rôle
article1-connect/rabbitmq-defs.json Queues, exchanges, bindings déclarés
article1-connect/rabbitmq.config load_definitions → charge le JSON au démarrage de RabbitMQ local

Les applications (A1Connect, Dema1n, Inspire) ne créent pas les bindings au runtime. Elles publient / consomment uniquement.

Local vs staging / prod

Environnement Qui charge les defs ? Redeploy API A1Connect / Dema1n / Inspire Restart du pod RabbitMQ
Local (a1connect-rabbitmq via docker-compose) RabbitMQ au boot, via load_definitions + volume monté sur rabbitmq-defs.json Aucun effet sur les bindings Recharge les defs si le fichier monté est à jour
Staging / prod (cluster K8s dédié, ex. rabbitmq-0) Personne automatiquement depuis un déploiement applicatif Aucun effet Insuffisant tant que le ConfigMap / volume de defs du cluster n’a pas été mis à jour (souvent absent ou figé)

En prod, le Management UI montre un cluster autonome (rabbit@rabbitmq-….rabbitmq-headless…), pas le conteneur docker-compose d’A1Connect.

Checklist développeur (modification des defs)

  1. Modifier article1-connect/rabbitmq-defs.json (queue, exchange, binding).
  2. Vérifier en local : restart de a1connect-rabbitmq, puis contrôler l’onglet Bindings de l’exchange concerné (http://localhost:15672).
  3. Ouvrir / documenter la MR avec une case cochable du type :
  4. [ ] Binding / queue à créer aussi sur RabbitMQ staging après merge
  5. [ ] Binding / queue à créer aussi sur RabbitMQ prod à la MEP
  6. Après merge staging : appliquer le changement sur le RabbitMQ staging (UI ou import), puis valider qu’un message de test atteint la bonne queue.
  7. À la MEP (tag prod) : appliquer le même changement sur le RabbitMQ production dans la foulée du déploiement applicatif — le tag Git ne le fait pas.
  8. Mentionner explicitement le changement RMQ dans le CR de MEP / release notes.

Appliquer un binding manuellement (Management UI)

Exemple vécu : Dema1n publie SUIVI_CREATED (routing key user___mvls) sur l’exchange dema1n, mais Inspire ne recevait rien car le binding vers InspireV2_mvls manquait en prod alors qu’il était dans les defs.

  1. Ouvrir RabbitMQ Management → Exchanges → exchange source (ex. dema1n).
  2. Section Bindings → Add binding from this exchange :
  3. To queue : nom de la queue cible (ex. InspireV2_mvls)
  4. Routing key : clé exacte (ex. user___mvls)
  5. Bind.
  6. Vérifier que la ligne apparaît dans la table des bindings de l’exchange.

Bindings MVLS de référence (defs)

Source (exchange) Destination (queue) Routing key
dema1n InspireV2_mvls user___mvls
inspire Dema1n_mvls user___mvls

Sans le premier binding, aucun message MVLS Dema1n → Inspire (USER_*, BINOME_*, SUIVI_*) n’atteint l’API Inspire.

Vérifications après application

  1. Exchange source → onglet Bindings : la ligne attendue est présente.
  2. Queue cible (InspireV2_mvls / Dema1n_mvls) : messages reçus (ready/unacked) lors d’un événement de test.
  3. Côté Inspire (échecs uniquement logués) :
    kubectl logs deploy/<api-inspire> | grep -E 'RABBITMQ_SUIVI|RABBITMQ_BINOME|MvlsSuiviService'
  4. Preuve métier suivis : ligne dans la table mvls-suivis (suiviIdDema1n).

Ce qu’il ne faut pas faire

  • Croire qu’un restart de l’API A1Connect / Dema1n / Inspire recrée les bindings.
  • Se contenter d’un restart RabbitMQ prod sans avoir mis à jour / réimporté les defs sur ce cluster.
  • Modifier uniquement le Management UI sans mettre à jour rabbitmq-defs.json (la dérive locale ↔ prod se reproduira).

Voir aussi

Local dev Roadmap