Qu’est ce que MiNET ? C’est l’association qui gère la partie étudiante du réseau de l’INT, soit environ 700 chambres réparties sur 7 batîments. Pour cela, elle dispose d’un réseau avec d’un coté, une fibre optique provenant de l’école et donnant accès à Renater et Internet, et de l’autre coté, une vingtaine de switchs et une centaine de bornes WiFi.

Un des grands problèmes est donc la gestion de ce réseau et plus particulièrement des accès : seuls les adhérents doivent pouvoir se connecter.

Depuis des années des applications ont été développées, chacune apportant une amélioration. ADH3 a apporté le concept de base de données liée avec les services réseaux. ADH4 a renforcé ce lien en passant sur un annuaire LDAP et des vlans attribués par le serveur Radius. La nouvelle version, ADH5, a quand à elle, permis de s’affranchir de la saisie des adresses MAC des nouveaux adhérents grâce à un mécanisme de détection/association.

L’architecture est plutôt complexe, il y a deux manières d’accéder aux données : en tant qu’administrateur ou en tant qu’adhérent. Ces deux applications sont cloisonées dans deux applications Rails distinctes. L’application pour les administrateurs contient entre autres une batterie de tâches à exécuter à intervalle de temps régulier. Par exemple, la libération des IPs des adhérents qui ne sont plus à jour ou le système de tickets.

Aperçu du portail et du site d’administration :

alt

alt

Chacune de ces applications est testées unitairement et via des tests sur navigateur. Le tout est automatisé grâce à un serveur Jenkins. Au final, on obtient un pipeline permettant une meilleure optimisation du temps de test.

Aperçu du pipeline :

alt

A la fin de celui-ci, nous déployons automatiquement sur une environnement de test similaire à la production. La différence étant, par exemple, que le serveur SMTP est remplacé par mailcatcher (un faux serveur SMTP avec interface graphique), que les chambres n’ont pas de ports associés, etc.

Après quelques commits sur la branche master et si la version en environnement de test est satisfaisante, nous pouvons déployer sur la production. Pour cela, il suffit de faire pointer la branche de production vers le commit désiré. Jenkins va rejouer les tests sur cette branche (les jobs sont séparés de la branche master). Il n’y aura plus qu’à lancer le déploiement en lancant manuellement le job sur Jenkins.

alt

En ce qui concerne le serveur de tâches/jobs (remplace en quelques sortes le cron), il est lui aussi dupliqué test/production. Il est réalisé grâce à un serveur Jenkins qui va récupérer la dernière version du dépot des jobs et lancé la tâche désirée.

alt

Nous bénéficions alors de tous les avantages de Jenkins : prévenir si la tâche échoue, envoyer par mail les résultats d’une tâche, etc.