Ce document décrit le fonctionnement du projet Référentiel de Mobilité Régional mis en place pour la Région Nouvelle Aquitaine. Il fait office de point d’entrée pour la documentation technique.
Les différentes applications disposent d’un fichier README.md à leur racine, décrivant comment les lancer et les points techniques spécifiques. Le but de ce document est d’offrir une vue d’ensemble sur le rôle de chaque application afin de pouvoir appréhender la pile technique. Il fait également office de dossier d’architecture technique en présentant les objectifs du projet, et les moyens matériels nécessaaires pour les atteindre.
Depuis ses débuts, Okina construit des solutions logicielles en s’appuyant notamment sur le logiciel Chouette. Ce logiciel, à l’origine une commande de l'Agence Française pour l’Information Multimodale et la Billettique (AFIMB), développé en Java, offre des tâches d’import / export / validation vers les principaux formats utilisés en France : Neptune et GTFS.
Le projet Rutebanken initié par le gouvernement norvégien en 2015, et mené par la société gouvernementale Entur, s’est appuyé sur le logiciel Chouette et les normes et formats d’échanges poussés par l’union européenne(Transmodel, NeTEx, Siri) pour créer une solution permettant de stocker les données de transport public à grande échelle. Cette solution adresse notamment les problématiques de volumétrie de données et de la centralisation de la gestion d’une offre de transport provenant de différents SI.
|
Note
|
Les lettres dans les chapitres suivants référencent le schéma d’architecture ci-dessus. |
Keycloak est une application open source soutenue par la société RedHat permettant d’implémenter simplement des politiques de sécurité au sein d’une application. Nous déléguons à Keycloak la gestion de l’authentification et de la sécurité au sein des applications. Des librairies fournies par l’éditeur existent dans les langages utilisés (javascript, java).
Keycloak est de plus capable de faire de la fédération d’identité, et donc éventuellement de communiquer avec d’autres applications du même type via des protocoles type SAML ou OpenID. Ceci ouvre la porte à une éventuelle intégration ultérieure en SSO des logiciels de l’application avec des logiciels issus d’autres systèmes d’information.
Kong est une application open source de gestion d’API. Kong permet d’unifier les APIs provenant de multiples applications au sein d’une même application, et d’appliquer des politiques de sécurité ou de bridage sur ces APIs. C’est un moyen d’offrir une interface d’accès rationalisée aux APIs de l’application, le projet contenant des APIs provenant de multiples projets open source et donc aux interfaces hétéroclites.
Nginx est le serveur web de référence. Dans le cadre du projet RMR, il sert de point d’entrée à l’application : toutes les requêtes web passent par ce serveur et sont ensuite distribuées aux applications composant la pile applicative. Plusieurs avantages pour ce procédé :
-
Gestion de la sécurité de l’infrastructure simplifiée : un seul port ouvert.
-
Gestion du reverse proxying au sein de la pile applicative : une fois un nom de domaine fourni, nous pouvons facilement créer des sous-urls et les associer à des applications.
Cible : solution avec indexage, recherche et webapp de consultation type ELK. A ce jour, les logs sont collectés et routés vers des fichiers sur le système de fichier via logspout.
ReactJS Spring Boot PostgreSQL
L’interface d’administration du projet se fait au travers d’une application ReactJS (Ninkasi. Cette application utilise les différentes APIs des backends disponibles pour permettre l’administration du projet. La gestion des différents producteurs de données est centralisée dans l’application dédiée Baba
A travers cette interface il est possible de :
-
Gérer les producteurs de données et les droits associés. L’interface d’administration communique avec Keycloak, et offre une interface de saisie plus pratique qu’au sein de Keycloak.
-
Suivre l’avancement des imports / exports de données pour les différents producteurs de données, les tuer si nécessaires, ou bien les relancer.
-
Consulter des statistiques sur les données théoriques
-
Consulter la liste des fichiers exportés
ReactJS Spring Boot PostgreSQL
L’application Bel est le point d’entrée pour un producteur de données souhaitant soumettre des données. A travers cette application, un producteur de données est capable de soumettre un fichier d’offre théorique et de suivre l’avancement de l’import.
L’utilisateur peut également avoir une vue synthétique des informations présentes dans le système, avec notamment les données expirant prochainement.
Ruby on Rails JEE PostgreSQL
L’application Chouette IEV (pour Import, Export, Validation), est une application JEE exposée sous la forme d’une API, et devant être déployée sur un serveur wildfly 8. Grâce à cette API il est possible de soumettre des jobs d’import, export, ou validation dans différents formats et de suivre leur avancement. L’application stocke les données au format Transmodel dans une base Postgres.
L’application Chouette 2 offre une interface permettant de visualiser les données stockées dans la base de données et de les manipuler.
ReactJS Spring Boot PostgreSQL
Les applications Tiamat (backend) et Abzu (frontend) sont dédiées à la gestion de points d’arrêts et permettent :
-
De créer des nouveaux points d’arrêts,
-
De supprimer des points d’arrêts,
-
De modifier des points d’arrêts existants,
-
D’exporter les données des points d’arrêts au format CSV suivant les filtres voulus.
Les points d’arrêts peuvent être créés au sein de l’application dédiée, mais sont également collectés depuis l’application Chouette lors des imports de données. L’application dédoublonne automatiquement les points d’arrêts provenant de systèmes informatiques différents en fonction de critères métiers (nom des points d’arrêt, coordonnées GPS, proximité avec d’autres points). L’application Tiamat est également en charge de la production des exports Netex de la base d’arrêts.
ReactJS Spring Boot PostgreSQL
L’offre de transport à la demande Zonale est déportée dans deux applications dédiées : Enki (frontend) et Uttu (backend). Uttu est responsable de la production de l’offre de TAD zonale au format Netex. L’offre TAD en ligne virtuelle se rapporoche d’une offre de transport plus classique et est à ce jour gérée dans Chouette.
Spring Boot PostgreSQL Camel - ActiveMQ
L’application Marduk est responsable des processus métiers d’import / export notamment. L’utilisation de JMS au travers d’ActiveMQ et Apache Camel permet d’offrir la résilience nécessaire à l’application, ainsi que la maintenabilité des workflows applicatifs (décrits au travers de composants Camel).
L’application Kakka gère la production d’exports réguliers de la base de points d’arrêts, en invoquant l’API de Tiamat.
L’application Nabu est chargée de collecter les évènements liés aux imports / exports, et offre une API permettant de récupérer ces évènements.
L’application Irkalla vérifie l’état de la synchronisation de la base de points d’arrêts entre Chouette et Tiamat, et la met à jour si nécessaire.
Divers autres composants de moindre importance, ou n’ayant nécessité pas ou peu d’évolutions sont listés ci-dessous.
Bogu Contient des composants ReactJS utilisés dans plus d’une application.
Netex-java-model Permet de générer un jar contenant le modèle Netex en Java d’après une XSD.
Chouette2-i18n et Chouette-projects-i18n contiennent les libellés de l’application Chouette2.
Les données sont exportées sur Google Cloud Storage afin d’être réutilisées notamment sur le calculateur multimodal Modalis. Toutes les nuits, un export complet Netex de l’offre de transport ainsi que des points d’arrêts est poussée sur GCS. Les données sont également poussées filtrées par producteur de données.
Les données d’offre de transport importées ou saisies dans l’application sont stockées par Chouette au format Transmodel. Concernant la gestion des producteurs de données, nous avons repris le modèlé mis en place par Entur sur Rutebanken. Les données
Une organisation est une entité pouvant produire ou gérer des données de transport, et devant donc interagir d’une manière ou d’une autre avec le RMR. Deux types d’organisation cohabitent :
-
Les autorités organisatrices de transport (Authority) : c’est une entité chargée de fournir une offre de transport public
-
Les opérateurs (Operator) : c’est une société responsable de l’exploitation de tout ou partie de l’offre de transport public. Les opérateurs agissent la plupart du temps sous contrat d’une autorité organisatrice de transport.
Dans le système, chaque organisation se verra attribuer un Codespace. Le Codespace (assimilable à la notion de namespace dans le monde XML) est une URL terminée par un code à 3 lettres qui permettra d’assurer l’unicité des données dans le système.
<Codespace>
<Xmlns>BME</Xmlns>
<XmlnsUrl>http://rmr.nouvelle-aquitaine.pro/bme</XmlnsUrl>
<Description>Bordeaux Métropole</Description>
</Codespace>Le déploiement sous forme d’un cluster Docker Swarm est préconisé : il permet aussi bien le déploiement sur une architecture on premise que du cloud, et offre la résilience nécessaire à ce type de projet.
Le projet est actuellement déployé en production sur un cluster de VMs hébergées chez un hébergeur cloud français.
Le projet, déployé dans un cluster Swarm, devra respecter a minima les contraintes d’infrastructure suivantes :
-
3 noeuds afin d’atteindre le quorum nécessaire à Swarm pour provoquer une réélection en cas de défaillance du noeud leader
-
Deux noeuds comportant au minimum 8G de RAM, et un noeud comportant au minimum 16G de RAM
-
Les machines devront être équipées a minima de processeurs quad core 3.7Gh
-
60G d’espace disque par noeud, pour le stockage des images Docker et des logs notamment. Un soin particulier est apporté à créer les images les plus petites possibles, mais nous dépendons parfois d’images tierces volumineuses au départ.
-
Un espace de données accessible par les 3 noeuds d’au moins 20G, permettant de stocker les fichiers de configuration, ainsi que les données applicatives (pour une intégration de fichier par exemple, qui pourra nécessiter de lire / écrire des fichiers).
L’utilisation de ces capacités machine est ponctuelle, et principalement liée à l’intégration des fichiers de données d’offre théorique. L’intégration des fichiers nécessite :
-
De mettre l’offre en mémoire pour pouvoir effectuer rapidement les vérifications nécessaires (d’où la RAM nécessaire)
-
Des capacités CPU importantes pour le traitement des gros fichiers de données.
La base de données est actuellement hébergée en production sur un des 3 noeuds composant le cluster Swarm. Chaque application back possède sa base de données. Elles sont listées ci-dessous, avec leur taille après 3 ans d’utilisation :
| Application | Taille de la base de données en Mb |
|---|---|
keycloak |
14 |
kong |
8 |
nabu |
158 |
baba |
20 |
kakka |
19 |
tiamat |
1944 |
uttu |
20 |
marduk |
20 |
chouette |
7926 |
iev |
123 |
L’application stocke les données exportées sur Google Cloud Storage. Le bucket GCS compte actuellement environ 50G de données historisées après 3 ans d’utilisation.
Les machines virtuelles sont sauvegardées toutes les nuits, permettant de restaurer tout ou partie du système très rapidement et avec moins de 24h00 de perte de données en cas de problème. De plus, un dump des base de données est également sauvegardé toutes les nuits.
Les applications sont déployées sous la forme d’images Docker. L’image peut être construite de deux manières :
-
via une commande Maven inviquant un goal SpringBoot permettant de construire l’image docker dans le cas des projets SpringBoot
-
via un Dockerfile et un script "build.sh" présent dans le projet et construisant l’image Docker pour les autres projets.
Le déploiement de la stack docker se fait à l’aide d’un script shell. Le script est chargé d’injecter dans le fichier docker-compose.yml et les différents fichiers properties les valeurs spécifiques à un environnement, puis de lancer le déploiement de la stack.
Les scripts sont en gestion de configuration, dans un projet dédié. Le projet sera partagé lors de la phase de réversibilité du projet.
| Composant | Rôle | URL de la branche de dev |
|---|---|---|
Cette documentation |
Documentation |
|
Chouette |
Import / export / validation offre |
https://github.com/okina-transport/chouette/tree/okina_develop_NA |
Marduk |
Orchestrateur |
|
Uttu |
Backend Zonal |
https://github.com/okina-transport/uttu/tree/first_okina_version |
Enki |
Frontend Zonal |
https://github.com/okina-transport/flexible-transport/tree/naq_develop |
Tiamat |
Backend Arrêts |
|
Abzu |
Frontend Arrêts |
|
Baba |
Backend Organisations |
|
Chouette2 |
Frontend offre |
https://github.com/okina-transport/chouette2/tree/okina_develop |
Ninkasi |
Frontend Organisations / admin |
|
Nabu |
Backend job status |
|
Kakka |
Scheduler export Arrêts |
|
Bogu |
Composants ReactJS communs |
|
Netex-java-model |
Générateur modèle Netex en Java |
|
Bel |
Frontend portail producteurs |
|
Irkalla |
Synchronisation Tiamat / Chouette |
|
Chouette2-i18n |
Traductions Chouette2 |
|
Chouette-projects-i18n |
Traductions Chouette2 |
Plus d’information concernant le modèle de données Netex associé à NeTEx est disponible sur le site d’Entur