Toute l'actualité devOps

Kubernetes est un système open-source de gestion d'orchestration de conteneurs, largement utilisé dans les infrastructures modernes. Il offre une plateforme flexible et évolutive pour le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. En raison de sa popularité et de son adoption croissante, Kubernetes est devenu un composant majeur des architectures de microservices et de cloud computing. Cependant, cette popularité a également attiré l'attention des attaquants. Dans ce talk, Thibault Lengagne de Padok vous présentera : Une rapide présentation de Kubernetes Une démonstration d'attaque en temps réel d'un cluster EKS, suivie de la compromission du compte AWS sous-facent Enfin, une surprise réservée par Thibault

📰 Tout un tas de news importantes sur l'avenir d'HashiCorp 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ➡️ Extrait d'Actus DevOps de janvier 2024 L'épisode complet : https://youtu.be/B5CXNcLBLaw https://www.silicon.fr/opentofu-openbao-hashicorp-fork-474235.html https://www.linkedin.com/feed/update/urn:li:activity:7141026556419682304 https://twitter.com/mitchellh/status/1735410621859221931 Terraform n'est plus Open-source ?! : https://youtu.be/DBN1ADX46Mo?si=SHSCe7U-NiUZcpFo 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ## Crédits ### Les podcasteurs - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - Nidouille sur les réseaux. Tous ses liens : http://labperso.ovh - DamyR : SRE chez Waays / DevOps, passionné d'open source & de logicel libre, :man_teacher: professeur vacataire à l'université Léonard de Vinci. Son credo : "*La connaissance n'a de valeur que si elle est partagée*" ;-). Découvre le : https://lydra.fr/ea-1-le-podcasteur-damyr/ | Linkedin : linkedin.com/in/tgerardin/ | Twitter : https://twitter.com/damyr_fr | Blog : https://www.damyr.fr - Nicolas Ledez : devops chez CGWire. Il travaille dans l'IT depuis 20 ans. Il est "Schizophréne" : adminsys et développeur suivant le moment de la journée. Il paraît que ça s'appelle "devops", même si il déteste mettre ce nom sur un poste. Découvre le : https://lydra.fr/ea-8-le-podcasteur-nicolas/ | LinkedIn : https://www.linkedin.com/in/nicolasledez | Twitter : https://twitter.com/nledez | Github : https://github.com/nledez | Le reste : https://nicolas.ledez.net ### Habillage sonore - L'intro et la fin sont de Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Image de Drazen Zigic sur Freepik : https://fr.freepik.com/photos-gratuite/triste-entrepreneur-emballant-ses-affaires-dans-boite-carton-quittant-bureau-apres-avoir-perdu-son-emploi_26390543.htm 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #ADOcourt #HashiCorp

Les avantages des microservices sont souvent énoncés mais c’est également une approche posant de nombreux challenges au quotidien. Au final, est ce que ça vaut le coup ? Sommaire Introduction Exploitation en production Communication, transaction, données Bus de message Rapide introduction à Kafka Transactions Découpler les actions Outbox Pattern Réconciliations Saga idempotence Accès aux données Duplication Désynchronisation Reconstruction Compaction et stream first Mauvais pattern de duplications Mauvais découpage des domaines Découpage pour la scalabilité et la tolérance aux pannes Dupliquer ou non les données Envoyer des emails Kafka Stream Appels synchrones Testing Reconstruire le monolithe Environnement de dev local Environnement à la demande Cloud Une histoire de confiance Découpler, tests inclus Un problème de lead time et de complexité accidentelle Ralentir Organiser Conclusion Bonus: authentification Introduction Cela fait plus de 10 ans (je pense ?) que l’on voit les microservices déferler dans nos SI. Le cloud et les outils d’orchestration de conteneurs ont également accompagnés cette montée en puissance des microservices au cours des années, simplifiant en partie leurs gestions. Les microservices apparaissent souvent comme une solution pour avoir de petites équipes travaillant de manière décentralisée. Le Domain Driven Design (DDD) est également une méthode de conception souvent mise en avant dans les microservices, où chaque service ou groupe de service sera responsable d’un domaine métier, domaine qui peut donc être assigné à une équipe dédiée. La théorie nous dit aussi que chaque service doit avoir sa propre base de données, car chaque service est le "propriétaire" de la donnée de son domaine: c’est lui la source de vérité unique de cette donnée. Sur le papier, tout ça est très intéressant. On a donc des services (et donc équipes, loi de Conway oblige) faiblement couplés, avec des dev travaillant en autonomie sur des bases de code réduites et spécialisées, et donc plus faciles à maintenir. Les services peuvent également être conçus dans des langages de programmations différents, et monter en charge de manière indépendante. Bien sûr, there ain’t no such thing as a free lunch. Et il est tentant d’ignorer les nombreux problèmes apportés par les microservices, ou de ne leur apporter qu’une solution partielle. Je donnerai dans cet article ma vision sur le sujet, en décrivant quelques patterns (ou antipatterns) que j’ai eu l’occasion de rencontrer au cours de ma carrière de manière la plus simple et objective possible. Je ne vais pas parler tant que ça de découpage d’un monolithe. C’est un sujet très important mais de nombreuses personnes le font déjà mieux que moi. Regardez par exemple le talk de Julien Topçu et Josian Chevalier sur le sujet: Et l’avantage d’un blog, c’est que cela me permet également de relire mes propres articles quelques années après et de voir comment ma vision des choses a évoluée ;) Exploitation en production Gérer le déploiement et l’orchestration de plusieurs centaines de services en production (et dans les autres environnements: QA, Staging…​) peut vite devenir un challenge. Heureusement, l’outillage a énormément évolué ces dernières années. Kubernetes, our Lord and Savior, aide par exemple énormément grâce à ce qu’il fournit nativement (tolérance aux pannes, service discovery, gestion du firewalling, health checks, rolling restart, load balancing…​). Ce n’est pas la seule solution mais dans tous les cas il est nécessaire d’avoir un moyen standardisé de gérer le cycle de vie d’un service de la CI à la production. Si chaque service doit avoir sa propre base de données (ou autre dépendance infra dont nous parlerons plus tard), il faut aussi être capable de provisioner et gérer dans le temps tous ces composants, pour chaque microservice. Bien sûr, c’est aussi le cas pour un monolithe: on n’imagine pas un monolithe sans tolérance aux pannes ou sans pipeline de déploiement continu (voir un de mes articles sur le sujet). D’ailleurs, les microservices permettent de déployer en production des changements plus petits, plus souvent, avec un "blast radius" plus faible en cas d’incident. Cela peut également être assez appréciable. Néanmoins, le debugging s’en trouve complexifié. Une requête HTTP d’un client peut facilement "passer" par plusieurs services (de manière synchrone ou asynchrone), et bien sûr planter à chaque étape. Cela peut être dû à un problème logiciel (bug dans un des services) ou tout simplement à cause d’un problème de l’infrastructure sous-jacente. Le microservice gérant vos utilisateurs doit par exemple envoyer des requêtes au service d’envoie d’emails, alors que dans un monolithe tout se ferait dans le même process. Des outils comme le tracing distribué (cliquez, vous verrez c’est intéressant :D) deviennent donc obligatoires pour tenter de comprendre ce qu’il se passe dans le système d’un point de vue macro. Ajoutez des métriques et des alertes sur vos services, configurez des SLO (plus facile qu’à dire qu’à faire, en réalité c’est une approche difficile à faire adopter). J’ai plusieurs articles sur le sujet des métriques si ça vous intéresse. On en arrive vite à rajouter une certaine complexité sur l’infrastructure et les services à cause des microservices: service mesh pour tenter de créer une infrastructure réseau plus robuste (c’est souvent l’inverse qui arrive), circuit breakers pour protéger des services ou dépendances en cas de pannes, retries à divers endroits…​ Bref, comme dit Murphy, "Anything that can go wrong will go wrong". Une certaine maturité technique sera nécessaire pour aboutir à une plateforme robuste. Le platform engineering est également obligatoire. Vos SRE devront travailler main dans la main avec vos développeurs pour que chaque équipe puisse travailler en autonomie sans avoir les ops dans le chemin critique. Cela est vrai également si vous ne faites pas de microservices d’ailleurs. J’avais fait un talk sur le sujet que je redonnerai dans une version complètement retravaillée prochainement: Une solution pour résoudre les problèmes de fiabilité (et surtout de cascading failures, où la panne d’un composant cause la panne d’autres services en cascade) est de tenter de découpler totalement les services. Serait-il possible d’avoir des services totalement autonomes et donc pouvant continuer de fonctionner en cas de panne partielle de système ? En théorie oui, mais nous verrons ça dans la section suivante. Communication, transaction, données On retrouve généralement dans l’informatique deux grands moyens de faire communiquer deux services entre eux: Synchrone: un service appelle un autre service via un protocole comme HTTP (ou gRPC par exemple) et s’attend à une réponse immédiate. Si le service cible n’est pas disponible, une erreur se produit. Asynchrone: un service pousse un événement un message dans un bus de message et un autre service consommera (éventuellement) ce message un jour pour faire quelque chose avec. Ces définitions sont bien sûr un peu trop généralistes. Des outils comme Nats supportent par exemple des patterns de type request-reply via des queues asynchrones (on simule donc du synchrone), ce qui peut être utile dans certains cas. Les appels synchrones créent un couplage entre l’appelant et l’appelé. Comme dit précédemment, si le service cible n’est plus joignable, le service appelant ne pourra pas fonctionner tant que la cible n’est pas restaurée. Ceci peut éventuellement être un problème (ou pas, nous y reviendrons). D’autres approches émergent pour tenter de découpler les services. Bus de message On voit dans ce nombreuses implémentations des microservices l’utilisation d’outils comme Apache Kafka pour distribuer des événements entre services, et donc tenter de les découpler. Rapide introduction à Kafka Kafka est un bus de message permettant à des consommateurs de s’abonner à des topics. Un topic est composé de plusieurs "queues" de messages appelés partitions. Lorsqu’un message est produit dans un topic, il est assigné à une partition en fonction d’une clé de partitionnement (généralement une valeur du message, comme par exemple l’ID de la ressource représentée dans l’événement). Cela est très utile car on a comme ça une garantie d’ordre: tous les messages d’une partition sont consommés en mode FIFO par les consommateurs et tous les événements pour une entité donnée seront consommés dans l’ordre d’arrivée. Dans cet exemple, un service produit des événements concernant des actions sur des utilisateurs (création de compte, mise à jour, suppression). Ces événements sont envoyés dans un topic composé de 2 partitions, partitionnées par ID de l’utilisateur. Les consommateurs consomment le topic. Chaque consommateur (aussi appelé consumer group dans le langage Kafka) lira l’entièreté des messages du topic. Les messages dans Kafka ne sont pas supprimés après lecture mais après un TTL (7 jours par exemple), ce qui permet de relire à tout moment d’anciens événements si nécessaire (tant qu’ils sont plus récents que le TTL). N’hésitez pas à googler si vous voulez en savoir plus sur Kafka, ça vaut le coup et il y a des tonnes de contenus sur le sujet. Fin Un service peut par exemple réagir sur la mise à jour d’une entité qu’il gère (de son domaine) en publiant un événement de domaine (une projection de la donnée du servicex). D’autres services, dont le service producteur n’a pas connaissance, peuvent consommer à ces événements et déclencher des actions en fonction de ce qu’ils reçoivent. A l’inscription d’un utilisateur le microservice responsable de la création du compte publiera par exemple un événement UserCreated (contenant les informations de l’utilisateur) qui pourra être consommé par un autre service qui déclenchera lui même une action. On peut aussi envoyer via le bus de message des actions (commandes) à réaliser par d’autres services, par exemple "Envoie cet email à l’adresse foo@example.com" qui sera ensuite consommé par un service chargé d’envoyer des emails. Ici, le découplage entre le producteur et les consommateurs est total. En cas de panne d’un consommateur, ce n’est pas grave: à son redémarrage il pourra reconsommer les événements envoyés par le producteur (avec du retard), ce dernier continuant de fonctionner normalement. Comme dit précédemment, c’est aussi un bon moyen d’avoir une communication 1 → N entre services, plusieurs consommateurs parallèle sur les mêmes événements étant possibe. Transactions Dans ce genre de système, l’ordre des événements est très important. En effet, il existe de très nombreux cas où le résultat d’une application d’une série d’actions sur une entité donnée dépend de l’ordre de ces actions. Les outils comme Kafka permettent de garantir l’ordre des messages en fonction de la clé de partitionnement des messages. Mais c’est là où les problèmes peuvent commencer également à survenir. Il est courant d’avoir des cas de figures où un service: A besoin d’écrire dans une base de données. Doit ensuite, une fois l’action réalisée, publier un événement dans un bus de message pour annoncer l’action aux autres services. On a donc en résumé besoin de réaliser une transaction entre deux systèmes. TL:DR: ce n’est pas possible à faire simplement et on peut rapidement se retrouver dans des cas où par exemple la donnée est écrite, mais l’événement non publié. Cet événement non publié ne sera pas donc propagé au reste du système, ce qui peut causer des problèmes d’incohérences. Comment résoudre ce problème ? Découpler les actions Découplons les deux actions avec un service intermédiaire, pour que chaque service ne fasse qu’une action transactionnelle et non deux: Dans 1), on a notre situation initiale: Le service A exécute les deux actions l’une après l’autre, sans garantie de transactionnalité. Dans 2), on utilise un pattern un peu différent: Le service A écrit d’abord dans le bus de message. Ce message est lu par Service B (qui pourrait même être Service A lui même qui reconsomme ses propres messages pour éviter de maintenir un autre service) qui lui écrit dans les base de données. On voit dans la seconde solution qu’on a gagné: nous n’avons plus cette transaction entre deux systèmes, au prix d’une complexité un peu supérieure. La solution 2) contient pourtant un inconvénient majeur: la possibilité de problèmes de type read-after-write. Imaginons le cas suivant: Un utilisateur décide de changer son nom dans l’application: Service A reçoit la requête, et pousse un événement de type Utilisateur Foo change son nom en Bar. Le service A n’a ici aucune idée de quand l’action sera réellement exécutée par le Service B (il n’a même pas connaissance de ce service), mais il répond quand même à l’utilisateur "l’action est effectuée". Si l’utilisateur rafraichit sa page avant que service B ait consommé l’événement et réalisé l’écriture en base, l’ancien nom sera toujours visible. Bizarre non ? Et que se passe t-il si Service B est en fait en panne et que le message met une heure à être consommé ? Bref, c’est problématique mais dans certains cas où le read-after-write n’est pas un problème cela peut être suffisant. Mais on reparlera de ce pattern plus loin ;) Outbox pattern Une autre technique possible est d’utiliser l’outbox pattern. Il est extrêmement bien décrit dans cet article donc je n’irai pas dans les détails. L’idée est de ne plus avoir à écrire la donnée dans deux systèmes à la suite (base de données et bus de message), mais d’écrire la donnée ET l’événement à envoyer dans une même transaction au même endroit: dans la base de données. L’événement sera écrit dans une table spécifique qui sera ensuite lue régulièrement par un système externe, et publié dans notre bus de message. On a cela grâce aux propriétés transactionnelles des bases de données (notamment SQL) la garantie que les deux actions seront faites, ou annulées. Mais jamais le cas intermédiaire. Que vaut ce pattern ? Ca marche, mais le coût de mise en oeuvre est important. Des outils populaires comme Debezium (très utilisé aussi pour un autre pattern appelé Change Data Capture) sont généralement utilisés mais ils demandent souvent une connaissance fine du fonctionnement d’une base de données (replication des WAL par exemple), et peuvent être assez sensibles à gérer en production. Here be dragons. Réconciliations Un autre pattern courant dans les systèmes distribués est de travailler avec des boucles de réconciliations. J’ai eu l’occasion de travailler presque 4 ans chez un cloud provider utilisant ce pattern. C’est également un pattern utilisé par énormément d’outils, notamment dans le monde de l’infrastructure (Kubernetes est un exemple). Dans un système distribué, tout peut arriver: problèmes d’infrastructures divers, problèmes réseau, bug dans une dépendance, crash d’un service…​ Le gros risque de tout ça est comme décrit précédemment l’interruption d’une action en cours de traitement. Pire, il faut pouvoir faire revenir à l’état nominal du système. Je vois encore trop d’équipes réconciliant des données "à la main" dans ce type d’architectures distribuées, car les applications n’ont aucun mécanisme de reprise. Et ce mécanisme peut être les boucles de réconciliations. Un très grand nombre de systèmes peuvent se définir en terme de "workflow": une série d’actions à exécuter pour faire converger une entité dans un état voulu. Dans notre exemple précédent, ces actions étaient au nombre de deux: écrire dans la base de données et publier un message dans le bus de message. Mais en réalité, il est assez commun d’avoir des workflow plus complexes: écrire dans une base de données, appel HTTP vers un service d’un partenaire, traitement de la réponse et nouvelle écriture en base, publication d’un message…​ Pourrions-nous construire un système spécifiant que lorqu’une action est acceptée par le système, on ait la garantie qu’elle va jusqu’au bout de son exécution même en cas de problème ? Oui. Dans mon expérience précédente, toutes les actions sur une entité (un enregistrement en base de données) pouvaient être décrites sous forme de machines à états finis déclenchant des workflow représentés par des arbres syntaxiques abstraits. J’ai apprécié cette manière de concevoir des services backend et les systèmes étaient extrêmement robustes. Qu’est ce que tout ça veut dire ? Nous utilisions une librairies (disponible d’ailleurs sur Github) pour définir simplement une série d’actions à réaliser. Ces actions pouvaient être appelées l’une après l’autre ou en parallèle (pour accélérer l’exécution), le tout de manière très flexible et avec des choses comme la gestion d’erreur ou le retry inclus. On voit dans cet exemple une série de 5 actions, dont deux sont réalisées en parallèle. L’ordre des actions est ici numéroté. Lors d’une action sur le service (appel HTTP, événement Kafka…​) l’entité pouvait optionellement changer d’état ("destroying", "updating", "upgrading…​ ce qui pouvait être aussi utile pour interdire des actions parallèles sur une entité en vérifiant son état) et une réconciliation était déclenchée. Si cette dernière plantait, elle était retentée plus tard (immédiatement, ou X secondes…​c’était configurable). En fin de réconciliation l’entité repassait dans un état nominal ("running" par exemple). Du tooling nous permettait de suivre en temps réel l’exécution de chaque étape d’un job et de forcer la réconciliation d’une entité. Ces slides (notamment à partir de la 47) décrivent briévement ce pattern, qui fonctionne très bien dans beaucoup de cas. On entend d’ailleurs de plus en plus parler de workflows et de "durable execution" en ce moment, qui est un concept assez similaire mais avec une vraie gestion de la temporalité. La grosse hype du moment dans ce domaine est Temporal, que je n’ai malheureusement toujours pas eu le temps de tester. Je vous conseille fortement de cliquer sur le lien et de jeter un coup d’oeil, ces patterns fonctionnant aussi dans des architectures classiques. L’idée à retenir de tout ça: construisez des systèmes capables de s’auto réparer sans actions de votre part. Saga Tout ça me fait aussi penser au pattern Saga. Le problème est toujours le même: comment exécuter une transaction distribuée (à voir ensuite si l’on souhaite vraiment des transactions entre services), et voir comment rollback en cas d’échec. Certains "frameworks" implémentant ce pattern sentent un peu le "framework d’entreprise™" mais il y a toute une littérature intéressante sur ce sujet. L’idempotence L’idempotence est obligatoire dans ce type de système. On parle d’idempotence lorsque la même action répétée plusieurs fois conduit au même effet. Pourquoi est-ce une notion critique en microservice ? Car la majorité des systèmes de ce type fournissent des garanties de type "at least once". Si le même événement est envoyé deux fois par un producteur dans un bus de message (à cause d’un bug, d’un retry…​), les consommateurs le recevront deux fois mais doivent produire le même résultat que si il n’avait été envoyé qu’une fois. Même chose pour des requêtes HTTP. Cela est assez facile à faire dans certains cas, plus difficile pour d’autres. Attacher un UUID d’idempotence aux actions peut être une solution (de nombreux SaaS dont Stripe fonctionnent comme ça par exemple), mais cela force les consommateurs à d’une manière ou d’une autre stocker et vérifier ces ID à chaque message reçu, et à gérer leurs expirations. Accès aux données The elephant in the room. Comme dit précédemment, l’état de l’art en microservice énonce que chaque service doit avoir sa propre base de données. Ce service doit être le seul à modifier cette donnée, et doit être la source de vérité pour l’état de cette donnée. Duplication Sauf qu’on se retrouve parfois dans des cas où un service a besoin d’une donnée d’un autre service. Prenons l’exemple d’un site de e-commerce, et l’exemple de duplication de données que l’on retrouve dans la majorité des architectures microservices (et que j’ai vu dès le début de ma carrière): la recherche. Un service peut par exemple être responsable de la gestion des produits, et un autre de la recherche. Le service produit pourrait utiliser une base SQL classique, et le service de recherche un outil comme Elasticsearch. Lorsqu’un nouveau produit est créé ou supprimé dans le service produit, ou modifié, un événement est émis par ce service dans le bus de message (le pattern Change Data Capture peut s’avérer également utile ici pour fiabiliser la production des événements). Le service de recherche consomme cet événement et met à jour sa propre base de données. Ceci est intéressant: les deux services peuvent fonctionner (et scale) en totale autonomie. Une panne du service de recherche n’affectera pas le service produit, et vice versa. Les caractéristiques de ce type de duplication de données doivent pourtant être bien comprises. Ici, l’intérêt est évident: faire de la recherche demande des technologies dédiées, des données ayant une forme différente par rapport à celles du service source (champs spécifiques, structure différente…​) et il fait sens de découpler les deux fonctionnalités. Un peu de duplication est donc conseillé, mais il ne faut pas en abuser et il faut toujours se poser la question du pourquoi on duplique, de comment, et si une solution alternative est possible. En effet, de nombreux cas limites existent avec cette approche. Désynchronisation Les données dans le service dupliquant les données (ici la recherche) peuvent être en désynchronisation avec le service producteur pour plusieurs raisons. Peut être par exemple que le service producteur a échoué à produire des messages, et je vous garantis que ça va arriver même avec la meilleure volonté du monde, il y aura des bugs dans votre système. Peut être également que la propagation entre le service producteur et consommateur prendra plus de temps que prévu, et donc que les mises à jours arriveront avec 10, 20, 30…​ secondes de retard. Bref, vous ne serez jamais sûr que les données sont complètement synchronisées des deux côtés. Est-ce acceptable pour votre fonctionnalité ? On peut considérer pour la recherche que quelques résultats incorrects (description non mise à jour, article qui vient d’être ajouté mais qui n’apparait pas encore dans les résultats…​) peut être "acceptable": à vous de définir vos SLO (service level objective) sur vos données. Dans d’autre cas, ça ne l’est pas. Imaginez la catastrophe si par exemple un utilisateur ayant son compte suspendu puisse continuer d’utiliser un sous-ensemble de votre service car sa suspension n’a pas été propagée à l’ensemble du système ? Les conséquences ne seraient sûrement pas les mêmes. Reconstruction Les données dupliquées doivent pouvoir être reconstruites car comme dit précédemment elles seront désynchronisées de manière subtile avec le temps. Si on reprend notre exemple de la recherche, peut être également qu’un nouveau champ a été ajouté dans la base de données du producteur et que l’on souhaite l’indexer dans le moteur de recherche. Ce process de reconstruction doit en plus fonctionner sans causer de downtime que ce soit d’un côté ou de l’autre. Et il faut bien sûr pouvoir également construire cette duplication une première fois quand le nouveau service est créé. Poser vous la question de comment faire avant d’implémenter le pattern. Une solution simple pourrait être de déclencher d’une manière ou d’une autre une action sur le service producteur pour reproduire la totalité des événements représentant sa base de données dans le bus de message, événements qui pourront être reconsommés par le service de recherche qui mettra à jour ses enregistrements. Selon le volume de données, ça peut piquer. Mais pour des cas simples (quelques millions ou dizaines de millions d’enregistrements) cela peut être suffisant. Le process peut être optimisé selon les besoins: utilisation d’un microservice de reindexation dédié, utilisation d’un replica de la base de données du producteur pour extraire les données…​ Bref, à voir en fonction du volume. Attention aussi à ne pas impacter d’autres services en faisant ça: rappelez vous qu’en microservice plusieurs consommateurs peuvent généralement écouter la même queue d’événement, créez en une dédiée à la réindexation pour éviter que l’ensemble des consommateurs aient à reconsommer un volume énorme d’événements. Avoir un peu d’outillage pour pouvoir très simplement réindexer une entité peut également être utile. Vous découvrez qu’un produit est mal indexé ? Un simple appel POST /reindex/<id> pourrait déclencher sa réconciliation. Attention aussi à la gestion des suppressions. Rater un événement de création ou de mise à jour n’est pas grave, il suffit de le reproduire depuis la source pour le réindexer correctement. Mais que se passe t-il si une donnée n’existe plus dans la source mais existe toujours dans la destination car l’événement de suppression a été perdu ? Cela montre aussi les avantages d’une réindexation complète malgré les challenges techniques qu’elle amène. Pour la petite anecdote, j’ai travaillé en 2017 sur un projet à base de microservices (dans Kubernetes), Kafka pour le bus de message, et avec chaque service ayant une base de données SQL dédiée. C’était un projet en grand groupe, pas encore en production mais il y avait quand même une soixantaine de personnes travaillant dessus (~40 dev de mémoire) et on avait déjà un environnement de QA utilisable. Les architectes avaient fait le choix de dupliquer de très nombreuses tables métier entre microservices via Kafka, un peu comme dans l’exemple de la recherche mais pour des données assez génériques et sans réelles transformations de ces dernières. On avait donc la majorité des services avec des duplications locales de données d’autres services, très souvent pour de mauvaises raisons (on y reviendra), bien sûr désynchronisées, et c’était devenu un bordel sans nom au point qu’il fallait régulièrement "reset" toutes les bases (supprimer toutes les données) pour repartir d’un état propre car au bout d’un moment l’utilisation normale de la plateforme devenait impossible ! Heureusement, c’était pas en prod (et j’ai quitté le navire avant^^) Cas classique où la solution technique a été mise en place sans analyse et stratégie pour ensuite être "scale" à l’ensemble des équipes qui ont toutes reproduites les mêmes erreurs sans trop de poser de questions. Cette cascade avait été réalisée par des professionels, ne faites pas ça chez vous. Compaction et stream first Depuis le début de cet article, je parle du bus de messages comme un moyen d’échanger des événements métiers ou des commandes entre plusieurs services. Mais on peut aller plus loin. Et si il était possible d’utiliser le bus de message comme une base de données ? Les données représentant des entités (les produits par exemple) n’expireraient jamais mais resteraient indéfiniment dans le bus, prêtes à être reconsommées à tout moment. C’est possible sur des technologies comme Kafka avec la compaction. J’étais comme beaucoup un peu hypé par le stream processing il y a une dizaine d’années. On avait depuis quelques années des outils comme Apache Storm, ou Spark Streaming qui ouvraient la voie à une nouvelle approche du traitement de données par rapport au batch (qui se rappelle de MapReduce ?). Puis est arrivé Apache Kafka (je me rappelle avoir travaillé avec la version 0.8 en 2015 de mémoire), Je n’ai jamais stoppé d’utiliser cette technologie depuis. J’avais un peu décrit le fonctionnement de Kafka en début d’article mais je n’ai pas parlé de la compaction. Mon premier contact avec cette feature fut chez Exoscale où elle était utilisée pour gérer les zone DNS (voir cet article de pyr, mon ancien CTO). Clairement le genre de features où lorsqu’on vous l’explique pour la première fois vous êtes comme ça: Comme dit en début d’article, Kafka garde les messages qu’on lui envoie durant une certaine durée configurable (TTL), comme par exemple 7 jours. Après ça, elles sont tout isimplement supprimées. Sauf avec des topics en mode compaction. Avec la compaction, Kafka gardera dans son topic le dernier événement pour chaque clé unique de message. Rappelez vous ce que j’écrivais en début d’article: lorsqu’on envoie un message dans Kafka, on choisit une clé pour ce dernier. Imaginons que nous envoyons dans Kafka les détails d’un utilisateur à chaque changement de ce dernier (création, mise à jour ou suppression). On aura donc une série d’événements dans Kafka contenant ces informations, chaque événement ayant comme clé l’ID de l’utilisateur. En mode Kafka "classique", les services consommateurs consomment ces événements, puis après quelques jours (valeur du TTL) ils seront supprimés de Kafka. En mode compaction, le dernier événement (le plus récent) pour chaque utilisateur sera gardé (voir la doc officielle sur ce sujet). Les consommateurs consomment les changements du topic consommé au fil de l’eau. A chaque mise à jour d’une entité, le changement est toujours propagé aux consommateurs. Sauf qu’ici, toutes les données de vos utilisateurs sont disponibles dans le topic. Grâce à la compaction, la taille du topic reste limitée (=~ le nombre d’utilisateurs dans votre système dans cet exemple). Il est également possible de configurer un consommateur pour retraiter l’entièreté du topic (et donc l’entièreté des données) ! Revenons à l’exemple du service Produit et du service Recherche décrit précédemment: avec un topic compacté, reindexer les données dans le service de Recherche devient facile: il faut juste lui dire de reconsommer le topic depuis le début. Je vous conseille fortement de le talk Turning the database inside-out du célèbre Martin Kleppman décrivant une architecture orientée streaming. L’implémentation "habituelle" de ce pattern est la suivante: Un service a une base de données "classique" et est le propriétaire de ces données En cas de mise à jour, il écrit dans sa base et pousse un événement dans le topic compacté La suppression fonctionne de la même manière: il faut pousser un événement spécial (de type tombstone) dans Kafka pour supprimer une clé d’un topic compacté, sinon l’entité restera pour toujours dans le topic. Pensez y, c’est obligatoire rien que pour des raisons légales (RGPD). Du soft-delete côté base de données peut être très intéressant pour faire re-converger ce topic (mais vous la base de données sera plus grosse). Ici se pose encore une fois la question de la qualité des données du topic compacté. Si un service écrit dans sa base mais ne pousse pas le message, le topic n’est pas mis à jour. On revient au problème (et solutions) décrites plus tôt dans l’article. Martin Kleppman va même plus loin: pourrions-nous faire une architecture 100 % orientée streaming, où la source de vérité n’est pas la base de données locale de chaque service mais le topic Kafka ? Dans cet exemple simplifié, deux topics avec la compaction servent à créer 2 "materialized views". Les écritures se font directement dans les topics, et des consommateurs (non représentés ici) se chargent de reconstruire des vues dans des base de données depuis les nouveaux événements. C’est intéressant car ici la source de vérité est Kafka, et chaque vue peut être facilement reconstruire "from scratch". On limite fortement les problèmes de désynchronisations par rapport à la solution précédente. La difficulté ici est d’intégrer ce modèle au monde d’aujourd’hui, notamment HTTP. Quand un utilisateur exécute une action côté frontend, il s’attend à avoir une réponse rapidement. On veut éviter également les problèmes de type read-after-write comme décrit en début d’article, donc répondre "OK" au client alors que la donnée n’est pas propagée aux vues (donc invisible côté client) est problématique. Une solution pourrait être d’attendre dans les services (comme dans le Service User) qu’un callback produit par un service consommateur arrive avant de répondre au client ( je link encore une fois la doc de Nats pour faire cela par exemple). Mais que faire si le callback ne vient jamais ? On ne peut pas répondre au client "réessaye", l’action est probablement toujours en cours dans le bus. On ne peut pas lui dire "OK", si il change son prénom, rafraîchit la page et voit toujours la même donnée, il ne va pas comprendre. Pour des systèmes critiques il vaut probablement mieux écrire dans la base de données avant. Par contre, pour du service interne où on a la main sur le client (contrairement à un browser web), ça peut marcher, notamment si l’on est pas intéressé par recevoir une réponse immédiate. Dernier conseil: lisez absolument le livre Designing Data Intensive Applications dont Martin Kleppman est l’auteur, il est génial. Mauvais pattern de duplications Parfois, les équipes dupliquent les données entre services pour les mauvaises raisons. Il devrait y avoir une règle universelle quand on fait des microservices qui ressemblerait à quelque chose comme On tourne 7 fois son clavier dans ses mains avant de dupliquer de la donnée. Mauvais découpage des domaines Erreur classique mais fréquente. Vous pensiez avoir bien identifié votre domaine, en fait vous aviez tort. Vouloir créer des microservices "trop petits" est je pense une erreur courante, notamment lors du découpage d’un monolithe. Découper à la tronçonneuse, c’est facile, mais quand on se rend compte de la boulette c’est trop tard et il faut passer du temps à re-fusionner des services ensemble (et on sait tous qu’il y a de grandes chances qu’on vous dise "ah non on a déjà fait l’effort de découper, on va pas encore refaire !"). Parfois, l’erreur n’est pas un bug mais une feature: "oui je sais c’est le même domaine mais moi je veux coder en Rust et le service existant est en PHP donc je ne veux pas contribuer dessus", mais là on est plus dans un problème organisationnel que technique. Bref, faites attention à ça. Découpage pour la scalabilité et la tolérance aux pannes Un cas que j’ai déjà rencontré dan

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ Dépôt : https://gitlab.com/xavki/tutoriels-wazuh Vagrantfile : https://gitlab.com/xavki/vagrant-files/-/tree/master/wazuh #wazuh #securité #opensource #ssh #devop Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ OPNsense est un puissant pare-feu et routeur open source basé sur FreeBSD, offrant une sécurité réseau de haut niveau avec une interface utilisateur conviviale. Conçu pour la performance et la fiabilité, OPNsense est équipé de fonctionnalités avancées telles que la prévention des intrusions, la gestion de la bande passante, et le VPN. Avec ses options de configuration flexibles et sa communauté active, OPNsense est le choix idéal pour les entreprises cherchant à protéger leur infrastructure tout en conservant la flexibilité. Découvrez comment OPNsense peut sécuriser votre réseau et simplifier la gestion de votre pare-feu dans cette vidéo. #OPNsense #PareFeuOpenSource #SécuritéRéseau #VPN #GestionBandePassante Slides : https://gitlab.com/xavki/tutoriels-opnsense Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

💸 Après avoir investit Cisco mange Isovalent 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr ➡️ Extrait d'Actus DevOps de janvier 2024 L'épisode complet : https://youtu.be/B5CXNcLBLaw https://isovalent.com/blog/post/cisco-acquires-isovalent 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ## Crédits ### Les podcasteurs - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - Nidouille sur les réseaux. Tous ses liens : http://labperso.ovh - DamyR : SRE chez Waays / DevOps, passionné d'open source & de logicel libre, :man_teacher: professeur vacataire à l'université Léonard de Vinci. Son credo : "*La connaissance n'a de valeur que si elle est partagée*" ;-). Découvre le : https://lydra.fr/ea-1-le-podcasteur-damyr/ | Linkedin : linkedin.com/in/tgerardin/ | Twitter : https://twitter.com/damyr_fr | Blog : https://www.damyr.fr - Nicolas Ledez : devops chez CGWire. Il travaille dans l'IT depuis 20 ans. Il est "Schizophréne" : adminsys et développeur suivant le moment de la journée. Il paraît que ça s'appelle "devops", même si il déteste mettre ce nom sur un poste. Découvre le : https://lydra.fr/ea-8-le-podcasteur-nicolas/ | LinkedIn : https://www.linkedin.com/in/nicolasledez | Twitter : https://twitter.com/nledez | Github : https://github.com/nledez | Le reste : https://nicolas.ledez.net ### Habillage sonore - L'intro et la fin sont de Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Photo de Sebastian Herrmann sur Unsplash : https://unsplash.com/fr/photos/deux-hommes-se-faisant-face-tout-en-se-serrant-la-main-et-en-souriant-NbtIDoFKGO8 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #ADOcourt #Cicso

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 Gitlab est un formidable outil pour disposer de différents services aux seins de votre infrastructure. Cela va aussi bien de services organisationnels que des services plus techniques. Et son périmètre rappelle bien volontier le périmètre de la philosophie #devops. Dans ce tutoriel GitLab : - quels niveaux de variables dans gitlab-ci ? - comment définir des variables globales ou locales ? - quelle différence entre les variables de groupes, de projets et lors d'un run manuel ? Sommaire de plus de 1150 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO Blog : https://xavki.blog ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃 Retrouvez plus de tutorials en français et formation pour devenir #devops : ### Devops/ CI-CD / Cloud Pipeline s01 : http://bit.ly/3a1YsOZ AWS : https://bit.ly/3c5gzUI ### Conteneurisation - docker engine : http://bit.ly/2Zu4F4X - docker compose : http://bit.ly/32hQa0T - docker swarm : http://bit.ly/34bU5hE - kubernetes : http://bit.ly/34jGoNV - vagrant k8s : http://bit.ly/34e5qx - LXC/LXD : http://bit.ly/39x0XJe ### Automatisation - ansible : http://bit.ly/2v3Mv8n - ansible ex. haproxy : http://bit.ly/35iHJDz - Jenkins : http://bit.ly/2Pv7GNH - Git : http://bit.ly/30REYb6 - Gitlab : http://bit.ly/34iqiUr - Jmeter : http://bit.ly/2rMr79R ### Infrastructure - consul : http://bit.ly/2ZFEebH - Infra Mesh : http://bit.ly/2MUWUhV ### LB et reverse-proxy - HAProxy : http://bit.ly/2HBDLxc - Linkerd : http://bit.ly/2MUWUhV ### SQL/NoSQL - ElasticSearch : http://bit.ly/2UitZFe - PostgreSQL : http://bit.ly/2UitZFe ### Sécurité - IPTables : http://bit.ly/2NIi6a9 - Netcat : http://bit.ly/2zFK3HA - TCPDump : http://bit.ly/2SbM8G0 ### Scripting - Scripting : http://bit.ly/32hRgtx - Flask : http://bit.ly/34hvQ1q - Python : https://bit.ly/3ba5OAB ### Raspberry - faire son infra : http://bit.ly/2wnqplF - k8s (pikub) : http://bit.ly/2zBWBQa

Quand Taiichi Ōno écrit Toyota Production System en 1978, c'est pour raconter comment il mit une décennie à convaincre ses chefs de changer les processus de production, mais de manière encore plus étonnante encore une autre décennie de plus à convaincre les ouvriers de l'intérêt pour eux de devenir polyvalents. Le toyotisme donnera plus tard naissance au Lean, et pendant un demi-siècle les méthodologies qui en découlent transformeront la manière de travailler à travers le monde entier, jusqu'à aujourd'hui en informatique. Quand on vous parle de craftsmanship, on vous parle d'un concept que cet ingénieur Japonais mettait déjà au cœur des pratiques sur ses lignes de production. Le craftsmanship c'est la manière de promouvoir la maîtrise de ses outils, d'être capable d'aider ses collègues, et de créer les standards. Et c'est un prérequis pour faire du DevOps et de l'Agilité à l'échelle. Durant ce talk, nous aborderons les points suivants : - Une brève histoire de l'agilité, qui est le point de départ - L'émergence du software craftsmanship et son manifeste - Le software craftsmanship comme levier pour gérer la complexité dans l'organisations IT

Retrouvez mon article sur le blog de mon entreprise SoKube.

Depuis qu'il a été lancé en 2014, Kubernetes est devenu le leader dans les outils d'orchestration de conteneurs. Il permet…

💰 Grosse somme pour se rachat qui fait trembler les utilisateurs de VMware. 💖 Soutient mon travail et la communauté sur : https://soutenir.compagnons-devops.fr ➡️ Extrait d'Actus DevOps de janvier 2024 L'épisode complet : https://youtu.be/B5CXNcLBLaw https://investors.broadcom.com/news-releases/news-release-details/broadcom-acquire-vmware-approximately-61-billion-cash-and-stock https://www.reuters.com/markets/deals/broadcom-closes-69-bln-vmware-deal-after-china-approval-2023-11-22/ https://www.it-connect.fr/broadcom-officialise-le-rachat-de-vmware-et-le-reorganise-en-4-entites/ https://techcrunch.com/2022/05/26/broadcom-to-acquire-vmware-in-massive-61b-deal 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ## Crédits ### Les podcasteurs - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - Nidouille sur les réseaux. Tous ses liens : http://labperso.ovh - DamyR : SRE chez Waays / DevOps, passionné d'open source & de logicel libre, :man_teacher: professeur vacataire à l'université Léonard de Vinci. Son credo : "*La connaissance n'a de valeur que si elle est partagée*" ;-). Découvre le : https://lydra.fr/ea-1-le-podcasteur-damyr/ | Linkedin : linkedin.com/in/tgerardin/ | Twitter : https://twitter.com/damyr_fr | Blog : https://www.damyr.fr - Nicolas Ledez : devops chez CGWire. Il travaille dans l'IT depuis 20 ans. Il est "Schizophréne" : adminsys et développeur suivant le moment de la journée. Il paraît que ça s'appelle "devops", même si il déteste mettre ce nom sur un poste. Découvre le : https://lydra.fr/ea-8-le-podcasteur-nicolas/ | LinkedIn : https://www.linkedin.com/in/nicolasledez | Twitter : https://twitter.com/nledez | Github : https://github.com/nledez | Le reste : https://nicolas.ledez.net ### Habillage sonore - L'intro et la fin sont de Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #ADOcourt #VMware

Tetris dans un terminal Teaser et #shorts d'Actus DevOps de janvier 2024 L'épisode complet : https://youtu.be/B5CXNcLBLaw