Cette page a pour objectif de présenter le travail des équipes d'ingénieurs, réalisé dans le cadre du Groupement De Services du CNRS Mathrice (GDS 2754 du CNRS).

Afin de donner une vue synthétique et schématique de l'architecture et des méthodes mises en œuvre, nous avons réalisé un poster intitulé « Architecture DevOps de PLM MATHRICE » ou « PLM MATHRICE DevOps Architecture » en anglais. Ce poster a été présenté aux JRES 2015 de Montpellier.

Le poster

Mathrice

Tout d'abord, présentons Mathrice brièvement. Mathrice est l'acronyme de "Math, Réseau d'Information, de Communication et d'Echange".

Mathrice est d'abord un réseau de métier regroupant les informaticiens (BIATSS et quelques chercheurs) affectés aux missions des Administrateurs Système et Réseau (ASR) des laboratoires de mathématiques du CNRS.

Mathrice est également un Groupement De Services du CNRS (GDS) ayant pour objectif de mettre à disposition des services numériques à portée nationale pour la recherche en mathématique effectuée au sein des unités de l'INSMI du CNRS. Ces unités sont pour un grand nombre mixtes, c'est-à-dire qu'elles possèdent d'autres tutelles que le CNRS, notamment les universités qui les hébergent ainsi que différentes écoles ou autres instituts de recherche. Les services sont également utilisables par tout collaborateur extérieur.

En résumé, Mathrice est constitué d'un ensemble de personnes oeuvrant à procurer un environnement numérique de travail, nommé PLM pour Plate-forme en Ligne pour les Mathématiques, favorisant le nomadisme et la collaboration à une thématique spécifique : la recherche en mathématique.

PLM pour Plate-forme en Ligne pour les Mathématiques

La PLM offre à la communauté mathématique des services numériques d’organisation et de production personnelle, de communication, et de travail collaboratif. Elle mutualise aussi des services d’accès à l’information scientifique, à des services de calcul, etc

Son architecture peut être représentée sous forme de tour ou de pile (cf « Mathrice Services Stack » sur le poster en partie gauche).

De sa base correspondant à l'implantation physique des matériels jusqu'à son extrémité présentant un échantillon des services numériques accessibles, sont déclinés les différentes ressources techniques et technologiques mises en œuvre.

Depuis 2012, toute évolution de cette plate-forme est envisagée sous un angle DevOps. L'implémentation de l'architecture matérielle mais également logicielle peut être décrite selon ces 3 modèles :

  • IaaS (Infrastructure as a Service) : pour l'infrastructure matérielle de base
  • PaaS (Platform as a Service) : pour les différents serveurs applicatifs de la plate-forme
  • Saas (Software as a Service) : pour l'interfaçage des services applicatifs/utilisateur

L'infrastructure matérielle

Les 4 sites principaux sont aujourd'hui équipés de façon similaire :

  • un sas (ssh) pour accéder au réseau d'administration des machines (pour les opérations d'arrêt, de redémarrage, d'installation ou de configurations matérielles ou logicielles des systèmes) ;
  • un serveur de stockage et son secours sous FreeBSD et système de fichiers ZFS ;
  • une infrastructure virtualisée reposant sur au moins 2 hyperviseurs en équilibrage de charge (sous KVM) ;
  • un filtrage réseau à plusieurs niveaux (entrée de campus, propre à chaque site et par service).

Les hyperviseurs sont banalisés et ne servent qu'à faire tourner des machines virtuelles (VM), dont les disques sont situés sur le serveur de stockage, qui les exporte par NFS. Les données utilisateurs, également localisées sur le serveur de stockage, sont montées sur les VM par NFS via un réseau dédié.

Toujours dans cette démarche de normalisation, les configurations ont été factorisées et centralisées (par puppet + kickstart + git) selon des procédures affinées au cours du temps.

L’infrastructure matérielle principale est localisée géographiquement dans les laboratoires de mathématiques : au LAREMA sur le campus de l'université d’Angers, à l'IMB sue le campus de l'université de Bordeaux , au LPP Laboratoire Painlevé du campus de l'université de Lille 1 et à l'ICJ Institut Camille Jordan sur le campus de l'université de Lyon 1 ; donc sur 4 sites éloignés, interconnectés au travers du réseau RENATER.

Un cinquième site héberge le service de sauvegardes, situé à l'UJF sur le campus de l'université de Grenoble. Enfin, l'université Paris-Saclay héberge l'infrastructure de stockage cloud du Labex CARMIN. L'ensemble de ces sites est également interconnecté par un réseau L3VPN de RENATER.

Les serveurs applicatifs de la plate-forme

Actuellement, chaque service est isolé dans une machine virtuelle et décrit dans un outil de gestion de configurations auquel est associé un mécanisme d'historisation. L'objectif de ce choix est de fournir des environnements de travail reproductibles afin de tendre vers une architecture de micro-services.

Concrètement, un mécanisme de création automatique de VM a été mis en place, couplé avec le gestionnaire de configurations puppet afin de proposer des environnements systèmes prêts à l'emploi répondant aux niveaux de sécurité et de filtrage prédéfinis sur la plate-forme. Enfin, les configurations sont historisés avec le gestionnaire de versions git. Différents systèmes d'exploitation sont proposés afin de ne pas restreindre l'offre d'une part, mais de ne pas non plus se perdre dans de nombreux environnements hétéroclites. Chaque service est ensuite installé et personnalisé sur la VM lorsqu'il s'agit d'applications au format source ou bien développé pour les logiciels spécifiques internes. De cette façon, la PLM offre des espaces de disques partagés (disque, plmbox), une messagerie électronique, des outils de création de listes de diffusion multi-domaines (sympa), de réseaux virtuels (VPN), de gestion de documents versionnés (git, svn), de développement de projets scientifiques, d'éditeurs partagés (plmlatex), ...

AuthPLM et Oauth2 : Un des challenges du projet fut de concevoir un système d’authentification unique, fiable, et simple, c'est-à-dire pouvant :

  • reconnaître les utilisateurs de la PLM au travers de leurs multiples identités numériques ;
  • les différencier comme membres de la communauté mathématique parmi toutes les personnes d'un même établissement fournies par les fédérations d'identités ;
  • bénéficier d'une authentification unique (SSO) basé sur la Fédération d'Identité RENATER.

Un module de convergence des identités a donc été développé. Il permet de mettre en relation l'identité présentée pour un usager par son établissement d'appartenance (universités, centre de recherche, etc.) et son référencement dans l'annuaire Emath (note 1). Ainsi, cette solution facilite l'accès à la Plateforme ce qui permet aux membres de la communauté mathématiques d'associer leurs différentes identités numériques.

Les applications accèdent à ces informations via le protocole OAuth2, qui permet de filtrer les attributs utilisateur qui seront transmis à chaque application. A l'aide des ces attributs, des habilitations peuvent être définies pour chaque service. Il est ainsi possible de différencier :

  • les administrateurs de services ;
  • les utilisateurs de la communauté mathématique avec privilèges hérités de l'unité d'appartenance ;
  • les utilisateurs de la communauté mathématique sans privilège ;
  • les invités.

La notion d'appartenance à un laboratoire est délégué à un correspondant identifié par unité (généralement l'informaticien ASR de l'unité).

Ainsi, n'importe quelle application peut bénéficier de cette fonctionnalité dès lors qu'elle supporte le protocole ouvert OAuth2. C'est le cas par exemple du nouveau portail math. Depuis ce site, les membres de la communauté mathématique française ont accès :

  • à la bibliothèque composée de la documentation en accès libre, des archives en licences nationales ou de certaines ressources en accès contrôlé ;
  • aux services numériques de la PLM (Plateforme en Ligne pour les Mathématiques) : courrier électronique, disque internet, invitation de collaborateurs extérieurs, PLMbox, serveur SAGE, plateforme WIMS .... ;
  • aux annuaires de la communauté (personnes, laboratoires et bibliothèques), à l'agenda national des séminaires et colloques,
  • ainsi qu'une liste de sites utiles.

L'utilitaire de partage et de contribution à des articles en LaTeX (ShareLaTeX) est en cours de déploiement sur la PLM grâce à ce mécanisme.

L'interfaçage des services applicatifs

L'architecture logicielle repose sur le développement de web-services, l'utilisation d'API standards et sur la production d'interfaces utilisateur intégrées et modulaires.

L'ensemble des applicatifs déployés sur la PLM sont instrumentés par des web-services (soit présents d'origine, soit développés spécifiquement), ce qui permet de les rendre tous interopérables. Les technologies de frameworks les plus adaptées sont utilisées : ruby Sinatra, python Django ou encore perl FCGI.

Les protocoles d'échanges et de manipulation de données utilisés au niveau des API sont aussi bien REST, SOAP, JSON, EXT-DIRECT ou RPC.

La gestion de session est assurée par Couchbase et l'authentification par le trio CAS+Shibboleth+OAuth2.

Enfin, la présentation utilisateur est développée en Html5 ou javascript, notamment avec les frameworks MVC, MVVM/VC Sencha ExtJS, Angular ou NodeJS.

Gestion et cycle de vie DevOps du projet PLM

L'expérience nous a montré qu'il ne suffit pas de mettre en place un outillage informatique structurant pour réussir un projet.

Les architectures matérielles et logicielles mise en œuvre sont le résultat d'une démarche tout d'abord pragmatique. La méthodologie suivie s'inspire également de la méthode Agile dans le but de développer rapidement et efficacement les applications. Les outils et les technologies ont donc été choisis légers, c'est-à-dire à couplages faibles, interagissant via des protocoles simples (par exemple REST), et soumis à des cycles de développement courts.

La roue de Deming, représentée en partie droite du poster, est une illustration de la démarche qualité PDCA (Plan Do Check Act), son nom vient du statisticien William Edwards Deming, telle qu'elle est mise en œuvre dans le projet. La méthode comporte quatre phases permettant d'améliorer en continu la qualité des services :

  • Phase 1 Plan : tous les développements sont réalisés sur un environnement technique de développement (DEV).
  • Phase 2 Do : les environnements DEV sont regénérés à l'identique pour proposer les services en pré-production (PRE)
  • Phase 3 Check : des tests sont réalisés visant à apporter des corrections éventuelles
  • Phase 4 Act : les services sont reversés dans l'environnement de production (PROD)
  • Bouclage sur la phase 1 : une réflexion sur les retours/remarques des utilisateurs et les propositions d'améliorations génèrent de nouveaux développements qui suivront ce même cycle.

Ces étapes sont facilitées par l'ensemble de l'architecture matérielle et logicielle :

  • l'infrastructure virtualisée sous KVM sur des filesystem ZFS exportés en NFS ;
  • le système de gestion de configurations des OS et des Vms (puppet) ;
  • les wikis, les listes de diffusion (sympa) et les salons de discussion (jabber) utilisés quotidiennement par les équipes ;
  • les gestionnaires de version (git et svn) qui assurent l'historisation des actions ;
  • les processus de gestion sémantique de version et des dépendances produisant du code packagé (sous la forme dev-gem, pre-gem puis prod) ;
  • les logiciels de monitoring (icinga, xymon) et l'intégration de métriques pour l'évaluation (soit standards tel que webalizer ou développés spécifiquement) ;
  • les outils de gestion des demandes utilisateurs et de rapport de bugs (RT, Bugzilla).

Les équipes

Actuellement une trentaine d'ingénieurs travaillent ou ont travaillé sur le projet. Le graphe des équipes en charge des services, en bas à droite du poster, donne une idée de la répartition des tâches. Il n'est évidemment pas exhaustif.

L'organisation stigmergique

Les forces en présence, basées sur le volontariat, sont disséminées sur toute la France, avec des temps de mobilisation restreints dans le sens où les personnels sont principalement affectés à des unités de recherche. Potentiellement, les ressources humaines pouvant participer à ce projet sont conséquentes, le vivier est constitué des informaticiens des unités de recherche émargeant au GDS Mathrice. Chaque agent organise son temps de travail dans son unité pour dégager des créneaux avec toute ou partie de l'équipe nationale. Le volume en temps consacré individuellement est donc très fragmenté.

L'infrastructure est gérée par la PLM Team, le développement par la PLM Dev. La constitution de chaque équipe varie et dépend des facteurs suivants :

  • l'intérêt ou l'implication technique d'un individu à un instant donné (contribuer à l'infrastructure ou au développment, à la documentation, aux tests, apport d'une expertise, etc.) ;
  • le temps qu'il peut y consacrer à ce moment là (une personne peut être très présente sur plusieurs mois, disparaître et revenir, ou non...).

Seuls les outils et les méthodes sont imposés pour préserver la stabilité et la fiabilité des services déployés. Ces outils intègrent la notion de trace exprimée dans le principe de stigmergie ce qui permet de pérenniser le savoir au sein de l'équipe.

Comme la constitution des équipes est ouverte, une personne peut s'intègrer à tout moment dans la démarche de proposer un nouveau service. Si ce service répond effectivement à un besoin (interne ou à celui des utilisateurs), il sera ajouté à l'offre globale et maintenu par l'équipe. Sinon, il sera abandonné. Le seul arbitrage réside dans l'adhésion du collectif.

A tout moment chacun s'exprime à voix égale. De fait, le groupe fait abstraction des profils professionnels de chacun (corps, grade, etc.). Actuellement, la PLM Team et la PLM Dev sont constituées de personnels allant du technicien à l'ingénieur de recherche, tous considérés avec le même niveau de responsabilité.

Une démarche orientée DevOps

De la superposition des personnes agissant aussi bien au niveau développement (PLM Dev) qu'au niveau opérationnel (PLM Team) émerge cette approche DevOps avec un profil par individu Dev ou Ops variant naturellement au cours du temps.

La dynamique individuelle induit des services déployés par des équipes restreintes (un, deux, trois individus). Ces mêmes personnes s'investissent dans l'instrumentation nécessaire (d'où la forte porosité entre administration système et développement) car elles comprennent la finalité de mettre à disposition des micro-services opérés par des web-services pour une meilleure intégration. De fait le travail se répartit sur de petites équipes et fonctionne sur le modèle de l'extreme programming.

La volonté de voir ces services maintenus et disponibles incite à réaliser les transferts en compétences et motive l'appropriation des technologies mises en oeuvre.

Bilan et perspectives

Le GDS qui est en charge des services numériques (la PLM) à destination de la communauté mathématique française, est avant tout une émanation du réseau de métier des ASR des laboratoires de mathématique français (Mathrice).

Depuis plus de 15 ans, ce réseau reste très actif avec ses rencontres bisannuelles, ses actions de formations et sa liste de diffusion. Elles contribuent à maintenir un lien humain et un bon niveau de compétences qui favorisent l'ancrage des agents dans leurs unités. Le dynamisme du réseau repose aussi sur sa cohérence thématique : un service apporté aux utilisateurs d'une même communauté, donc sur des problématiques très proches.

De ce fait, Mathrice constitue bien l'élément structurant qui permet aussi de préserver la proximité entre les usagers et les équipes en charge des services numériques.

Dans ce contexte, l'organisation humaine basée essentiellement sur la confiance et la responsabilité des participants fonctionne bien, elle :

  • implique des personnes motivées à produire et à offrir des services ;
  • apporte de la compétence à chacun ;
  • permet d'acquérir une plus grande polyvalence ;
  • fait émerger des personnes structurantes garantes d'une vision commune et de la bonne poursuite des objectifs.

Pour nous, cette expérience constitue une évolution possible de notre métier d'ASR : plus polyvalent, plus collaboratif, plus transverse.