 Bon alors, bonjour à tous et bienvenue sur la track de The Dead Nation Day, 100% francophone. Donc déjà, juste un petit check encore pour savoir si vous m'entendez bien sur le chat. Je ne sais plus comment dire si vous m'entendez bien. Oui, merci Mickael pour ta confirmation. Donc n'hésitez pas pendant la présentation à poser vos questions sur la partie, sur le long-glaie Q&A. Et je les poserai donc à Victor et Thomas à la fin de leur présentation. Et donc là, nous avons Victor et Thomas qui travaillent chez Quanto. Pour ceux qui ne connaissent pas Quanto, c'est une fine tech qui offre des services de banques, de banques aux entreprises. Et donc eux, ils ont, ils utilisent apparemment Argosidi pour déployer des applications dans les tests. Et donc ils vont nous présenter tout ça. Donc bienvenue Victor et Thomas et je vous laisse le micro. Et à tout à l'heure. Merci. Merci. Je vais présenter mon écran. Bien sûr, il fait des mots de la découverte 30 secondes avant que, étant un fervent Firefox, ça ne me marche pas trop bien de mon côté. Merci à tous déjà. Donc comme l'a dit Sun, notre thème aujourd'hui c'est le déploiement d'applications dans Qube avec Argosidi. Donc on va parvenir sur ce qu'est Qube. Vous m'excuserez si des fois je dis Qubernetes, Qube, enfin Qube, je pense qu'on fait tous un peu en tant que francophone, c'est faute là. Et on va donc plus vous détailler ce que c'est qu'Argosidi et c'est un retour d'expérience sur comment on l'a intégré chez nous, comment on s'en sert, quel a été notre besoin et qui nous a fait migrer sur ce genre d'outils et surtout qu'est-ce qu'il est capable. Alors qui nous sommes ? On est donc SRE Citrateability Engineers chez Compto. En gros on gère du Qube, de l'Argosidi, du GitLab pour la CIA, du Prometheus, du Thanos. Enfin tout ce qu'est un peu cloud native et on est totalement chez Amazon. Ça ne nous empêche pas de faire des trucs un peu plus à l'ancienne, fait du bon Kafka, de l'elastic search etc. Donc nous c'est Victor et Thomas et pour moi ça fait 18 mois que je suis chez Compto et un peu plus d'un an pour Victor. Donc là je vais vous exposer notre contexte. Pourquoi, enfin, qui on est déjà au sens de l'entreprise ? Donc Compto c'est un service, on est le leader européen actuellement et je pense qu'on va le rester et on va faire mieux même. De la gestion financière pour les PME, TPE et indépendants. Donc on a environ 150 000 clients en plus maintenant, on est présents sur 4 pays en plus de la France. France, Espagne, Italie, Allemagne. Ça marche très bien avec les pays latins que sont l'Italie, l'Espagne, aussi avec l'Allemagne. Et ce qu'on fait en fait c'est qu'en tant que fondisseur de services financiers, on a une gestion de compte bancaire, gestion de cartes de paiement virtuel et plus physique. On a avec le solde en temps réel sur une autre application, etc. Et depuis peu, il y a un partenariat, on fait aussi du crédit. Donc ça vous permet d'avoir des comptes à découvert, faire du crédit pour la création d'entreprise, etc. On fait du tépot de capital, etc. On fait tout ça. Notre équipe produit plus tech à l'heure actuelle c'est environ 120 personnes et on est en dehors de notre scope à nous qui est la plateforme l'infrastructure avec SIR. Les équipes qui développent sont conçues en mode close future team. Donc elles ont des scopes, elles ont un à un micro-service dans leur giron et pour certains micro-service c'est géré en mode de manière mutualisée. Du coup je vais enchaîner sur la partie notre staging. Nous on a deux environnements principaux, on a l'environnement staging et environnement de prod. Et en staging on utilise ce qu'on appelle des future branch. En fait, vu qu'on essaie de devenir leader européen et qu'on souhaite se développer des fonctionnalités et les envoyer plus rapidement possible en production on se doit d'avoir un tooling adapté pour les développeurs. Et c'est pour ça qu'on a ce qu'on appelle un concept de future branch ou toute branch-geet sur n'importe quel micro-service de la plateforme va pouvoir avoir un environnement dédié. Donc je veux travailler sur une future, je crée une branch sur n'importe quel micro-service je la push et j'ai mon environnement dédié, une sorte de mini-contos sur lequel je vais retrouver à peu près mes 60 micro-service et je vais pouvoir tester les fonctionnalités. On a fait ça en sorte de manière à ce que l'environnement en termes de data il y ait tout ce qui est nécessaire pour que l'environnement soit prêt et fonctionne et un déploiement le plus rapidement possible. Tout ça fait beaucoup de conteneurs donc on a à peu près en moyenne 80 environnements par environnement une soixantaine de micro-service et ça représente entre 4000 et 6000 pods. Donc on a à peu près entre 70 et 100 nodes. Récemment en fait on a arrêté avec le déploiement le automatique on utilise soit un nom dans le comite donc déploy ou on trigger un job-git-lab manuel à n'importe quel moment du processus de la pipeline et à peu près en trois minutes on a l'environnement dédié. Avant on était en full automatique sauf qu'on a tellement de branches que ça a créé beaucoup trop d'environnements et on avait à peu près, on est allé jusqu'à 200 nodes et on a touché un peu au limite de KS et de la paye cube. On en parlera après en fait dans nos retours d'expérience avec ArgoCeline mais ça a généré beaucoup dans le cas de la paye cube. On a doublé le nombre de pods, on a dépassé les 12 500 pods et tout ça pour dire que du coup notre environnement de saging et l'environnement le plus complexe chez Konto et la prod à côté est beaucoup plus statique en fait puisqu'on a beaucoup moins de comptes. Donc en fait avant de parler d'ArgoCeline on avait deux grosses problématiques pour avoir ce concept de feature range. On l'avait quasiment au tout début de Konto il y avait deux gros problèmes en fait c'est un ensemble de scripts bâches et pitons avec des helpers sur M donc beaucoup de tooling qui faisait que c'était extrêmement difficile à débugner c'est à dire qu'en fait il y a un ensemble de logs c'était en fait c'est disponible sur une pipeline Jenkins et une pipeline qui mettait à peu près 30 minutes à tout déployer et que quand ça a planté en fait en plein milieu c'était extrêmement compliqué pour n'importe qui la team est sérieux compris de pouvoir débugner on était sur des milliers de lignes de logs avec des boucles pour checker l'état de santé et planter après cinq minutes par exemple et on avait aussi des dépendances c'est à dire qu'on déployait par batch et du coup si le premier batch échouait par rapport à un déploiement qui est en erreur alors tout le déploiement est en erreur et on passait beaucoup trop de temps on s'est investigués et les développeurs à avoir en fait ces environnements dédiés et puis les développeurs se peignaient aussi que quand ça marchait et si ça marchait le déploiement était beaucoup trop long donc on est parti du principe là on voulait avoir un outil qui soit facile à débugner et avec un temps de déploiement en record donc pour la débugabilité l'objectif c'était que n'importe qui notamment les devs puissent corriger eux-mêmes un problème avec un déploiement l'arabe dévare pas et en prennent de migrations escuelles ou autres, il devrait être capable en toute autonomie de trouver le problème et de corriger et donc pour ça Ragoci va nous aider à avoir en fait une route cause visuelle on va savoir très vite où est l'erreur et ouvert le pod et puis voir les logs depuis une interface on va présenter après et l'autre objectif c'est d'avoir un temps de déploiement très rapide on voulait que une fois que l'application soit a été buildé avec Docker puis s'être déployé qu'on puisse avoir cet environnement maximum 3 minutes et donc pour ça ça passait aussi par arrêter avec des batchs de déploiement et avoir la capacité de pouvoir tout déploier en parallèle du coup je vais laisser Thomas présenter Rago donc Rago déjà il faut savoir que c'est un projet qui s'inscrit dans un groupe de projets donc tous les projets Rago ils sont pour la plupart hébergé maintenant par la CNCF hébergé dans le géant la CNCF Rago CD étant le plus avancé il y en a d'autres un workflow pour faire des pipeline etc je taisis un œil franchement ils font des produits d'excellent qualité vraiment directement orientés cloud les équipes sont très responsibles à répondre rapidement aux besoins et tout donc c'est plutôt vraiment sympa et nous on est parti sur Rago CD donc le loti qui fait du continuous deployment qu'est ce qui nous a séduit en niveau de Rago c'est que déjà c'est vraiment un produit en plus d'être vraiment pure cloud natif vraiment orienté pour déploiement donc cube directement et pas autrement il est vraiment enterprise ready c'est-à-dire qu'on peut out of the box en servir en prod vraiment il ne s'est pas forcément mis là mais typiquement sa résidence sa résidence à l'échec pour qu'il soit haute disponibilité c'est natif du fait qu'il se base directement sur les composants de cube c'est que sa configuration tout ce qu'il gère etc il le stock n'ont été cd donc si le cluster est résilient Rago est résilient je pouvais faire les serres on l'a fait nous-mêmes vous l'installez, vous supprimez tout vous le remettez techniquement les données sont toujours d'anticid et donc il sera comme s'il n'avait jamais été supprimé il causera un peu plus l'architecture tout à l'heure mais il y a ready c'est juste du cache donc il n'y a pas vraiment aucun problème ça c'est vraiment impressionnant et intéressant il y a une interface graphique qui est extrêmement bien elle est très claire, elle fonctionne super bien il gère du SSO ce qui n'est pas le cas de beaucoup de produits il y a une notion de Airbag donc de droits d'accès très très fines sur beaucoup de choses on a les logs etc c'est vraiment bien fait il y a tout un tooling autour qui est extrêmement pratique pour l'exploitation, typiquement quand vous installez Argo dans votre cluster ou à côté dans un autre cluster il va mettre en place des CRD donc des Customs sur 6 Definition qui permettent de gérer ce que vous allez déployer avec ça aussi on ne vous explique qu'après il y a du webbook dans les deux sens donc il est capable d'envoyer de pouche mais aussi on peut piloter il y a des webbooks il y a une CLI aussi il y a des notifications et le grand point c'est qu'il est agnostique au sens où il n'a pas besoin de savoir quel est l'outil que vous allez utiliser pour générer les YAML qui va appliquer typiquement dans notre cas chez Conto on a toujours fait du Helm donc Argo ne va pas faire un Helm Apply il ne va pas appliquer directement il va faire un Helm Template pour récupérer les YAML et il va ensuite appliquer ces YAML c'est à dire que si vous utilisez du Helm du Casonet n'importe quoi de maison chez vous qui sort un YAML qui suit les définitions connues par cube ça fonctionnera ce qui nous permet, nous dans notre cas de passer par exemple par Helm Sops qui est un petit wrapper à Helm qui nous permet de déchiffrer tous nos secrets qui sont chiffrés avec Sops c'est ce qu'on appelle des plaintins internes pour faire le point de vue général alors je sais pas si je sais que c'est assez grand je vais vous l'expliquer rapidement donc ça c'est une vue de Argo le premier truc, ça c'est aussi un truc assez sympa si vous installez Argo vous n'aurez pas la petite barre rouge ce sera un espèce de bleu gris c'est juste qu'il permet aussi facilement de override certaines valeurs de CSS donc nous nos Argos de Prod on a mis en rouge ça on est sûr qu'on ne peut pas faire une bêtise quand on est dessus on sait qu'on est sur la Prod c'est tout bête mais ça permet d'éviter parfois des erreurs donc là typiquement c'est une de nos applications il y a plusieurs vues j'ai fait une vue appels c'est simple on a une vue en plus logique des flux on a l'ingresse qui parle un service qui parle au POD en plus visuellement on peut pas faire plus simple et plus compréhensif on a différentes colonnes avec LC donc ça c'est tout est-ce que tous les déploiements sont OK tout est en ready est-ce qu'on a déployé le bon nombre de replicas c'est le LC il y a plusieurs checks possible on a rajouté nous-mêmes qui sont custom si il y a besoin on a resté sur ce basic de Argos et après on a deux colonnes synced on dit Argos fonctionne vraiment logique GitOps donc il va suivre un repo Git et il va s'assurer de toujours synchroniser une ressource cube avec ce repo Git donc ça c'est divisé en deux morceaux la première c'est quel commit je suis dans Git est-ce que j'ai bien synchronisé moi dans mon cache locale est-ce que j'ai bien récupéré les dernières infos donc c'est la première colonne et la deuxième c'est OK maintenant que j'ai mon ma partie Git est-ce que dans le cube j'ai synchronisé est-ce que j'ai la même chose est-ce que c'est correspondant et ça c'est quand même super pratique donc il s'assure d'avoir les deux je vais pas te montrer juste la slide mais je vous montrera que d'avoir cette logique GitOps et d'assurer un diff permanent entre ce qu'il y a dans Git et ce qu'il y a dans Cube on peut avoir visuellement dans la face d'Ago comme quand on fait une review de code sur GitLab, GitHub, un diff un rouge, vert, ce qui est d'un côté qui n'est pas de l'autre etc on peut demander à déployer, on peut faire des rollbacks aussi, il y a un petit bouton historique en rollback on peut choisir une version d'avant en rollback dans Additels on peut surcharger dans l'interface certaines values c'est très pratique quand on va faire des tests etc et puis en fait je rajouterais aussi que ça nous aide aussi, ça sert un peu de développeurs portales on peut arriver en fait d'ingénieurs backend ou fontaine qui ne connaissent pas forcément Cube ça permet de rapidement voir en fait qu'est ce qui est les conteneurs en clic dessus, on peut voir les logs les events et on peut essayer de débugger ça devient rouge on clique et on a en fait le détail de pourquoi ça ne réussit à démarrer ou pourquoi ça restart c'était quand on mettait tout à l'heure plus facilement pour débugger nous c'est plus de nous qui devourons directement mais ce sont les développeurs là typiquement c'est un problème c'est un petit coeur rouge brisé on clique dessus et directement ça nous dit image pull back off one value etc c'est direct en fait ça nous fait beaucoup moins de lignes personne n'aime lire 500-800 lignes de Jenkins du coup par rapport à l'architecture alors en fait le coeur d'Argo Sidi c'est Argo Sidi Controller donc c'est un opérateur Cube qui va communiquer avec la pays et avoir en fait des custom resource definition pour définir nos ressources donc là techniquement cette application que vous avez vu tout à l'heure ça correspond à une custom resource de type application dessus en optionnel on peut déployer un serveur dex pour le connecter au SSO donc chez Konto une cheese one login on a une interface web qui est dédiée en micro service et un un déploiement dédié en l'occurrence on en a plusieurs on a aussi un Argo repo serveur c'est là où on a la dépendance un peu avec l'infrastructure donc il a besoin d'un release pour gérer son cache et pour éviter de faire systematiquement des appels soit la pedicube soit à GitLam et par exemple au charte Elm et c'est au repo server la petite spécificité c'est que nous on stock nos chartes Elm privées sur S3 et que Argo Sydney ne supporte pas le protocole S3 ce qui est classique il attend un point HTTP donc même si on ajoute le plugin qui va bien Elm pour supporter S3 il ne sera pas capable puisqu'il fait de la validation sur le protocole et il supporte plus le protocole HTTP ou HTTPS donc pour ça on a juste nous rajouter un petit pod pour faire proxy avec S3 mais ça reste assez simple un autre composant qui n'est pas parti du projet Argo Sydney donc là tout cela font partie du projet Argo Sydney central c'est dans l'installation de base après il propose d'autres outils qui vont venir compléter le déploiement et on s'appelle Argo Sydney Notification je crois que c'est une Notifier il a changé le nom, ils ont fait pas mal de versions la dernière version a beaucoup de changements parce qu'ils veulent le rendre avant il était purement Argo Sydney maintenant pour tout leur projet on va pouvoir utiliser il s'appelle Argo Notifier ce qui est pratique c'est qu'il a assez agnostique il ne se base pas du tout sur tout le reste il va juste regarder en fait les CRD et en fonction des events qui vont se passer sur les CRD dans le champ status il va déclencher la pipeline et nous on utilise en tout cas en prod pour qu'à chaque fois qu'il y a un déploiement qui se passe en prod on puisse le voir directement c'est assez simple à part Redis soit à déployer en TANCODE soit utiliser un service malagé c'est extrêmement simple à déployer il n'y a pas de ressources à part TCD et donc via les CRD Cubes au niveau des CRD du coup on va aussi au niveau de la configuration on va aussi se base sur un projet et un projet c'est un ensemble d'applications au sein de ce projet on va pouvoir définir le chose et un peu le scope de déploiement c'est à dire que les namespace les applications de ce projet vont pouvoir déployer quelle ressource ils vont pouvoir déployer ce qu'ils vont pouvoir créer des cluster roles par défaut en fait ils vont fournir des white list des choses qu'on peut déclarer des blacklist et si on veut changer un comportement par défaut on va pouvoir le faire par exemple si je crée un projet monitoring dans lequel je vais déployer Prometheus Alert Manager etc j'ai pouvoir dire en fait je vais créer un projet monitoring dans lequel on va pouvoir déployer son espèce monitoring mais c'est tout et après on peut créer autant d'applications qu'on veut leur attacher au projet et définir comment on veut déployer l'app on va en fait à se baser sur quel projet Voici les fichiers L dans tel dossier et je vais pouvoir ajouter des paramètres custom en plus qui vont pouvoir surcharger la conf qui est contenue dans mon projet ProjetGit c'est un peu l'arboréissance de base et c'est les deux CRD proposés par un gocili pour manager tout le reste et quelque chose qui est important c'est qu'à gocili à chaque fois qu'on fait une PR sur leur item ils insistent sur le fait que chaque fonctionnalité proposée via les CRD soit aussi disponible depuis l'interface donc à tout moment en fait ce qu'on va voir dans les CRD on va pouvoir aussi le voir et le modifier depuis l'interface du coup par rapport au workflow qu'on a actuellement nous on utilise Elm pour déployer un peu tout enfin pour déployer toutes nos applications et au niveau des fichiers Ranges on va utiliser aussi Elm les propriétés de Elm pour boutsraper des ressources infrastructure donc comment ça se passe c'est que quand on pousse une branche on a une palcane générique qui sort et qui démarre on va pouvoir créer le name space créer le projet RagoCili on déploie toutes les applications courantes à part toutes les applications à part l'application courante pendant ce temps là du coup les 60-1 microservice on pouvoir démarrer une image locker et on va déployer l'application courante et la façon dont ça marche c'est grâce à Elm dans chacun des folders de nos projets de nos microservice on va avoir des init jobs qui vont boutsraper les ressources infrastructure donc si j'ai besoin d'une base RDS si j'ai besoin d'une file SQS c'est ces jobs là qui vont juste avant le déploiement venir créer les ressources correspondantes et après par dessus donc ça va être la restauration de data pour que l'environnement ait les bonnes données pour que l'environnement puisse fonctionner et qu'on puisse partir d'une version stable et après je vais déployer tous mes services etc et on a ce principe là sur tout le microservice qui veut dire qu'aussi si demain on décide de changer d'outil si ce n'est pas RagoCili ou autre on va pouvoir garder ses mêmes fonctionnements avec Elm et changer l'outil donc on n'est pas sur une pipeline on va juste faire des cubes et tel applied de ressources de custom ressources definition cube et Elm va s'occuper de tout le reste puisque RagoCili en fait va supporter les propriétés, les annotations Elm hook supporter de base par Elm pas toutes mais la majorité donc même si effectivement maintenant en staging on ne déploie plus automatiquement tout l'environnement à chaque branch une fois que c'est fait une fois que la branche a été déployée et elle sera, tous les microservices seront ce qu'on appelle en auto sync c'est à dire que Rago permanence va aller vérifier par rapport à ses références est-ce qu'elle a été mise à jour etc l'avantage de la future branch c'est que on va avoir sur 60 microservices qu'on travaille que sur un donc par exemple dans ce cas là c'est API API va pointer sur la branche donc elle est en train de développer mais tous les autres microservices autour dont API va dépendre ou qui dépendent d'API seront eux branchés sur master c'est à dire que tant que la future branch sera là, on est assuré qu'on sera toujours à jour pour tous les microservices autour de celui de ce qu'on est en train de développer donc ça évite des phénomènes bizarres où la master a changé on ne savait pas trop on va le voir dans notre branche et donc la master elle est aussi en staging en auto sync permanence c'est par défaut dans Argo il va regarder le différentiel tout qui est 3 minutes c'est pas du temps réel temps réel mais on peut baisser, on peut augmenter, ça dépend de vos besoins et l'avantage de faire comme ça, de faire pointer une référence pour l'application c'est que si on a besoin de développer deux applications puisqu'elles ont une dépendance un changement de schéma ou n'importe quoi dans la communication on peut le totalement le faire on suffit juste que nos deux applications on travaille dans une branche qui a le même nom ce qui fait que sur l'exemple qui arrive violet vous voyez qu'on a API et check qui sont tous les deux dans une branche qui sont pointés sur les branches respectives de leur repos et on a haute à côté qu'est sur master et ça c'est super pratique pourquoi ça marche, cette explication est à droite c'est que quand on déploie l'application via notre CI et puis la CV on fait un apply et pas un criette l'apply permet de surcharger avec un criette, on met tout sur master et une fois qu'on fait déploie, on fait un apply avec QPSTL et là on écrase ce qu'il y avait au niveau du CRT pour l'application c'est basique mais ça nous sauve bien la mise et donc pour gérer en fait toutes ces conflits ces configurations on a un dossier charte en chacune d'une micro service qui va contenir en fait des fichiers en l'occurrence on se base en fait sur une elm charte générique en un terme qui contient un peu toute la configuration par défaut et on va rajouter un override sur ces valeurs par défaut qui s'appelle défaut.yamel et évidemment en fait on a des différences entre la façon de déploie en staging et la façon de déploie en prod, ne serait-ce que pour gérer la disponibilité ou la ressource ou le taux de l'HPA et on va aussi avoir en fait l'ensemble des 6 crêtes donc tout le monde fait sops donc c'est juste des fichiers chiffrés avec l'occurrence des clés KMS sur AWS et en fait l'ensemble de ces 3 fichiers vont générer la conflit de staging et l'ensemble de ces 3 autres 3 fichiers vont générer la conflit de production et on a rendu ça on a cette même configuration ou c'est même chez moi, partout dans l'ensemble de nos applications qui ont ce pas terme là de feature range staging master et production. On n'en parle pas mais la plupart des applications se basent sur une charte Elm maison qui permet de simplifier les choses donc en fait il y a dans default ce qui est partagé effectivement entre staging et prod et on essaie d'avoir le minimum de choses à chaque étape pour qu'en fait les développeurs qui soient totalement indépendants et s'ils ont juste besoin de changer leurs ressources ils peuvent le faire sans aller fouiller dans la charte ou dans le plein de valeurs où ils ont une value parmi 10 et puis c'est fini c'est plutôt pratique et bien sûr on a aussi créé un peu de tooling autour de tout ça pour essayer de faire nettoyer ces environnements quand ils sont plus équilés donc on a plusieurs critères comme le dernier commit qui date plus de 5 jours une fois que la merge request si la branche appartient à une merge request qui a été mergée depuis on suppose que la branche n'est plus utilisée et on va la détruire et les environnements vides soit parce qu'il y a les applications de côté d'il y a la main ou modifiée ou en fait il y a une pipeline qui a jamais pu s'exécuter complètement, le projet a été laissé en l'état au bout d'un jour on décide que c'est un environnement vide qui n'est pas utilisé on va le suppriser donc on a juste créé un script en piton qui va prendre des décisions de suppression en utilisant c'est un peu ces critères et en faisant des requêtes API à GitHub et on va venir en fait supprimer application par application au sein de la même projet puis supprimer le projet d'Argosily là ce qu'on voit les applications et les projets c'est les ressources CRD d'Argosily et dessus on a des finalizers qui vont s'occuper aussi d'il y a de la ressource cube avant de supprimer l'application donc le principe c'est que je dilite mon application de mon CRD donc comme on dit un déploiement Kubernetes va attendre de supprimer les ressources qui lui en dessous donc là, nos pônes, nos services, nos Ignace etc. et nous derrière une fois que l'application est supprimée on va aussi supprimer les ressources infrastructure on peut l'abandonner à Poserey Redis, SQS, les Kafka les topiques Kafka, les indices CSX Search et puis les namespace associés au projet donc ce script qui tourne il est 30 minutes et il est assez pratique pour supprimer de façon autonome on l'a aussi mis à disposition des développeurs pour qu'ils puissent le trigger à la demande pour dire je vais supprimer telle application parce qu'en fait j'ai envie de résoudre ma donnée pour partir à zéro ou j'ai envie de supprimer complètement mon projet pour partir à zéro voilà on a aussi ce qu'on appelle on en parle pas dans les slides mais des environnements permanents qui sont les environnements qui sont jamais supprimés et qui sont présents par exemple si on va faire des tests de charge si on va faire du monitoring un peu avancé on va réussiser ce même système-là c'est juste qu'Augustini Cleanup ne va pas s'activer automatiquement on va pas supprimer la vanche automatiquement ce sera manuel donc maintenant on a vu notre staging nos besoins en prod on n'a pas activé l'autosync à part certaines applications on est quasiment à Dupar et To donc on a 20% des nos microservice d'autosync pure on marche dans master c'est déployé tout de suite la plupart sont en déploiement manuel Argo va le détecter c'est au développeur en charge de la feature ou en charge du merge d'aller spécifiquement dans Argo faire le sync c'est juste une question de maturité c'est quelque chose qu'on vise parce que parfois ils veulent le mettre dans la branche master sans que ça soit déployé c'est prévu d'un point de vue communication marketing il peut y avoir plusieurs besoins comme ça mais l'avantage qu'on n'avait pas forcément avant avec 100 Argo mais maintenant c'est plus facile avec les dernières versions de Cube Cutter on peut avoir du différentiel mais l'interface d'Argo donne visuellement comme une review de code un du rouge-verre pour savoir qu'est-ce qui va changer c'est très simple c'est juste une image mais si ça avait été encore dans les ressources juste pas un host dans l'ingresse etc etc on le verrait visuellement donc c'est très j'avais dit convenient c'est pratique quand on est un développeur mais même nous de savoir exactement ce qui va changer quand on va appuyer sur sync ça c'est vraiment un confort et ça nous ça évite beaucoup de désagréments on a aussi tool tooling ça c'est pratique il y a des barges à gauche ça peut être celui de staging pour la branche master en staging et à droite en prod sur master donc on va être typiquement une application qui n'est pas tout à fait psychique ce sont les barges je ne viennes pas d'appliquer la même application j'ai dû les mettre juste pour que vous voyez les couleurs ça c'est pratique ça permet directement au développeur d'avoir l'état dans ce qu'on utilise dans son repo et en cliquant sur le barge il va directement dans l'interface d'Argo CD on a mis les bons liens même nous on clique et on est directement à la bonne référence et en dessous je vous montre juste un exemple de notification qu'on peut avoir avec Argo Notifier tout est paramétrable là c'est nous c'est le template qu'on a décidé mais on a l'application le commit etc donc l'application on clique on arrive dans Argo le commit on clique on arrive nous directement sur le commit exact dans GitLab donc on n'a même pas besoin de se poser la question on sait qui a fait quoi etc ça arrive un incident on sait tout de suite le déploiement qu'est le lieu on n'a pas besoin d'aller fouiller dans le flux des infos Slack et on sait qui a cliqué sur le site en prod donc on peut tout de suite lui dire est-ce que tu étais au courant etc c'est pas pour faire du finger pointing c'est mal c'est pas escreux c'est juste pour pouvoir tout de suite parler à la bonne personne et éviter de faire une requête qui va se répercuter en éco parmi on a un dernier tooling là c'est un truc qu'on n'avait pas forcément avant on a avec Argo ces logs de déploiement etc on est capable maintenant d'avoir des statistiques sur ce qu'on déploie en production beaucoup répartition quelle est l'application qu'on déploie le plus c'est ce qu'on voit des fréquences etc et avoir le nombre aussi donc là à l'heure actuelle on tourne à une centaine 120 déploiements par semaine donc sur les 5 jours ouvrés en heure ouvrée je pense beaucoup beaucoup plus que ce qu'on avait avant ce qui prouve bien que nos équipes techniques ont vraiment adopté l'outil et c'est devenu simple pour elle et sans sans problème on a très très peu de déploiement fail, ça peut arriver effectivement mais on a toujours les mécanismes de rollover qui font que ça en déploie un pod puis il faut qu'il soit rédi donc on a très très très peu d'incidents liés à au pur déploiement en plus on a quand même toute la staging future branch master et on a des contrôles sur master pour éviter de déployer n'importe quoi ça c'est plutôt pratique et ça nous permet de suivre l'évolution et on a bien vu la montée au fil du temps que l'on a plus en plus et je pense que ça va être encore plus qu'on crée des nouveaux services etc et quand on aura des conditions de déploiement ça serait encore plus simple l'astrante est tranquille et sur les parties argo cidi quand on a déployé argo cidi en staging et qu'on a migré la staging pour utiliser l'argo cidi future branch on a souhaité réguiser l'outil pour la production mais c'était compliqué d'arrêter le service en fait on avait comme prématique de migrer les services existants pour être managé par argo cidi c'était lm2 en plus et donc pour ça argo cidi pour qu'on puisse voir les ressources au sein d'un déploiement visuellement dans l'interface et pour qu'il puisse dire en fait cette ressource c'est à moi et celle-là c'est pas moi qui la gère il va se baser sur le label apculinitisio instance là normalement c'est le nom de la release elm associé dans notre cas et donc en fait on n'a plus patché l'ensemble de nos labels sur les ressources qui ont été managées historiquement par elm on les a vues monter apparaître sur l'interface et là on va pouvoir faire utiliser ce que Thomas a montré là tout à l'heure pour réopérer les différences entre ce qu'on a mis dans le nouveau repo et ce qu'on a réellement sur le cluster et en fonction de cette différence là on n'a plus itéré jusqu'à ce qu'il n'y a quasiment plus aucun diff pour dire ok maintenant c'est managé par argo cidi on amignait l'application et ça on l'a fait sur l'ensemble de nos microservice à peu près en 2 semaines petit à petit et ça s'est très très bien passé parce que faut savoir en fait que les ressources qu'on avait historiquement étaient malagées par elm et grâce à des scripts de helper autour maintenant on utilise vraiment elm pure sans helper et on utilise les propriétés des charts pour essayer de simplifier la config donc ça se fait aussi très très bien d'importer les ressources existantes maintenant en fait on a aussi des ressources statiques c'est à dire en fait tout ce qu'il n'y a pas ou le code en fait n'est pas chez nous à savoir par exemple on utilise trafic pour notre ingresse on utilise sur le torsoscaler on utilise pas promettus, opéraseur donc en fait sur GitLab on a créé un dossier qui s'appelle Kubernetes ressources et dans lequel on va avoir des projets Git et dans chacun des projets Git on va avoir des dossiers, d'environnement ou un déploiement d'elm chart donc on utilise des charts communautaires quand il y en a sinon on utilise nos propres charts en interne voire au sein du du repo si un jour on soit de sortir de elm pour avoir de faire du gsonnet ou autre on pourra toujours le faire et le principe c'est on fait l'amr on change en fait ses values et au merge en master en fait enfin chaque fois qu'il y a un merge GitLab va envoyer un appel Http à Ravocidi via le système de webbook qui va forcer Ravocidi à faire un fort fetch et on a mis une première mode of sync directement après si on ne fait pas ce webbook là de toute façon Ravocidi par défaut va faire ce fetch auto sync toutes les 3 minutes mais on a la possibilité de le faire directement pour éviter toute attente et il y a quelque chose aussi qui est pratique c'est qu'à Ravocidi grâce à ce fetch on va aussi afficher des métriques prom sur lesquels on va pouvoir faire de l'alertine donc si jamais il y a un repo elm qui est défraqué comme on a eu par exemple la game stable et les derniers mois le projet va passer en statut unknown puisqu'il pourra pas récupérer les sources et on va être alerté là dessus pour pouvoir corriger directement VS, notre système d'avant où en fait si le projet n'avait pas été ployé depuis 2 ans on ne le savait pas on va le redéployer on va se rencontrer en fait la source novice on va faire quelques remarques plutôt retour d'expérience il faut dire que nous on a migré parce qu'on avait vraiment le besoin comme a dit tout à l'heure c'était GIG c'est devenu très pénible pour les développeurs une demi heure pour attendre de tester son appui son code c'était pas faisable donc on est allé un peu vite en besoins on a bossé longs beaucoup mais on l'a fait sur un court temps on avait de zéro à plusieurs milliers d'applications à déployer dans Argo donc on a très vite tapé des limites la première ça a été les limites au niveau des performances on a commencé en version 1.7 et ça a beaucoup changé quand on est passé en 1.8 on a gagné 40% d'utilisation mémoire 30% d'utilisation CPU ça a été assez impressionnant les changements à chaque fois qui font des réalises majeures mais maintenant à l'heure actuelle en version 1.8 la version stable ça les a deux quelque chose la toute dernière on va migrer on se rend compte qu'au-dessus de 4.500 d'applications on commence à nous avoir quelques soucis de latence et au-dessus de 6.000 ça devient très difficile même si Argo passe on peut avoir 10, 15, 20 minutes avant que le sync soit vraiment effectif complet ou tout est synchronisé etc ça pose soucis surtout qu'il propose un sharding maintenant ce qui n'était pas le cas avant au niveau du contrôleur sauf que le sharding se fait par cluster ce n'est pas par application ce qui fait que si vous avez un cluster vous déployez 10 applications et un cluster vous en appoyez 10.000 vous n'aurez pas un Argo qui va faire un des réplicats du contrôleur qui va faire les 10.000 et un autre qui va faire les 10 applications ça c'est assez gélant ça peut marcher des hooks avec des jobs nous on a eu ce cas là où on peut avoir du sort de speedbrain parce qu'on a tenté le multi-controller et on a aussi on est arrivé on a été se rottler plusieurs fois par l'API cube on l'a saturé beaucoup c'était aussi lié à un mauvais pattern chez nous où on n'avait pas toujours des bons labels on avait un label avec un timestamp donc vu que le timestamp de ce label changait à chaque fois Argo considérait que ça devait être un nouveau déploiement donc il essayait de redéployer les apps sur la production ça posait pas de soucis parce qu'on est assez limité on a un environnement master avec nos 60 microservice qui font quelques centaines de pods avec les réplicats etc mais en Staging ou à cette époque là on tapait les 4000 applications on était à 8000 ou 9000 pods ça devenait assez problématique heureusement maintenant on n'a plus le souci parce qu'on a fait le fix sur ce label un problème que l'on a eu aussi c'est sur les métriques donc c'est super argo que la MediVictor c'est plus qu'on peut scraper qu'on peut se servir pour avoir le nombre de déploiements top sync etc ou en erreur sauf que jusqu'à que la contribution Victor on ne sait pas un César ce qui est assez là le contrôleur gardait toutes les métriques nous on supprimait le namespace donc la manche tout était là donc on cumulait on cumulait et le scrapping devenait très très très long en fait ça ne servait rien parce que les manches n'étaient plus là donc ils scrappaient des choses qui ne bougeraient plus qui ne bougeraient plus jamais donc il y a eu cette notion d'espiration de cash qui a été mis donc effectivement au bout d'un moment les métriques qui ne bougent plus sont expurgés sont nettoyés et donc on a plus ce problème là là beaucoup ça pas posait problème parce qu'on l'avait anticipé mais c'est quelque chose à savoir Argo s'assure il est très très rigide dans le sens où s'il en guide j'ai 3 réplicats je vais dans le cluster j'ai 3 réplicats si vous faites du HPA donc horizontal pas d'autoscaler le 3 réplicats il peut changer on peut passer à 6, à 7, puis redescendre à 3 etc heureusement c'est prévu encore une fois Argo a prévu le coup on peut lui dire tu ne sais pas grave tu peux considérer que si c'est pas bon sur certaines valeurs c'est quand même ok chématiquement c'est un peu ça on peut lui dire d'ignorer ces infos là un peu comme on pourrait faire avec certains cas dans terraform et donc ça permet de pas poser ce genre de soucis si vous avez du HPA ou du mutati ou des boucles on pense à Istio par exemple qui va peut rajouter des sidecars etc ça c'est pas prévu d'envite donc Argo peut dire non c'est pas bon vous pouvez tomber dans une boucle infinie etc vous le prévoyez et il n'y a pas de soucis façon Argo va vous le dire j'ai une différence il ne vous fera pas ça sauf si vous êtes en dosing l'auto sync c'est aussi on l'a pas dit mais faire du auto heal c'est jamais vous supprimez un déploiement il va se recréer etc c'est plutôt pratique je pense qu'on est plutôt pas mal sur le timing on est un peu dépassés on a quelques questions je les ai sonne si tu veux pour répondre plus rapidement on va éviter de faire le peut les répéter du coup je vais les répéter Jérôme demande pourquoi Argo est pas flux pourquoi Argo c'est parce que moi je l'ai ramené de mon expérience professionnelle précédente où je n'avais pas pu le mettre en place en production mais je l'avais pu le tester il nous semblait plus avancé que flux surtout d'un point de vue GUI ce qui était très pratique pour nous, pour les développeurs qui ne sont pas forcément tous très confidants très à l'aise avec cube et ces notions et il était plus avancé aussi au niveau de l'écosystème CNCF et on l'a vu en plus à cette époque là il y avait en plus la je fais beaucoup de répétition je pensais que flux et Argo devaient fusionner donc il devait faire une sorte de produit commun c'est un peu tombé aux oubliettes donc voilà pourquoi après c'est des commentaires encore Jérôme qui nous demande est-ce que le cleanup n'impacte pas à la B testing tu veux répondre Victor, c'est simple pour le coup sans plus oui parce qu'en fait tout ce qui est sur le testing c'est c'est connu les devs ils sont courants en fait des environnements qui vont être dilites et aussi on a des branches permanentes pour faire ce genre d'opération en production on n'a pas de B testing et il n'y a pas de cleanup c'est vraiment le cleanup est vraiment purement dans notre staging et pour le coup il n'y a pas cette notion d'AB testing parce qu'ils développent leur future branch ils testent les fonctionnalités de leur future branch mais on n'a pas nos clients qui tapent le staging un jour on arrivera peut-être effectivement sur la notion d'AB testing en production sur moi même même du canary, plein de choses très intéressantes on se posera la question de comment gérer mais techniquement Argo à la capacité de faire de la B testing ils ont un projet qui s'appelle Argo Rollout je crois que c'est comme ça qui gère ce genre de cas on peut faire des choses vraiment très avancées avec tout leur récosystème tout fonctionne ensemble dans la même logique et dernière question de Loic au niveau de Helm utilisez-vous beaucoup les dépendances librairies entre vos chartes les dépendances qu'on a c'est les dépendances avec nos chartes Helm custom interne donc effectivement à chaque fois qu'on a une instance d'une application on va utiliser en fait une dépendance de nos chartes interne et aussi quand on déploie leur source statique sur des projets open source j'utilise je ne sais pas, on va déployer un redis exporter on a la besoin de 3 instances on peut utiliser Helm pour avoir ces 3 blocs si on a besoin de faire vraiment beaucoup de configuration on a tendance à forquer la charte pour ne pas rendre générique volontairement c'est pour asserir cette complexité et avoir quelque chose de réagir beaucoup plus simple par exemple pour les développeurs plutôt qu'avoir quelque chose qui est quasiment paraphrase la config cube on va leur rendre et c'est d'abstraire cette complexité pour donner quelque chose d'assez simple à utiliser on va envoyer des logs sur Kibana on a juste un booleen à changer qui explicite vs, un label custom sur lequel on a tendance un peu à paraphraser donc pour nos ressources statiques nous c'est pas très grave parce qu'on connaît bien cube on a tendance à simplifier aussi pas mal pour que on soit rapide et qu'on n'est pas à chaque fois à réécrire donc on construit le standard et en fait une fois qu'on l'a c'est extrêmement simple de déployer une nouvelle app ça reste à la marge pour les applications du trahifique du redis exporter on essaie quand même d'utiliser ce que fait la communauté et quand on a des choses qui ne nous conviennent pas et qu'on sait qu'ils peuvent être utiles on l'a fait plusieurs fois il nous manque telle ou telle chose des charts qu'on peut pas rajouter des annotations comme on veut pour proposer nos changements parce qu'on préfère garder l'upstream en référence quand c'est pas quelque chose d'interne un microservice qui est vraiment chez nous on n'a pas de flux-value à maintenir une charte trahifique sachant que la continuous le fait aussi par contre si il y a un truc qu'on a un besoin qui n'existe pas et qui nous semble pertinent on contribue il n'y a pas aucun souci là-dessus il y a une question sur le chat sur la partie Q&A de Patrice Mayer, avez-vous utilisé un customizer en complément en placement de Elm ou est-ce que Elm répond à toutes vos attentes pour la gestion des configurations environnementes alors est-ce qu'on l'a étudié ? non, est-ce qu'on connaît l'outil ? enfin étudier, non on n'a pas poussé plus d'influences carra pourquoi Elm c'est parce que déjà Elm était chez nous bien avant que Victor est moindier c'était déjà déployé comme ça et comme je l'ai dit Argo est agnostique il géré Elm très bien donc on était capables de simplifier nos charts à part les migrés au niveau des repos et des applications mais on pouvait récupérer on a fait une migration sans douleur sans refonte des values etc et sans perturber nous et les développeurs pour un nouveau de façon de gérer le déploiement c'était ce qui nous paraissait plus simple mais effectivement il n'y a que customizer un état mais peut-être qu'un jour on passera là-dessus on fait directement du Yamel et ça marche très bien on n'est pas fermé mais c'est juste qu'on sait que customize peut être un peu plus ardue que Elm mais juste un fichier de values n'importe qui peut juste changer sa valeur customize ça demande un peu plus de logique mais c'est les goûts et les couleurs il n'y a pas de soucis alors je crois que c'est tout il n'y a pas d'autre question en tout cas merci beaucoup Thomas et Victor merci beaucoup pour la presse c'est génial présentation ça donne envie on va fournir les slides je pense oui sur le Slack le Slack il va rester ouvert si vous voulez poser des questions un peu plus tard à Victor ou à Thomas n'hésitez pas à rester sur le chat vous avez les contacts directement pour pouvoir poser d'autres questions même après l'événement ça sera toujours là et puis donc merci encore à vous donc là c'était la dernière session de la track 2 donc je vous remercie tous les deux mais aussi des speakers d'avant et tous ceux qui ont participé à cette track 2 qui je pense était la meilleure de toutes les tracks du coup on va retourner sur la track 1 parce que je crois que la pause gaming va bientôt commencer donc ça sera si je me souviens bien du pack pan avec du Kubernetes et tout donc ça sera nué par cibi ensuite toujours sur la track 1 donc il y aura un talk qui est préparé Nvidia comment eux ils font des opérateurs pour pouvoir utiliser les Nvidia et accélérer les performances de vos Kubernetes en fonction de vos besoins et on terminera ensuite toujours sur la track 1 par la table ronde être un développeur ou une développeuse open source épanouie donc je vais arrêter la diffusion merci encore à tout de suite sur le pack man