 Bonjour tout le monde. En voyant l'appel à propositions de Python, il y avait plusieurs durées de temps, dont le 10 minutes. Je me suis dit en 10 minutes, ça serait intéressant en français de répondre clairement aux questions que beaucoup peuvent encore avoir. Qu'est-ce que c'est les containers ? Les containers, à quoi ça sert, et ainsi de suite. Beaucoup vont déjà connaître ça, mais peut-être qu'un des liens que je vais avoir, une façon d'écrire, sera utile à communiquer à d'autres personnes, que ce soit des nouvelles collègues ou des managers, décideurs, gestionnaires, ou je veux dire que c'est des personnels. J'ai un peu moins d'une minute par point, donc je vais y aller tout de suite. Je ne sais pas m'interrompre si je ne suis pas clair, par contre les questions seront à la fin. Je travaille chez Caravan, pour regarder notre site, notre portfolio. On a un tas de métiers différents, de designers, aux développeurs, intégrateurs, administrateurs et systèmes ainsi de suite. On est partenaires de Python, tout ça qu'on se motive à soumettre quatre ou cinq talks, puis à voir celui qui a été pris. Celui-ci a été pris. On fait Django, Pyramid et ainsi de suite, plein de types de sites différents. On va commencer directement par la question numéro 1, à quoi ça sert, avant de dire qu'est-ce que c'est ou comment ça fonctionne. À quoi sert un container ? Pourquoi tous les déploiements de serveurs utilisent des containers ? Pourquoi les gens parlent que nos laptops bientôt auront des containers, nos téléphones vont être mis à jour par des containers, les Arduino qu'on a dans nos robots ou dans les ampoules du salon vont avoir des containers. C'est partout, mais à quoi ça sert ? Pourquoi cette technologie qui a émergé depuis à peu près quatre ans ? Le but principal, c'est ça. Si vous déployez sur un serveur que vous contrôlez entièrement, le Bermittal fait que c'est un serveur sur lequel vous connectez à distance par SSH, ça prend du temps à mettre en place, ça vous prend des heures à déployer une nouvelle version de votre application, ou ça peut prendre des minutes si vous l'avez automatisé, et puis ça prend plusieurs minutes pour que ça démarre. Il y a le petit moteur qui démarre, si on utilise Django, il faut préparer, installer les dépendances, collecter fiers statiques, connecter à la base de données, faire les migrations, puis après plusieurs minutes, le site est prêt. Pendant ce temps-là, peut-être que vous avez dû éteindre le site, le mettre en maintenance et puis au bout de plusieurs minutes, il est prêt à être utilisé à une nouvelle version. Le but des containers, qui sont la troisième colonne en bas, c'est que ça prenne juste quelques minutes de préparer une nouvelle version et puis des secondes ou moins d'une seconde à démarrer une evaluation du programme. Si vous voulez avoir dix instances de votre site web qui sont prêtes à avoir des milles de requêtes par seconde pour chacune de ces dix instances, si vous avez dix serveurs, ça fait dix serveurs à acheter, à brancher ainsi de suite. Si vous avez dix machines virtuelles chez DigitalOcean, cette dix machines virtuelles à acheter, à louer, à préparer ainsi de suite, si vous avez dix containers, ça prend une seule machine virtuelle, un seul serveur qui les héberge, qui les démarre et chacun de ces dix versions de votre serveur démarre en quelques secondes. C'est ça le but. Il y a moins d'automatisation pour démarrer un container qui contient un programme qu'une machine virtuelle ou une machine complète qui sert à faire ça. Ça prend moins de ressources, moins de taille sur le disque dur, ou le disque n'importe comment il est. Ça prend moins de ressources processeurs et moins de mémoire pour avoir ces dix programmes côte à côte. Quand je dis dix programmes, ça peut être 100 programmes. Si vous achetez une instance de DigitalOcean, vous payez 20 ou 30 dollars par mois pour héberger peut-être deux, trois sites et une base de données, vous pouvez avoir un petit nombre dans les dizaines de machines virtuelles. C'est avec ça que vous déployez. Vous déployez en container, vous pouvez en avoir mille sans vous inquiéter, sans que le processeur soit à 100% utilisation tout le temps. C'est ça qui explique la montée des microservices. Vous devez faire une application qui est un serveur, une application Django. Il y en a dix côte à côte. Ça sert à faire les images. C'est un microservice qui se connecte à Twitter. C'est un microservice qui gère autre chose. Tout ce découpage dont on parle, il est permis grâce à cette technologie. Ça explique les sandbox qu'on voit partout. Si vous utilisez les notebooks de Jupyter, qui s'appelait IPiPhone avant, comment c'est possible que je clique sur Jupyter Hub, je fais démarrer en fork de ce notebook, je le modifie puis il démarre. Je pourrais faire une boucle infinie puis planter le serveur. Non, parce que mon notebook Jupyter s'exécute dans un container. Pareil, si vous utilisez Travis CI, c'est un outil d'hiver qui installe vos dépendances et qui roule vos tests. Tout ça roule dans des containers pour être certain de sandboxer que si un tel prend des heures et des heures et toute la mémoire a démarré, il ne va pas vraiment bloquer le serveur physique, mais il va utiliser les ressources qui lui sont données limitées dans un container. C'est utilisé chez Netflix et Twitter, Facebook. Toutes ces compagnies ont besoin de justement avoir des milliers de serveurs qui sont capables de traiter les millions de requêtes par seconde. C'est aussi utile en local. J'en parlais plus tard pour avoir une copie exacte. Si vous avez un problème qui arrive que sur notre serveur en production, vous dites qu'il y a tels settings qui sont différents de ma copie locale sur laquelle je travaille, il y a tels dépendances de paquets qui ne sont pas exactement pareils. Avec les containers, vous avez des outils, vous pouvez avoir exactement les mêmes données et les mêmes logiciels dans votre workflow local. Deuxième question, un container, qu'est-ce que c'est ? Qu'est-ce que c'est réellement ? Ce qu'il faut savoir, c'est qu'un container, c'est pas vraiment un objet. Dans le sens où pour le noyau Linux, pour votre ordinateur, un socket, c'est un objet. C'est quelque chose qui est écrit par un appel système sur lequel on écrit. Un socket, par exemple, qui me sert à recevoir un flux vidéo, c'est un objet dans le noyau qui a une famille de fonctions pour écrire ou lire des octets depuis. Un container, c'est pas un objet. C'est le mélange d'un système de fichiers qui est isolé, un peu comme un chroute. C'est un mélange de namespace. Dire que l'ordinateur dit au container, il y a un seul user, son ID est mille, puis t'as pas à savoir qu'il y en a d'autres qui existent. Il va dire au container, il y a un CPU, tu peux l'utiliser à 100%, alors que la vraie machine a peut-être 4 CPUs ou 132 CPUs, mais les namespace sont une limitation des données réelles, des ressources diverses, fait que le container ne peut pas tout utiliser des ressources de l'ordinateur. Puis s'il y a un container qui est utilisé pour ce qu'elle est donnée de quelqu'un, un autre container qui sert à faire autre chose n'a pas accès à ses fichiers. Pour être plus précis, un container, c'est un processus qui roule avec un file système dédié qui est contrôlé par des namespace et des C-groups. Tout ça, c'est des features diverses du noyau. Les C-groups, c'est des contrôles groupes. Ça limite ce que le container peut utiliser. Je disais mon exemple, un processeur sur 4. Les namespace, c'est plutôt ce que le container voit. Je peux très bien avoir 10 bases de données côte à côte. Chacune pense qu'elle a le port 5.4.2, mais en fait, à l'intérieur du container, c'est le port 5.4.2, puis à l'extérieur, c'est un autre port. Ça, il n'y a pas de conflit. Je peux très bien avoir 10 bases de données post-grès SQL qui ont 10 versions différentes. Je travaille sur 10 projets qui n'ont pas les mêmes besoins. Je n'ai pas besoin de changer la configuration. Avec des containers, je peux démarrer mes 10 versions. Chacune pense qu'elle possède le port 5.4.2. Le graphique, si vous pouvez lire du fond, vous voyez que la petite baleine, ça représente Docker. Il y a un engin qui fait ce que je disais, qui fait démarrer le processus en l'isolant puis en lui prétendant une version tronquée du monde. Dans ce container, il y a un file system, par exemple, il y a USR, BIN, Python qui peut être dans ce container et Python 3.6. Ça n'a aucun importe le fait que sur ma machine, si j'avais, par exemple, des tests il y a deux semaines, je ne peux pas avoir Python 3.6. Il n'y a que 3.5 et puis on attend que 3.6 arrive. Ce n'est pas exactement vrai. 3.6 était là, mais pas la version par défaut. Dans le container, je peux très bien faire que USR, BIN, Python 3 plutôt sa pointe vers Python 3.6. Ça n'a aucun rapport que sur ma machine, j'ai aussi un slash USR, BIN, Python qui va être autre chose. Puis le petit dessin sur le côté, c'est un volume. Dans le container, c'est les fichiers qu'on lit. User, BIN, Python va lire UserLib, LibPython qui va aller lire UserLib, CTypes, SSL ainsi de suite. Dans le container, j'ai une copie de la LibSS, la LibCurse, la LibC ainsi de suite qui peut être différente. Encore une fois, d'un container à l'autre, j'ai des binaires, User, BIN, Python. Je vais peut-être avoir BIN, BASH, mais peut-être pas. Je n'aurai peut-être que DASH. Puis pour écrire des fichiers, pour sauvegarder les images, si c'est mon serveur web ou n'importe quoi, l'engin Docker démarre le container et démarre un volume qui a un espace de stockage en lecture et en écriture. Question suivante, qu'est-ce qu'une image ? Dès que vous rentrez dans les tutoriels ou la documentation de celle de Docker, on vous dit qu'on parle des containers tout le temps. Les containers, c'est le processus qui tourne, mais on le crée depuis une image. L'analogie, c'est qu'une image, c'est comme une classe Python. Ça définit qu'est-ce que j'ai dans mon container ? Qu'est-ce qui doit se passer quand je le démarre ? Et puis, le container, c'est une instance de cette classe. Fait que les images Docker fonctionnent avec des layers. Fait que si par exemple, ma machine, je dis, OK, à part, je vais faire, je voudrais une image qui est PostgreSQL, une image qui est Python. Puis, les deux se connectent. Mon image de base va être peut-être Ubuntu, une certaine version. Puis, ça me donne un container. Fait que je peux démarrer un container avec Ubuntu. Puis, j'ajoute par-dessus les paquets nécessaires à Postgre. Ça me donne une autre image qui est celle de Postgre. À côté de ça, je peux faire une autre image en partant d'Ubuntu. J'ajoute ce qu'il faut pour avoir, puis ton 3.6, de disponible. Puis ensuite, avec Docker, je peux dire, démarre un container depuis l'image Postgre. Là, j'ai accès à tous les binaires de Postgre SQL. Démarre un autre container qui peut voir le port de Postgre pour se connecter. Cet autre container, lui, contient les outils Python. Puis, en local, vous avez beaucoup d'informations dans la décommenacation de Docker. J'ai pas deux fois tout le poids d'Ubuntu. Mais Docker, un système de stockage fait qu'il va stocker une seule fois les fichiers nécessaires au Ubuntu de base. Puis, juste le diff nécessaire à avoir une image Postgre, puis le diff qui donne une image Python. Il y a beaucoup d'analogés avec Git. C'est le type que vous utilisez. Puis, il y a une façon contre les images que j'ai pas le temps d'aborder, qui mériterait son propre dix points sur les images Docker. Mais c'est ça l'idée. Avec le plus important, un container est un processus avec de l'isolation. Et une image, c'est une description de ce que contient ce processus. J'ai déjà dépassé les dix minutes. Ce n'est pas une de mes questions pour aujourd'hui. Ce n'est vraiment pas beaucoup de temps d'avoir 50 secondes sur chacune de ces questions. Peut-être qu'il y en a que je mettrai plus importante que d'autres ou d'un état qui ne gérerait pas. Je vous laisserai regarder mes slides. Ça montre le rapport entre image et container. Question. Finalement, vous pouvez me dire qu'un container, c'est comme une VM. Peut-être qu'en local, quand vous arrivez dans une compagnie, on vous dit pour travailler sur nos projets, on utilise Vagrant. Vagrant a une configuration standard dans notre compagnie. Ça t'installe l'idée qu'on utilise, les outils de développement, des buggers ainsi de suite. Et puis comme ça, tout le monde a le même baseline. Certains peuvent penser, finalement, un container, c'est une autre façon de faire une machine virtuelle. Puis, vous pouvez être habitué à voir des pipelines de déploiement qui créent une machine virtuelle et qui la mettent sur les serveurs. De cœur, ça paraît pareil. Il y a une grande différence technique, une grande différence d'usage. Une différence technique est ici. Une VM, c'est extrêmement lourd. Je disais tantôt que peut-être que vous en avez 10 sur votre salaire DigitalOcean. C'est beaucoup. Sur mon petit laptop, j'aimerais pas en avoir deux en même temps, par exemple. J'aimerais pas avoir une VM pour Postgreep, une VM pour développer. Ce serait lourd par rapport aux ressources que j'ai. Le graphique explique que la machine virtuelle, c'est un logiciel qui prétend qu'il est un matériel. Il doit répondre aux appels bas niveau, le 10 qui a donné des octets, le réseau s'est réveillé, l'écran a fait ceci, cela. Par contre, un container, il ne contient pas un OS complet. Si je démarre de machine virtuelle, il y a mon OS qui est débian, qui va démarrer l'OS qui est au bout de tout, 100% puis démarrer les processus dedans. Si je veux faire un jeu, je vais démarrer une machine virtuelle Windows qui va aussi prendre des gigas et des gigas de mémoire et de beaucoup de ressources processeurs. Un container, il y a le Noyulinux, ce qui implémente les éléments de base dont je parlais tantôt, les namespace et puis les six groups. Puis l'engin Docker, il fait juste rendre user-friendly les fonctionnalités du Noyulinux. L'engin Docker, il se dit, on m'a demandé de démarrer un container pose gré, un container piton. Cela prend très peu de mémoire et cela ne fait pas d'émulation d'un OS complet. Mais le plus important, c'est que ça n'a pas le même but. Vous pourriez techniquement faire un container qui contient un démon SSH, le server web Apache ou nGNX et le server piton et le server pose gré. Ce n'est pas prévu pour, puis les outils vont se battre contre vous. Le but d'un container, c'est de rouler un processus. Si vous voulez avoir quatre choses différentes, il faudra quatre containers. Cela prend d'avoir de l'outillage pour que ce soit gérable ensuite. Mais il y a des images qui existent, qui vous disent utiliser cette image de base pour faire vos propres images Docker qui sont extrêmement lourdes, qui contiennent un OS complet. Ce n'est pas le but des containers. Je parlerai plus tard comment répondre à ce problème de développement avec ça. Je voulais dire, en bref, c'est plus léger. Une VM est censée être un OS complet qui va avoir plein de programmes. Un container est censé être un processus unique, mais qui peut être lié à d'autres. Un point bref sur les formats. On tombe vite sur des images comme ça. Il y a plein de formats de containers, plein de formats d'images. Même, je vais donner l'exemple tantôt, démarrer un container Postgre qui pense qu'il apporte 5.4.3.2. Un autre container qui est mon application qu'utilise Python. Comment cette application-là peut se connecter au port 5.4.2 à l'intérieur de l'autre container? C'est ce que fait entre autres l'engin Docker. Il y a des outils comme Docker Compose ou sur Amazon Web Services, vous pouvez faire ça. Vous pouvez dire, démarrer plusieurs containers puis linkler entre eux. Il faut que celui-ci accéde au port de celui-là. Il y a plein de formats. Vous posez la question du lock-in. Dites-vous que si je vais dans tous les outils Docker, Docker, Docker Swarm, Docker Compose et ainsi de suite, je ne profite pas de cet autre outil où je n'aurai pas le choix de prendre autre chose. Je ne veux pas que vous voyez tout. C'est plus un exemple de tout ce qui existe. Je ne peux pas aller plus loin pour le moment. Comment fonctionne Docker? En local ou sur votre serveur, ce qui est intéressant, c'est des choses qui ne changent pas. Vous avez toujours votre choix de ces rack space qui fait notre hébergement, où c'est DigitalOcean, où c'est notre infrastructure OpenStack. Ça, ça ne change pas. La seule différence, c'est quoi le livrable? Qu'est-ce qu'on déplace de la machine de développement, de la machine de tests et de la machine de production? Lorsque ce soit une VM, un paquet d'heb, un RPM, un virtual Env dans une tarballe ou que sèche d'autre, format d'échange devient une image. Par rapport à celle précédente, elle n'est peu importe si c'est une image, format Docker, format OCI ou autre. Il y a des outils qui permettent de les convertir de l'une à l'autre. C'est des gens qui compétitionnent, des compagnies qui sont en compétition, mais qui font en sorte que leurs outils puissent être convertis d'un format à l'autre. L'infrastructure ne change pas et le host OS ne change pas. Si vous avez une expertise avec déployer des biens et le sécuriser et puis facilement partir un nouveau serveur en deux minutes, vous gardez ça, le seul différence c'est qu'au lieu de faire un guide clone puis démarrer un process Python, vous allez installer une image Docker et puis partir un container. Après, vous pourriez vous dire qu'il y a des OS qui sont faits exprès pour ça. Il n'y a qu'un OS qui est spécifique à une base minimum qui s'est roulé des containers. Il y a Red Hat qui fait projet atomique. Ça peut être des choses intéressantes. Là, vous voyez à gauche un exemple fait que Docker, il y a un client. Ça peut être Docker ma commande en ligne de commande ou ça peut être un script en Python. C'est des clients qui parlent à la paix de Docker qui ont jeté TP. Puis, il y a un serveur en local qui roule les containers. Je vais passer à la suivante. Donc Docker, la sécurité. Si vous souvenez de la slide sur container qu'on tient un file système, j'ai dit par exemple, mon container Python, il va avoir l'IBSSL puis mon container Postgre aussi, qu'est-ce qui se passe quand il y a Heartbleed? Comment je sais si tout d'un coup je suis heureux que j'ai 10 containers qui hébergent mes services? Comment je peux savoir si mes services sont vulnérables? Si j'ai construit mon image il y a 2 mois puis que la l'IBSSL a une mise à jour de sécurité cette semaine, premièrement, comment j'inspecte? Avant, j'allais sur mes machines en SSH puis je roulais une commande pour savoir est-ce que la version installée est susceptible et vulnérable au bug? On a besoin d'automatisation quelque part. Ceci nous force à automatiser. On ne peut plus avoir d'opérations manuelles. Je peux plus aller sur mes serveurs en SSH puis taper une commande parce que mon serveur est l'autre de 10 containers ou 100 containers. Ça nous force à utiliser des choses qui sont des bonnes pratiques qui sont d'avoir des outils de contrôle d'orchestration qui permettent sur mes 100 instances d'avoir une réponse immédiatement quelle version sont installées. Et puis ça fait aussi que on ne peut pas créer les images à la main. Il faut pouvoir facilement dire idéalement dans chaque compagnie il faudrait faire une pipeline où je change mon image de base pour la l'IBSSL avec la version mise à jour et puis il faudrait que ça reconstruise toutes les images pour faire des plots to the container. Par contre, les containers nous donnent une surface d'attaque réduite. Puisqu'ils étaient tantôt ils ont un port qui est ouvert et ce port par exemple, il est accessible uniquement aux autres containers, c'est la même machine. Fait que si j'ai un container secondaire qui me sert juste à faire mon traitement d'image faire les miniatures et puis les traitements en version de gris ainsi de suite pour mon service, mon forum j'ai un container qui fait juste le traitement d'image. Si quelqu'un rentre dans une faille puis se retrouve dans le container il n'aura aucun accès à ma base de données. Par contre, si quelqu'un rentre dans mon container qui est mon appris web comme l'appris web a un accès au container de base de données l'attaquant aurait le même accès. Mais il y a un tas de choses permises par les containers qui sont de monter le code source en lecture seule donc on oublie les attaques d'écriture de code des fichiers spéciaux comme Slash 6 Slash Proc sont en lecture seule pour utiliser des failles de shell pour contrôler les paramètres du noyau Il n'y a pas non plus d'accès aux répertoires des développeurs sur les machines sur les serveurs si vous avez des comptes puis des clés SSH des outils de développement les containers ont des accès et des permissions très limitées. Il y a des choses intégrées des configs et groups que les administrateurs systèmes connaissent comme SELinux ou apparemment puis des choses qui sont des features sont aussi des faiblesses j'en parlerai dans quelques slides j'ai évoqué cette question comment déployer, fait que là on a compris container est un processus il est créé depuis une image cette image je peux la créer localement où je peux suivre la documentation de Travis CI qui m'indique à partir de mon code source qui est un déput guide avec du piton je regarde la documentation du docker file ça me dit comment faire je vais créer un environnement piton installer mes dépendances et préparer mon app qu'est-ce que je fais de cette image encore une fois vous n'avez pas forcément besoin de tout changer vous aviez sans doute une pipeline avant qui était peut-être comme mon code est comité si les tests passent sur la branche d'Ev je l'envoie avec Ersync je l'envoie avec Geeklone, je l'envoie avec TAR puis vous vous remplacez une étape à la fois de dire je veux construire une image envoyer l'image sur le serveur puis démarrer un container tout de suite d'aller dans les outils d'orchestration très puissant mais très compliqué il y a Mezos qui est développé par Twitter et d'autres compagnie il y a Kubernetes qui est produit par les gens de Google à base maintenant par beaucoup de compagnie mon expérience c'est que c'est pas obligatoire si j'ai besoin d'un serveur dans ma première semaine pour démontrer le site à mon client je n'ai pas oublié d'investir tout de suite dans tous ces outils je peux très bien avoir une partie de mon déploiement que j'avais avant puis juste changer le qu'est-ce que je démarre dans un sessus comme ça ouvert à tout mais je démarre dans un container ça c'est un graphique avec un article intéressant où il y a plusieurs serveurs, tests et productions je pourrais vous laisser le consulter vous-même j'ai évoqué tantôt différents projets, différentes compagnie Docker a été critiqué au niveau technique le démon Docker quand vous tapez Docker Run c'est un petit client de la docomonde qui parle à un démon le Docker 2 qui roule sur la machine puis lui il roule comme route et c'est tout faire il s'est téléchargé une image du registre des images Docker, il s'est envoyé une image il s'est construit une image, il s'est démarré un container c'est beaucoup de responsabilité des gens ont créé CoreOS que l'OS que j'avais évoqué qui est spécialisé pour les containers, puis eux c'est un autre format qui s'appelle Rocket ils ont critiqué le fait que c'est un démon qui fait tout c'est pas une bonne chose technique de leur point de vue puis CoreOS utilise plusieurs composants séparés il y a aussi une critique d'organisation Docker c'est un format d'image un format de container et un format de lien entre plusieurs containers et un format pour contrôler des machines distantes qui ont des containers des compagnies comme Red Hat on dit peut-être on veut pas être 100% lié à une seule compagnie qui contrôle tout Docker peut être une très bonne runtime pour rouler un container mais on veut autre chose qui fasse la connexion à distance sur les serveurs ou autre chose qui fasse l'orchestration Google a bien réagi en extraitant des components fait que maintenant il n'y a plus juste Docker mais il y a le projet Mobi qui est une liste de composants réutilisables pour y écrire votre infrastructure qui a des besoins spécialisés qui utilisent pas Docker tel quel et puis il y a des choses qui sont partagées entre différents concurrents il y a aussi l'intégration native entre Kubernetes qui a un outil FAR pour orchestrer et Docker qui a des outils de conversion de format d'un à l'autre les concepts sont plus importants que les outils puis Docker la vraie révolution c'est plus ce que ça nous permet de faire puis on a une assurance que cette version si cette image a passé sur le savoir de test j'en vois exactement la même chose en production je fais pas une nouvelle installation un nouveau build l'image Docker contient toutes les librairies nécessaires les librairies libres, les librairies en piton c'est que le même artefact se retrouve exactement déployé de mon savoir de test à mon savoir de production puis ça nous force à automatiser la release, les mises à jour et ainsi de suite avoir des outils pour se dire quelle version roule sur tous mes containers fait que ça c'est intéressant de rentrer dans ces outils-là puis si Docker tourne vraiment évol ce sera pas un comment difficile de passer un autre format comment débuguer fait que ce que je voulais dire c'est qu'en local vous n'êtes pas obligé de tout changer c'est intéressant d'avoir des containers en local mais moi par exemple j'utilise pour avoir une version de base de données qui me convient postgres avec extension géospatiale telle version mais si vous avez des façons de faire façon habituelle que ce soit vagrant ou virtuelant vous n'importe quoi vous êtes allé, vous avez vos outils je trouve qu'il n'y a pas besoin de changer le mode local on peut avoir les outils qui sont pratiques où on tombe dans un debugger on peut avoir notre terminal si on a une exception et puis on peut très bien avoir les containers qui sont développés même dans les plus grandes compagnies par une équipe spécialisée juste pour les déploiements par contre si on a des containers sur les serveurs et là qu'on veut debugger de quoi je reviens sur l'idée de Tanto si vous avez une machine virtuelle elle contient Bache, SSH, un tas d'outils divers mais si vous avez un container qui contient uniquement Python 3.6 il n'y a même pas S-Trace j'ai même pas l'outil pour inspecter les appels système que fait un programme si je veux débuguer des trucs fins d'import j'ai même pas l'outil puis la réponse de Docker à ça c'est plus de container donc j'ai mon premier container qui est mon application qui est mon application Python je peux très bien démarrer un deuxième container par exemple se connecter au namespace cpu au namespace process de l'autre et là je vous laisse stress je peux démarrer un deuxième container et puis demander à l'engin de Docker branche-le sur le même namespace de réseau et au lieu de se dire que je suis dans une VM il faut que j'ai tous mes outils ils sont accessibles par les containers roulés par le même engin donc c'est une faiblesse parce que c'est un point d'entrée mais en fait c'est une feature il y a un bon article que j'ai en lien qui dit qu'on peut pas prendre un point fort de machine virtuelle et l'appliquer en critique au container puis il y a beaucoup d'autres choses que je pourrais dire au lieu de dire comment je vais sur la machine voir les logs, faites un système envoyer quelque part, qui est plus facile à consulter au lieu de dire comment je peux tomber dans un debugger si j'ai pas un vrai terminal utiliser un remote debugger comme celui qui est dans Celery en offre 1 ou d'autres projets en nom il y a les debuggers intégrés dans les stacktrace des frameworks comme le Verkstoy debugger et le Dingo donc il y a toujours des solutions des fois comme oublier un peu comment on faisait mais on peut trouver un outil équivalent qui vous permet de pas compromettre votre belle infrastructure en container je m'arrête maintenant ça c'est des personnes intéressantes qui ont écrit plein de beaux articles ça c'est des références pour la plupart des slides désolé du temps que ça a pris s'il y avait une question il y aurait le temps mais c'est parfait je serai au Benelux si vous voulez développer certains des points merci