Bruno:
Docker, c'est un peu comme la magie noire du dev moderne. Tout le monde en parle, tout le monde croit savoir ce que c'est, mais rares sont ceux qui savent vraiment ce qui se passe sous le capot. On connaît tous la théorie, le principe fondateur, on lance notre Docker Compose et la magie opère. Ils se murmurent dans les milieux autorisés que les Ops, eux, savent vraiment comment ça fonctionne. Et alors qu'on pensait qu'on pouvait se reposer les pieds dans le sable sur le confort apporté par Docker, Voilà que maintenant, il nous annonce Docker Sandbox. Mais alors, pourquoi certains l'utilisent sans même s'en rendre compte ? Est-ce qu'on pourrait tous dockeriser notre vie ? Et surtout, est-ce que Docker, ça simplifie ou ça complique l'existence ? Pour répondre à ces questions contenues, je ne reçois pas Jack Sparrow, mais il s'y connaît en carte au trésor. Guillaume, bonjour.
Guillaume:
Bonjour.
Bruno:
Alors Guillaume, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Guillaume:
Oui, bien sûr. Donc, je m'appelle Guillaume Lours. Je suis Software Engineer chez Docker et je travaille principalement sur Docker Compose. C'est mon travail au quotidien. J'ai travaillé également sur Docker Soundboxes dont on pourra parler aussi un peu, parce que c'est les nouveautés qui arrivent, mais voilà, au quotidien. Mainteneur d'un projet avec quelques millions d'utilisateurs.
Bruno:
D'ailleurs, ça serait assez sympa de bosser sur un projet qui a ce type de volumétrie ou est-ce que c'est un stress encore plus important ?
Guillaume:
Non, en vrai on a une communauté qui est tellement adorable, qui adore le produit et donc on reçoit beaucoup de... J'allais dire de l'amour. Ouais, clairement, c'est toujours bienveillant en fait. C'est rare qu'on ait des gens qui ouvrent des issues en mode extrêmement énervé, voilà, et tout ça et d'une manière générale on a un accueil qui est vraiment, sympa de la part de la communauté donc en plus d'être gratifiant à titre personnel, on le fait pour une communauté qui aime ce qu'on fait et qui soutient, donc ça c'est cool.
Bruno:
Moi je viens d'une... Moi j'ai commencé à Dev au siècle dernier donc bien évidemment Docker n'existait pas à l'époque donc je fais partie des gens qui ont connu l'avant Docker et qui voient en fait tout ce que Docker a apporté. Mais du coup, parce que Docker, ça fait un petit moment maintenant que c'est en place, que c'est bien installé, que c'est considéré comme une référence. Est-ce que tu as l'impression que les plus jeunes générations le considèrent justement comme acquis ? Et tu parles de cette communauté qui est bienveillante. Est-ce que vous n'avez pas petit à petit des gens qui sont moins bienveillants parce que justement, ils n'ont pas connu le sang Docker ?
Guillaume:
Je ne sais pas. Je ne le ressens pas au quotidien, clairement. Ce que je sais, c'est que ça fait partie de beaucoup de cursus maintenant, pour les ingénieurs dans les écoles d'ingé ou dans les facs. Donc, beaucoup de gens le découvrent là où, moi comme toi, ça n'existait pas. Donc, on l'a découvert sur le tas. Je veux un peu rebalancer parce que les gens ont l'impression que tout le monde utilise Docker. Mais je suis sûr que dans tes auditeurs, il y en a plein qui vont dire « Non, on ne va jamais l'utiliser, je ne connais pas. » Et en fait, on ne va pas, En effet, du côté Ops et tous ceux qui font du cloud, c'est quelque chose qui est juste naturel parce que c'est l'une des briques essentielles pour déployer des applications, des services et même des parties de l'infrastructure elle-même. Mais il y a beaucoup de gens qui ne connaissent absolument pas. Quand j'ai signé chez Docker, j'étais trop content de l'annoncer à mes potes qui avaient fait la fac avec moi. Et sur les trois que j'avais autour de moi j'en ai un qui m'a dit ah je connais c'est le truc qui m'emmerde quand je déploie ma base de données, et les autres m'ont dit je m'ai entendu parler voilà donc, il reste encore plein de gens qui ne connaissent pas et qui ne savent pas comment est-ce qu'on peut simplifier ou complexifier leur vie alors du coup pour les 60% de gens qui peut-être ne.
Bruno:
Connaissent pas effectivement Docker tu peux nous faire un petit résumé rapide de la techno, de ce que ça change.
Guillaume:
Ouais alors donc l'idée c'est de faire tourner dans un processus isolé, un service ou une application, donc en gros, ça veut dire que je vais prendre l'exemple qui marche le mieux parce que, enfin je sais pas si tu te rappelles mais à notre époque si on voulait tester une migration vers une nouvelle version de base de données il fallait réussir à avoir deux version de la base qui tourne en concurrence sur la machine. L'enfer.
Bruno:
Voir même dans le pire des cas, il fallait prendre une autre machine pour se connecter.
Guillaume:
Exactement. Là en fait, on va juste dire je vais démarrer un conteneur qui a la version A et un conteneur qui a la version B et puis je fais basculer mon application d'utiliser le conteneur A vers le conteneur B et je vois comment ça se passe. Donc en gros, on va pouvoir démarrer, en effet, des applications de manière isolée du reste des hôtes, ce qui va permettre de faire tourner plusieurs versions de la même application, de faire des applications, ce qu'on appelle multi-containers, où on va pouvoir avoir, par exemple, un back-end qui tourne dans un conteneur, qui connecte à une base de données, qui tourne dans un autre, un front-end à côté, tout ça dans le même network, donc pas visible forcément des hôtes, avec que la partie front qui est accessible, par exemple, de l'extérieur, et tout ça. Donc, ça va faciliter d'une manière générale l'utilisation d'applications déjà existantes. Tu vas les installer plus facilement sur ta machine. Moi, ça fait des années que j'ai pu installer une base de données. J'ai des collègues qui ne veulent absolument pas avoir NPM qui touche leur host. Donc, ils vont démarrer un conteneur dès qu'ils ont besoin de développer avec Node.js et NPM. Il y a tout plein de cas d'usage possibles mais principalement c'est faire tourner de manière isolée une application.
Bruno:
Ce qui a permis aussi de faire disparaître le ça marche sur ma machine donc démarrer toi avec ça.
Guillaume:
En partie on.
Bruno:
Va dire c'est une des promesses en tout cas il y a toujours.
Guillaume:
Plein de petits cas à la marge qui font que en fait.
Bruno:
Ça marche que.
Guillaume:
Sur ma machine encore.
Bruno:
On est je pense assez d'accord en tout cas moi de ce que je perçois c'est quand même un outil qui apporte, beaucoup de confort auprès des équipes de dev mais aussi aux côtés des équipes Ops, est-ce que pour toi c'est un outil que tout le monde devrait utiliser où ça reste tu nous évoquais les SaaS, est-ce que pour toi c'est réservé.
Guillaume:
Alors c'est pas réservé qu'au SaaS, clairement pas après il y a plusieurs choses, il y a des domaines où ça va être euh, un peu compliqué de l'embarquer. L'embarquer, clairement, ils ont besoin généralement d'avoir des applications natives hyper optimisées pour les, processeurs qui sont sur la machine avec les limites d'un RAM qu'ils peuvent avoir et tout ça. On vient ajouter une couche d'abstraction qui ne va pas aller dans ces cas-là. Par exemple, ça c'est typiquement un cas où la question peut se poser. Je ne dis pas que ça ne peut pas se faire, mais ça va vraiment dépendre du type d'embarqué que tu fais. Tu fais ton home lab avec des Raspberry Pi, tu peux y aller, il n'y a zéro problème, ça va tenir. Si tu fais vraiment des outils haute performance pour de l'industrie, Il réfléchira deux fois avant de prendre ça. Et après, il y a aussi des écosystèmes qui l'utilisent sans l'utiliser. Je vais m'expliquer. Moi, je viens de l'écosystème Java. Quand j'ai découvert Docker, on démarrait la base de données dans un conteneur. Éventuellement, le front-end, si on ne travaillait pas sur front-end. Puis, je travaillais sur mon back-end et lui il était démarré depuis mon IDE qu'il savait bien faire et il se connectait aux autres trucs donc parce que, non ça n'a rien à faire là dedans et mon application je la déployais après en tant que WAR sur un serveur d'application c'était jamais conteneurisé en fait, en fait je l'utilisais le concept et puis la commodité que m'offrait, la conteneurisation pour pour faciliter mon travail de dev au quotidien, mais ce n'était absolument pas utilisé derrière, même dans mon cycle de mise en production. Clairement. Donc, il y a encore des écosystèmes où, non, le conteneur n'a pas forcément besoin, on ne le fait pas. Après, c'est vrai que dès que ça part dans le cloud, on ne le fait pas. Voilà, soit c'est hébergé sur du cube, soit c'est des CAS, des conteneurs as a service. Certaines solutions de lambda s'appuient aussi sur les conteneurs pour démarrer super rapidement. Donc, ouais, là, par contre, la question, elle se pose quasiment pas. mais.
Bruno:
Du coup les contextes où tu expliques il y a des gens qui l'utilisent sans savoir qu'ils l'utilisent c'est à dire qu'en fait c'est les mêmes concepts qui s'appliquent mais sans être forcément la notion stricto sensu de la containerisation et encore moins en étant Docker je pense pas qu'il y ait des gens qui utilisent Docker sans savoir qu'ils utilisent Docker.
Guillaume:
Alors si on a des cas on a des cas de clients qui, ont des équipes dédiées d'architectes qui vont mettre en place à toute la conteneurisation des projets de développement par exemple et qui vont fournir des scripts et des wrappers au dessus soit de Compose soit de la CLI directement et en fait, certains devs arrivent et savent que le matin il faut lancer la commande un truc pour set-up et l'environnement, et le vendredi il rappelle le wrapper pour dire arrête toi et voilà et en fait ils ne savent absolument pas que derrière ça a démarré un Compose qui a lancé la base de données démarré le Kafka dont ils vont avoir besoin pour leur développement au jour le jour voilà, ça va vraiment dépendre des types de développeurs, mais il y a vraiment dans certains de nos clients, nous on a accès à vraiment, qu'une infinie partie des développeurs parce que les autres ne savent juste pas, pour ceux qui ne sont pas curieux, qu'ils utilisent Docker ceux qui sont curieux évidemment ils vont le voir, ils vont aller voir ils vont voir les process, Pourquoi j'ai un docker desktop qui tourne s'ils sont sous Mac ou Windows ? Mais il y en a qui ne savent absolument pas. Et puis, ce n'est pas nécessaire pour eux au quotidien.
Bruno:
Après, on peut supposer que la majorité des gens qui écoutent ce podcast sont des gens qui ont un naturel de curiosité. Parce que c'est quand même des gens qui s'astreignent volontairement de leur propre chef d'écouter un truc de dev en dehors de leurs heures de travail. Donc, a priori, ils ont quand même déjà une certaine curiosité. Sur ce qu'apporte Docker, cœur. Plusieurs fois j'évoque sur ce podcast que je trouve dans notre métier il y a un phénomène que je trouve un peu étrange l'espèce de dualité, c'est-à-dire qu'on a une complexification et en même temps une simplification du métier. Comme je disais, moi quand j'ai commencé à coder dans les années 90, mettre un site sur internet c'était extrêmement entre guillemets facile, c'est-à-dire que tu as besoin d'une machine, un peu de PHP, un petit serveur Apache et puis ça tournait. Aujourd'hui c'est quand même un peu plus complexe, mais en même temps c'est plus complexe. Tu vois, le front est devenu un vrai métier. Il y a des technologies qui sont devenues hyper complexes. Mais en même temps, on fait des choses beaucoup plus complexes qu'avant, beaucoup plus facilement qu'avant. Est-ce que toi, tu vois Docker et la containerisation comme étant un truc qui a ajouté de la complexification ou qui, au contraire, a allégé beaucoup de sujets côté dev et ou côté ops ?
Guillaume:
La question piège.
Bruno:
Côté OPS, je pense que ça a facilité beaucoup de choses. Et encore ?
Guillaume:
Ça dépend de ce qu'on met dans la conteneurisation. Si on reste juste sur les principes de la conteneurisation et de ce qui est Docker depuis le début, je vais dire que ça a simplifié. Ça a simplifié le développement. Parce que, comme on disait, la base de données, on ne l'appuie en local. On veut tester l'immigration, c'est super facile. Mais on parlait de migration d'une base de données mais on peut parler de migration applicative tu changes de framework comment est ce que ton appli se comporte avec la nouvelle version du framework tu n'es pas obligé de tout casser juste tu démarres un nouveau conteneur qui contient la nouvelle version du framework et puis tu peux tester donc de ce point de vue là sur toutes les tâches un peu un peu compliqué et casse gueule il ya une vraie simplification moi je Je travaille beaucoup sur la boucle de développement avec Compose. Donc je suis peut-être un petit peu plus loin de la production elle-même. Donc mon boulot au quotidien, c'est juste de faire en sorte que ça soit le simplifier au maximum. Donc je pense que c'est le cas. Si on prend le conteneur dans son écosystème de manière plus globale, on a complexifié un certain nombre de trucs. Kubernetes est un outil impressionnant qui permet de faire des choses. Mais vraiment s'il avait fallu faire ça sans les conteneurs. Ça existait un peu c'était pas les on était pas sur les mêmes outils c'est un exemple que je donne souvent.
Bruno:
Il y a 30 ans tu voulais faire un cluster il te fallait une équipe de 20 personnes payer un prix d'or pour te faire un truc.
Guillaume:
Mais d'un autre côté on va pas dire que le ticket d'entrée dans Kubernetes il est facile donc, Donc je pense que c'est assez balancé en fonction de ce que tu vas faire. Pour le dev, je pense que ça peut simplifier beaucoup le quotidien. Sur la partie ops, si on part sur la mise en place de clusters et tout, c'est plus compliqué, mais on fait aussi des choses vachement plus abouties avec de la scalabilité, de la redondance. Des choses, comme tu dis, il fallait des équipes entières. C'est toujours le cas, on a toujours des équipes entières pour le mettre en place, mais peut-être moins et puis avec surtout une élasticité qu'on n'avait pas.
Bruno:
Avant et ça c'est assez impressionnant Est-ce que tu penses que on aurait les architectures microservices si on n'avait pas eu la cotonisation et Docker ?
Guillaume:
Non On est d'accord On ne l'aurait pas eu, Est-ce que j'y vais ou j'y vais ? Je pense que c'est un mauvais side effect de la cotonisation, non en fait c'est toujours pareil je pense que tu l'as déjà abordé dans beaucoup des podcasts avec d'autres invités on est quand même dans une économie qui suit énormément les modes et on se retrouve à faire des trucs dont on a absolument pas besoin, parce que Netflix l'a fait mais parce que dans le cas de Netflix ça avait un intérêt ou Google l'a fait parce que dans leur cas d'usage qui n'est pas du tout le même que la plupart des autres sociétés ça avait un intérêt Alors après.
Bruno:
Sur ce podcast on l'a beaucoup dit donc je pense que l'audience l'a intégré c'est que le microservice versus le monolithe c'est pas tant une réponse technique c'est avant tout une réponse.
Guillaume:
Organisationnelle c'est.
Bruno:
Comment tes devs travaillent et parfois ça a plus de sens effectivement de passer en microservice ou d'être en monolithe c'est plus une question d'organisation d'humains qu'une question.
Guillaume:
Purement technique. Et puis ton métier enfin je veux dire si tu fais de l'application de gestion ? Peut-être soit deux fois la question. Si tu fais des trucs hyper distribués, avec, je sais pas, de la faible latence et tout, bah ouais, là, tu vas avoir besoin d'avoir tes services qui sont sur différentes, dans différentes zones de data center avec la redondance qui va bien et tout. Et là, là, oui, tu vas y aller. Mais je suis pas sûr que ce soit la majorité des cas, quoi.
Bruno:
La chance du coup qu'on a de te recevoir c'est que toi effectivement tu as beaucoup bossé sur Docker Compose donc tu sais bien comment est-ce que ça fonctionne et c'est toujours intéressant de creuser un peu comment est-ce qu'une automatisation, fonctionne est-ce que du coup tu peux pour commencer déjà à nous raconter un peu, pour ceux qui ne sauraient pas à quoi sert un Docker Compose et du coup nous dérouler un peu c'est quoi toute cette magie que j'évoquais en intro qui s'opère quand on lance une fameuse Docker Compose est-ce.
Guillaume:
Que je fais un peu d'histoire ou pas.
Bruno:
?
Guillaume:
Allez, quand Docker est créé et lancé en 2013, il faut écrire, Tout à la main dans la ligne de commande. En gros, Docker run, je te passe mes paramètres pour avoir tel port d'exposé, je te monte tel volume, là je fais du bindement, là je crée... Et on se retrouvait avec des lignes de commande énormes. Et ça, c'était pour un conteneur. Et s'il en fallait plusieurs, qu'on voulait mettre en place un réseau entre eux, c'était compliqué. Donc il y a une petite société qui a créé un produit qui s'appelait FIG et qui a juste dit, nous on va utiliser du YAML pour écrire ça une fois. Et puis, on va faire un fig, et puis ça va réappliquer à chaque fois le truc. Donc, ça a commencé, c'était juste monoservice. Donc, on pouvait définir juste un conteneur avec tous ces paramètres, mais on pouvait leur lancer avec juste une commande hyper simple, sans avoir à se rappeler de tout. Bon, évidemment, ils ont résolu un vrai problème qu'il y avait. Donc, la boîte a été rachetée par Docker assez rapidement. Et à partir de là est né Docker Compose qui a eu plusieurs évolutions la première c'était de rajouter du multiservice et de commencer à pouvoir faire d'avoir plusieurs conteneurs de défini à l'intérieur, du format de fichier et puis après ça s'est encore enrichi avec, des volumes, du network et tout ça donc en gros, parce que je vois, je vais déjà dans le détail, il faut peut-être que j'explique ce que c'est d'abord, Docker Compose C'est une ligne de commande qui va prendre un format de fichier YAML. Dans ce format de fichier, on va décrire une application composée de plusieurs services, qu'on appelle des services, et ces services vont être. Créés sous forme de conteneurs du côté de l'engine. Donc en gros, l'exemple classique, j'ai une application entière, un front-end, un back-end, une base de données, chacun va être un service, ils vont avoir des images différentes qui peuvent être buildées localement ou pas, et puis si on ne fait rien, Docker Compose va créer un réseau automatiquement pour eux, et ces services vont être capables de communiquer entre eux via un DNS interne. Ou alors, on peut créer son propre. Stratégie réseau. Voilà, exactement. Donc, sur le principe, c'est ça. Donc, ça veut dire que vous pouvez faire assez facilement des applications avec des dizaines et des dizaines de services. Du Kafka.
Bruno:
En définissant à chaque fois, qu'est-ce qui t'en comme applicatif ? Exactement.
Guillaume:
Est-ce que c'est exposé à l'extérieur ou ça reste à l'intérieur de l'infra donc est-ce qu'on peut y accéder depuis l'host ou non et tout ça. Donc voilà ce qu'on pose c'est un outil qui va te permettre de, d'exécuter une application multiconteneur en faisant juste Docker, Compose, Up.
Bruno:
Et de construire quasiment toute une infra, pas une seule ligne de commande, mais à peu de choses près, c'est un peu ce qui est en train de se passer. C'est ce qui avant nécessitait une équipe de 20 personnes avant qu'on ait tout ça.
Guillaume:
Oui, alors après, il faut savoir que Compose, c'est un outil client-side qui tourne sur la machine. Donc, il est stateless quand il exécute une commande il l'a exécuté, c'est fire and forget j'ai oublié ce que j'ai fait, je peux pas donc tu vois ça fait pas vraiment de l'orchestration ce que je veux dire c'est que toute l'intelligence de le conteneur il doit redémarrer ou il doit attendre que l'autre soit démarré pour être créé lui et tout ça c'est fait côté Docker Engine et Compose c'est vraiment un client du Docker Engine un client survitaminé, qui sait gérer pas mal de choses mais qui ne reste qu'un client, et ça c'est important à avoir en tête parce que ça veut aussi dire qu'il est mononeux il s'est communiqué avec un seul engine, et si tu veux mettre du compose en production c'est possible, il y a zéro problème il ne faut pas que tu aies besoin de scalabilité c'est à dire que tu vas faire ça pour une application qui peut s'arrêter et puis on peut redémarrer qu'il n'y a pas de criticité particulière et qu'on peut rebooter en automatique et tout ça. Mais il y a plein de cas d'usage où ça suffit. Donc c'est bon à savoir. Mais voilà, c'est important de le préciser parce qu'il y a plein de gens qui disent « Oui, mais pourquoi est-ce que Compose, il n'est pas plus intelligent ? » Parce qu'il y a des fois, il y a des choses, on ne peut pas le faire. Ce n'est pas nous qui avons la main, c'est l'engine.
Bruno:
Alors comment se répartit cette responsabilité entre Compose et l'engine ?
Guillaume:
Comment elle se répartit ? Principalement, nous, on va faire en sorte de simplifier la vie du développeur. Nous, on est vraiment sur le côté développeur. C'est comment est-ce qu'on peut faire pour que son format de description soit le plus simple possible pour lui, mais que nous, on soit capable de réappliquer, à partir des quelques informations qu'il nous a fournies, une bonne stratégie de création et de déploiement. Parce qu'on s'occupe quand même de l'organisation et du séquencement de la création des conteneurs. C'est-à-dire que l'engine, tu lui donnes un compost file, tu ne sais pas quoi en faire ton truc. Par contre, nous, on est capable de reconstruire l'arbre de dépendance entre les services, savoir qu'il faut démarrer le service A avant le service B, mais que le service C doit attendre absolument que le service A soit healthy dans un état pour être démarré, alors que le service B s'en fiche. Toute une stratégie comme ça de dépendance inter-service tout ça on va le gérer du côté de Compose Compose va s'occuper de la création des ressources. Dont tu peux avoir besoin si tu définis toi-même tes networks c'est lui qui va faire l'appel à l'engine pour créer les networks avant de créer les conteneurs pour pouvoir les rattacher correctement après pareil pour les volumes, les volumes c'est pour stocker les données pour le stockage des données et c'est lui qui va s'occuper de le faire. Donc, en fait, on a quand même toute une stratégie là-dessus. Et puis, si on fait des modifications dans un Compose File et qu'on refait un Docker Compose, hop, bah Compose va être capable de voir qu'il y a eu des changements sur tel ou tel service et de redemander la création au Docker Engine et tout ça. Et ça c'est pas l'Engine qui va faire, c'est Compose qui va être capable d'analyser, de faire ce process de réconciliation, de dire attends c'est quoi ton statut là-bas, c'est quoi le statut qui est attendu, enfin le state expected et puis de faire le diff entre les deux et dire ok, on renvoie et c'est ça le nouvel état qu'on va vouloir avoir à la fin.
Bruno:
Donc au final tu nous disais tout à l'heure que Docker Compose était stateless et qu'une fois que tu avais exécuté ta commande il allait oublier ce qui se passait au final pas complètement parce qu'il est capable de mais c'est.
Guillaume:
Pas lui qui conserve l'état.
Bruno:
Et toi.
Guillaume:
Il vient récupérer et l'état du fichier qui est en local et il vient récupérer demander.
Bruno:
À l'étude c'est.
Guillaume:
Quoi l'état courant en.
Bruno:
Fait pour.
Guillaume:
Pouvoir faire la.
Bruno:
Réconciliation mais.
Guillaume:
De lui même il est absolument pas au courant de.
Bruno:
Quel état il a pas toutes les commandes qui ont été faites effectivement j'entends, donc tu nous as parlé de l'ordre des opérations, qui va être du coup défini par Compose, ça du coup c'est pas un élément enfin c'est un élément qu'on peut définir dans notre YAML mais que Compose est aussi lui capable entre guillemets de surimprimer et de définir lui-même ses ordres de priorité.
Guillaume:
Ouais alors là ça peut être le moment des grandes surprises en fait c'est à dire que, Compose par défaut la liste des services c'est une map et en go une map c'est pas ordonné, donc le même projet si on définit pas de dépendance entre les services ils peuvent démarrer dans un sens complètement arbitraire donc pour certaines applications c'est absolument pas problématique pour d'autres on a des utilisateurs qui vont nous voir je comprends pas, ça a démarré alors que la base de données elle est pas prête, C'est pour ça qu'on vous a rajouté des informations à mettre pour dire que le service back-end, il dépend du service base de données. Et puis, il ne fait pas juste que dépendre, donc il n'attend pas juste que le conteneur soit créé. En vrai, il va attendre qu'on ait le chèque qui a été défini dans le service de base de données. Celui-là, il a bien été fait et du coup, qu'on est OK pour dire c'est bon, tu peux démarrer, tu vas pouvoir te connecter sur la base de données. Elle accepte les connexions maintenant. Mais par défaut Compose va va lire son fichier YAML va avoir les services qui sont mis dans un certain ordre dans sa map.
Bruno:
Ah donc par défaut il n'y a pas de calcul de recherche.
Guillaume:
Non si, alors en fonction des attributs on peut avoir par exemple s'il y a des links alors c'est des trucs qu'on ne conseille plus forcément d'utiliser, qui étaient là, des links entre les services il va être capable de voir que celui-là il doit être mis avant l'autre, Mais typiquement et de manière principale, c'est vraiment tout ce qui va être « depend zone » qui va dire « le service dépend de l'autre service » et la partie « health check » pour dire «, Il dépend, mais il faut attendre un état particulier de l'autre service avant de démarrer ou de créer et tout ça. C'est vraiment ça qui va permettre à Compose de reconstruire l'arbre de dépendance des services.
Bruno:
Donc ça, c'est à définir entre guillemets manuellement dans ton YAML ?
Guillaume:
Ou alors tu peux le faire de manière itérative. Tu lances la première fois, tu t'aperçois que ton backend ou ton frontend, il a démarré alors que la base de données n'est pas prête. Et puis que ça ne marche pas et que ton appli crache parce que tu n'as pas fait les retry dans ton appli.
Bruno:
Ça te permet c'est de.
Guillaume:
L'hardway mais tu peux tu peux apprendre des choses aussi et progresser en travaillant comme ça.
Bruno:
De toute façon là où moi je trouve ça hyper intéressant c'est que ça t'oblige aussi de lire des logs parce qu'en général c'est là où tu vas retrouver les informations et je l'ai dit plusieurs fois dans ce podcast mais vraiment beaucoup de fois, lisez vos logs c'est hyper intéressant c'est une source d'information hyper importante donc il faut de toute façon aller lire ces logs et.
Guillaume:
Savoir que nous on affiche pas tout par défaut on a un mode verbose.
Bruno:
Qui va.
Guillaume:
En afficher beaucoup plus si jamais vraiment vous comprenez pas ce qui se passe.
Bruno:
Donc on a évoqué cette, ordonnance ordonnancement des instructions c'est la capacité d'aller voir l'existant pour te voir le décalage, c'est quoi la mécanique qui permet de mesurer ce décalage simplement tu reprends le YAML de l'ancien ?
Guillaume:
Non parce qu'en fait on l'a pas le YAML de l'ancien c'est celui que t'as sûrement modifié donc on n'a pas la version comme je dis on est stateless on n'a pas une gestion de l'historique des versions il.
Bruno:
Pourrait être attaché à celui qui est en run.
Guillaume:
Mais il n'y a rien en fait côté engine ça n'existe pas, l'engine il ne connait pas le Composy Amel donc on ne lui a jamais passé on n'a fait que des appels d'API pour dire crée moi un conteneur machin, crée moi un conteneur truc et donc ce qu'on va faire on va faire l'inverse on va aller, recommuniquer avec l'engine pour le dire, tous les conteneurs qui sont créés avec Compos sont créés avec des labels, qui nous permettent de savoir quel est le projet, quelle version de Compose, enfin plusieurs métadonnées en fait qu'on va utiliser. Nous on va se resservir de ces métadonnées pour quand je suis sur mon projet A et que je veux récupérer l'état courant de mon projet A, On va faire des requêtes vers l'engine en disant fais-moi un docker, l'équivalent d'un docker PS en fait, avec des filtres pour dire je veux que les conteneurs qui ont les labels blablabla, et notamment un qui est le nom du projet Compose pour récupérer ces conteneurs. Du coup, une fois qu'on les a récupérés, on est capable d'avoir leur définition. Est-ce qu'il y a des ports exposés ? Et puis là, on est capable de faire le diff par rapport à ce qu'on vient de charger, depuis le Compose File et dire est-ce qu'il a changé, pas changé, est-ce que je dois demander à l'engine de leur démarrer si oui c'est quoi la nouvelle config c'est quoi la nouvelle config on lui passe la nouvelle config mais.
Bruno:
Du coup ça veut dire que tu as peut-être un fonctionnement par tri au sens un arbre de manière assez classique c'est à dire que tu vois les nœuds qui ont changé.
Guillaume:
Donc tu.
Bruno:
Peux déterminer à partir de quels nœuds.
Guillaume:
Derrière nous on a une structure go sur laquelle on va être capable de faire les diff pour voir et puis on sait lequel vient de l'état courant et lequel est l'état attendu donc on est capable de revoir les diff tu.
Bruno:
Peux avoir certains éléments de ton arbre enfin certains conteneurs qu'il faut changer mais du coup en changeant tel conteneur en fait il faut que tu redémarres aussi.
Guillaume:
Alors ça derrière c'est la deuxième en effet la partie qui suit derrière donc là moi je te parlais juste de la comparaison, service à conteneur par contre service à service en fait et une fois qu'il a fait ça en effet il va aller regarder s'il y a des services qui dépendent les uns des autres et si pour ces services, l'utilisateur a demandé explicitement à reforcer la recréation quand le service dont il dépend a été lui-même modifié parce qu'il y a certains services je ne sais pas si la configuration change dans le service principal ont besoin de redémarrer parce qu'ils vont appliquer une nouvelle config de leur comté ou je ne sais quoi, donc on a aussi ces mécanismes là qui passent après coup, On récupère les informations de l'engine, on fait le diff pour voir ce qui a changé dans les services et après coup, est-ce qu'il y a des dépendances qui doivent être aussi, même si elles n'ont pas changé, elles directement, doivent être redémarrées ou recréées au besoin.
Bruno:
Et donc ça permet de redémarrer, enfin de démarrer un nouveau conteneur pour tous les trucs qui ont changé, de faire la bascule quand il est up et après du coup c'est...
Guillaume:
Donc ça peut être super c'est à dire que si par exemple vous avez un seul service qui a changé et qu'il n'y a pas de service qui en dépendent même si ceux qui en dépendent n'ont pas une dépendance forte ce qui fait qu'ils n'ont pas besoin d'être créés vous pourrez faire un Docker Compose Up en donnant le nom du service, et ça va juste réappliquer en fait, la recréation que pour ce conteneur là et donc toute la stack elle est restée, elle est restée up et c'est vraiment quasi instantané ça c'est un mécanisme qu'on utilise pour Watch par.
Bruno:
Exemple C'est quoi la différence du coup entre la conteneurisation et la virtualisation ?
Guillaume:
La question La question J'y ai réfléchi et je me suis dit forcément elle va tomber Comment est-ce que je peux l'expliquer de manière simple ? C'est deux choses différentes et ça se passe d'un point de vue kernel. En gros, la virtualisation va s'appuyer sur un hyperviseur qui est un logiciel particulier de l'OS, qui va en fait permettre de démarrer une toute nouvelle machine, avec son propre kernel qui peut être différent de la machine sur laquelle elle tourne et avec ses limites, la config qu'on veut lui donner on peut dire je vais démarrer un Ubuntu, je ne connais plus les versions ou une Alpine ou je ne sais pas quoi, mais je vais la démarrer en m'appuyant sur un hyperviseur qui va me donner accès aux ressources de la machine hôte de manière virtuelle je vais avoir aucun composant. Physique réel dans cette machine, donc on a une isolation qui peut être du coup extrêmement forte. Parce que on peut complètement tuner toute cette OS jusqu'à tout son elite boot en fait, donc on a vraiment une manière de, ça j'en veux pas, je dégage machin, truc bituel là où le conteneur est en fait un processus comme les autres sur la machine haute, sauf qu'on va utiliser les notions de CNAME et CGROUP pour à la fois limiter, la visibilité et l'accès à toute une partie des ressources de la machine, et puis le limiter sur sa consommation de ressources, de CPU, de machin. Quand on est sous Linux, ça a l'avantage de donner un accès direct, par exemple, au GPU. Ce qui, quand on fait l'IA, peut être super intéressant. c'est-à-dire que le conteneur sur une machine Linux, il peut demander l'accès à la ressource GPU et l'avoir en direct et travailler. Alors qu'elle sera émulée côté machine virtuelle et du coup, pas aussi efficace, voire pas accessible en fait. Par exemple, sous Mac, c'est juste l'enfer pour pouvoir accéder au GPU depuis une machine virtuelle. Mais vu ce que je viens de dire, c'est comment ça marche sur Mac et Windows. Ce n'est pas un process Linux. Il n'y a pas de process Linux dans Mac et dans Windows. C'est parce qu'en fait, il y a une machine virtuelle. Voilà, donc ça vous explique aussi pourquoi est-ce que vous ne pouvez pas accéder directement à votre GPU depuis vos conteneurs sous Mac et sous Windows. C'est parce que vous êtes déjà dans une machine virtuelle qui, elle, fait tourner un Linux. Qui va vous donner accès à la configuration des six groupes et vous allez vous retrouver à voir vos conteneurs qui fonctionnent Cela dit.
Bruno:
Je crois que les devs ça fait longtemps que je ne dev plus sous Windows mais je crois que les devs qui font eux-mêmes leur installation Docker sur Windows, ont cette, perception de la virtualisation parce qu'ils sont obligés de le faire, là où sous Mac tu n'es pas obligé de le faire, tu vois ce que je veux dire ou pas ?
Guillaume:
Non, je ne suis pas sûr.
Bruno:
Parce que quand tu es dev dans une grande boîte on te file une machine qui est déjà installée, déjà configurée tu le vois pas mais si t'es dans une plus petite boîte où t'es indépendant ou étudiant en fait c'est à toi de faire tes installs sur ta machine et quand t'es sur Windows t'es obligé d'installer en fait ton WSL donc t'as quand même cette approche de la version Tu peux utiliser Docker Desktop ?
Guillaume:
Il va t'installer.
Bruno:
Il ne te demande pas quand même de installer WSL ?
Guillaume:
Il va te le faire pour toi.
Bruno:
Il le fait pour toi. À l'époque où je le faisais sous Windows, ce n'était peut-être pas encore...
Guillaume:
Non, peut-être que WSL doit être installé. Par contre, il va te prendre la bonne image et tout. Peut-être qu'il a raison. Il faut peut-être qu'il l'installe.
Bruno:
Donc, tu as quand même, tu vois, je trouve cette approche de l'activisation sous Windows que tu ne vois pas du tout sous Windows.
Guillaume:
Avant, elle était masquée quand il n'y avait pas WSL parce que c'était avec HyperV. Il fallait juste l'activer HyperV et les gens ne savaient pas je l'active sans se rendre compte que tu viens d'activer un hyperviseur qui va te faire de la virtu parce qu'on va te démarrer une machine virtuelle.
Bruno:
C'est aussi pour ça qu'on a parfois l'impression que quand on lance Docker, d'un coup notre machine elle se prend une claque, en termes de perf c'est parce que justement t'as cette.
Guillaume:
Virtualisation qui.
Bruno:
Est un truc assez gourmand en.
Guillaume:
Ressources il faut lui donner un petit peu d'espace un petit peu de CPU pour que ça puisse fonctionner correctement même si ça démarre plus vite beaucoup plus vite qu'avant Enfin, je ne sais plus, on a des études de perf, on démarre aussi vite que nos concurrents et tout. C'est pas... Enfin, ça s'est vraiment amélioré sur le sujet.
Bruno:
Et donc, le dernier sujet qu'on voulait évoquer avec toi, c'était Docker Sandbox ?
Guillaume:
Bah oui, parce que moi je vous dis, il faut faire des conteneurs, mais Docker Sandbox...
Bruno:
Alors du coup, déjà c'est quoi Docker Sandbox ?
Guillaume:
Déjà c'est quoi Docker Sandbox ? Docker Sandbox, c'est un outil qui va vous permettre d'exécuter, enfin de travailler avec vos agents de code de manière sécurisée en étant en Yolomod en fait. Donc votre agent ne va plus jamais vous poser les questions de est-ce que je peux aller lire le fichier machin ? Est-ce que je peux accéder à l'API ? Est-ce que tu m'autorises à faire ça ? En fait, tout ça où quand on commence à travailler et qu'on fait attention à sa machine, on dit oui, ça tu peux. Puis au bout de 20 fois, on en a marre. Donc on commence à plus lire ce qui se passe. Alors les plus téméraires passent directement en mode diolo sur leur host. Elle est comme moi, continue à appuyer sur Yes, mais ce n'est pas forcément mieux. Et puis on s'est retrouvé avec plein de cas de figure où des gens ont eu leur home partiellement effacé. Ou le projet. Complètement détruit par l'agent voire dans des cas bien pires je ne sais pas comment ils se sont démerdés d'ailleurs des problèmes en prod avec des effacements de bases de données, et ça quel que soit l'agent c'est pas Claude, c'est pas Gemini c'est juste la manière de les laisser travailler, en autonomie qui est problématique donc là l'idée c'était de dire comment est-ce qu'on peut les laisser travailler en autonomie parce que c'est extrêmement important, c'est là où ils sont le plus efficaces. Quand on les laisse travailler, quand on leur dit, tu peux installer les packages que tu veux, fais ce dont tu as besoin pour répondre à la demande que je t'ai adressée. Et l'idée, c'est de dire, ok, donc il faut qu'on puisse faire ça, mais il faut qu'on puisse le faire de manière totalement sécurisée, c'est-à-dire que ça ne mette pas la machine du développeur à un risque. De préférence, ça n'ait pas du tout accès à aucun secret. Parce que si au passage il envoie les secrets dans le... Une clé ou je ne sais pas quoi dans la nature, c'est moyen. Et puis, on a aussi des clients qui nous disent, on va même plus loin que ça. C'est-à-dire que nous, il y a des sites où juste l'agent n'a pas le droit d'aller voir. On ne veut pas qu'il communique avec ces sites. Donc, comment est-ce qu'on peut offrir une expérience avec les codicats agents qui soient efficaces et sécurisées ? Donc, ça, c'est le principe de Docker Sandbox.
Bruno:
En sachant qu'effectivement le concept de créer un espace fermé et on peut dire le mot conteneurisé, c'est un peu la base de votre métier.
Guillaume:
C'est un peu la base de notre métier. Et bien pour autant, on a décidé de faire ça, donc on le fait, on utilise des conteneurs à l'intérieur d'une machine virtuelle. C'est-à-dire que, donc là, ça fonctionne sans Docker Desktop, pas besoin de Docker Desktop. Mais ce que va faire Sandbox, c'est que ça va booter une micro VM. Cette micro VM est extrêmement légère, il n'y a quasi rien dedans, à part un container dit et du coup, la possibilité de démarrer un démon Docker, en fait, à l'intérieur. Et à partir de là, nous, on va aller monter, enfin, on va aller télécharger une image, en fait, faire un pool d'une image qui contient l'agent, en fait. Et puis derrière on vient se plugger sur la sortie réseau de l'AVM puis on regarde tout ce qui passe et si ça a besoin d'une clé parce qu'on va je sais pas, on va chez Anthropic parce qu'on utilise Cloud et qu'à un moment il faut passer la clé parce que sinon derrière ils vont dire bah non je te réponds pas t'es gentil mais t'es qui, et bah on va faire du man in the middle et venir réécrire les URL pour réinjecter les credentials. Donc ça, ça reste côté host, c'est le boulot de Docker Sandbox qui va venir réinjecter les credentials au bon moment sur les bonnes requêtes pour pouvoir aller interagir avec les. Agents qui sont remote pour récupérer l'information et la renvoyer derrière l'agent. Et lui, il travaille en mode complet. Puis si tu demandes c'est quoi ta clé GitHub ? Parce qu'on a la CLI de GitHub qui est installé, donc il va faire un GH. Hausse je ne sais plus, c'est token, je ne sais plus quoi pour récupérer le token, et puis là ça va être écrit proxy manage. Maintenant ils commencent je sais pas s'ils ont appris nous ou quoi quand je les utilise en cas ils me disent ouais c'est parce qu'en fait, il y a un truc au dessus qui surveille qui nous empêche d'aller faire n'importe quoi donc ça veut dire que t'as plus de credentials qui sont accessibles directement par l'agent, on filtre le réseau c'est à dire qu'on a plusieurs stratégies par défaut on a tu bloques tout t'autorises tout, Nous, on a fait un truc qui est balance, en fait, pour les développeurs où tu as accès à tous les trucs cloud, accès aux codes sources, donc GitHub, tout ça, les repos genre Meven, NPM, tout ça. Et là, on laisse accès. Et après, pour les clients pour qui c'est hyper important, il y en a une solution payante. Parce que, alors, je n'ai pas dit, Sandbox est gratuit. Vous pouvez l'utiliser, il n'y a pas de problème. Par contre dès que vous voulez les features on va dire pro sur la sécurité c'est le moment où il faut venir voir nos commerciaux et là eux du coup peuvent mettre en place leur propre profil en fait et donc avoir, qui descendent sur les machines de leurs développeurs. Des configurations alors Eden ils peuvent avoir leur propre agent c'est à dire, leur propre version de leur agent donc pour les boîtes qui ont des agents custom et tout ils peuvent les packager et utiliser sandbox avec et puis derrière ils peuvent appliquer leurs règles, strictes réseau et tout ça directement pour bloquer les accès.
Bruno:
Donc ça te permet effectivement de te dire on se concentre sur cette partie de définition stricte, de bien définir notre besoin, ce qu'on veut, cadrer le projet autant qu'on veut et du coup après tu peux lancer ton agent en mode one shot et tu lui dis vas-y fais-moi tout.
Guillaume:
Exactement il y va, il a accès comment la monter dans une machine virtuelle ? Et que je t'ai dit il y avait un Docker Engine qui tourne à l'intérieur et bien on a zéro problème à lui donner accès à cette socket parce que s'il sort il sera dans sa VM où il n'y a rien d'autre de toute façon donc c'est pas grave mais ça lui permet aussi lui et l'agent de créer des nouveaux conteneurs si besoin de lancer des applications qu'on pose enfin voilà il peut il peut, vivre sa vie complètement et, ils sont généralement en plein d'imagination donc et nous on s'amuse de très régulièrement à leur demander de sortir parce que il faut vérifier qu'on n'a pas à recréer des trous c'est.
Bruno:
À dire que vous demandez à vos agents d'essayer de sortir de la virtualisation et.
Guillaume:
Ils arrivent ?
Bruno:
Pour le moment non.
Guillaume:
On essaie régulièrement parce.
Bruno:
Qu'on sait jamais.
Guillaume:
On peut réintroduire sans s'en rendre compte des fois il suffit d'un petit truc où on se dit ça va c'est rien c'est pas méchant c'est tellement créatif qu'ils vont réussir à trouver des.
Bruno:
Trucs il y avait un article qui sortit il y a pas très longtemps qui avait fait du bruit surtout dans la presse grand public parce qu'il y avait une histoire d'un Claude qui avait réussi à sortir d'un truc mais ça n'avait rien à voir avec ça non ? Non.
Guillaume:
Non, non, je ne pense.
Bruno:
Pas ça ne me parle pas De toute façon les titres dans la presse sont souvent un peu Oui.
Guillaume:
Non, non, là sur pour l'instant, alors je ne dis pas je pense qu'en s'acharnant bien, et en étant peut-être des pros du prompt parce qu'on n'est pas forcément, on est des devs donc on n'est pas, je ne suis pas un spécialiste de l'IA, peut-être qu'il y a moyen de sortir mais Mais voilà, il va falloir y aller parce qu'il n'y a vraiment pas grand-chose dans la VM. Donc, même si une fois sorti du conteneur...
Bruno:
Il n'y a plus grand-chose à faire.
Guillaume:
Ouais, c'est un peu ça, ouais.
Bruno:
Sur cet usage de pouvoir avoir un contexte où tu peux laisser ton agent en mode one-shot, créer tout le code qu'il veut et créer tous les conteneurs qu'il veut... Je trouve ça hyper intéressant. Dans ma manière de travailler, je trouve que c'est hyper utile. Je trouve que c'est top, surtout dans un contexte de Greenfield où tu es en train de créer une application de zéro. Effectivement, tu le laisses partir. Dans des contextes où tu as déjà tout un legacy, les gens peuvent être un peu plus frileux de le faire. J'entends quand même beaucoup de gens dire qu'il faut quand même bien relire tout ce que l'IA fait.
Guillaume:
Clairement.
Bruno:
Le problème, c'est que si tu le laisses en mode one shot, tu lui donnes une spec un peu taffée et tu lui dis, je te laisse trois heures, tu fais tout ce que tu as à faire. En fait tu ressors avec 50 000 lignes de code, avec 25 canteneurs t'as pas la personne a la capacité de relire tout ça clairement, parce que du coup au final vous donnez les moyens aux gens de créer ces contextes là qu'on est plus du tout capable de maîtriser parce que derrière.
Guillaume:
Je suis je suis complètement d'accord c'est un sujet qui est j'ai pas de réponse.
Bruno:
Sur le.
Guillaume:
Truc d'un autre côté On l'a utilisé pour Compose, sur des rifactos de Compose, où il y a quelque chose qu'on n'arrivait pas à adresser, parce qu'humainement, on n'y arrivait pas. C'est-à-dire qu'à chaque fois qu'on... C'était tout process de réconciliation, en fait, de le refaire bien propre. Toutes les choses étaient un peu entremêlées, partaient dans tous les sens. Et on avait une claire vision de ce qu'on voulait. C'est récupère-moi l'état attendu, l'état courant. Faisons proprement le DIF et réappliquons derrière l'ensemble des règles. Ça n'était absolument pas fait comme ça. Ça, on n'arrivait pas à l'adresser parce que dès qu'on commençait le rifacto, ça partait tellement dans tous les sens que nos cerveaux n'arrivaient pas à gérer toute la complexité. Par contre, on était extrêmement capables d'expliquer à un agent ce qu'on attendait en fait. Alors ça a mis un petit peu de temps de prompting pour avoir quelque chose de propre, mais on l'a eu. Et en deux jours. Alors qu'on s'était cassé les dents déjà plusieurs fois sur deux, trois jours à chaque fois chacun avec Nicolas. Donc tu te dis, c'est toujours pareil, t'as un outil qui te permet de faire tout et n'importe quoi. il faut l'utiliser de manière, faire attention à ton usage et pas te laisser déborder par ce qu'il est capable de faire.
Bruno:
Est-ce que ça veut dire que grâce à ce système de sandboxing on peut se dire que maintenant on va, tu parlais de ce travail sur le prompt le truc c'est que de plus en plus ton prompt c'est pas juste un prompt c'est que tu lui files toute une doc tout un temps d'U.S. et compagnie des.
Guillaume:
Fois t'as même plusieurs itérations.
Bruno:
Mais est-ce que justement l'idée c'est pas de se dire que tu peux lui dire comme t'es en mode sandbox, je te donne une bonne grosse fat spec tu me fais tout un truc, je teste si ça marche pas en fait je scrape tout et tu relances une sandbox et tu lui fais recommencer.
Guillaume:
Ça peut tu peux t'en servir pour essayer d'améliorer ton prompt qui sera le prompt final on va dire et puis en effet jeter mais récupérer la nouvelle version à chaque fois jusqu'au moment où tu vas arriver à ce que tu attends donc faire du littératif sur ça serait quoi le meilleur prompt pour obtenir un résultat qui soit indigeste et qui fonctionne et puis que je vais être potentiellement capable de relire, moi j'utilise pour faire des revues de PR rien de toi a rien à voir pour l'expérimentation moi je pense que c'est un outil génial tu veux tester un truc sur ton projet, Tu changes, je ne sais pas, une librairie centrale de ton... Tu veux tester le changement d'une librairie centrale de ton projet. Ça tape partout à l'intérieur. Allez, vas-y, essaye. Remplace la librairie machin par la librairie truc. On regarde c'est quoi le résultat à la fin, quoi. Donc, tu vois, il y a plein de cas d'usage où ça apporte vraiment quelque chose. D'une manière générale, je te donne... Tiens, c'est ça qu'il faut faire. Vas-y, c'est la nouvelle feature. j'ai un peu plus de mal parce que mais c'est pas lié au sandbox tu vois, il y a des gens qui le font déjà sans les sandbox pour autant c'est plus une manière de voir le développement. Ouais moi comme je l'ai dit je fais mes revues de PR parce que du coup je peux, de manière tranquille récupérer le code qui est un code que je connais pas à l'intérieur de ça, Et puis demander une première passe de revue, tester, vérifier que ça adresse bien. Parce que quand on a des issues qui sont ouvertes, on demande des cas pour reproduire. Donc d'aller reproduire le cas qui a été donné dans l'issue d'origine et tout. Donc en fait, toute une partie de mon travail qui était assez manuel, qui pouvait être risquée, parce que ça veut dire qu'il fallait vraiment que j'aille déjà fait une première passe de revue. Là déjà, je vais pouvoir l'automatiser en lui disant, tu me fais tout ça. Et puis déjà si on passe pas le test qui a été donné dans un premier issue. Ça corrige pas le problème je vais pas, plus loin surtout qu'on a je crois que t'as eu la discussion dans un podcast je m'en disais pas avec Sébastien Deleuze où vous parliez de l'AI slope et de l'overhead qu'il y a sur le nombre d'issues enfin de PR notamment de pull requests qui sont ouvertes sur les projets open source, on en souffre aussi parce qu'on est un projet open source visible et comme il dit, les gens ont envie d'avoir leur nom dans la liste exactement et donc du coup on a plein de trucs comme ça qui sont balancés et tous ces trucs là ça nous permet, de limiter un peu cet effet, mais les sandbox, un autre cas d'usage que je vois c'est t'es en train de rechercher un nouveau boulot, on te demande d'aller installer un logiciel parce que tu vas travailler dessus on a eu des cas où des gens se sont pleins en disant je me suis fait avoir c'est une arnaque, le logiciel en fait il est allé liant mes clés SSH elles sont parties machin, lis les clés SSH de la VM il n'y a pas de problème il n'y en a pas dedans ça peut être ça quand on te demande d'exécuter un code que tu ne connais absolument pas pas de problème tu ouvres la sandbox vide et puis tu dis fais moi qui te clone de ça et.
Bruno:
Tu le fais de manière plus sécurisée.
Guillaume:
Ouais, c'est ça.
Bruno:
En ce moment, on voit beaucoup de boîtes aussi annoncer un tas de chiffres en disant, nous, on a X% de notre code qui est écrit par des IA et autres. C'est toujours intéressant quand on reçoit des grands noms, effectivement, comme Docker. C'est quoi la philosophie aujourd'hui chez Docker sur l'écriture du code ? C'est-à-dire que vous êtes tous...
Guillaume:
Ouais, il faut qu'on utilise des agents de code, clairement. Juste.
Bruno:
Parce que du coup tu as utilisé le terme il faut Vous avez tous vraiment Un incentive très fort et presque une obligation A le faire ou c'est juste qu'en fait Comme vous êtes nombreux à le faire Et vu ce que les gens font en fait si tu veux juste tenir.
Guillaume:
Le récit Je pense pas qu'on ait quelque chose De formel décrit quelque part, On a souvent des messages qui nous disent Augmentez votre usage Augmentez votre usage Donc il y a quand même Un mouvement dans ce sens là, Moi je l'utilise donc je ne peux pas te dire si ceux qui ne l'utilisent pas se font tirer les oreilles ou pas, autour de moi je n'ai pas d'ingénieur qui ne l'utilise pas il.
Bruno:
N'y a pas de récalcitrant il n'y a pas de...
Guillaume:
Non parce que, on travaille sur des outils à destination des développeurs donc il faut qu'on, comprenne comment ça fonctionne qu'on les utilise pour qu'on puisse derrière adresser, les futurs cas d'usage en fait donc on est obligé d'y aller on a intégré dans Compose le support des modèles il n'y a pas longtemps donc si tu as des modèles qui tournent en locaux tu peux les définir dans Compose ça va les injecter dans les services qui en ont besoin et du coup tes conteneurs vont avoir accès au LLM, ils vont pouvoir discuter on a la possibilité d'avoir une MCP Gateway qui est définie dans du Compose, pour faire tout ça, il faut qu'on joue avec qu'on travaille avec qu'on soit des utilisateurs pour comprendre les besoins qu'il va y avoir à adresser derrière. Donc... Il faut être curieux. Je suis toujours, toi, entre les deux, en me disant c'est génial, on peut faire des trucs super. Et j'en ai vu tellement de merde à côté, toi, aussi. Oui, mais si c'est pour faire ça, fais pas, quoi, au fait. Ma plus grosse crainte, là, c'est cette course à la productivité. Et je dis bien productivité plutôt qu'à l'efficience. c'est à dire qu'on va shipper des features dont les utilisateurs n'ont absolument pas besoin qu'il va falloir maintenir qui sont des fois pas pensées en termes d'architecture, mis dans le code de manière un peu, ouais bon là la feature c'est bon puis dans 6 mois ça va péter ça va être à cause du truc qui est là et que personne utilise et si on ne l'avait pas shippé en fait on serait mieux donc. Je pense qu'on est tous en train de découvrir un peu et les usages, par la pratique on a déjà vu des bons côtés on a déjà vu des mauvais côtés comment est-ce qu'on fait pour s'assurer que les mauvais côtés on les a moins on fasse en sorte qu'ils soient moins présents, Je ne peux pas te dire. On a quand même des gens qui débarquent, ouvrent des PR, et puis quand on va voir leur profil, ils ont ouvert 55 PR dans la journée sur 15 projets open source qui n'ont absolument rien à voir entre eux. En face, tu as aussi des gens qui font des fermes de bottes pour avoir leur nom sur les projets. Est-ce que.
Bruno:
Tu as une idée De la proportion de code Chez Docker.
Guillaume:
Absolument pas Je ne peux pas te dire Je ne sais pas si les chiffres sont monitorés, Et sur toi individuellement.
Bruno:
C'est quoi tu penses la proportion de code Que tu écris encore à la main.
Guillaume:
J'écris plus de code à la main, Par contre je connais Très bien mon projet donc en fait je sais exactement ce que je demande à mon agent et que tant que ça a pas atteint, ce que je veux alors si quand je suis vraiment très proche et qu'il y a vraiment juste 3-4 trucs à faire je vais les faire parce que je vais aller plus vite puis je vais pas consommer de la ressource juste pour dire allez je vais me changer les 3 trucs là que je peux changer moi immédiatement mais, ouais non je vais aller direct ça fait longtemps que j'ai pas eu alors je pense si des corrections de typos des, des trucs assez obvious dans le code là c'est pas la condition sur le livre c'est pas la bonne elle a inversé, tous ces trucs là qui vont me prendre moins de temps en fait est-ce que je vais aller plus vite à le faire moi-même que voilà mais sinon ouais beaucoup, et puis pas que pour pas que pour écrire le code pour la revue euh.
Bruno:
Mais du coup, toujours, toi, tu gardes cette logique de, il faut que tu sois capable d'expliquer le code qui a été généré.
Guillaume:
Oui. Ah oui, oui. C'est important que je comprenne le code qui a été généré. Alors, je sais que je ne suis plus tout seul parce que j'en ai discuté avec d'autres. Je fais partie de ces gens qui... Je ne peux pas travailler sur plusieurs instances. J'ai du mal à travailler sur plusieurs instances en même temps. C'est-à-dire que si je lance... Nous, on travaille avec Cloud. Si je lance une instance de Cloud sur la feature que je suis en train de développer sur Compose ou du bug fix que je suis en train de faire, ce que je vais faire avec une autre instance, ça va être quelque chose du genre de l'expérimentation, des choses où j'ai pas besoin d'aller voir ce qui se passe en fait parce que je regarde en fait ce qu'il est en train de faire l'agent et je l'interromps en plein milieu de ce qu'il est en train de faire en disant, je connais assez bien, tu pars pas dans la bonne direction c'est ça, oups j'ai oublié de te donner ça qui va changer complètement la manière dont tu vas interpréter donc je suis, assez intrusif dans la manière dont il fonctionne, je vais venir l'embêter c'est peut-être trop souvent, mais au moins, de mon point de vue, j'arrive à avoir du code, Qui aurait pu être celui que j'aurais shippé.
Bruno:
Canon, merci beaucoup Guillaume pour cette discussion. J'aurais deux dernières questions pour toi, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu voudrais partager avec l'ensemble des auditeuristes ?
Guillaume:
Oui, je voudrais... On a fait le compilé sur la souveraineté. Je voudrais revenir sur un sujet qui... Un point de vue qui est intéressant. Qui est fait par éventuellement Coding, mince j'ai perdu, Hugo Lassiège, son blog post. Où c'est des sujets qui commencent pas mal à adresser sur la souveraineté d'un point de vue plus géopolitique, pour le coup. Parce que je pense qu'il faut qu'on retire nos œillères de développeurs où on ne fait que du code. Non, on fait du code dans un écosystème qui est plus large. Il a fait une session à Devox sur le truc qui devrait bientôt sortir. Et donc, ma deuxième recommandation, c'est la chaîne YouTube de Devox France parce qu'on est le 6 mai. Ça devrait vraiment pas tarder à sortir les vidéos de toutes les conférences. Donc, voilà. Et en plus, continuez à suivre cette chaîne sur l'année parce qu'Emmanuel Bernard a fait tout un tas d'interviews avec les speakers qui étaient là et tout. Ils vont les faire paraître au fur et à mesure de l'année. donc vous allez avoir un contenu récurrent en plus de celui-ci pour votre veille techno voilà.
Bruno:
Canon en plus je pense que le temps que cet épisode sorte à mon avis le contenu sera déjà disponible sur D-Roc donc effectivement allez jeter un tour ce sera forcément et notamment.
Guillaume:
La conférence d'Hugo sur la souveraineté.
Bruno:
Canon dernière question qui est la plus importante de ce podcast Guillaume est-ce que tu es plutôt espace ou tabulation ?
Guillaume:
La question ne se pose pas pour moi d'accord alors pas parce que j'utilise l'IA mais parce que je fais du go et que c'est l'inter qui l'impose voilà si je donne ma réponse à titre perso espace mais configuration par tabulation dans l'idée en fait comme ça, Le meilleur des deux mondes.
Bruno:
C'est propre. Très bien. Merci beaucoup, Guillaume.
Guillaume:
De rien. Merci à toi.
Bruno:
Merci à tous d'avoir su cet épisode. J'espère que... Alors, si vous ne connaissiez pas Docker, à mon avis, ça vous a donné une bonne idée des choses. Si vous connaissiez déjà Docker, je pense que ça vous a donné envie de tester aussi Sandbox, qui je pense que c'est un projet intéressant parce qu'on a effectivement des usages de création de code qui changent. Donc, autant avoir des outils qui nous permettent d'explorer les choses en toute sécurité. Et Dieu sait que c'est important parce qu'effectivement, il y a eu trop d'histoires, qui ont un petit peu dérapé. De mon côté, je vous remercie toujours de partager ce podcast autour de vous. N'hésitez pas à aller checker en description de cet épisode pour aller essayer le MCP, DiffTTD, ce qui vous permet aussi de rendre votre cloud code, votre curseur encore meilleur et tout le savoir qui a été partagé par Guillaume mais aussi par d'autres dans ce podcast. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien.
