 Bonjour à tous, j'espère que vous avez passé une bonne journée. Alors aujourd'hui on va parler de SLO. Je ne sais pas si vous êtes connaissés la pratique des SLO, donc on va se baser essentiellement sur l'utilisation des frémorques SLO qui vont nécessiter notamment de l'observité. Et on va voir que je vais introduire un frémorque open source qui s'appelle Captain et on va voir qu'on peut faire plein mal de choses avec. Et surtout je vais vous expliquer pourquoi ce frémorque existe et à quoi il va vous aider. Petite introduction. Qui je suis, je m'appelle Henrik Reckseid. Je travaille pour Dinatras. Je suis cloud native advocate. Et donc ma spécialité c'est tout ce qui est Kubernetes, tout ce qui est Open Observability. Avant Dinatras, je travaillais plus de 15 ans dans l'ingénierie de la performance. J'étais développeur aussi. Et donc du coup l'ingénierie de la performance c'est quelque chose qui est dans mon cœur. Et donc c'est pour ça que j'anime une chaîne YouTube avec d'autres spécialistes qui s'appellent PervBytes. Donc c'est l'icône que vous avez là, le deuxième icône. Et donc c'est une chaîne qui va permettre de donner des tutos, des explications théoriques sur comment bien faire de l'ingénierie de la performance parce que l'ingénierie de la performance, si il y a de la méthodologie derrière, il n'y a pas de l'improvisation. Et enfin il y a moins d'un an, j'ai ouvert une chaîne YouTube qui s'appelle Is it observable. Donc Is it observable c'est que une chaîne YouTube pour fournir des tutos sur l'observité. Donc je ne parle pas de Dinatras, je parle essentiellement de tout ce qui est framework open source. Expliquer la valeur d'un framework en particulier. Et puis donner un exercice ou une explication sur la valeur du framework. Et enfin, le dernier logo si je ne vous le connaissais pas c'est CNCF. Je suis membre CNCF, je travaille dans plusieurs groupes au sein de CNCF, donc tout ce qui est open telemetrique dans un côté et aussi tout ce qui est sur l'observité, sur humanité. Allez, on va commencer. Alors que si vous restez avec moi, j'aimerais bien que vous restiez avec moi quand même. Qu'est-ce qu'on va parler et qu'est-ce que vous allez apprendre pendant ces 45 prochaines minutes ? Plusieurs choses. Comme je l'ai mentionné en début, on va parler de méthodes SREs. Donc si vous ne connaissez pas la méthode SREs, on va faire une piqueur de rappel. Qu'est-ce que c'est ? Qu'est-ce qu'est la valeur des bases ? Et surtout, on va s'attoler sur ce qu'est un SLI et un SLO. On voit bien voir que derrière, il faut de l'observité. S'il n'y a pas de données, on ne peut pas mettre en place cette méthodologie. Donc on va rappeler que l'observité en général est importante et présenter quelques frais morts qu'au open source qui sont présents. On va faire une petite piqueur de rappel sur Prometheus, parce que dans la démon, on va parler de Prometheus. Donc si vous ne connaissez pas Prometheus, je vais rappeler ce que c'est. Je pense que la plupart d'entre vous connaissent et utilisent Prometheus. Mais on va quand même faire une petite piqueur de rappel. Et enfin, ça me permettra de commencer à présenter Captain, expliquer ce que c'est, et on finira par une petite démonstration. Est-ce que vous êtes prêts ? Alors on ne fait pas simplement de SREs. C'est une méthodologie, je pense que vous connaissez tous DevOps. DevOps est super connu, c'est une méthodologie, mais il n'y a pas d'outils. DevOps est juste une méthode. Il n'y a pas d'outils et d'applications pour mettre en place une bonne pratique DevOps. SREs, c'est l'inverse. Alors on va rappeler un petit peu, on va retenir dans le passé. Pour ceux qui n'ont pas vécu cette période, il y a une période dans le temps où on n'était pas du tout agile, on n'était pas du tout DevOps. Et du coup, on mettait en place, on avait une barrière entre guillemets, entre le développeur et la partie exploit, la partie prod. Ce mur était présent et il y avait des vrais combats qui s'installaient entre le dev et l'exploitant. Parce qu'en réalité, il y avait deux objectifs différents. Moi je suis dev, mais moi je veux l'innovation, je veux de l'agidité, je veux amener des choses, de la valeur au sein de l'application. Alors que en tant que quand je suis en prod, moi je ne veux surtout pas toucher si c'est stable, je ne touche à rien. Donc je veux de la dispose, je veux de la stabilité. Donc du coup, on fait des tests de notre côté côté dev, on valide, mais la partie exploit a différents critères et différents objectifs, donc on a des rejets et on peut avoir justement des conflits qui sont assez importants. Donc les choses ont changé. On a introduit à l'agile, méthode très intéressante. On a introduit et DevOps, c'était super. Mais on n'avait pas d'outils pour modéliser et suivre en temps réel l'évolution de la stabilité, de la performance de notre système. Donc l'idée c'est d'avoir un prod d'octoneur et on va travailler dev et SREs, ou exploit, pour définir ces objectifs ensemble. Donc on va définir des critères qui vont être liés sur la partie perf, comment on peut mesurer en prod que mon système est bien performant, comment peut-on mesurer que mon système est disponible et bien entendu, on a plein de critères diversifiés. Et pour ça, on va utiliser des SRA et des SLO. Le concept des SRA et des SLO, c'est d'identifier des problèmes avant qu'un utilisateur puisse se détecter. Et encore, on a une notion d'objectifs, c'est des SLO. De manière générale, quand on suit des objectifs, souvent on se challenge. Maintenant, on va essayer de me challenger, je ne vais pas l'atteindre, c'est sûr. Mais dans la pratique SREs, il faut avoir des objectifs atteignables. Sinon, ça n'a pas de sens. Parce qu'on va voir derrière, il y a des choses qui sont calculées, notamment le rubberjet. Alors le SLI, le SLI, ça veut dire service level indicator. Donc, on se dit, c'est une métrique. CPU, tendre réponse, ou autre. En réalité, non, ce n'est pas tout à fait une métrique. C'est un ratio. La méthode de calcul dans SLI, c'est je prends le nombre d'événements positifs qui sont convenables, qui sont divisés par le nombre total d'événements et je multiplie par 100. On va faire un exemple. Je mesurerai la performance de mon système. Mon critère, c'est, à partir de 5 secondes, qui peut être discutale, on pourrait dire 3 secondes, c'est mon objectif. Donc je vais mesurer, compter le nombre de requêtes, HTTP, qui sont inférieures à 5 secondes. Et je vais diviser par le nombre total de requêtes qui ont été surveillées dans cette période. Multiplie par 100. Donc là, j'ai moins SLI, je suis satisfait. Maintenant, il va falloir mettre un objectif en face du SLI. Donc, le SLI, le SLO, on va essayer d'identifier la limite où l'utilisateur est insatisfait. Et on va fixer en pourcentage ce SLO. On se reprend sur l'exemple de tout à l'heure. Donc, souvent, l'objectif, on ne va pas le fixer à 90%, à 95%, on va se rapprocher des 99. Et après, je pense que vous avez entendu la loi des 99.9.9.9.9, plus on s'en met de 9, plus c'est compliqué à atteindre, et plus ça coûte extrêmement cher à arriver à cet objectif. Donc là, on va prendre un objectif, on va dire, tiens, moi, ce que je veux, c'est qu'en performance, je suis à 99%. Une fois que j'ai identifié ce SLO, j'ai pouvoir fixer un error budget. Donc, ce error budget, finalement, je prends 100, je retire mon SLO dans 99, il me reste 1%. Et donc après, derrière, je sais que dans mon prod, je fais une release tous les 30 jours. Donc, du coup, je vais évaluer mon SLO sur cette part de 30 jours. Et je sais qu'en prod, sur cette part de 30 jours, j'ai à peu près un million de requêtes. Donc, si je prends 1% d'un million de requêtes, ça veut dire que j'ai droit à 1,000 requêtes sur 30 jours qui ne respectent pas ce critère des 5 secondes. Alors, à quoi ça sert d'avoir ce error budget ? Donc là, je sais que j'ai 1000 requêtes acceptées. Derrière, on va identifier ce qu'on appelle un fast burn rate et un slow burn rate. Alors, fast, ça veut dire je consomme vite mon budget. Slow, je consomme doucement. Donc, si je suis en production et que je vois que tout d'un coup j'ai mon total de 1000 et je vois que dans l'espace de 1 minute j'en ai mangé déjà 350. Je me dis où là ? Il me reste quand même 29 jours. Donc je ne suis pas très bien. Donc là, je identifie que c'est un fast burn rate. Donc là, la manière de traiter l'incident va être complètement différente. Donc là, je vais avoir quelqu'un tout de suite sur le pont. On va essayer de couvrir l'incident plus vite pour éviter la catastrophe et d'avoir plus de budget. Par contre, si je suis en slow burn rate, j'ai une requête dans la journée. Je m'a dit, j'ai quand même 30 jours pour qu'on sait encore 999 requêtes. Donc là, je suis sur un slow burn rate. Je vais ouvrir un ticket. Les équipes de devs vont le traiter sans aucune urgence, sans aucun stress. Et on pourra gérer l'incident convenablement. La deuxième chose qui est importante c'est l'automatisation. Remove told. Donc le concept, c'est qu'on va pas faire, on va retirer toutes tâches manuelles et répétitives au maximum. Donc forcément, quand je fais l'exploitation en production, je vais avoir des tâches d'opération. Je vais consommer 50% de mon temps là-dessus. Et l'autre partie, 50%, je vais faire du dev. Je vais automatiser. Alors pourquoi on fait ça ? Parce qu'à terme, je prends un exemple. Si j'arrive à automatiser convenablement, ça se trouve, je vais pouvoir passer que 25% de mon temps sur les tâches d'exploitation. Je garde mes 50% sur fondant du dev. Et après, je vais pouvoir investir 25% sur d'innovation, sur former mes équipes, amener de la valeur en entreprise. Donc c'est ça la mentalité autour d'USRs qui a été introduite, il y a plus d'une dizaine d'années par Google pour justement amener la stabilité de leur système. Alors maintenant, on a vu que sur l'USRs, on se base sur des métriques. Si on n'a pas d'observaté en dev, en QA ou en prod, on ne peut pas mettre en place cette méthodologie. Donc il va mettre en place de l'observaté. Donc on va rappeler qu'est-ce que c'est l'observaté. L'observaté, ça se base sur des piliers. Il y a plusieurs piliers disponibles. Donc on a forcément les logs. Quand on crée du code, on va générer la log. Donc les logs sont une source d'information très riche. On va se baser sur des événements. On va faire des systèmes aujourd'hui comme Kubernetes. On va générer des événements. Ces événements vont être une source de troubleshooting qui va être très efficace. On va regarder les métriques traditionnelles qu'on a pu le faire dans le passé. Sauf que ces métriques, il faut qu'il y ait des dimensions. C'est-à-dire qu'à passer de prendre un CPU mais pouvoir le couper par service, par machine, par autre chose. Si je n'ai pas cette contexte, la métrique ne va pas me servir à grand-chose. Je sais qu'il n'y a plus quelque chose qui va mal et enfin les traces. Très riche pour pouvoir identifier où on passe du temps et être plus efficace dans l'analyse. Il y a le dernier PD qui est en train de s'introduire dans l'observité. C'est le Continuous Profiling qui va arriver plus vite qu'on pense. On regarde le paysage chez CNCF. On se dit je vais mettre ça en place. Il y a plein de frameworks open source. Je vais regarder sur la catégraphie CNCF. Il y a plein de frameworks qui ont été fournis par plein de sociétés très intelligentes et très efficaces. Donc c'est génial. Je suis en bonne voie. Quand on prend du recul et qu'on regarde finalement le tableau CNCF, on se rend compte que c'est un peu ça. Il y en a partout. Il y a des projets un peu partout. Quand on commence et qu'on ne connaît pas les projets, souvent on se dit lequel je vais prendre. Ne vous inquiétez pas. Je vais vous expliquer lesquels projets ont du sens et celles qui ont de la valeur donc sur la gauche c'est les standards qu'on va aller voir tout à l'heure et sur la droite ce sont les frameworks pertinents. Donc sur la log il y a plein de frameworks qui vont récupérer de la log qui ont de la valeur. Celui qui est en avis le plus mature aujourd'hui et le plus stable c'est Fluendy et Flanbeat. Fluendy qui est sur un système plutôt traditionnel bernmétal. Fluendy plus pour la partie Kubernetes. Prometheus. On a en parler tout à l'heure. Prometheus c'est le standard aujourd'hui pour la métrique. Si vous voulez vousz la métrique, si vous n'avez pas Prometheus c'est qu'il y a un problème. Et enfin Thanos, c'est pour du Prometheus distribué, Thanos a vachement de valeur. Et enfin sur les couches basses, on a Jäger pour la partie Gtracing, Cortex qui est un standard de tracings et de métriques et enfin Grafana pour la partie visualisation. Sur la partie standard, on a OpenTelemetry. OpenTelemetry je ne sais pas si vous le connaissez. C'est le deuxième projet le plus gros après Kubernetes chez CNCF. L'objectif d'OpenTelemetry c'est je ne ferai pas une solution. Je ferai un standard. Une manière standard de produire des métriques une manière standard de produire des logs une manière standard de produire des traces etc. Une fois que je suis dans un standard après je peux envoyer mes métriques mes données dans n'importe quelle solution du marché. Cloud events. Je vous l'introduis parce qu'en fait Capitaine Sobas sur Cloud events c'est un framework d'échange dans le cloud qui a standardisé des échanges HTTP pour faire des événements cloud. OpenMetrics c'est standard métric. C'est des events. C'est le petit frère de Cloud events. C'est pour tout ce qui contige des livris. On s'inspire sur les Cloud events et on voyait des événements pour déclencher des chaînes d'automatisation. Et enfin OpenSlow c'est un standard pour définir CSLO parce qu'aujourd'hui on a à chaque outil, à sa manière propre de définir des CSLO. Donc en mettant en place un standard au moins ça évite de revenir en arrière à la prométheuse. Prométheuse c'est un fournisseur d'émétrique et je vais vous brièvement vous décrire l'architecture que vous pouvez avoir dans Humanities. Donc quand vous installez Prométheuse dans Humanities déjà on utilise l'opérateur l'opérateur de Prométheuse qui va déployer plusieurs composants. Le premier composant en cœur c'est le Prométheuse server. Ce Prométheuse server va avoir en fait à l'intérieur 3 composants qui ont un rôle important. Le premier c'est Scrap Scrapping. Prométheuse n'a pas de métrique. Il va aller piocher des métriques sur une application qui elle expose des métriques. Donc la première composant on va chercher les métriques et après il va utiliser le deuxième composant qui est la time series à la base. Et enfin derrière il y a un autre 3ème composant qui est l'interface web qui vous permet de regarder rapidement vos données, faire des requêtes en Prométheuse du Promql et souvent on va pas rester dans l'interface graphique de Prométheuse mais on va plutôt construire ce dashboard dans Grafana. Enfin on a l'Alert Manager c'est un composant clé qui va définir des alertes basées sur des Promql. Ces alertes sont sur des solifixes et donc on a ces 3 composants qui fait la valeur de Promql. Si on regarde à gauche on a 3 exporteurs. Ces 3 exporteurs vous permet d'avoir une observéité, une compréhension sur vos clusters Humanities. Le premier c'est Culset Métriques qui vous donne les santé de vos objets. Deuxième c'est nos d'exporteurs qui donnent la santé de vos neux au serveur physique ou virtuel et enfin on a le CI Advisor qui donne la santé de vos conteneurs. Prométheuse c'est un vrai standard au-delà de Humanities quand on regarde si vous utilisez un environnement permétal on va regarder que toutes les bases fournissent des données au format Prométheuse. Quand on regarde l'hardware c'est pareil. Toutes les données hardware aujourd'hui fournissent des données Prométheuse. Que ce soit du messaging, du stockage, que ce soit du CICD que ce soit même du log de la gestion de vos pipeline de log tous fournissent des données au format Prométheuse. Pour ceux qui il y a 10 ans de cela si vous deviez surveiller un appliance réseau on devait faire du SNMP il faut lui trouver l'expert en interne qui sache configurer le SNMP donc là c'était déjà le challenge et une fois que c'était activé on était très content on a des données qui arrivent. Aujourd'hui il y a du hardware, physique combien d'interface c'est Prométheuse ce qui est juste magique. Prométheuse est clairement partout. On a vu la partie observité. En Prométheuse c'est ce qu'on va utiliser. Maintenant on va regarder comment automatiser. Et donc pour automatiser on va rappeler ce qu'on fait aujourd'hui pour ceux qui font du CICD aujourd'hui quand tu fais du CICD on va créer un pipeline en production, en staging, en dev et on va avoir différents outils qui vont nous permettre de réaliser les tâches d'automatisation qui vont tester déployer notre code en production en staging ou en dev donc du coup on va interfacer j'ai prendre cette application là je vais l'interfacer sur mon pipeline avec celui-là et puis on se rend compte que c'est fastidieux et puis après ce qu'on se rend compte qu'il y a un pipeline qui marche et quelqu'un qui prend la section de pipeline, il la copie, il la colle il la met ailleurs et puis on revient trois semaines ou un mois plus tard on se rend compte que ce bout de code de mon pipeline il est partout dans l'organisation on se retrouve dans un vrai spaghetti d'automatisation qui est compliqué à maintenir et dès qu'on doit changer d'outil c'est un vrai projet. Il faut changer tous les pipelines de l'organisation parce que aujourd'hui par exemple j'utilise un changement d'outillage et très coûteux pour une organisation donc la maintenance aujourd'hui il faut comprendre que CIR-CD c'est quand même du code qui permet de gérer vos codes et il faut quelqu'un qui gère ce code et donc c'est quand même très lourd à mettre en oeuvre et donc c'est pour cela qu'il y a quatre ans Dynatras on s'est dit tiens il y a un problème comment on pourrait faire quelque chose de plus simple il faudrait une plateforme qui gère tout sans avoir des conséquences d'automatisation et bien ça la réponse c'est captain captain est un framework basé sur des cloud events on a des étapes dans ma chaîne d'automatisation et les outils vont souscrire à un événement et cet événement je m'a souscrit un événement test captain lui il sait pas que c'est l'outil A, B, C, D il en a rien à faire il envoie l'événement l'outil en question prend l'événement et il fait son travail donc le fait d'avoir cette chaîne d'événement on va transclater ce qu'on avait avant qui était lourd, pénible à maintenir en quelque chose de beaucoup plus simple on crée une chaîne de séquences d'automatisation qui est basée sur un événement et derrière on va souscrire des outils à haut de différents événements de ma chaîne d'automatisation et donc on a l'automatisation qui se fait très facilement et je dois enlever un outil pour le remplacer par un autre mais j'ai juste à enlever la souscription et remplacer par une souscription donc captain, comme j'ai dit, c'est à 4 ans aujourd'hui on est projet CNCF on est passé de sandbox à incubation on a une command line on a un interface GUI derrière on fait beaucoup de choses on fait pas que le CI CD on va expliquer, on choisit à la clé de comment utiliser captain on est assez souple sur la manière qu'on s'amarche c'est tout est basé, je demande cette notion de SLO sur la partie SOS donc aujourd'hui on va essayer de mettre en œuvre dans les mots qu'on va faire l'utilisation des SLO pour valider une chaîne d'automatisation captain est au milieu et pour évaluer je peux avoir des critères d'évaluation dans ma chaîne d'automatisation dans différentes étapes, donc je fais du test j'ai envie d'avoir quelque chose qui me dit est-ce que mon test est positif ou négatif sur la partie SLO captain n'a pas d'observéité il va s'interfacer sur un métric provider donc on a le promettéus métric provider qui est là pour s'interfacer sur le promettéus on a un datadog promettéus provider qui va s'interfacer sur le datadog on a aussi forcément dinatras donc on peut choisir quel outil on veut se connecter et on va définir les SLI dans le formalisme de l'outil cible et captain lui et la connaît vos objectifs récupère les métriques et va identifier si oui on est bon ou non on n'est pas bon et donc on peut déclencher d'autorehumidisation en production on peut faire la notification sur Slack, sur n'importe quoi et donc vous avez vraiment en automatique vous êtes au courant de tout ce qui se passe alors le principe très simple on va d'abord identifier un use case on peut faire tout, une products delivery donc je gère tout par captain mais toutes les organisations aujourd'hui utilisent GitLab, Jenkins donc ça a pas de sens de tout faire le coût de changement pourrait être assez lourd à mettre en avant je peux très bien utiliser captain pour je veux juste utiliser captain pour valider mes tests donc du SLO QuayTicket ou je peux mettre en place des scénarios plutôt SREs en production donc je veux faire d'autorehumidisation je veux faire d'automatisation en production donc je peux aussi utiliser captain une fois que j'ai mon use case j'ai des configurations à envoyer dans captain donc si je fais du CICD je veux définir un shipyard si je fais du QuayTicket la rémédiation basée sur des SLI et des SLO il va falloir que je définisse les SLI et SLO si je fais du test en charge je veux définir un fichier de workload si je fais etc etc après j'ai mes outils et après je les interface et captain va provenir une interface graphique qui permet de suivre vos différents séquences de votre projet et on a une hipmap qui vous rappelle vos différents SLI alors si on rappelle donc je peux utiliser captain soit captain fait tout le cycle d'automatisation soit je vais utiliser que pour tester donc là j'ai une cycle je déploie, je teste et il faut que je valide donc juste à pas d'inquiétisation ou je peux laisser captain faire tout captain va déployer, va tester, va faire la release à tout faire alors qu'on a passé la barrière de la prod on passe en prod donc là je vais avoir je peux avoir des besoins de faire des cani release des blue green deployment je peux faire des rémédiations donc à un moment donné il va falloir pour générer une release il va falloir un service qui évalue qui dit oui tout est bon ou non au contraire tout va mal donc tout ça cette partie de rémédiation se fait au travers des SLI et comme j'ai dit précédemment on va interfacer derrière un metric provider on va définir le SLI dans captain qui va lui lancer la séquence d'automatisation vers les outils qui vont bien alors on va prendre le cas de l'évaluation on va le voir tout à l'heure en démonstration donc je fais une évaluation, j'ai fait un test j'ai envie d'évaluer si mon test est valide ou non donc du coup j'ai un service qui s'appelle le light house dans captain et du coup ce light house lui dit j'ai un SLO qui est un service pour le dev j'ai un SLO donc là on vous voit par exemple j'ai un error rate j'ai un la jvm memory j'ai le nombre d'appel en basse de nez donc là j'ai défini tous mes critères et je vais mettre un score en fait en réalité captain va attribuer un nombre de points pour chaque indicateur que vous avez défini donc si j'ai 3 indicateurs dans mon cas présent j'aurai 33 points par cent 33 points pour chaque indicateur et donc du coup en fonction du succès je vais mettre un score derrière et on va récupérer le SLI donc là je vois que pour ce service déterminé c'est Prometheus ou ça peut être dinatras et donc là j'aurai un fichier SLI propre à l'outil concerné donc si c'est du Prometheus je vais exprimer comment récupérer cette métrique en prime QL si c'est du dinatras je vais soit je pourrais faire un dashboard soit je pourrais faire une métrique en question donc vraiment il faut bien avoir cette notion qu'on a deux fichiers différents qui permet de spécifier l'objectif comment on va récupérer cette métrique et après une fois que tout a été évalué c'est là on va mettre le hitmap à jour on peut également faire tout ce qui est une séquence complète c'est le déploiement, le test c'est ce que j'ai fait dans ma démo et en fait on va voir que captain au travers de cette approche va pouvoir décider par lui-même de dire je déploie en dev tout passe bien, tout est vert pourquoi attendre, je vais pas sur staging donc il déploie, si tout se passe bien pourquoi attendre, je vais passer un point donc en quelques minutes en fait si tout se est vert vos microservices peuvent partir en prenant en direct la valeur de captain c'est que c'est extensible on a plein de plugins c'est la valeur d'open source c'est que chacun peut contribuer créer son propre service dans des use cases différents pour déployer pour gérer la validation donc on est dans artifact hub on est dans github bien entendu et aussi on a cette CLI donc cette CLI ça va s'interfacer au travers de cloud events donc soit j'ai la CLI et j'envoie un appel captain vers cette CLI soit au contraire je suis dans github j'ai envie de m'interfacer dans captain j'envoie un appel HTTP avec un bon payload puisque c'est le principe des cloud events et là la chaîne va se lancer alors on va voir la petite démo alors la première démo on va voir en fonction du temps qui me reste la première démo on va vraiment utiliser captain on fait du test en charge parce que je sais pas si vous avez fait le test en charge dans votre vie mais le gros problème du test en charge dans l'automatisation c'est qu'aujourd'hui on fait du test en charge on vaille d'automatiquement donc on a une chaîne automatique qui lance tout et puis après on sort on a un statut qui est vert puis souvent on se dit j'ai pas confiance je vais comme analyser moi-même et ça c'est pas normal donc on est plus dans l'automatisation on est dans une fausse automatisation on a besoin d'avoir quelqu'un qui regarde le résultat et donc l'objectif ici c'est qu'on va exprimer nos SLA et SLO et comme vous avez vu avec si on crée plein de SLA et plein de règles différentes on a cette notion de poids de SLA et plus important du coup on a une règle de validation qui est beaucoup plus complexe et on va pouvoir avoir confiance au positif qui a été sorti de la chaîne automatisation donc là la première démo c'est qu'on va utiliser K6 il n'y a pas l'intégration avec K6 je vais mettre en avant le fait qu'on a un job executeur donc il n'y a pas l'ancien importe quoi et donc du coup ça va automatiser la chaîne de validation et après on va avoir la partie rémédiation si on a le temps alors première chose on va savoir je peux pas voir attention alors ici on a Capten si vous voulez les intéresser sur le projet Capten.sh c'est le site internet on a la documentation on a pas mal de tutos vous pouvez étape par étape ou suivre des tutos sur utilisation de Capten c'est plus avec Dynatra c'est plein de choses donc déjà si vous êtes intéressé commencez par un tuto ça permet de voir un peu et comprendre comment ça s'interface dans votre environnement et la valeur qui est derrière deuxième chose qu'il y a ici c'est Capten je suis sur le Capten Bridge donc là j'ai un projet ici on voit Capten ici il y sera tous les projets qui sont disponibles donc là j'ai que le online boutique donc il y a cette notion de je crée un projet et dans ce projet j'ai des services donc là aujourd'hui j'ai qu'un seul service qui s'appelle Product Catalog qui est ici et derrière je vais avoir à définir une séquence donc j'ai trois environnements au cas présent j'ai du dev, du staging et de la prod et donc après je peux aller regarder une séquence en particulier je vais regarder la séquence qui s'est passée tout à l'heure que j'ai lancé il y a quelques minutes sur la partie dev et donc je peux voir qu'on a fait un déploiement donc le déploiement il se base sur Helm donc il faut mettre à disposition une Helm chart et Capten va pouvoir le déployer ici j'ai une tâche automatique donc là j'ai lancé un test de charge avec K6 et après on a la partie evaluation donc là on est sur la quality gate proprement dit donc quand on parle d'évaluation et après bien sûr là il a on a récupéré les maîtris qu'à associer et puis comme on avait un critère c'est tout se passe bien mais il est passé automatiquement en staging donc il a lancé en dev il est passé à 5 minutes plus tard il était déjà en staging et 10 minutes plus tard il était déjà en prod donc là vraiment grâce à ce mécanisme je peux lancer des chaînes automatisations des chaînes automatisations complètes sur ensemble donc après je peux regarder ici si je veux un peu cette notion de quality gate donc là sur le dev oh mais tiens c'est moi que je sais pas c'est bizarre ça donc là on va regarder sur staging donc là j'ai différents ici SLI que j'ai exprimé donc je peux regarder ici tous les statues avec les objectifs que j'ai fixés et le score que j'ai eu ça ne fait rien de m'empêche de regarder la valeur de chacun des indicateurs au niveau du tableau après je peux aussi aller en charts donc regarder les valeurs de chacun des indicateurs mais encore une fois de plus ce n'est pas un outil de observabilité c'est un outil qui va permettre de automatiser la prise de décision dans un cas de test ou d'autoramisation en production la particularité de captain à partir du continuous delivery ce qui a été mon cas c'est que je vais interfacer avec un repo donc un repo GitHub repo GitHub, repo Bitbucket n'importe quel donc là ici moi j'ai interfacé ici un repo qui s'appelle hipster shop parce que c'est on a une boutique de Google et vous allez voir qu'en fait ce repo il est complètement vide il y a un petit prème internet donc ce repo est complètement vide mais quand on aura accès au repo vous allez voir qu'on a captain a créé automatiquement des branches donc dans ce repo il a créé une branche dev parce que dans mon cas il y avait dev, staging et prod donc il y a trois branches de dev, staging et prod et tous les fils de configuration associés à chaque environnement sont présents dans le GitHub ou dans un présent GitHub donc en fait il y a vraiment cette notion de jeu stock je modifie des configurations, je fais un commit et donc du coup si on a besoin de revenir en arrière et utiliser d'une manière inexpliquée autre chose que l'automisation qui est fournite par captain on peut le faire très bien avec les fichiers qui sont présents captain si on regarde ici on voit tous les différents branches donc là je peux aller dans la branche de dev et on va voir que ici j'ai le product catalog qui est le seul service que j'ai mis à disposition sur l'environnement et je vais voir ma M-chart qui est ici, j'ai mon job parce que je fais de l'automisation via un job aux exécuteurs et j'ai tout ce qui est SLO qui est présent ici et les indicateurs dans mon cas j'utilise Prometheus avec les métriques Prometheus qui sont exprimés ici donc chaque chaque projet aura une arborescence similaire donc on peut très bien revenir pour avoir accès aux fichiers si besoin c'est la première chose donc on va regarder maintenant au niveau du code comment ça se modélise, c'est ce que je vous ai montré première chose, ici j'ai créé le projet quand j'ai créé le projet j'ai défini ce qu'on appelle un chip yard donc on va définir les différents étapes de ma chaîne d'automatisation donc là j'ai dit que j'avais une séquence de dev et dans dev j'ai une séquence qui s'appelle delivery et dans cette phase de delivery on va passer d'abord un sur déploiement direct parce que c'est du dev et après on va lancer un job qui s'appelle K6 component testing et après on va demander l'évaluation et l'évaluation on va se faire sur 5 minutes, sur les dernières 5 minutes parce qu'en fait je sais que mon test dure que 5 minutes sur le staging ça va se déclencher si la séquence de dev delivery a été réalisée avec succès donc si elle s'est réalisée avec succès captain va automatiquement déclencher la séquence liée au staging et va faire avec moi la même chose donc là on est sur un déploiement direct on va lancer un job qui s'appelle K6 et on aurait une évaluation sur les 10 dernières minutes donc c'est assez simple donc on est sur du YAML on est très proche de la culture community et ça se représente de cette manière là maintenant on va regarder je voulais vous montrer le job en question donc là j'ai deux jobs K6 component qui lancent le job K6 et on a le job qui s'appelle K6 tout simplement donc là on a K6 ici qui est lancé un test composant donc là c'est un micro service en GRPC donc je vais m'interfacer sur l'interface de son micro services via des tests de GRPC et ici je définis tout simplement j'ai un job qui va s'inscrire à cet événement donc K6 component et ici je vais démarrer un un conteneur en question et je vais lui envoyer les variables d'environnement et en fait tous ces éléments là on a maintenant la lancement du conteneur avec les informations qui a été présente dans le cloud event l'autre test que je voulais vous montrer c'était le end to end avec un autre conteneur mais on est dans la même logique maintenant regardons la définition des SLI et des SLO derrière on lance le test le test s'est exécuté on est très content mais derrière il va falloir valider le bon fonctionnement du test j'ai le SLI donc on va regarder le SLI le SLI dans mon cas présence sur ce component testing je vais regarder le temps de réponse de mes appels GRPC donc là c'est juste une prime QL classique donc si je connais les métriques que j'ai regardé dans Prometheus si je vois la valeur de la métrique je peux faire la bonne prime QL la renseigner dans mon fil SLI et c'est réglé je donne un nom à cette métrique et après quand je vais définir mon objectif je vais y référer ici tout simplement si cet appel GRPC est inférieur à 10ms c'est bon et si c'est en warning si c'est inférieur à 20ms c'est-à-dire que si c'est supérieur à 20ms je suis en erreur donc là c'est la manière d'exprimer ces objectifs associés alors là c'était le premier cas de test le cas d'utilisation en réalité j'ai juste à montrer une chose c'est qu'en réalité il y a un peu mort et donc du coup sur un projet en question on peut configurer soit tout ce que j'ai montré on peut complémenter la configuration vers l'interface graphique et dans mon cas présent j'ai une intégration donc on voit toutes les services qui sont aujourd'hui enregistrées dans cette séquence d'automatisation et dans mon cas présent j'ai ce fameux job executeur un certain nombre d'événements donc on a cette notion de j'ai un job qui va se lancer uniquement sur le projet online boutique uniquement sur l'étape de dev et uniquement sur le service product catalog en fait vous pouvez avoir cette granité je ne veux que ce service ou tous les services ou tous les projets donc c'est à vous de voir la généralisation de la définition de vos services donc là c'était le premier cas d'utilisation donc là j'aurais pu démarrer une séquence je peux vous montrer rapidement comme j'ai participé précédemment je peux faire juste un appel ABI ou je peux utiliser l'interface graphique là je vais faire product catalog je vais lancer un cycle de delivery on se base sur le cycle d'automatisation qu'on a décrit tout à l'heure et derrière je vais dire j'ai une nouvelle version avec une nouvelle image de mon service micro-service on va reconstruire une nouvelle référence donc on va utiliser une nouvelle image je vais lui dire tu vas déployer une nouvelle image on va prendre cette image là et on va prendre le tag associé là je vais lui demander de lancer et donc là automatiquement il va démarrer la chaine d'automatisation qui va passer par dev il va déployer le service en helm et il va lancer les tests qu'on a montré modéliser précédemment en réalité ce qui se passe si je regarde les namespace qui sont dans ce cluster en réalité on peut voir qu'il a créé automatiquement les namespace donc là moi j'ai rien créé il a créé un namespace qui s'appelle projet d'ache là à l'étape de mon projet donc là j'ai un namespace pour online dev j'ai un namespace pour online prod un namespace pour lab staging si je regarde à l'intérieur de ce namespace le déploiement est réalisé dans ce namespace concerné par rapport à l'étape où je suis dans mon automatisation et la version du conteneur que j'ai stipulé tout à l'heure va être déployée dans chacun de ces namespace et c'est pour ça que l'on est dans notre automatisation associée donc ça c'était vraiment pour la partie CI... on va dire complètement CI CD et comme j'ai bien dit tout à l'heure on n'est pas obligé de faire tout avec on peut dire tiens j'ai juste utilisé la partie QUAITI GAI mais j'ai quand même besoin de définir un service définir un projet parce que derrière quand j'ai définit un objectif il faut qu'il soit attaché à un projet et à un service donc ça c'était pour la partie automatisation sur la partie test en charge maintenant ce qu'on peut regarder c'est la rémédiation donc là la rémédiation je ne sais pas si vous connaissez le concept je suis en production j'ai un événement lambda qui a été détecté par l'alerting de Prometheus ou l'alerting de n'importe quoi et je vais envie de déclencher une chaîne d'automatisation je sais que je suis dans un cas de figure où je suis en train de consommer trop de mémoire sur mon conteneur je sais que je vais avoir un omkill donc mon pote va être tué par Kubernetes donc j'ai une chaîne d'automatisation je vais juste redémarrer où je vais rajouter un 2 supplémentaires pour essayer de donner un peu plus de mémoire donc je peux avoir n'importe quoi et donc là le concept il est particulier où justement j'ai un système tier qui lui a détecté un problème il va envoyer un appel à captain et captain lui va déclencher l'automatisation qu'on a décrite dans un fichier de rémédiation donc là si on regarde dans le code là je vais pas le lancer parce qu'on est un peu short et j'aurais pris des questions de rémédiation qui va être attaché à la prod et un service et un projet déterminé donc là je vais déterminer les choses donc là si j'ai un problème de type out of memory je restart donc là il va lancer un job de restart si je suis un problème de type le temps de réponse est trop important là je vais autoscaler automatiquement donc je rajoute un pote supplémentaire et là si je n'ai pas du tout de problème qui a été envoyé par le système tier donc là je lance le site normal d'automatisation et dans mon cas présent c'est que je redescend un seul réplica donc là vraiment on voit que c'est assez simple et derrière quand on regarde ici dans la prod j'ai mon job executeur qui est défini et ici je vois que j'ai mes différentes jobs qui vont être appelés en séquence donc là restart dans le cas où je viens de redémarrer je fais un bash je fais cube citiel dilette et je supprime le point en question etc etc donc là on va pas le lancer mais la logique est très similaire et donc la capteine ne fait que la remédiation donc vous pouvez très bien utiliser capteine dans ce contact-là voilà pour aujourd'hui petit rappel donc ma chaîne youtube c'est is it observable comme j'ai mentionné précédemment j'ai essentiellement des tutos sur kubernetes, fnbeat, open telemetry sur n'importe quoi la chaîne elle a moins d'un an j'attends des feedbacks donc n'hésitez pas à regarder si c'est mauvais dites le moi je sais que c'est mauvais et que je vais m'améliorer mais c'est en feedback on peut pas s'améliorer donc merci de essayer de consommer autant que possible ces vidéos elles sont là pour ça merci à tous pour écouter et suivre cette présentation excusez des questions bonjour alors moi je voulais savoir dans les tests de charge par exemple que vous faites ou autres tests c'est fait sur des conteneurs on est d'accord captain est un frément orchestration qui va tourner sur kubernetes on peut utiliser captain qui va lancer un appel sur un système tier annex mais le service qui va lui translater et dire tiens démarre ton test il va juste interfacer sur un système qui est donc là ou d'ailleurs mais on a besoin d'un pont qui va dire qu'est-ce que ça veut dire lancer un test d'accord je me questionnais sur la pérennité des données les logs par exemple si on veut les étudier par la suite et tout en fait on peut, là j'ai pris K6 où il n'y a pas une vraie intégration par contre il y a une intégration que j'y metteur donc là on peut lancer des tests soit dans le cluster soit en dehors du cluster une intégration avec neolode de tricentis et donc il va, là il est dans le sec à présent il s'interface pas sur sur un pod ou un conteneur qui est dans le cluster il envoie un api à la plateforme sas et lui la plateforme sas fait son travail et puis il notifie quand il la finit d'accord merci bonjour moi c'était sur la remédiation c'est ce que les exemples que vous avez enfin je suppose que la réponse est qu'on peut faire plus mais sur les exemples que vous avez donné enfin quelle est la différence entre ce que fait captain et ce qui est natif à Kubernetes parce que par exemple la lot of memory en théorique c'est censé cracher le pod donc il devrait être restarté automatiquement par Kubernetes alors oui mais si on est en site critique de lot of memory c'est-à-dire que je ne sais pas si vous connaissez mais il va resquitter le pod mais s'il n'y a plus de nœud disponible donc l'idée c'est d'arriver à déclencher la remédiation avant qu'on soit tué en fait c'est l'objectif c'est on veut réduire au maximum le downtime donc là c'était des exemples assez basiques mais par exemple je sais qu'Orange utilise en interne et ils font des stacks d'exécution automatique pour faire la remédiation sur des problèmes bien précis en fait pour mettre la remédiation en place il n'y a pas de secret il faut déjà comprendre la problématique et se dire comment je pourrais la résoudre très facilement avec une chaîne d'automatisation en fait l'idée c'est effectivement de détecter les problèmes avant qu'ils arrivent avec les indicateurs merci d'autres questions oui si on a des déploiements sur plusieurs cluster Kubernetes entre la prod et leur prod j'imagine que c'est les supportés oui tout à fait on a cette notion de remote job executor qui est captaine dans un cluster et il y a un autre cluster à côté et on va s'interfacer sur l'autre cluster évidemment en fait comme je l'ai mentionné précédemment on est sur un framework de cloud events partirment on peut envoyer un appel HTTP avec le payload cloud events et que vous avez le trafic HTTP qui est autorisé donc le service en question qui est situé ailleurs dans un cluster lui va faire son travail qui est demandé on a encore un peu du temps pour des questions s'il y en a d'autres non alors oui au niveau de comment dire en termes de gouvernance autour du projet et de forcement de l'intégration c'est la CNCF le projet est apparté à CNCF depuis qu'on est en sandbox la gouvernance elle est gérée par les équipes internes c'est à dire qu'on a un commutu manager qui travaille chez Dignatras en fait moi je fais partie d'équipe qui s'appelle le programme office on est pas là pour forcément travailler avec des outils Dignatras on est là pour promouvoir et faciliter la mise en oeuvre de projet open source ou inner source et après aider les projets CNCF donc dans ce contexte là l'équipe captain comme c'était les gens qui ont créé les produits ils gèrent la communauté donc on a des développeurs internes et on a bien entendu plein de contributeurs externes qui participent et qui font de la maintenance sur le projet en fait la particularité c'est que captain depuis qu'il a 4 ans on a lancé une offre SAS qui est un module dans notre plateforme Dignatras qui s'appelle Cloud Automation et derrière en fait on est sur du captain manager avec plein de choses entreprise qui est automatiquement embarquée dans captain core mais oui aujourd'hui c'est CNCF le code appartient à CNCF partiement on a un projet open source et qu'on veut faire partie de CNCF de vous déléguer vous donner la propriété intellectuelle du code à CNCF après derrière on a la partie committee manager qui va gérer et on a une équipe de maintenance propre qui sont là pour gérer les releases gérer les bugs comme un projet classique ok alors merci beaucoup c'était excellent je me suis régalé je pense qu'on peut l'applaudir