Sommaire
Le WeShare, c’est le premier lundi de chaque mois, journée pendant laquelle l’ensemble de la tribu se retrouve pour du partage.
En septembre, à l'occasion de notre rentrée, nous avons eu un incroyable lot de conférences, quickies, REXs, Démonstrations et Hands-on… Le contenu est d’excellente qualité et en attendant que vous en retrouviez certains en conférence, vous pouvez retrouver ci-dessous un résumé de chacun d’entre eux.
REXs
Le platform engineering, ou comment libérer les devs des contraintes ops
Le Platform Engineering est une discipline qui permet aux développeurs de disposer des outils nécessaires pour déployer et gérer leur application, sans avoir besoin des équipes systèmes. Elle peut être opposée à la méthodologie DevOps, qui demande souvent d'intégrer des éléments ops aux équipes de développement. Dans ce talk, Clément nous présente comment son client a abordé cette problématique, et a créé une solution permettant aux équipes de développement de déployer des applications sur AWS+Kubernetes sans avoir à connaître l'un ou l'autre, et ce en autonomie totale.
L’application du platform engineering a permis d’augmenter la vélocité de déploiement tout en sécurisant les environnements. Bien que le platform engineering demande un investissement initial important, dans des grands projets il permet sur le long terme d’avoir la méthode de déploiement la plus efficiente avec une petite équipe “plateforme” pour maintenir et améliorer la plateforme.
Effectuer une migration d'un cluster EKS sans interruption de service.
Au cours de ce retour d’expérience, Otmane nous présente une problématique à laquelle il a dû faire face chez son client. Il s’agit d’une migration de cluster EKS (recréation, upgrade, adaptation de la configuration pour des besoins de renommage) et ce, sans interruption de service. Dans sa solution choisie, il est passé par une duplication de l’infrastructure et le déploiement d’un deuxième gestionnaire d’API temporaire pour pouvoir facilement tester la nouvelle infrastructure en parallèle. Une fois la validation technique et fonctionnelle effectuée, il a pu simplement rediriger le trafic vers le bon environnement. En effectuant ces opérations sur chacun des environnements, du dev à la prod, il a pu s’assurer de la maîtrise de sa solution entièrement automatisée et minimiser l’interruption de service. Techniquement, par un jeu de duplication de workspace terraform et de recopie du state, l’opération lui a permis de ne pas avoir à supprimer l’ancienne infrastructure pour pouvoir la recréer.
Tools in Action
Renovate et la gestion des dépendances
Renovate permet de détecter les mises à jour des dépendances d'une application. C’est un outil, présenté par Antoine, qui se greffe directement sur le repository de sources et est compatible avec un grand nombre de solutions, de GitHub à GitLab en passant par AWS commit et Bitbucket notamment. Il couvre de nombreux outils comme docker, golang, java, php, javascript, python, ruby, rust…
Renovate vient lire les fichiers de dépendances en auto-découverte dans votre repository. Dans l’idéal vous le lancez régulièrement à l’aide des outils de CI intégré comme GitHub actions ou GitLab CI. Le petit côté magique de l’outil est qu’en le lançant une première fois, il viendra vous proposer une pull request / merge request sur votre repository pour y ajouter un fichier de configuration par défaut.
Dans cette configuration vous pouvez activer bon nombre d’options, le flow d’approbation désiré, le niveau de version que vous voulez incrémenter pour ceux qui font du semver, regrouper les PRs pour éviter d’en avoir une seule par version ou par outil et faire une sorte de rate limiting des PRs. Renovate propose également la mise à jour des dépendances transitives s’il y en a. Vous aurez également la possibilité de retrouver un historique des modifications faites via les issues de votre gestionnaire de source avec des descriptions en markdown très jolies et bien documentées.
Pour terminer, Antoine nous a fait une démonstration de l’outil. Parmi les réponses aux questions posées en fin de talk, il nous explique que vous avez aussi la possibilité de référencer un repository comme source de configuration pour éviter d’avoir à répliquer vos configurations partout et ainsi propager une modification de configuration automatiquement.
Scaphandre pour Kubernetes
Scaphandre est un outil open source atteignant ce jour 1K2 stars du github, écrit en Rust, permettant de mesurer la consommation énergétique de votre application au niveau de l’OS. Il s’appuie sur Powerpcap_rapl. Dans Kubernetes, il faut être vigilant à l’accès à /proc et /sys/class/powercap pour pouvoir utiliser cet outil. Une fois mis en place, on s’appuie sur Prometheus pour remonter les métriques de puissance consommée en watt, et ensuite diviser la consommation par process.
Dans les prérequis de cet outil, vous aurez besoin d’une architecture CPU ARM, un kernel Linux et d’être sur une infrastructure bare metal ou sur une VM en propageant la métrique par l’hyperviseur (attention, les providers cloud testés, Scaleway et GCP, ne le permettent pas).
Une démo est effectuée sur un nœud bare metal, Damien et Rémi s'appuient sur le control plane de kosmos qui fait le lien avec le nœud au travers d’un tunnel VPN.
Scaphandre expose deux principales métriques, host_power et process_power. Pour avoir la puissance réellement consommée, il faut utiliser un facteur PUE (Power Usage Effectivness) pour palier aux consommations généralisées des datacenters (PUE de 1.2 par exemple). Cela permet par la suite d’effectuer une conversion en émission de CO2 en fonction de l’évolution du mix énergétique local.
Une alternative à Scaphandre existe, PowerAPI, qui a une approche similaire, écrit en Python, mais qui connaît moins de traction sur GitHub.
GreenFrame
GreenFrame est un outil pour mesurer et identifier des axes de réduction des émissions de CO2 d'un site web. Il aide les développeurs à créer des applications Web à faible émission de carbone, économes en énergie et à réduire leur empreinte environnementale, en utilisant un modèle basé sur des données scientifiques du CNRS.
Vincent nous explique le fonctionnement de l’outil avant de nous en faire la démonstration sur notre propre site web. Ce qu’il faut retenir de l'outil, GreenFrame permet de simplement et rapidement mesurer l’empreinte carbone d’une application web et d'identifier rapidement une éventuelle fuite lors d’une modification du code. Il simule le comportement des utilisateurs à l’aide de la librairie de test E2E Playwright. Il s’intègre donc parfaitement aux tests automatisés d’une CI. On regrettera que le rapport détaillé ne soit accessible que via la web UI qui fait partie de la version payante.
Multitenancy metrics
Ronan nous partage la solution de métrologie qu’il met en place chez son client. Dans les outils présents de cette stack on retrouve Prometheus, la solution de collecte de métriques qui fait plutôt l’unanimité, Mimir, qui sert de à centraliser et interroger les métriques de plusieurs clusters, Cortex-tenant, un side project de Cortex, qui sert de proxy pour gérer le sharding multi-tenant, Grafana pour l’affichage des métriques et le dashboarding et enfin Grafana Operator, l’opérateur Kubernetes de Grafana. Dans un weshare précédent, il nous avait présenté Mimir, et sa concurrence, en donnant une grille de lecture pour choisir son outil, et comment il était possible de le mettre en œuvre. Ici on jette un œil plus global sur la stack technique qui l’entoure et sur les détails de son implémentation.
Hands-on
Introduction aux réseaux de neurones artificiels
Julien nous a embarqués vers le monde complexe du fonctionnement des réseaux de neurones. En s’appuyant sur des métaphores et au fil de manipulations mathématiques de plus en plus abstraites, nous avons plongé dans les concepts tels que les poids et biais en entrée, les fonctions d’activation (ReLU, sigmoïd, tanh …), et comment calculer le gradient d’erreur d’une fonction de perte afin de propager cette information via la backpropagation et permettre au réseau d’apprendre.
Son exposé et ses exemples interactifs étaient construits dans un notebook Jupyter. Nous avons même pu mettre la main à la pâte en faisant fonctionner un “réseau” d’un seul neurone, ou perceptron.
L'event storming dont vous êtes le héros
Guillaume et Gérôme ont lancé cet atelier pour faire découvrir à une dizaine de personnes comment dérouler la méthodologie Event Storming, présentée dans un WeShare précédent, sur un cas fictif. L’idée était de modéliser le domaine métier d’une agence de voyage. Nous avons donc collé nos post-it© en suivant les différentes étapes de l’atelier (événements, actions déclenchant ces événements, acteurs à l’origine de ces actions, règles autorisant l’action, agrégats, contextes métier, etc…)
Le bilan attendu avec la plus grande impatience par l’ensemble des participants était : à quoi sert cette méthode ? Deux réponses ressortent de nos échanges :
- Partager la connaissance de l’existant entre les équipes métier et dev. Ce partage de connaissance permet également de définir un langage commun (Ubiquitous Language) voué à être employé dans toutes les étapes du projet : de la définition des US à la base de code en passant par les scénarios d’acceptance.
- Extraire des domaines métiers pour mieux définir la cible vers laquelle le SI doit évoluer (que ce soit pour du simple refactoring ou bien définir une nouvelle architecture d’infrastructure) en appliquant une approche Domain Driven Design.
Jouons avec des fonctions serverless et Slack
Guillaume nous propose de démystifier les Azure functions au travers d’un exemple simple et de la création d’une application Slack. Son objectif est de nous montrer avec quelle simplicité il est possible de répondre à des besoins de notifications, de calculs serverless ou de gestion de workflows en mode ChatOPS avec Slack.
Dans un hands-on entièrement guidé, nous avons tous pu effectivement en moins d’une heure, installer les prérequis Azure, créer notre Azure fonction et notre application Slack qui y répond.
Conférence
Traitement de données en périphérie avec Greengrass+Telegraf+GCP
Stéphane nous parle de la stack technique qu’il a pu mettre en œuvre chez son client et du cas d’utilisation concret de GTG (Greengrass, Telegraf et Google Cloud).
Tout d’abord, on retrouve AWS IoT Greengrass pour la gestion de composants qui se déploient directement sur les edge devices. Il permet donc de filtrer et de transformer des données directement sur chaque device avant de les renvoyer sur le cloud. Il permet aussi de gérer l’indisponibilité variable inhérente aux stratégies edge (les devices n’ont parfois pas accès au réseau, subissent des coupures de courants, nécessitent des mises à jour, etc.). AWS Greengrass dispose de tout un ensemble de composants standards plus ou moins techniques comme un composant qui va rediriger les logs vers CloudWatch, ou encore un broker MQTT (Moquette), ce qui va permettre d’intégrer facilement un outil tiers comme Telegraf.
Le deuxième composant de cette stack est donc InfluxData Telegraf. Grâce à une collection de plugins incroyables, il permet de récupérer de la donnée de multiples sources (on va d’un broker MQTT à des statistiques d’utilisation CPU/Mémoire, en passant par des données métiers comme des statistiques de serveur Minecraft), de faire des traitements de données (rotation de payload, renommage de champ, etc.), de les agréger (calcul de moyenne, médiane, etc.) et ensuite de les renvoyer vers de multiples cibles (comme de l’AWS Kinesis, du Topic PubSub GCP, ou même des fichiers CSV si c’est là votre besoin !).
Dans le cas métier qu’a traité Stéphane, c’est un Topic PubSub GCP —que l’on ne présente plus— qui a été utilisé pour la récupération des données traitées et leur consolidation dans Big Query.
Voilà un beau cas pour montrer que tirer les meilleurs services de chaque cloud provider, en tout cas le plus adapté à son besoin, est la bonne manière de s’appuyer sur le cloud !
Naviguer dans le Labyrinthe : Les Dangers de la Surutilisation d'Outils et de la Surenchère de Complexité en DevOps et Cloud
Guillaume nous déroule un talk qu'il a déjà porté en conférence récemment (JUG Summer Camp & Cloud Sud). À l'ère numérique actuelle, la multitude d'outils et de technologies disponibles pour le DevOps et le Cloud Computing présente à la fois des opportunités et des défis. Un problème critique découle de cette abondance, la surutilisation d'outils et la surenchère de complexité. La surutilisation d'outils se réfère à l'utilisation excessive d'outils, de plateformes ou de technologies, souvent au-delà de ce qui est réellement bénéfique. La surenchère de complexité, quant à elle, dénote le développement de systèmes si complexes qu'ils deviennent plus enclins à l'échec, plus difficiles à maintenir et plus ardus à comprendre. La surutilisation d'outils et la surenchère de complexité peuvent entraîner une prolifération d'outils, des coûts gonflés, un risque accru de défaillances et un ralentissement des délais de livraison.
Guillaume nous propose des KPI pour identifier les signaux faibles et autres red flags d'une mauvaise implémentation DevOps, pouvant mener, si non traités, à des situations désastreuses.
