Chez Cantor, nous utilisons la technologie Docker depuis ses débuts.
Nous sommes très grands consommateurs de celle-ci, au point de « dockeriser » chacune de nos applications tant que possible. 

En association avec Docker, nous utilisons également Ansible pour automatiser et centraliser le déploiement de nos applications depuis maintenant quelques années. 

De ce fait, nous possédons à ce jour plusieurs centaines de conteneurs d’applications aussi bien pour des environnements de sandbox, de recette mais aussi de production.

C’est donc tout naturellement que nous nous sommes posés la question des technologies d’ orchestration de ces conteneurs. 

Cette question est d’actualités lorsque l’on évoque la question d’un plan de reprise d’activité (PRA), renforcée en cette période de confinement.

Aujourd’hui les applications ne sont plus monolithiques.
Elles sont au contraire composées de multiples composants mis en conteneurs associés qui doivent fonctionner ensemble. 

L’orchestration de containers permet avant tout d’organiser un flux de travail des composants individuels et du niveau des applications. 

A partir du processus d’organisation de travail, Les outils d’orchestration de containers permettent aux utilisateurs de guider le déploiement de conteneur et d’automatiser les mises à jour, la surveillance d’état et les procédures de basculement.

Il y a plusieurs mois, nous avons réalisé une première étude pour évaluer Kubernetes dans notre contexte. 

Notre étude nous a démontré qu’il existe bien des alternatives plus adaptés que l’utilisation de Kubernetes. Nous avons donc étudié l’hypothèse d’une orchestration de containers plus pragmatique et simple à intégrer : Swarm.

Pour Cantor, l’orchestration de containers ont des objectifs particuliers :

• Des déploiements et mises à jour simples
• Une meilleure gestion des ressources
• Des services résilients
• Une scalabilité

• Un ensemble de nœuds prêts à l’emploi
  • Un (ou plusieurs) manager
  • Un (ou plusieurs) worker
• Un moteur de conteneur : Docker
• Un moteur d’orchestration : Swarm

Contexte d’usage d’un container d’orchestration

Dans une architecture orchestrée, nous communiquons uniquement avec nos managers.
Nous leur demandons de déployer nos services, indépendamment de leurs localisations. Le manager définit sur quelle machine le déployer et chaque nœud susceptible de l’héberger.

Déploiement

ETAPE 1 : Nœud hors service

ETAPE 2 : Redéploiment

 La scalabilité

La « scalabilité » est le fait de déployer plusieurs instances d’un même service.

Il y a deux avantages majeurs à la sacalabilité :

• La continuité de service
• La répartition de charge

La continuité de service est assuré par le manager qui conserve son état initial compte-tenu de ses nœuds à disposition. 

C’est également lui qui s’occupe de la répartition de charge ou load balancing entre les différents couple nœud-service.

ETAPE 1 : Nœud hors service

ETAPE 2 : Préserver l’état initial

 

Le manager connaît donc en temps réels les états de ses nœuds et services.

Cela fonctionne parfaitement pour des services « stateless ».

Qu’en est-il des services « stateful » ?

Effectivement, dans ce type d’architecture, le service ou le programme peut être déployé n’importe où sur le système, mais il est indispensable de l’associer aux données qui lui sont propres. 

En effet, le programme doit enregistrer les données clients des activités d’une session pour une utilisation dans la session suivante.  

 

ETAPES 3 : Services stateful

La solution intuitive est donc de partager les données entre les différents services déployés.

Nativement, Docker propose des volumes pour persister la donnée des conteneurs, cependant Swarm ne gère pas ce partage entre les différents nœuds.

Alors dans quelles mesures peut-on répliquer ce service transverse ?
La question reste ouverte !

Le Design For Failure (DFF) est la capacité d’un système à résister aux pannes d’autres composants, autrement dit la résilience d’une application.

• Tolérance aux pannes

• Prévention des pannes

• Supervision

Jusqu’à maintenant on a parlé de comment protéger des appels vers des services externes. Il faudrait donc répéter/réutiliser/dupliquer les stratégies de DFF pour chaque services distants, comme dans le schéma suivant :

C’est là qu’interviennent les principes d’API Gateway, de BackForFront et de Service Mesh

Dans quel contexte suivre la température d’une salle serveur ?

Après un problème de clim survenu malencontreusement dans la salle serveurs, nous avons compris l’urgence d’installer un système permettant de mesurer et de gérer la température de la salle de façon constante. Un système qui permet d’être averti en cas de clim en panne !

À Cantor, nous avons un pôle informatique industriel et instrumentation … alors nous pouvions le faire nous-même, rapidement et pour un coût négligeable.

Le Raspberry Pi est un nano-ordinateur avec un processeur ARM. En plus de sa petite taille, de son faible coût, la consommation de celui-ci est assez faible et il convient pour la surveillance à distance (dans un environnement non industriel). Ce système nous permettrait donc de surveiller à distance et de façon constante la température et surtout d’être averti en quelques minutes si la clim du local technique tombe en panne.

Ainsi pour mesurer la température de notre salle serveurs nous nous sommes doté d’un Raspberry Pi et d’une sonde 1-wire DS18B20.

Quel matériel nécessaire ?

– un Raspberry Pi 2
– Une sonde de température DS18B20 1-wire (entre 1 à 6 € selon le modèle)
– Une résistance de 4.7K Ω
– Quelques câbles
Soit un budget total d’environ 50 €.

Quel montage ? 

Nous avons fait le choix pour notre montage d’opter pour des sondes DS18B20 qui utilisent le bus 1-wire. La résolution de celle-ci est ajustable, soit de 9 à 12 bits et la plage de mesure est de -55°C à 125°C. Le bus 1-wire est basé sur la notion de maître/esclave. Le maître, ici le Raspberry Pi, interroge les différents esclaves à travers le bus ou leur envoi des ordres. Il est donc possible de brancher plusieurs sondes en parallèle sur notre bus.

 Schéma branchement sonde DS18B20

Ainsi nous avons donc branché l’alimentation du capteur sur la pin 3.3V du Raspberry Pi, la masse du capteur sur la pin de masse et enfin la patte de données de la sonde à la pin GPIO 4. La résistance de 4.7K Ω est alors placée entre l’alimentation et le fil de données. Afin d’éviter toute surchauffe nous avons pris le soin de vérifier le sens de branchement de la sonde.

Sonde DS18B20

Quelles résultats ?

Après avoir configuré le système et programmé la surveillance, nous avons en permanence l’enregistrement des températures et accès à l’historique (tiens, quelqu’un a ouvert la porte 🙂 )

L’envoi d’un email d’alerte à notre équipe infra reste le point clé du projet. Dès que la température dépasse le seuil que nous avons configuré, un mail est envoyé à l’équipe infra, qui pourra intervenir au plus vite.

Quel bilan ?

Notre solution « surveillance de la température d’un local technique » fonctionne 24 heures sur 24, 7 jours sur 7 et 365 jours par an. Avec une technologie simple et un coût négligeable.

N’hésitez pas à nous contacter si vous souhaitez des détails sur cette petite installation.

Dans le domaine de l’analyse d’images, un problème récurrent est celui de la détermination des caractéristiques morphologiques individuelles de particules dans un ensemble plus vaste.

Les domaines d’application sont très variés. On citera par exemple en biologie les fréquences de particules d’ADN anormales dans une série d’images obtenues par microscopie optique. Autre exemple, les calculs de diamètres de particules en suspension dans les huiles dans l’extraction du pétrole, ou encore les répartitions de tailles de grains de composés étudiés dans la métallurgie.

Le but est souvent de permettre l’automatisation des calculs sur des séries d’images, particulièrement quand les particules à étudier sont nombreuses.

L’idée centrale de l’analyse individuelle de particules est de calculer de façon simultanée, ou en tout cas d’effectuer en un nombre minimal et maitrisé de balayages sur chaque image, une batterie de mesures individualisées par particule.

Après détermination, des caractéristiques telles que la taille, la morphologie et la composition des particules sont analysées afin de les classer, les filtrer et finalement en extraire l’information recherchée.

• Individualisation des particules

La première étape est de traiter l’image afin d’obtenir une image binaire (souvent de façon automatisée) puis d’individualiser les objets obtenus après binarisation, ce qui revient à les compter.

• Calcul des mesures individuelles

Une première phase de calcul des mesures des particules s’effectue en un minimum de balayages sur chaque image. Il s’agit de mesures primaires (par exemple, l’aire et le périmètre bruts de chaque particule).

Dans une deuxième phase, les mesures composées, c’est-à-dire combinant plusieurs mesures primaires, sont déduites particule par particule.

Ces deux phases sont naturellement essentielles dans l’analyse de particules.

• Filtrage des particules

A partir des mesures calculées, il est possible alors de filtrer les particules en suivant des règles déterminées par les utilisateurs. Les règles les plus simples sont de respecter des seuils de variation pour une ou plusieurs mesures choisies. Elles servent ainsi à éliminer les particules anomales dans la population étudiée.

La fréquence et les similitudes dans la résolution de ce type de problème nous ont amenés à fourbir une boîte à outils de transformations d’images relativement classiques, dont la première qui est la numérotation de la population de particules que l’on veut étudier.  La partie centrale de la boîte à outils est l’implémentation du calcul des mesures prises, ainsi que la façon de les archiver dans une base de données. Il s’agit de pouvoir retrouver aisément toutes les mesures qui ont été prises et calculées pour chaque particule, tout en autorisant inversement, pour chaque mesure calculée, d’en obtenir l’histogramme pour toutes les particules.

Un cas qui revient souvent est celui du classement de la taille des grains dans des matériaux. Le calcul d’une mesure particulière (typiquement la surface) est choisi sur ce qui est visible dans l’image. Le calcul est itéré sur toutes les particules individualisées, représentant par exemple des graviers, et est suivi d’un filtrage par taille. L’équivalent est une opération de tamisage numérique pour obtenir une répartition granulométrique.

Pour réaliser ce genre d’opérations, nous avons mis au point une bibliothèque de traitement dans laquelle on calcule toutes les mesures qui sont sélectionnées. Ce module, nommé Escalus, opère les calculs et gère les résultats de mesure en permettant de les ranger soit pour une particule donnée, soit pour une mesure donnée et cela de façon simultanée.

Pour implémenter la manipulation des images nous utilisons une deuxième bibliothèque maison, soit Noema, qui permet de gérer les données images (pour y accéder et y écrire) et dans laquelle on a également la notion de transformation qui permet de traiter un ensemble d’images en parallèle. Nous pouvons ainsi obtenir l’image binaire avec une mécanique de parallélisation des traitements en pipeline. Ce module favorise de façon générale la parallélisation du traitement dès qu’on affine une image à l’entrée du pipeline (ou plusieurs images en fonction du nombre de tuyaux), la capacité du système dépendant bien sûr du nombre de machines disponibles. De fait, les traitements sont effectués en cadence comme sur une chaîne de production. Ce système permet d’exploiter les capacités parallèles des processeurs.

Aujourd’hui, nous utilisons de nombreuses applications dans des buts très divers. De ce fait beaucoup d’échanges sont effectués entre les utilisateurs et les applications et même entre applications. Ce qui a pour effet de générer un nombre conséquent de logs. Ainsi avec la multiplication de ces échanges, les utilisateurs ne peuvent pas consulter manuellement toutes les applications pour consolider ces données.

L’idée était donc de mettre en place un système qui permettrait de simplifier ce processus de consultation pour toutes nos applications.

Ainsi à Cantor, étant donné que 90% de notre infrastructure est « dockerisée », nous avons décidé d’en profiter pour mettre en place un système centralisé afin d’optimiser notre temps de travail en réduisant les efforts nécessaires à la consultation fastidieuse des fichiers logs.

Pourquoi une simplification des fichiers logs  ?

Ayant pour fonction le stockage des lignes d’informations générées par le serveur, la gestion des fichiers de logs est bien souvent contraignante, cependant il s’agit d’une source d’information précieuse, permettant la détection d’erreurs.

L’objectif était donc de ne plus aller consulter manuellement les fichiers journaux, ce qui impliquait de se connecter sur chaque machine, d’obtenir le lieu de stockage des fichiers logs de chaque application avant de pouvoir les consulter.

Pour simplifier cette gestion des logs, nous avons donc cherché à mettre en place un système centralisé et basé sur notre utilisation de Docker.

Quel système centralisé par Docker ?

Pour consolider les logs de toute une infrastructure dans une seule et unique application, Cantor a choisi d’intégrer une stack ELK avec Docker. Soit l’acronyme de trois projets open source : Elasticsearch, Logstash et Kibana.

En effet les composants ELK sont libres et gratuits, sans compter leur configuration simple et le fait qu’il n’y a pas d’impact applicatif. La mise à disposition de leur conteneur s’est intégrée parfaitement avec nos pratiques et nous avons de cette façon pu facilement mettre en place l’environnement.

De façon plus détaillée, la stack ELK se trouve en bout de chaîne d’une centralisation à deux niveaux. Dans un premier temps, les méthodes de logging natives à Docker nous permettent de centraliser les logs sur un seul et même conteneur dans un voisinage réseau. C’est à ce stade que le deuxième niveau prend place, avec une synchronisation distante des logs auprès de chacun des conteneurs de premier niveau. Nous sommes alors capables d’obtenir l’intégralité de nos fichiers de logs de cette façon, qui sont ensuite indexés dans la stack ELK.

Un des avantages implicites de cette centralisation est l’économie d’espace disque. D’une part les logs ne sont plus stockés localement sur nos applications, et d’autre part la stack ELK possède un système de purge permettant de fixer nos règles de conservation des logs.

Quelle système d’automatisation avec Ansible ?

L’automatisation est aujourd’hui un élément essentiel de la transformation numérique.
En complément de Docker, nous utilisons donc Ansible pour orchestrer nos déploiements de conteneurs ou de configurations. Ce qui nous permet de configurer automatiquement nos machines pour les brancher sur notre chaîne de log.

Ainsi nous avons la capacité de déployer l’ensemble des containers de gestion de logs en une ligne de commande, que ce soit pour les containers locaux à chaque VM ou pour le cœur de la stack ELK mais aussi pour l’outillage en charge de rapatrier l’ensemble des logs de chaque VM.
L’automatisation avec Ansible a permis un gain de temps considérable et surtout d’éliminer les taches répétitives.

En somme, chez Cantor nous sommes capables de nous abstraire de la gestion des fichiers logs en mettant en place un système de centralisation à deux niveaux. A l’aide de Docker et Ansible, la totalité de notre infrastructure est concernée et branchée sur notre chaîne de logs et nous pouvons à tout moment les consulter au travers de tableaux de bords sur une seule et même interface de visualisation.