 Merci d'avoir joigné ma première session après le keynote. J'espère que vous aurez apprécié le keynote et pour moi, c'est mon premier Capcom comme attendeur et bien sûr, mon premier Capcom comme speaker. Il y a quelques mots sur moi. Je m'appelle Benoît Mousseau. Je suis français et je vivais en Paris. J'ai commencé ma carrière en C, C++ et Java. Et ensuite, j'ai bougé un architecte et consultant en faisant des performances autour de l'observer dans G2E. Les dernières 10 décennies, j'ai mis elles dans le monde de DevOps et en détail dans la intégration continue, et dans la delivery continue, un système sub-système dans une compagnie qui s'appelle Xibia Labs. Dans cette compagnie, nous avons ajouté une solution qui aide la compagnie à performer d'automation et de réautomation. Pour 1 an maintenant, j'ai joigné la vmware, le team Tonsu, un ingénieur de solution senior pour aider notre client à déployer, à donner des updates et à éliminer l'application en utilisant le container et le cloud. Et nous avons promosé une solution sur le site de l'infrastructure qui vient de la vmware avec une solution appelée Tonsu Kubernetes for Operators et aussi sur le site de l'application, Tonsu application platform pour tourner vos containers dans un service de plateforme. Avant de passer à la session, j'ai juste envie de me raconter avec la réalité si le développeur ne pousse pas le code sur le Git repo, il n'est pas utile parce que, à la fin, le target est la production et rien d'autre est OK avec la production pour l'application. L'autre c'est juste de faire IT pour IT. Donc, la personne. On a 4 personnes qui sont dans la présentation. Les deux premières sont très connaissances les dev et les ops. Donc, le dev évoque l'application et commette un code avec une nouvelle idée pour manager le business. Et les ops réunissent l'application sur les différents environnements. Et entre nous, maintenant, pour quelques années, on a deux plus de personnes. La première est les apps-ops bien connaissances comme dev-ops mais je préfère les app-ops parce que c'est plus sur le dev-size pour aider les dev-teens à intégrer et à déployer l'application et à manager le framework et ce qu'on appelle le « software factory ». Et sur l'autre côté, nous avons le SRE venant de la Google World, l'engineur de site reliability qui aide les ops-teens à manager le cours de l'application. Donc, en fait, nous avons 4 personnes maintenant dans la histoire. Et la histoire est la suivante. Nous voulons déployer l'application en production. Donc, dans la dernière ou même dans la petite compagnie, vous avez l'application bleue, vous avez l'application bleue et parfois vous avez l'application rouge qui se tourne en Gauland pendant que vous avez l'application bleue en Java. Et le target est vraiment l'environnement de production. Mais avant d'arriver dans l'environnement de production, vous devez promouvoir l'application dans plusieurs environnements pour faire des tests. Et puis, vous devez promouvoir l'application entre l'environnement et l'autre. Et avant d'arriver, nous devons intégrer. La phase d'intégration est en fait un processus qui va permettre votre code, en fait, un comité, ou une branche, ou un tag, à un set de items ou des items versionnels. Et maintenant, le container world est l'image de container. Et cet artifact va être touché peut-être dans un système de file mais il peut être maintenant dans des repositions d'artifactoire ou d'image registre. Mais sur l'autre côté de la binary, nous avons aussi la configuration. Il peut être seulement une application Java ou une configuration. Mais maintenant, nous avons plein d'autres langues pour contribuer votre application. Parce que maintenant, vous managez pas seulement l'application, mais aussi l'infrastructure. Ce n'est pas nouveau. Tout ce processus a été déclaré dans deux fameux livres, continue d'intégration et continue de delivery. Et si l'intégration continue est maintenant une phase bien-known dans les entreprises et dans les phases légales, le développement continue et le delivery continue est encore une issue. Et l'application cloud native a offert une solution d'offrir de nouvelles issues. Donc maintenant, si on veut regarder le processus CICD, donc le processus CICD pour le processus global vient d'aller de source à production. Et votre processus est naturellement expliqué dans deux petits projets. C'est l'exemple, de regarder mon report, de construire une image, de faire des tests, de générer des configurations et de déployer ma image. Et dans la tête de tout le monde, le processus est comme ça. Un task, un autre task et l'autre. Mais en fait, en milieu, on a ce qu'on appelle un tool orchestration et un orchestrateur. Et en fait, la relation entre le task n'est pas directement entre le task, mais c'est quelque chose d'autre. C'est pour l'end, et pour l'end, un autre, peut-être faire des opérations entre les deux. Donc, bien sûr, c'est ce qu'on appelle un design naturel. Un système d'opérations est basé sur ce processus pour diviser un task en deux petits tasks. Mais on a aussi l'habilité dans ce processus, pour avoir un point unique pour monitor, pour regarder et pour contrôler. Parce que tout est centralisé. Mais le drawback est l'impact de la modification. À chaque fois, vous devez modifier le processus par ajouter un nouveau type de tasks. Par exemple, vous devez avoir quelque chose sur le task d'orchestrateur mais pas sur le processus. En même temps, à la fin, nous avons un task très courant. Cela signifie que c'est très compliqué de créer un task. Vous pouvez réutiliser ou substituer d'autres processus. Il est difficile de quitter un task pour un autre. Ou, comme tout est centralisé, cela devient un point single de défaut. Bien sûr, par le point de vue de runtime, en termes de ressources, storage et network. Mais aussi, par le point organisatif, parce que seulement quelques personnes dans le team, typiquement le secteur de software ou le team de ops, il est difficile de avoir un autre team qui peut le manager. Et, à la fin, c'est rigide. Cela signifie que le processus a été créé de gauche à droite, au début de l'endroit. C'est souvent compliqué de créer un task en parallèle, qui traite le processus dans le milieu. Par exemple, si vous voulez rébuilder quelque chose, parfois vous devez traiter un commit artificiel dans votre repos pour traiter le processus. Donc, c'est pour un processus. Et, à ce point, nous avons plus ou moins le même problème. Bien sûr, nous pouvons avoir un team utilisant Golang, un autre en Python et l'autre en Java. Et, le processus est seulement créé, souvent, durant Spring Zero, avec un building block offert par le secteur de software, sans d'autres updates. C'est compliqué d'avoir quelque chose que vous pouvez réutiliser entre différents projets. Et, souvent, dans une grande organisation, je sais que ce processus est seulement managé par le dev team et c'est compliqué d'avoir quelqu'un de l'extérieur de la team que je peux ajouter des idées pour augmenter le processus. Mais ce n'est pas nouveau, parce que tous les projets, tous les outils qui font la CICD, d'abord, par exemple, pour l'action de Github ou Tecton, sont basés sur ce concept. Ce n'est pas nouveau, mais peut-être que nous pouvons augmenter. Ce processus est appelé le pattern d'orchestration parce que, en fait, nous pouvons mémiquer un orchestra où tous les musicians savent comment jouer de la musique, mais il faut attendre l'ordre pour les chefs pour commencer à jouer de la musique et pour arrêter de jouer de la musique. Donc, il fonctionne. Peut-être que vous pouvez faire quelque chose d'autre. Ce n'est pas la chorégraphie. Donc, dans la team de danse, dans la team de chorégraphie quand la musique commence à jouer, tout le danseur sait comment faire. Et peut-être qu'un danseur peut falloir et le processus global peut être autonome. Il peut continuer à jouer sans quelqu'un qui peut dire qu'il faut commencer ou pas. C'est la principale différence entre l'orchestration et la chorégraphie. Donc, si nous essayons d'appliquer ce pattern, nous aurons des ressources et cette ressource va avoir input X et peut-être produire output X. Et vous pouvez aussi avoir input Y avec output Y. Mais aussi, vous pouvez avoir une ressource qui traite de nouveaux événements basé sur le temps, basé sur l'événement peut-être chaque heure ou chaque jour. Donc, c'est pour une seule ressource. Peut-être que nous pouvons avoir quelqu'un qui peut aider une autre ressource à regarder l'output de la ressource A et peut-être créer et injecter l'output de la ressource A à l'output de la ressource B. Donc, pour exemple, vous devez avoir l'output X à l'output de W. Et vous devez avoir des compagnons qui poursuivent toutes les deux. Cette vision peut aussi être comme un bord électronique. C'est typiquement le pattern où nous faisons des électroniques où vous plugz l'output et vous devez avoir quelque chose de très clé. Mais dans le processus CICD ce processus, cette option, cette nouvelle solution c'est le projet de cartographe. Donc, le projet de cartographe c'est déjà un projet CNTF donc tout le monde connait ce landscape et nous focusserons seulement sur le sub-système qui est un projet très fameux qui s'appelle ArgoCD et FluctCD. Et si vous étiez là, comme le code Github, nous parlons beaucoup de ces deux projets. Mais maintenant, nous avons un nouveau projet qui s'appelle le cartographe et qui s'est déjà investi dans le CNTF. Mais c'est un projet très jeune parce que c'est seulement huit mois mais très actif et réveillé par VMware. Donc, maintenant, on va essayer de vous expliquer comment nous pouvons mimiquer ce projet. Donc, nous avons notre orchestration je veux remettre ce projet et je veux juste maintenir le projet comme ça. Et en fait, la première chose que je veux faire c'est d'encapsuler tout le projet pour seulement focusser sur l'input et l'output. C'est à dire, en fait, je n'ai pas plus de bleu ou d'orange et d'orange-tasque j'ai seulement focussé sur l'input et l'output. Et ce que je veux faire maintenant, c'est d'encapsuler tout l'input et l'output. Ce qui veut dire que en fait, nous allons avoir un processus qui va de gauche à droite et nous allons avoir un processus qui va de droite à gauche. En fait, nous réagirons de l'output de la autre chose. Donc, en fait, la image de l'image réacte sur l'output de l'output. Le test réacte seulement si j'ai une nouvelle image. Ce processus sera un concept et c'est ce qu'on appelle un blueprint dans le contrôle caractéristique. Ce contrôleur peut être déployé sur des clusters confirmant de Kubernetes. Cela signifie que vous n'avez pas besoin d'un cluster Tantu. Vous pouvez utiliser vos AKS, EKS ou quelque distribution. Ce processus, ce blueprint n'est pas faible par le SRE et les appOps. En fait, ils ont la knowledge d'intégrer l'application ou de déployer l'application. Sur l'autre côté, nous avons un dev qui va en fait créer et demander pour un nouveau workload. Donc, le dev va spécifier que je veux un workload pour intégrer mon service Java. Donc, je veux intégrer mon Golan AI service database. Et basé sur la spécification, le contrôle caractéristique va s'intégrer la phase d'intégration. Sur l'autre côté, les apparts vont déployer et en utilisant le même processus, le contrôleur catégraphe va trouver ce que le blueprint sera intégrer. Et en fait, il est très important d'avoir cette séparation. En fait, vous êtes quelqu'un qui veut l'intégrer et d'autres personnes qui veulent le déployer. Donc, pour le dev, je dois intégrer mon code. Et comme des apps, j'ai offert des gens de dev, des services de service sur l'autre côté. Comme des apps, je veux déployer l'application. Et comme une série, j'offre aux gens un moyen de déployer l'application à travers différents clusters. Et vous avez un moyen d'aider la complexité et d'avoir une séparation entre les consommateurs et les producteurs. Nous sommes à CubeComp, donc c'est temps d'avoir des YAML. Donc, nous avons ici la description du workload. Et le workload est la description pour faire une phase d'intégration. Donc, vous avez la ressource. Donc, le catégraphe brings un nouveau set de CRD. Et la première est le workload où l'utilisateur va spécifier le workload. Donc, vous pouvez voir qu'il ne spécifie pas exactement un nom, mais il y a des labels. Et basé sur ces labels, sur les propriétés, le controller des titres de contrôle va instancier le bloc droit. Il peut aussi vous donner des paramètres sur le GIT repo et des paramètres pour configurer les services. Par exemple, si j'ai besoin d'un DB ou pas, pour être inclus dans mon service. Donc, si j'ai un nouveau workload, je suis dans cette situation. Donc, je supplie mon nouveau workload et basé sur la spécification dans mon workload et basé sur la permission, le catégraphe va instancier le bloc. Et par cela, il va créer de nouvelles ressources basées sur le template qui est descrivé dans le bloc. Donc, en fait, vous avez quelque chose comme ça. Je veux dire, associé à mon workload, je vais avoir un set de ressources liées au lifecycle de la workload. Donc, les ressources ne sont pas liées au contrôle du catégraphe. Elles ne sont pas liées au bloc, mais vraiment liées au workload. Si j'ai changé mon workload, la ressource peut être changée. Si j'ai délégué mon workload, tous les ressources seraient liées. Donc, nous avons une relation comme ça. Donc, en fin de compte, c'est un déploiement. En fait, la combination de 3 repositories managées par 4 personnes. Nous pouvons avoir le dev managing l'application configuration. Nous avons le up-stream ou up-personnel managing l'application configuration. Et nous avons d'autres ressources dans une repositorie managées par devops, appops et software factory et SRE. Si je explique ce repos dans le processus CICD, nous allons avoir des personnes dév qui commettent des codes. Et dans le processus CICD, nous créons un nouveau item dans l'application configuration et un nouveau item dans la registre image. Donc, le up-stream va vouloir rouler l'application, peut-être décrire l'environnement et tout ce repositorie sera mixé ensemble pour créer de nouvelles deliveries qui poursuivront tout cette information afin de déployer l'application. C'est ce qu'on appelle le github pool mode. Donc, ce pool mode est vraiment ce qu'on appelle le niveau 3 ou 4. Je ne me souviens pas exactement. C'est un niveau très haut de sécurité, de constante, d'assurer que vous puissiez repliquer votre cluster à l'aide d'un test ou d'une réplication de bug. Donc, maintenant si nous zoomons le processus CICD, nous allons avoir, en fait, je veux bouger de l'application, le repos et la registre image. Et ma subvention sera une combinaison de 4 ressources. La première est de flux CD parce que dans le projet c'est le mode pour réutiliser un set d'existences de components C&CF. Donc, le flux CD va regarder le repos. Dès que j'ai un nouveau comité, il va créer une image K-Pack afin de construire une image. C'est ce projet qui est base sur le plan natif BuildPack qui aide aux utilisateurs à construire une image Docker. Et cette image sera la poste Docker pour mes images de G3. Et j'ai un nouveau comité pour mes configurations d'application en utilisant Tecton. Donc, en détail, c'est ce qui s'est passé. J'ai mon repos G3 avec tous mes paramètres. Donc, c'est un ressort standard avec la spécification et les statuts. Dès que j'ai un nouveau comité, mes statuts ont changé avec un nouveau repos. J'ai un nouveau comité en regardant mon repos. C'est typiquement pas un sport parce qu'il t'essaie seulement à promouvoir la valeur et l'autre. Toutes les ressources travaillent tout à l'heure. Donc, comme nous avons en action, j'ai ma spécifique de mon workload et quand j'applique mon delivery, ma chaine supply cluster, vous pouvez voir, basé sur le workload build, un set de ressources elles-mêmes peuvent générer d'autres ressources. Donc, une image génère un nouveau port et j'ai un renouvel d'un Tecton task run pour créer mon nouveau comité. Donc, vous pouvez voir, toutes les ressources sont liées à mon workload. Donc, quelle information je veux commettre. Donc, cette information est managée par l'autre côté et nous pouvons imaginer avoir une sorte de structure. Donc, ça pourrait être un système de file ou un GPO avec l'application folder et entre cette application folder il y a deux applications called loader and micropads. Et sous micropads, vous avez une version et j'ai utilisé le timestamp pour créer une version. Je peux aussi avoir une version chaleur. Donc, en fait, quand j'ai commis quelque chose dans ZIA, comme l'outil de ma phase intégration, je veux seulement commiser ces valeurs. Et ce que nous avons dans ces valeurs, nous n'avons pas des ressources de Kubernetes. Mais nous avons seulement les choses et nous avons le nom de l'application, le nom de la service et des paramètres. Bien sûr, en bas, nous avons le lien entre mon RMS registre. En l'autre côté, nous avons l'obsteam qui peut décrire et manager tout l'environnement. Donc, ça pourrait être un environnement non-environnement, un environnement UAT. Et nous pouvons avoir la suivante structure où je peux avoir une split here dans mon sample environnement par hyper-scaleur. Donc, j'ai un environnement en AWS, et en bas, le nom de l'environnement. En utilisant le même principe, j'ai l'environnement value file. Et dans cet environnement value file, j'ai la spécification et la valeur manager par l'obsteam. Typiquement, je peux mettre le nom de l'environnement. Je peux spécifier ce genre de ingress que je veux utiliser, c'est-à-dire contour ou estio, par exemple, et ce qui sera l'expos public dns et l'internel dns. Donc, typiquement, c'est managé par les gens de l'obsteam, et vous avez un set d'environnement. Et entre nous, nous devons avoir des règles. Et ces règles peuvent être déclarées comme ça. Donc, c'est un set de un set de niveau. Nous pouvons regarder le niveau de service. Donc, nous basons l'information donnée par les apps et les devs et l'obsteam. Nous allons générer le standard Kubernetes source, c'est-à-dire Kubernetes deployment, ConfigMap, CreadService ingress, etc. Mais peut-être j'ai voulu essayer de déployer ma application avec Knetive et j'ai eu un ordre qui pourrait être KService. Donc, plutôt que de générer ressources Kubernetes, mais de générer seulement Knetive service. J'ai aussi imaginé un service non-service qui n'a pas de valeur réplique si j'ai seulement une simple chose qu'on veut déployer et qu'on doit déployer la valeur. Donc, en ce cas, bien sûr, la génération de la ressource sera directement Kubernetes ressources. Donc, nous sommes quelque chose comme ça où le SRE et les apps-ops vont avoir un moyen de générer, en utilisant dans mon exemple, un langage qui s'appelle YTT. Ce YTT est venu d'un projet aussi basé par VMware qui s'appelle Carvel. Carvel offre en fait un set d'outils avec une philosophie avec un outil, un outil qui n'est pas un outil qui fait tout les choses. Bien sûr, à la fin, il s'agit d'établir, de générer et de déployer mais essayez d'avoir un outil spécifique pour que l'image crée une référence unique. Donc, Carvel est un projet très intéressant et dans cet outil, nous avons deux outils intéressants qu'il s'appelle YTT. Donc, YTT s'appelle YAML Template Tool donc, seulement procéde YAML. Donc, ne seulement provider un moyen pour répliquer l'evaluation mais aussi pour créer un overlay et si vous êtes un peu de dev, des gars en utilisant des codes pétaniches vous pouvez aussi générer des codes et envoyer des codes pour vous aider à générer des codes. Et c'est très intéressant car vous pouvez l'utiliser d'autres Kubernetes, mais aussi pour CloudFormation, pour Azure Cloud, quelque chose, je ne vous remercie pas le nom. Donc, si vous avez YAML vous pouvez l'utiliser même avec Elm, vous pouvez utiliser l'outil d'Elm pour s'assurer que l'evaluation n'est pas managée par Elm. Ensuite, nous avons aussi un moyen de déployer l'application avec un autre CLI Toul, vous pouvez le downloader et l'utiliser maintenant, appelé CAP, CAP. CAP as il peut répliquer le Kubernetes pour le déployement. Il fait deux choses, la première c'est de gasser un set de ressources sous le nom il peut être l'application, le nom de service, le nom de component. Donc, il va stamper tous les ressources que vous déploiez avec le nom et il va contrôler tous ces ressources avec le même lifecycle donc il va éviter d'avoir quelqu'un qui peut patcher votre ressource avec un autre déployement et pour être sûr, tout est sous le contrôle. Les autres ressources, c'est un tool synchronisé c'est-à-dire que vous savez que si vous êtes ici, quand vous faites Qtl appuyer en fait, c'est juste d'appuyer et de recruter le cluster Kubernetes pour appuyer cette configuration avec CAP, pas seulement CAP, appuyer cette configuration, mais aussi vérifier si tout est en train localement, c'est-à-dire vérifier si mon port a commencé si mon ingress est correctement créé et donc on a un checklist et à la fin, vous avez un state clair si c'est déployé ou pas c'est très intéressant donc vous pouvez l'utiliser dans votre cluster Kubernetes mais dans votre sample, nous allons utiliser le site server de cet objectif avec un composant appelé CAPcontroller qui sera en fait un mix entre YCT et CAP server en fait, vous avez un ressource comme ceci, où vous pouvez spécifier la façon de déployer si vous voulez faire ça synchronement pour augmenter ou partager les ressources, et à la fin le state de votre ressource reflète votre déployement et pour la phase de déployement nous allons utiliser aussi un autre ressource appelé Smoke Test ce n'est pas parce que vous avez tout votre ressource que vous avez appuyé et déployé à la level Kubernetes tout ensemble c'est ok tout le monde a déjà 2 troubleshoots pour connecter votre ingress pour votre service, pour votre port pour votre config map, pour votre volume donc à la fin c'est pas parce que tous vos composants sont déployés, tout est ok donc j'ai un projet de site personnel appelé Smoke Test Operator qui donne une façon pour protéger les tests de smoke pour valider si je peux protéger quelque chose depuis le début et la fin de votre call délicaté de API call ou la main web page sur ma web app afin de vérifier tout est correct donc maintenant si on veut créer une chorégraphie de tout ça en fait nous allons avoir un déliver qui va spécifier plusieurs repositions de githre qui vont regarder les règles de déployement la configuration de l'application et la configuration de l'environnement pour que ce soit modifié l'output de l'application de githre sera mobilisé et sera injecté dans le cap contrôleur c'est-à-dire que vous êtes vraiment l'output d'un githre injecté dans le cap contrôleur la ressource de cap contrôleur va attendre pour le déployement et si c'est ok on modifie le test de smoke afin de protéger la validation tout est sous contrôle c'est la même pattern qu'on a avec le workload c'est la même avec le déliver donc on donne un nom label, je veux avoir mon déliver en utilisant le smoke test c'est une réquestion on peut imaginer de déliver un projet sans smoke test parce qu'il n'est pas implanté et d'autres avec smoke test parce qu'il est designé dans la série on donne les paramètres et les paramètres ont seulement deux c'est la version de ma application et la version, bien sûr, et l'environnement donc pour les gens de HOP c'est seulement pour déployer une version de ma application sur mon environnement et bien sûr, je peux donner un lien à mes règles de déploiement peut-être que je veux tester des règles de déploiement pour PROD ce n'est pas exactement la même pour pre-prod parce que je fais des tests et peut-être que je migrate pour QNITS124 à 125 dans les prochains mois c'est comme ça donc en utilisant la même pattern on ajoute pour le workload on crée une nouvelle ressource et le contrôle catégraphe génére et instantiate la ressource associée et vous pouvez voir là-bas pour mes déliverables doigts je vais avoir des apdoigts 3G, 3po et un smoke test et le smoke test trigger un travail et vous pouvez voir que tout est sous contrôle et en utilisant les mêmes cycles de vie que les déliverables ce n'est rien de managé directement par le catégraphe donc si nous voulons rappeler cette présentation c'est vraiment un nouveau moyen de faire un CICD et ce que j'ai préféré c'est de faire un CICD peut-être ce n'est pas vraiment nouveau mais c'est le meilleur pour avoir quelque chose de nouveau pour améliorer notre processus et c'est toujours bon d'avoir un projet de site et d'autres projets pour essayer de avoir un nouveau moyen de notre déliverable aussi il offre vraiment une complexité parce que vous avez vraiment une séparation entre l'Obs team ce que nous et le dev team et l'app Ops et le SRE avec de la même manière pour l'instantiate, c'est très important si vous faites déployer, go, intégrer .net core ou Java le contract est toujours pour créer un nouveau workload ou créer un nouveau déliverable et basé sur la spécification basé sur ces ressources un nouveau blueprint va être installé ou upgradé selon le besoin peut-être vous pouvez avoir un update par le SRE en cas de déployement nous voulons ajouter par le team sans demander l'Obs team de redeployer quelque chose ou de modifier une modification sur leur site si vous êtes un peu curieux nous avons le cartographe.sh sur le gauche et vous êtes vraiment très curieux, vous avez le source code written on go, bien sûr ici vous avez la liste de toutes les ressources que j'ai utilisées durant cette présentation je n'ai pas eu l'opportunité de le faire mais nous pouvons avoir une discussion et ça fonctionne en bas et en bas et si vous n'avez pas de distribution maintenant vous pouvez utiliser le vmware community edition dans lequel vmware a donné un set de components incluant le cartographe et aussi la distribution de Kubernetes et avec le nouveau annoncement de Dockercon vous pouvez créer dans un clic un nouveau cluster avec le set de packages sur le gauche tous les components pour ne pas seulement déployer le cartographe mais aussi pour déployer tous les packages nécessaires Kpack, Carvel tools et Tecton donc c'est prêt à être déployé et à être utilisé si vous ne voulez pas utiliser le vmware community edition vous pouvez appliquer le même package sur votre AKS ou votre propre cluster merci si vous avez des questions, s'il vous plaît vous avez un microphone dans le milieu d'autre part je serai à l'extérieur il y a un de l'online qu'est-ce qui est différent entre Carvel et Elm en fait, nous sommes plus ou moins au même niveau en fait, nous pouvons les voir comme compétiteurs, vous pouvez utiliser par exemple, YTT avec Elm, typiquement vous avez une charte M et vous voulez modifier un paramétre vous ne pouvez pas modifier avec Elm en valeur vous pouvez utiliser Elm Generate Pipe avec YTT Pipe avec Kubecutter et si vous n'aimez pas Elm vous pouvez remplacer le tout de la chaine Kapp