Ce projet définit les recommandations élaborées à l'État de Genève pour ses développeurs d'applications productrices et consommatrices de messages RabbitMQ.
| Recommandation | Catégorie | Producteur | Consommateur |
|---|---|---|---|
| Coordonner les équipes | Gouvernance | X | X |
| Prendre en main RabbitMQ | Outillage | X | X |
| Utiliser RabbitMQ à l'État | Outillage | X | X |
| Être au clair sur le contenu des messages | Messages | X | X |
| Échanger de petits messages lisibles | Messages | X | X |
| Échanger des métadonnées sur chaque message | Messages | X | X |
| Relier chaque message à un usager (imputabilité) | Messages | X | |
| Prévoir les évolutions du contenu des messages | Messages | X | |
| Tracer les messages | Gestion opérationnelle | X | X |
| Gérer les erreurs de traitement | Gestion opérationnelle | X | |
| Ne pas perdre de messages (acquittements) | Gestion opérationnelle | X | X |
| Savoir réémettre un message | Gestion opérationnelle | X | |
| Pouvoir consommer plusieurs fois le même message (idempotence) | Gestion opérationnelle | X | |
| Savoir traiter les messages dans le bon ordre | Gestion opérationnelle | X | |
| Gérer l'indisponibilité de RabbitMQ | Gestion opérationnelle | X | X |
| Respecter la bande passante allouée | Gestion des ressources de RabbitMQ | X | X |
| Utiliser un pool de connexions à RabbitMQ | Gestion des ressources de RabbitMQ | X | X |
| Gérer la connexion à RabbitMQ | Gestion des ressources de RabbitMQ | X | X |
| Contrôler les envois de message selon leur importance | Suivi et surveillance | X | X |
L'usage de RabbitMQ à l'État de Genève provient de la nécessité du remplacement de JMS, jugé vieillissant comme système middleware de gestion de queues. En 2020, l'étude d'un cas en interne a mis en concurrence Apache Kafka et RabbitMQ. Il en a été dégagé que le besoin de l'État de Genève n'était pas ceux d'une gestion de flux aux performances stratosphériques, mais ceux d'une solution plus classique de gestion de queues : (relative) simplicité, découplage, robustesse. De plus, un système RabbitMQ complet peut être monté en open source, tandis que si le noyau de Kafka est librement accessible, des éléments nécessaires à l'exploitation sont payants. Aussi RabbitMQ a-t-il été retenu.
Le déploiement de RabbitMQ à l'État de Genève a été conçu selon les axes suivants :
- À chaque domaine fonctionnel son RabbitMQ. On n'a donc pas cherché à établir un agent RabbitMQ global ou une ferme d'agents RabbitMQ globale ; au contraire on a préféré compartimenter les domaines afin qu'un incident sur un agent d'un domaine ne puisse pas affecter un autre agent.
- La sécurité est un élément-clé de la solution :
- Une application productrice ou consommatrice de messages utilise le protocole OpenID Connect pour obtenir un jeton (access token) d'un serveur UAA, lequel s'authentifie au système de général de gestion des accès de l'État (appelé Gina) et en récupère les rôles de l'usager via un appel LDAP.
- l'accès humain à la console RabbitMQ, pour des raisons historiques, est protégé un peu différemment : l'usager s'authentifie à Gina, puis le serveur UAA récupère les rôles de l'usager, via un échange SAML et sans appel LDAP.
- Le déploiement de chaque agent RabbitMQ et de l'UAA, en développement, en recette et en production, s'effectue via des scripts Ansible et un serveur GoCD.
Pour les développeurs d'applications de l'État, en Java, en PHP ou en JavaScript, l'usage de RabbitMQ n'est pas familier. Aussi cette série de recommandations et d'injonctions à leur intention a été rédigée.
Principaux auteurs : François Montmasson, Jérémy Meunier, Pierre Laroche, Yves Dubois-Pèlerin.