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. Pour les mois de février et de mars, 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.
Quickie
Quand un incident remet en cause la gestion des secrets
A la suite de l’annonce de l'incident CircleCI et les suspicions de leaks, en tant que membre de l’équipe sécurité, Benoît a participé à la gestion de crise chez son client. Après avoir réalisé un audit interne, pris les mesures adéquates pour mitiger les risques et participé aux rotations nécessaires, il s’est lancé avec son client dans un processus de réévaluation de sa politique de gestion des secrets. Quelques retours sur les efforts en cours et la stratégie mise en œuvre.
REXs
Terraformer l'existant
Bien avant l'avènement du DevOps, les infrastructures Cloud existaient déjà. Le travail pouvait être long, fastidieux, répétitif et assujetti à l'erreur, mais les services fonctionnaient, l'infrastructure était stable. Guillaume nous pose alors la question, comment passer d'une infrastructure existante à de l'IaC ?
Au travers d'une expérience authentique, il nous propose une solution, un chemin, pour Terraformer une infrastructure déjà existante. Il fait la comparaison des approches brut force (destruction, reconstruction), douce (import Terraform des ressources existantes) ou même la possibilité de rester sur un mode de fonctionnement qui a, certes, des défauts, mais fonctionne. Il nous présente ensuite son choix de la méthode douce et le chemin qu’il a emprunté. Les étapes ont été de créer une équipe dédiée à cet effort, en réunissant des personnes ayant la connaissance de l’infrastructure existante et des compétences Terraform. Il a fallu ensuite inventorier toutes les ressources et tous les environnements, terraformer le tout, importer les ressources dans les states Terraform, tester, vérifier, contrôler (beaucoup, beaucoup de Terraform plan à faire, soyez patients) pour enfin appliquer les “changements”.
Expliquez-moi la CNCF
La Cloud Native Computing Foundation ou CNCF joue un rôle important dans le monde de l’open source. Ces initiales sont connues des utilisateurs de Kubernetes, Istio, Argo et autres projets open source incubés par la fondation ces dernières années. Mais de quoi parle-t-on vraiment ? Quel est le fonctionnement de cette fondation ? D’où vient-elle ? Quel est son but ? Comment à mon échelle je peux y participer ? Autant de questions sur lesquelles Ismaël et David nous apportent des éclaircissements afin que chacune et chacun ait une idée plus précise de ce qu’est la CNCF.
À noter que nous sommes Silver Member de la CNCF, Kubernetes Certified Service Provider et que nous donnons les formations officielles Kubernetes de la Linux Foundation qui préparent à la CKA et la CKS.
Tools in Action
Vector, un outil pour mettre un pied dans la matrice
Nos applications étant de plus en plus distribuées, elles génèrent un volume de données d'observabilité de plus en plus important. Collecter, transformer et acheminer ces données de manière simple, robuste et efficace n'est pas une tâche aisée. De même, pouvoir facilement acheminer ses données d'observabilité d'une solution vers une autre pour éviter le vendor lock-in est de plus en plus complexe. Avec Vector by Datadog, cette solution existe et est open source. Cette application écrite en Rust permet d'obtenir des performances jusqu'à 10 fois supérieures à d'autres solutions comme fluentbit ou logstash. Dans ce Tool in Action, David présente la solution, ses avantages, ses inconvénients et les différentes actions à mettre en place pour obtenir un pipeline d'observabilité.
Déployer des modèles IA plus rapide que la lumière
Rémi nous présente la librairie Optimum d'HuggingFace et la met en pratique, pour nous montrer comment accélérer l'inférence des modèles IA déployés en production avec des optimisations telles que Intel OpenVINO ou ONNX. L'objectif de cette présentation est de nous montrer les challenges de la mise en production d'un modèle IA et de donner des pistes aux Ops pour travailler avec les Data Scientists à l'optimisation de l'inférence des modèles IA en production.
Après quelques rappels sur l’IA, pour poser un langage commun, il nous explique ce qui se cache derrière les outils de la startup franco-américaine, Hugging Face. Dans ses démos, qu’il déploie sur ECS, il fait un comparatif du temps de réponse des modèles suivant les architectures (ARM vs AMD), un temps de réponse qui peut être divisé par 2 avec Optimum. À noter qu'il ne faut pas négliger le temps de chargement des poids du modèle car cela peut être un facteur important pour l’autoscaling. Il est possible de chercher des optimisations avec Safetensor. Rémi mentionne également la nécessité de réfléchir avec les Ops et les Data Scientists, ensemble, aux techniques à utiliser avant de mettre en place des modèles qui coûteront cher en production.
J'ai ma Livebox dans un carton
Dans un slot que seul Lilian sait nous apporter, on aborde une alternative à la Livebox pour votre accès internet à la maison. Il retrace le chemin qu’il a pris pour pouvoir s’en passer. On aborde beaucoup de notions de réseau, de la rétro-ingénierie, de la prospective du petit matériel spécifique et du Linux.
Mosh the Mobile Shell
Lilian nous présente Mobile Shell (Mosh) qui est un outil de terminal distant. Il permet de se connecter à des serveurs à travers des connexions instables ou intermittentes, telles que des connexions WiFi ou cellulaires, sans perdre la session. Contrairement aux connexions SSH traditionnelles, Mosh utilise un protocole de communication sans session et est capable de récupérer rapidement de tout paquet perdu ou retardé. Cela permet aux utilisateurs de travailler de manière plus efficace en évitant les interruptions causées par les pertes de connectivité, et améliore l'expérience utilisateur lors de la connexion à des serveurs distants.
Development Containers avec Visual Studio Code
Antoine nous parle des Development Containers dans Visual Studio Code. Après une présentation de l’extension, il nous fait une démo pour nous montrer comment on peut réduire le temps de OnBoarding d’un nouveau développeur et éviter les problèmes liés aux différences entre les environnements de développement. On travaille ainsi plus efficacement en réduisant le temps passé à la configuration de son environnement. Tous les outils, les dépendances et les configurations nécessaires pour votre projet sont packagés dans un conteneur et peuvent être facilement partagés avec le reste de l’équipe.
Conférences
SRE, ou comment améliorez la fiabilité de votre plateforme
Jean-Pascal et Damien nous proposent de revenir en détails sur le rôle de SRE, ils nous font un état des lieux / retour d'expériences sur les bonnes pratiques et les pièges à éviter.
SRE c’est évaluer les risques, mettre en place des SLOs, éliminer les tâches laborieuses, monitorer, automatiser les déploiements, faire de la gestion du changement, simplifier l’existant. Pour ce faire, il est important de participer à 50% de run et 50% de build. Un profil SRE doit être curieux, touche à tout, avoir la capacité de comprendre ce que fait une techno rapidement, être exigeant sur la qualité du service rendu et aimer automatiser. Ce n’est pas pour autant un magicien qui apportera toutes les solutions ni un génie qui connaît toutes les technos comme s’il les avait codées. Et d’ailleurs, il peut aussi bien avoir un background DEV qu’OPS.
Dans leur présentation, ils nous précisent les attendus d’un SLI (Service Level Indicator). C’est un indicateur sur le service rendu du point de vue de l’utilisateur, qui peut s’intéresser au taux d’erreurs, à la saturation du service, au débit, au nombre de requêtes ou à la latence. Il faut s’appuyer sur les standards existants et que l’applicatif soit agnostique de la solution d’observabilité. Pour mesurer, imposez-vous des intervalles de pull suffisamment fins mais qui n’apportent pas de surcharge à l’outillage.
Concernant les SLOs (Service Level Objectives), ils servent à définir le seuil de qualité acceptable. Il représente un ratio sur les SLIs entre 2 intervalles (en pourcentage donc) et permet notamment d’identifier rapidement l’apport de nouveaux changements poussés sur la prod. Cela vous permettra de quantifier l’effort à apporter à votre plateforme en termes de résilience et sur quelles parties de l'application il est intéressant d’intervenir. Il vaut mieux rester simple sur ses objectifs et ne pas se baser uniquement sur l’état actuel des performances de votre plateforme. En exemple, vous pouvez vous fixer un objectif de 99% de requêtes avec un statut OK.
Pour finir, les SLAs (Service Level Agreements) sont la promesse contractuelle de fiabilité que vous mettrez en place avec vos clients. Il y a la possibilité d'envisager des compensations financières en cas de non-respect de vos SLAs.
Une fois ces indicateurs mis en place, il est conseillé de définir un budget d’erreur, qui sera le pourcentage restant entre un SLO et les 100%. Il permet d’argumenter un choix autour de la question : “est ce qu’on peut livrer en production ?” Si le budget d’erreur est déjà consommé, à cause d’incidents par exemple, de manière pragmatique, vous pourrez dire s’il est opportun de livrer une nouvelle feature ou non, ou bien si les changements apportés sont justement là pour corriger les erreurs qui ont consommé le budget.
Jean-Pascal et Damien parcourent ensuite les thématiques de gestion d’incidents, de post-mortem et de chaos engineering.
En plus de tous ces bons conseils, on notera que votre organisation a besoin d’une observabilité mature, de l’agilité pour bénéficier d’itérations plus courtes et des moyens suffisants pour apporter les changements nécessaires. Pour reboucler avec le constat du début, vos profils SRE ne doivent pas fonctionner dans un pôle isolé, cela empêcherait vos équipes de prendre conscience des vraies problématiques de développement et/ou de run.
Mimir
Dans une présentation autour de la solution de stockage long-terme de métriques Mimir, Ronan retrace l’historique du produit, notamment depuis son fork de Cortex. Le projet est développé en Golang sous licence AGPLv3 (pour éviter une exploitation abusive sous forme de service managé par un cloud provider comme on a pu le voir par le passé, et permettre le backport de contributions aux projets) et il fournit une solution de stockage pour Prometheus. Autour de quelques démos, Ronan nous montre quelques features de fédération de métriques de plusieurs Prometheus ainsi que l’isolation fournie entre les tenants, de son couplage avec Grafana, l’architecture du produit, son déploiement et nous parle de ses performances.
Il fait le comparatif avec quelques produits du même segment comme Cortex justement, Thanos et Victoria Metrics. Cortex reste assez similaire mais on peut voir clairement que Grafana Labs était le plus gros contributeur. Suite au fork, l'évolution de Cortex est fortement réduite. Contrairement à ce dernier, Thanos vous permet de faire du downsampling (réduction du nombre d’intervalles entre les métriques pour optimiser les performances et diminuer les coûts de stockage au détriment de la précision) mais on notera que celui-ci fonctionne en sidecar dans les pods Prometheus. Il sera donc consommateur de ressources sur les clusters qui héberge les applications. Victoria Metrics quant à lui dispose d’une architecture plus simple et d’une très bonne collection de documentation et de case studies pour l’implémenter dans de bonnes conditions. Il est cependant moins flexible que Mimir par exemple.
En conclusion, Mimir est également intéressant pour sa rapidité dans l'exécution des requêtes, sa capacité à exploiter diverses sources de métriques, son support des alertes dans Grafana, mais il est bon de noter que le downsampling par exemple n’est absolument pas prévu dans la roadmap. C’est un projet relativement jeune (fork de Cortex pour rappel) et il est conseillé de l’expérimenter à côté de vos solutions existantes pour vous faire un avis par rapport à vos besoins.
Quelles différences entre AVC et ACV (Analyse des Cycles de Vie) ?
Après avoir traité le titre racoleur en nous faisant un rappel préventif sur les Accidents Vasculaires Cérébraux, Gérôme nous a fait une introduction sur les Analyses des Cycles de Vie. Il nous a présenté les différences entre l’ACV, le bilan GES, le Bilan Carbone© et l’empreinte carbone. Puis nous avons parcouru les différentes étapes de la méthodologie avant d’explorer un exemple d’ACV appliqué à un produit numérique.
Même si la méthode existe depuis plusieurs dizaines d’années, elle est encore balbutiante sur le domaine numérique. Le manque de données sur les impacts environnementaux de nos produits numériques l’explique en grande partie.
Falco: le pack gratuit de surveillance et alerting au runtime pour votre k8s
Lors d'un précédent WeShare, Akram a abordé l'ensemble des solutions présentes sur le marché pour surveiller la sécurité d’un cluster Kubernetes, du code jusqu'au run. Il avait fait le constat qu'énormément d’outils existent, et que par conséquent, le choix de la meilleure solution n'est pas évident. Dans la même logique, les outils de sécurité permettant de détecter les menaces au niveau d’un runtime sont nombreux et n'ont pas forcément tous le même objectif. Lors de ce WeShare, il nous présente l’outil Falco, puissant et très important dans votre outillage pour surveiller de manière précise ce qui se passe dans vos runtimes. On fait le tour de son architecture, de son fonctionnement mais aussi de son installation. Akram simule quelques menaces afin de démontrer comment Falco se comporte face à celles-ci. Pour finir, il explique comment répondre à ces menaces dès leur détection.
Mais c'est quoi un Data Mesh bon sang !
Le terme "Data Mesh" a été initié en 2019 par Zhamak Dehghani dans un article qui a fait date. Sa promesse d'offrir une scalabilité organisationnelle et technique pour votre donnée opérationnelle et analytique fait néanmoins de ce sujet tout sauf une trivialité. Pourtant, le terme de Data Mesh est peu à peu tombé dans la catégorie peu lisible des buzzwords et du flou entourant cette notion. Il existe toutefois des approches théoriques intéressantes tirant leur origine dans le software design pour réussir à capter l'essence du Data Mesh, et finir par imaginer des implémentations concrètes à partir de vos services Cloud du quotidien. C'est ce dont Charles-Alban et Ismaël nous font la démonstration dans leur talk en mêlant théorie et pratique.
Si cela attise votre curiosité, vous pouvez retrouver notre dernier épisode de podcast dans lequel Ismaël échange avec Yoann Benoit, CTO chez Hymaïa sur ce même sujet, ainsi qu’un article sur notre blog.
Pulumi - Infra as true Code
Dans une présentation pleine d’humour et de jeux de rôles, Stéphane nous retrace l’historique de l’Infrastructure as Code, AKA IaC, des bons de commandes de serveurs à la déclaration d’indépendance des devs vis-à-vis de l'infra. Mettant en avant les inconvénients de devoir réapprendre des pseudo-langages et autres DSL (Domain Specific Language), il nous présente Pulumi dans le cadre d’une gestion d’infrastructures cloud. En effet, en s’appuyant sur des compétences en développement que l’on a déjà dans nos entreprises, on peut, comme dans ses exemples en s’appuyant sur localstack, coder son infrastructure en Go ou en Typescript mais aussi plein d’autres langages. On aborde également le mode SaaS proposé par Pulumi qui fonctionne sur un système de crédits, qui coûte certes un peu d’argent, mais apporte une gestion des secrets et la gestion du state en managé tout en proposant une API et des webhooks pour automatiser les déclenchements à la GitOps.
En résumé, avantages et inconvénients sont à prendre en compte avant de s’orienter sur cette techno. Stéphane met en avant la flexibilité du modèle et la transition facilitée depuis un existant. Il mentionne cependant un outil qui a du mal à se faire de la place dans l'écosystème cloud actuel et une gestion par “stacks”, comme on le retrouve dans Cloudformation, qui peut vous mettre des bâtons dans les roues pour des environnements dynamiques par exemple.
Wayland : vous n'êtes pas prêt !
Wayland, le successeur du serveur graphique X11 est considéré stable depuis plus d'un an. Est-ce que vous l’avez essayé ? Oui mais combien de fois ? Êtes-vous retournés à votre bon vieux X après moultes déceptions et frustrations ?
Sur la base de ses expériences perso et de son fou rire en trouvant la page AreWeWaylandYet, Olivier nous explique tout, à partir non seulement de la genèse de Wayland, mais carrément des débuts des serveurs graphiques. Dans une présentation pleine d’humour et d’effets de manche, il aborde les freins inhérents à son installation et son adoption, son architecture, l’audace et le courage des mainteneurs de ce projet. Il nous explique les besoins aujourd'hui couverts et ceux qui ne le sont pas encore en tentant de nous donner envie de (re)tenter le passage à Wayland. Nous avons même le droit à quelques démonstrations en ligne de commande de features de partage d’écran et d’affichage déportées sur son téléphone portable au travers de VNC. Sacré Olivier.
Docker Compose n'est pas mort !
A travers ce talk, Morgan et Akram nous montrent que bien que Kubernetes soit actuellement l'outil de déploiement d'applications conteneurisées le plus populaire, Docker Compose n'est pas mort pour autant et bien au contraire, les outils peuvent être complémentaires. En effet, Docker Compose reste un outil de choix pour les applications de petite à moyenne taille, où la simplicité et la rapidité de déploiement sont des critères importants. De plus, Docker Compose reste très apprécié pour le développement et les tests en local, car il permet de mettre en place rapidement un environnement de développement cohérent avec l'environnement de production. Après une partie théorique et des retours d’expériences, Morgan nous a fait une démonstration pour montrer les dernières évolutions de docker-compose en faisant un parallèle avec les fonctionnalités de kubernetes. Cela permet d’avoir dès l’environnement de développement, une architecture applicative proche de la production. Avec l’outil kompose, il nous fait la démonstration de transformation d’un fichier docker-compose en manifests kubernetes, très utile pour accélérer le passage à kubernetes.
Flux ou ArgoCD ? Lequel choisir ?
Le GitOps est un pattern de CD qui a le vent en poupe mais qui est paradoxalement mal compris : Il ne s’agit pas uniquement de dire que Git devient notre source de vérité pour notre infrastructure, il y a une philosophie derrière qui repose sur un couplage faible entre la CI et la CD. ArgoCD et Flux sont deux approches au GitOps sur Kubernetes. Chacun présente des concepts différents sur comment le déploiement devrait être réalisé tout en se rejoignant sur le principe GitOps. Se pose donc la question du choix et des critères l’accompagnant : lequel est le mieux adapté pour votre infrastructure ? Votre organisation ? Vos utilisateurs ? Après avoir rappelé les avantages du GitOps, Clément et Bastien éclaircissent ces sujets à la lumière de leurs retours d’expérience de production de ces deux outils.
Introduction aux tempêtes d'évènements plus communément appelé Event Storming
Gérôme présente l'Event Storming, un atelier créé par Alberto Brandolini permettant d’aligner les participants autour d’un domaine métier.. Cette introduction à l'Event Storming commence par une démonstration de son déroulement sur Miro, en présentant les codes et le vocabulaire spécifiques à cette méthode. Ensuite, plusieurs cas d'utilisation sont abordés, ainsi que les points clés à prendre en compte lors de sa mise en place, tels que les participants et les attentes à définir.
Goldie d'or et les trois CNI
Au travers du conte pour enfants, Jérôme revisite Boucle d'or et les trois ours. Sous forme de récit donc, il fait une approche d’une problématique réseau bien précise de nos environnements distribués d’aujourd’hui. Il teste donc les 3 CNI du landscapes CNCF : Calico, Cilium et Antréa. Il appuie ses tests et sa démo sur un cluster Kubernetes et nous explique, en détails, avec des exemples simples, les impacts que peuvent avoir le choix de son réseau. On parlera notamment de MTU et d’overhead sur les trames réseau, d’autant plus dans un contexte de service managé comme EKS sur AWS, de chiffrement du trafic et d’autres trucs encore plus fous. Vous pourrez d’ailleurs retrouver ce talk qui a rencontré un grand succès dans les replay du Kubernetes Community Day Paris très prochainement.
Kafka expliqué au Grumpy Cat
Comme Joachim et Stéphane le mentionnent, Kafka est vraiment très mis en avant et bien souvent considéré sans même savoir ce qu'il fait vraiment et comment il fonctionne. En prenant volontairement une approche de vulgarisation pour permettre à des profils moins techniques de suivre également, ils nous exposent les besoins auxquels répond vraiment Kafka, son fonctionnement et la manière de l’utiliser. Ils le comparent à différents services similaires sur des clouds publics mais aussi à d'autres produits comme Pulsar, RabbitMQ, NATS ou même Akka. Sans trop rentrer dans la technique donc, on parle des grands principes d'architecture, interne et applicative dans son utilisation, car le but est de savoir ce que fait Kafka, mais également dans quel cas il est bien approprié.
Hands-on
Hashistack
Aurélien nous lance dans un hands-on sur le projet open source made-in Wescale : Hashitack. L’idée derrière cet atelier est de faire un point d’étape pour partager l’état d’avancement de ce projet open-source, et débroussailler ensemble le parcours de déploiement, de prise en main, l’automatisation et la documentation autour du projet. Pour rappel, Hashistack fournit une stack HashiCorp complète, à savoir Vault, Consul, Nomad, orchestrée par beaucoup d’Ansible, et déployée (pour l’instant) sur Scaleway à coup de Terraform.
Le format était également très intéressant parce qu’il demandait simplement, par groupe de 2 ou 3 personnes, de dérouler la documentation de pré-requis et d’installation (nous permettant de dénicher tous les éventuels problèmes liés à nos environnements personnels) mais également de préparer un mini pitch de quelques minutes sur l’un des aspects techniques du projet. Nous avons donc pu couvrir, à nous tous, les sujets de déploiement, d’automatisation, d’intégration DNS, de gestion des certificats, des root tokens et du monitoring.
