Bonjour à toi chers compagnons et bienvenue dans ce nouvel épisode de Radio DevOps, déjà
le 9ème épisode et aujourd'hui c'est le nouveau format, on va faire uniquement un
épisode de Radio DevOps sur les actus, on a quand même pas mal parlé de contenter et de
Kubernetes donc on reste dans la thématique. Donc aujourd'hui je suis avec Erwan, bonjour Erwan,
bonsoir, Damir, bonsoir et Benoît qui est notre nouveau podcasteur qui nous rejoint.
Salut et donc on va parler des conteneurs, si vous avez écouté mon épisode solo vous devez
en savoir un petit peu plus si vous ne connaissiez pas avant et vous devez aussi savoir pourquoi
est-ce que vous devez les utiliser mais là la question qu'on va se poser c'est est-ce que
on doit les utiliser tout le temps jusqu'où, enfin bref on va discuter de plein de choses.
Donc évidemment vous avez dit conteneurs mais c'est quoi ? Le conteneur c'est quoi les principes de
base et justement Damir voulait nous parler de quelques principes de base et donc on va
l'écouter attentivement, on va écouter professeur Damir. Je vais essayer de vulgariser au maximum
sans perdre l'information essentielle. Donc globalement les conteneurs quand on en parle
aujourd'hui on s'imagine, on pense surtout à Docker, ce qu'il faut bien comprendre c'est que Docker
c'est assez récent et que globalement le Docker, le conteneur existait avant, je fais moi même
le lapsus c'est magnifique. Donc le conteneur existait bien avant ça et c'est quelque chose qui est
assez vieux dans l'informatique et il y a une commande alors Linux qui s'appelle chroute,
je veux dire change route qui permet de plus ou moins isoler un processus sur un système de
fichier, un système Linux en général en passant notamment par système de fichier vu que sous
Linux tout est fichier et globalement en fait c'est une première solution légère de conteneurs donc
c'est assez vieux et c'est apparu au siècle dernier comme quoi c'est pas Docker qui a tout inventé
et petit à petit en fait c'est devenu assez populaire sachant que le conteneur n'est pas une
VM mais pendant très longtemps jusqu'à Docker globalement faut bien comprendre que le conteneur
avait le cycle de vie d'une VM ou d'une machine en barre métal. Donc globalement vous créez votre
conteneur vous avez des volumes qui sont du coup sur stocker et vous allez la démarrer,
l'arrêter, ajouter des programmes dessus, vous allez faire un petit tapet à pt get des choses comme ça,
des choses que vous ne faites pas du coup sur Docker mais c'est bien pour montrer qu'il y a eu un
changement de paradigme aujourd'hui mais à la base en tout cas c'était assez proche au final
d'un cycle de vie d'une VM ou d'une machine en barre métal et petit à petit ça a évolué,
il y a eu plusieurs choses ça a été intégré au kernel Linux sous la forme d'un produit que vous
connaissez sûrement niveau conteneur qui est Alixé d'ailleurs c'est intéressant de savoir que
Docker au début se basé sur Alixé donc Docker était un warp, un wrapper Alixé et a ramené
juste un écosystème et après ils ont eu leur propre système donc ça c'est intéressant de voir
cette transition mais en tout cas au début c'était juste un système d'isoation de processus
qui avait globalement cycle de vie d'une VM ou d'un savoir barre métal mais qui n'en est pas un et
qui permettait d'être plus léger vu que vous n'avez pas émulé la partie du coup machine que vous
êtes obligé de faire dans une VM donc ça vous a porté un gain en performance et surtout
c'était un peu plus efficace on va dire ça vous forcez à être sur le même OS que l'OS Auto
je sais pas si c'est assez clair ou si il y a des choses à ajouter c'était très clair je pense et
d'ailleurs pour illustrer le fait que Docker c'est un écosystème en ce moment il y a un projet qui
commence à prendre un peu d'ampleur qui est très intéressant qui est enfin c'est plusieurs projets
mais qui sont plus ou moins tous baqués par Red Hat c'est Podman, Builda et Scopeo et alors
Podman c'est globalement le truc qui va permettre de lancer des conneurs et de les faire vivre
Builda c'est le truc qui va permettre de construire les images pour ensuite les donner à Podman et
Scopeo c'est le truc qui permet de manipuler les registres et les images stockées à distance
et ça est assez intéressant à creuser pour voir tout ce que fait Docker au final avec un seul
démon et un seul utilitaire et ça permet un peu de déconstruire la simple notion de conteneurs
avec ce que fait Docker en vrai et du coup la différence entre les deux. Podman là-dessus
est assez intéressant je pense c'est un produit qu'il faut suivre je vous invite vraiment je
mettrai en description il y a eu un très bon talk aux Fossed Em qui est de découvert de Podman et
j'ai fait moi même un meetup qui accessible en ligne sur Podman donc je donnerai le lien Christophe
pour les mettre dedans mais c'est un produit qui est effectivement intéressant à suivre et qui
peut permettre de donner une vraie alternative à Docker qui comporte certains soucis notamment
le fait que ce soit assez monolithique entre guillemets. Je pense qu'on pourra revenir justement ça dans
les limites des conteneurs et de Docker et j'ai prévu aussi de faire soit un podcast soit une vidéo
sur justement les limites qu'apporte avec le recul Docker même s'il a popularisé de manière
assez impressionnante les conteneurs. Moi je ne sais pas vous quand vous avez rencontré les
conteneurs la première fois mais moi c'était vraiment enfin j'avais utilisé chez H-Crew
avant je m'en rends un petit peu mais la présentation qu'avait fait Solomon Ix en 2013 j'ai tout
les conteneurs au travers Docker et avec la facilité qu'avait l'utilisation de Docker à l'époque
c'était vraiment c'était magique je sais pas si vous vous rappelez de ce moment là mais moi j'étais
devant YouTube je pense. Je serai un peu tatyant mais je dirais avec l'écosystème et avec la vision
de Docker et le paradigme de Docker qui est peut-être que t'as eu ça me reviendra dessus mais c'est
tout avec ça que la facilité je ne suis pas vraiment moi je pense c'est un peu différent en fait dans
l'idée. Moi pour info moi j'ai commencé le conteneur avec OpenVz il y a un petit bouton ça devait
être en 2011 ou un truc comme ça et j'ai commencé là dessus donc globalement on s'en servait comme
une VM même si c'est peut-être pas une VM mais on traité ça comme une VM en un peu plus light
entre guillemets donc c'était c'est pour ça que j'insiste sur la notion de différence entre les deux.
Justement je me demande quand je travaillais sous Yx si j'utilisais pas déjà des conteneurs
en pensant que c'était des VM à l'époque parce que j'avais pas bien saisi la différence c'est
possible en effet que ce soit OpenVz que j'ai utilisé après je l'ai utilisé très peu de temps donc mes
souvenirs sont un peu floues. Justement comme on parle de Docker on peut parler des apports de la
dockerisation de la comptorisation méthode Docker on va dire et tout ce qu'a apporté dans son
sillage Docker et les évolutions qu'on a connues alors qui veut commencer qui veut nous parler
de selon lui ce que nous a apporté Docker. Moi je sais pas trop par où commencer mais je pense
que le vrai game changer autour de Docker c'est un peu ce que commença à évoquer Damir c'est
l'écosystème il y a tellement d'outils pour faciliter les builds et les registries même si
t'as pas d'infra hyper ambitieuses les docker compose pour reproduire des infras.
Moi je me souviens que c'est quand j'ai expliqué Docker compose c'est là où je me suis dit
ah ouais mais en fait ça y est je peux avoir sur ma machine exactement un même truc comme la
prod en entre guillemets sans avoir installé 12 milliards de trucs sans avoir à me préoccuper
que les versions de ce que je pouvais avoir sur ma machine de dev pouvait différer avec les versions
de prod et pour moi c'est là dessus que Docker c'est là dessus pour moi que ça fait que ça a pris
autant et que c'est devenu un incontournable des équipes de développement et comme on parle beaucoup
dans ce podcast et sur le forum de la philosophie DevOps donc de ce lien de ce pont à créer entre
les équipes de dev et les obs et l'infra en général et en fait Docker c'est exactement ça c'est
un c'est le c'est vraiment un un langage que tout le monde sur ce pont parle et et ça ça
vraiment été je pense game changer c'est fini le moment où tu livrais des archives avec avec
un truc qui explique comment comment tu déploie enfin comment tu déploie comment tu installes
les paquets dont il a besoin maintenant tu fournis bah tu fournis juste un fichier qui correspond à
ton à ton de car file j'exagère mais vous voyez l'idée et et puis c'est fini et et ça c'est un
langage que tout le monde comprend et pour moi c'est c'est là dessus le qui est que Docker vraiment
a vraiment fait le switch et je sais pas si vous rejoignez ce point de vue benoît peut-être
si si complètement enfin c'est le moi aussi j'ai l'impression que c'est ça qui a fait que ça
était adopté aussi largement et c'est ça aussi l'intérêt c'est que ça simplifie les échanges
entre le développement et la la prod ça permet d'avoir un langage commun et ça effectivement
c'est un peu c'est un peu la base du tout c'est voilà enfin oui moi aussi des fois quand je
parle j'ai un peu l'air de critiquer mais au final je ne remets pas en question le fait que
que ça est vachement facilité les choses dans mes deux précédents boulots si j'avais pas eu Docker et
son écosystème mon travail aurait été bien bien bien plus compliqué je vais clairement pas cracher
dans la soupe c'est on est d'accord là dessus peut-être que Damir peut pondérer ce que je viens de dire
non non mais je pense que vous avez vous avez dit des choses assez intéressantes et je suis plutôt
d'accord avec vous dans l'idée générale après moi je parle vraiment du principe je vais utiliser
smo beaucoup trop de fois aujourd'hui mais c'est paradigme c'est que Docker quand il est arrivé
sur le marché il arrive au bon moment avec le bon écosystème en fait et au bon moment où les
paradigmes sont échangés c'est à dire qu'ils sont venus sur le marché quand le DevOps commença à
pas se démocratiser on commença à en parler on commença à vouloir comme et Juan le disait on a
dit on va faire parler des équipes de dev et d'ops mais il faut qu'ils aient un langage commun
se retrouve quelque part il faut qu'il se connecte en fait il y a eu ça il y a eu du
coup le principe du pet versus catel qui a commencé à apparaître et à exploser de se dire bah
notre machine on va plus la traiter en fait comme un animal de compagnie on va plus donner un joli
petit nom en mode vous avez tous connu vos petits serveurs qui ont des jolis pinons genre baltazar
comme ça ils ont tous des petits noms on en prend soin on s'en occupe quand il y a un truc qui va pas
on essaie de comprendre les réparts et on est parti dans l'idée vers ce juste de l'abattoir on se dit
on lance la machine bah là un souci à la machine bah on a trache on a trache on en
recréer une autre avec le même programme et en fait ça ça commence à être populaire
un docker le permette et le faciliter il y a eu l'infras code aussi qui commence à apparaître
on se disait faut quand même mettre tout le code qu'on a faut le mettre quelque part faut le mettre
dans le guide l'infras faut essayer de la diriger encore plus vers du code et du coup docker
bah avec le docker file avec après docker compose et des choses comme ça il commençait
quand même à apporter cette notion là et il y a et ensuite une notion très simple c'est que ça
va aussi permettre au niveau communication si vous avez un docker file par exemple
bah aux ops et au dev en fait d'avoir le ce point de contact dans le guide et de se dire
bah le dev il va faire son image ou l'admin il va dire attends j'ai changé ton image tu fais une
poudre request parce que là tu faisais tout en route j'étais mis à un utilisateur que j'ai créé
etc donc cette cette idée de collaboration qui a vachement été poussée du coup par ça je pense
je sais pas ce que t'en ce que t'en penses de tout ça christophe moi je fait pour moi ça
était un révélateur de ce que je voulais faire parce que à l'époque où j'ai découvert docker
je me rappelle je travaillais encore j'étais gestueur d'application chez casino et j'installais
des applications j'étais même pas encore administrateur système et j'avais déjà des
problématiques d'isolation à l'époque qui était pas totalement réglé avec chroute je t'en parlais
mais c'était pas totalement réglé on avait encore des soucis etc quand j'ai vu comment la
facilité qui t'a apporté les et comme tu le dis le paradigme qui était apporté je suis ah ouais
il faut que je faut que j'investigue là et puis avec le temps je me suis aperçu que c'était
vraiment un outil formidable qui a plein de problèmes mais qui a tellement d'avantage que du
coup tu passes outre ces problèmes des fois et pour moi il y a un truc que j'ai découvert
justement avec le temps c'est l'aspect des microservices et qui du coup il ne pouvait pas
exister avec les vm parce que quand tu lances une vm tu t'installe une application avec tout ce
qui va avec mais là c'est tellement facile de lancer un conteneur une petite enveloppe avec
juste juste une petite api ou une petite application dedans que tu peux faire des services pour chaque
bout ton application et comme ça tu peux mettre à jour à chaque bout indifféremment et tu peux
morceler tes équipes les faire travailler sur plein de projets tu peux utiliser ton bout de
microservice sur un autre projet enfin je pense que là ça a apporté une dimension encore différente
grâce à ça et du coup c'est l'infrastructure qui vient bousculer un petit peu le développement
je trouve que c'est assez intéressant pour le coup c'est ce bousculement est ce que vous
l'avez vécu dans vos métiers alors Erwin comme toi tu es chez un éditeur finalement de ça c'est ce
que cet aspect microservice vous vous le mettez en place oui alors en gros les stacks des clients
sont composés de plusieurs conteneurs qui ont chacun une tâche propre donc il y a un conteneur
pour les espèces d'apis qui fait des screenshots un conteneur qui représente les les workers
la pays etc et effectivement le pourquoi on est passé sur sur sur du docker et que je pense ça a
du sens comme ça c'est que on voulait à la fois être assez souple sur la façon de gérer de gérer
c'est les microservices que tu décrivais et en plus on voulait que ça soit isolé que ces trucs
ne fin que ce que ces conteneurs ne soient que dans un écosystème où ils se voient que et
non pas interaction avec l'extérieur et effectivement je fin aujourd'hui je sais pas comment j'aurais
fait je aurais fait sans sans sans docker et sans les conteneurs pour pour pour pour pour pour
avoir ce genre d'archi et effectivement alors moi je connaît enfin les j'ai bien sûr utilisé les
chroutées plein de choses dans ma vie et j'ai utilisé pas mal les jail de bst plus jeune mais mais
en fait penser une archi ou aujourd'hui je sais pas on doit avoir 250 ou 300 clients donc à chaque
fois avec quatre à cinq conteneurs par par steak en fait je vois pas comment on aurait pu faire
un truc pareil sans sans ce type de technocrat donc clairement le le microservice et ce et
cet apport de l'isolation c'est c'est deux choses qui ont encore une fois de coeur entre pile
pile dans les casques quoi honnêtement ça va pas changer de la même manière en un méthode
trahier déjà parce qu'on avait pas mal d'infrascode avec beaucoup de chefs et de choses comme ça et
du peu pète aussi avant et on avait bah tous les déploiements étaient automatisés avec du
produit s'appelait chez fils tranneau si vous avez connu c'est c'était vraiment la joie mais du
coup qui marchait plutôt pas trop mal et on était plus sur une idée de faire des petites vm pour
séparer les choses dans le départ que que du conteneur notamment parce que moi j'ai commencé
à l'époque où le docker a explosé en fait moi j'étais sur de la production sur des grosses
productions donc en général le temps que ça remonte jusqu'en prod sachant que pendant longtemps
docker quand même elle n'est pas forcément on va dire les requins de maintes nécessaires pour
être en prod bah pendant longtemps en fait je n'ai pas vraiment vu tourner en prod je le voyais
un peu bah moi sur mon poste ou sur les postes des dev mais le voir en prod ça a pris un peu de
temps quand même pour qui qui fasse un truc correct et qu'on commence à avoir des solutions propres
donc ça a pas changé directement ma manière de travailler en truc moi il y a un truc que j'ai
vu arriver bon en effet docker et les conteneurs au début en prod c'était pas ça c'est plus en
plus le cas et ça nous permet d'imaginer des choses notamment dans un service qu'on développe
qui s'appelle la boîte à outils où en effet sans conteneurs je pense qu'on ne développerait
pas de la même manière il ya une version historique qui n'est pas avec des conteneurs mais la nouvelle
version qu'on imagine c'est tout un ensemble d'outils qui communiquent entre eux et chaque
client qui va signer avec nous va avoir son propre son propre essi entre guillemets qui sera
toute à base de conteneurs qui communiqueront ensemble et qui communiquent une qui qui moune
un de trois qui ne communiqueront pas avec les conteneurs des autres et du coup ça sans les
conteneurs c'est plus dur à faire notamment parce qu'on veut densifier la plupart des applications
sur un minimum de machines donc on veut surutiliser les machines qu'on a et du coup les conteneurs
nous permettent justement de densifier énormément avec les orchestrateurs en plus dès que
il ya une machine qui est un peu trop chargée et pof il va déposer ses conteneurs ailleurs et ça
c'est quelque chose qu'on peut difficilement faire avec l'evm et je sais pas si vous vous rappelez
mais moi dans mes anciens dans les mes anciens boulots hop une machine a été chargée à 70%
ça y est on vous appelait l'astrâne parce que c'était pas normal etc aujourd'hui moi si ma
machine n'avait pas chargé à 90% bah ça m'inquiète je sais pas vous comment ça se passe mais
du coup cette densification pour moi elle est super intéressante parce qu'elle va réduire le
nombre de machines qu'on va utiliser et du coup ça va aussi réduire le coût et le coût énergétique
et le coût écologique du fait pour le coup je me permet de rebondir la densification pour moi
elle était moins importante que quand la vm est apparue en réalité je parle pour le conteneur
moderne entre guillemets parce que déjà quand j'avais des vm moi je prends mon cas à l'époque
j'étais plus dans ddsc et malheureusement paix à mon âme je faisais plus de windows mais
pour le coup j'avais le même principe avec des clusters on va dire de 7 8 machines physiques
sur lequel mes vm quand il y a une machine qui était trop chargée il a basculé sur une autre
pour moi là dessus ça n'apporte pas grand chose quoi non pas grand chose on va dire ça pas été
game changer si je veux dire ça pas changer les choses ça pas être des disruptifs comme disent les
jeunes personnes la start-up nation mais pour le coup pour moi ça a plus été fait avec avec la vm
et clustering là dessus mais j'ai quand même temps ça m'a inquiété à pas laisser mes machines
atteindre 90 de charge que c'est pas vraiment normal je préfère être à 60 pour la marge en
cas de pique après bon j'aime pas vivre dans le risque j'ai fait trop d'astreinte mais pour moi
il y a un truc c'est les vm permettez en effet d'atteindre la densification mais je pense que tu
vas être d'accord avec moi une vm c'est quand même beaucoup plus consommateur qu'un conteneur
quelque part et du coup en fonction de ce que tu prévois pour ton infrastructure et ton application
l'un ou l'autre des cas va pouvoir s'adapter je ne dis pas que tout doit aller dans les conteneurs
évidemment là dessus je suis d'accord avec toi je dis juste et j'ai les garrafes au début l'apparition
du conteneur à la docker entre guillemets avant quand je faisais déjà du conteneur perso on
avait déjà densifié là dessus moi c'était un peu un bordel parce qu'on avait du conteneur sur
des vm qui était sur des clusters et si mais globalement on était déjà à peu près à ce niveau
de densification mais après oui le conteneur en soi c'est reprend la notion de conteneur général
parce que c'est vrai qu'en un temps ça a parlé de conteneur mais en général c'est sous-entendu à
la docker ou dans dans cette dans ce paradigme je vais faire un jeu à boire avec ce mot sur
spot cast n'essayez pas pour le coup je suis d'accord si on prend notion de conteneur en général
mais si on prend la notion moderne entre guillemets ça n'a pas de temps changé que ça là où je
rejoins christophe c'est qu'il ya un truc qui est intéressant après ça dépend comment on veut
mettre en place et c'est pas toujours possible de faire du full conteneur et de se passer de la
virtu mais c'est effectivement cloverhead d'un conteneur et plus faible que celui de machine
virtuelle donc t'as juste une granularité un peu plus fine et du coup quand tu veux répartir
tes workbooks sur tes machines pour les utiliser au maximum ça a grandit à marge de
main avant on va dire après effectivement le principe n'est pas nouveau ça se faisait déjà
ça se faisait déjà avec de la virtu que ce soit avec des moires avec open stack ou avec d'autres
orchestrateurs ça pour le coup je suis d'accord avec d'ailleurs non mais je ne dis pas que ça
n'a rien apporté je dis que la conteneurisation à apporter de l'identification je dis juste que
la conteneurisation et docker en particulier n'a pas vraiment augmenté en fait ce principe c'est
juste ça que je disais mais je suis d'accord du coup avec tous les deux je pense ça l'a simplifié
quoi en fait au final on vient toujours au même point c'est qu'effectivement comme tu dis
docker a pas changé le game de la conteneurisation mais par contre docker et les techno qui s'en sont
suivi et qui ont entouré ce projet là on simplifiait les choses pour des gens qui avaient moins de notions
deep d'infra au départ c'est ça a rendu le truc plus accessible et ça l'a démocratisé du coup
le plus de monde utilise une techno le plus il va y avoir de documentation le plus il va y avoir de
projets annexes qui vont améliorer la techno initial et voilà il fait boule de neige quoi
parce comme ça qu'il a ressenti en tout cas c'est assez intéressant parce que du coup Benoît
Christophe vous parlez beaucoup de simplification alors moi je c'est une question très très simple
mais je vois pas spécialement quoi docker a simplifié les choses dans la mesure où le conteneur
avant c'était plus ou moins la même la même gestion qu'une vm on lui a signé des ressources
on a signé des volumes des choses comme ça sauf que c'était en local et on n'émulait pas le hardware
donc au final c'était pas très compliqué c'était pas beaucoup plus compliqué qu'une vm en faisant
suivant suivant avec des interfaces graphiques et du coup je pense que docker au contraire il a
rapporté beaucoup de complexité parce que toutes les notions dont on parle depuis le début et
c'est pas en mal ça permet de résoudre beaucoup de problèmes mais ça aussi créé en fait ça a fait
que nos métiers ont évolué il a fallu apprendre beaucoup de choses moi en tout cas au début quand
j'ai commencé à avoir du conteneur tout ce qui est pète versus cattle des choses comme ça le
status etc mais je pense qu'on n'en reparlera c'était pas rentré on va dire dans dans les esprits
et j'ai vu beaucoup gens qui utilisent docker mais très mal on se retrouve avec énormément de
problèmes donc au final je pense pas que ça soit plus simple je pense que ça apporte il y a une
complexité cachée c'est effectivement très simple vous allez au tout début de docker je me rappelle
bien il y avait cette fameuse du je maîtrise docker j'ai fait un docker pouge j'ai fait un docker
run je suis le roi du monde et ça il y a eu énormément cet effet là au début c'était la
première fois qu'on voyait ça côté hop tout en tout cas de mon point de vue et ça m'avait
choqué parce que j'en disais maîtrise quelque chose mais en fait c'était très complexe qu'il y avait
des notions super abstraite il y avait des choses où bah clairement si tu pousses pas un peu et tu
réfléchis pas un peu à comment ça se passe tu les voyais pas je pense que ce côté simpliste en
tout cas mon sens il est pas si vrai que ça je ne sais pas vous ce qui vous fait dire à ce point
là ce qui est que c'est magique et simpliste entre guillemets quoi j'exagère un peu je vais préciser
alors parce que à l'époque où j'ai docker et arrivé et comme tu dis c'était la bonne époque
j'avais un projet en fait qu'on avait développé pour casino c'était une garde de triage en gros
c'était un système de répartition des fichiers on avait des clients qui venaient déposer des
fichiers sur une machine en fonction des en fonction des noms les répartissait on les envoyait à
l'intérieur du réseau etc donc il y avait un truc dans une DMZ des autres et en fait on utilisait
sra.chcoute et plein d'autres trucs et on était vite limité par par justement les aspects non
isolation des process unics et donc quand moi j'avais vu arriver docker j'étais en plein
dans en fait dans ce truc là dans le fait de tout doit tourner sur la même machine parce que
une machine centrale sur lequel les gens viennent déposer des trucs mais il faut qu'on puisse
isoler encore plus nos process Linux et du fait on voulait pas lancer une VM par process parce que
c'était des petits bâches tu vois c'est vraiment ça consomme pas grand chose et cette notion là
de conteneurs qui était que moi je connaissais pas à l'époque pour le coup ou alors je n'avais pas
affra parce que moi j'étais pas au-delà de l'infra et je suis qu'à dis-nous il y avait plein d'ops
il m'avait pas proposé ce genre de choses et donc c'est pour ça que dans cette thématique là c'était
facile de lancer un process de manière totalement isolée du reste de la machine c'est je veux dire
une ligne de commande et pouf et puis le fait de concevoir une image avec un docker file c'est
moi j'utilisais vagueront et virtual box à l'époque sur ma machine c'était pas aussi simple
enfin je veux dire c'est pas aussi rapide à mettre en place ça va dire ça dépend de jusqu'à
ça dépend de l'existence un peu c'est un peu plus complexe il y a un contexte à avoir et pour à
tout à fait honnête le contexte de l'époque je connais plus par coeur même si mon âge avancé
ma panne quand elle passait tout à fait ma mémoire ça remonte quand même il y a beaucoup
de choses qui sont passées donc repasser les choses dans les bonnes dates c'est un peu compliqué
ok mais ce que je veux dire c'est qu'il ya quand même de la complexité que c'est pas c'est pas magique
quoi ouais non je vais reformuler ce que j'ai dit de tout à l'heure effectivement le dami
remarque un point c'est pas une simplification au sens pour faire la même chose mais c'est plus que
ça proposait une nouvelle voie c'est moi ressentir c'est ça proposait une nouvelle voie qui était
très ou la barrière la barrière à l'entrée était très basse donc c'était c'était facile à
prendre en main ça veut pas dire qu'on maîtrisait la technique mais ça veut dire que on comprenait
très vite le principe et les avantages que ça pouvait apporter par contre effectivement ça a eu
plein d'inconvénients notamment le fait que au départ tout le monde se ruait sur le docker hub
public pour publier des images utiliser des images sans regarder comment elles étaient construites en
termes de sécu en termes de stabilité il ya eu des tonnes de soucis et les exemples ne manquent pas
donc c'était pas c'était pas exempt de tout problème mais là où c'était intéressant je suis
d'accord avec toi qui fallait voir ce qu'il y avait derrière et comprendre que c'était une nouvelle
voie une nouvelle manière de faire les choses et pas juste un moyen de faire comme avant en plus
simple c'était pas dans ce sens là que je l'entendais et effectivement ouais voilà ça nécessité de
comprendre ce qu'il y avait derrière ce qui n'a pas été toujours le cas ce qui n'a pas été le
cas au début ça commence à être le cas les gens arrivent à maturité un peu sur ce sur ses
mécanismes là mais voilà c'était plus dans le sens là c'était plus dans le sens ça offrait un
nouveau choix une nouvelle manière de faire de l'infra et de déployer des applications
qui était plutôt facile à préander au départ même ça veut pas dire que quand on l'a prérandé
on peut tout de suite mettre en prod mais ça a donné une nouvelle voie intéressante mais par contre
c'était pas ouais la même manière c'est pas la même manière de faire en plus simple c'était pas
dans ce sens là que je l'entendais en tout cas oui tu voulais dire plus easy to learn à un tout master
il y a un peu de ça ok je pense qu'on peut on peut parler du coup des limites parce que
on arrive à un point où justement on se pose des questions sur qu'est ce que
qu'est ce que nous a apporté les contenus mais du coup quels limites elles ont et qu'elles
limitent à docker aujourd'hui parce qu'il y a plein de gens qui utilisent docker et qui n'ont pas
conscience des limites qu'apporte docker et tout à l'heure en effet quand je disais c'est facile
il y a un truc faut pas oublier docker c'est un binaire à installer et puis c'est tout et donc ça
fait partie de la facilité mais ça fait partie des limites c'est à dire que c'est un binaire c'est
un démon qui tourne et tout est fait avec le même binaire le démon tourne en route tu dois l'utiliser
en route ton client c'est le démon enfin il ya plein de il ya plein de choses comme ça qui pour moi
sont limitantes et a priori docker a pas prévu de changer ces choses là on pas prévu de séparer
le démon du client de pas lancer le démon en route et genre de choses il est spotman le faire
tout à fait il est spotman le faire il le fait très bien je pense et ça c'est une limite qu'on
voit peu ou qu'on envisage peu et moi je sais que le fait que docker tourne tout le temps en route
et surtout qui lance tous les conteneurs en route pour moi c'est un vrai problème pour le coup et
c'est un problème de sécurité parce que j'ai pas forcément envie que tout tout soit route finalement
sur ma machine j'ai bien envie de lancer des conteneurs qui ne soient pas routes et potman
permettre de faire ça justement et tout à l'heure bono tu parlais justement de des failles enfin
de des images qu'on récupérait et moi c'est vrai que je dis tout le temps aux gens quand vous
utilisez des images allez lire le docker file comprenez ce qui est fait dans le docker file parce
que si vous prenez l'image comme ça toute bête ça ça va vous poser des problèmes et vous savez
pas ce que les gens ont injecté dedans donc déjà il faut lire le docker file et puis il faut bien le
tester il faut bien comprendre ce qui est fait parce que si vous avez un problème et bien du coup
c'est en fonction de comment le conteneur a été fait qu'il va falloir agir je sais pas
que ça vous évoque justement le fait d'aller lire les docker files que vous l'utilisez déjà
les docker files de tous les images que vous utilisez j'imagine que oui alors moi je vais être
honnête je les lis pas forcément tous mais j'essaie d'utiliser au maximum les images officielles
par exemple je suis pas l'image piton n gx ou maria db ou mongo par exemple je
je prends pas celle d'un garante d'oeuvre je prends l'officiel qui est censé respecter les
différentes les différentes comment dirais je requie pour avoir le fameux badge sur
de coeur qui va bien donc donc voilà et puis à par contre ce qu'on ce qu'on fait là où je suis
c'est que toutes les images qu'on qu'on bah effectivement qu'on récupère et où qu'on produit
elle passe elle passe dans les dans la moulinette là qui analyse les différents layer pour le
pour les files de cq on est d'ailleurs allez sur le forum il ya un très bon thread là dessus
sur les différentes techniques qui qui peuvent être utilisés et et en fait à défaut je veux dire
c'est utiliser ce genre d'alternatives donc il ya plein d'outils il ya il ya clair il ya si vous
utilisez la registrie quay ben quoi il le fait aussi etc et ça ça va vous sortir les cve qui sont
qui sont associés à l'image que vous utilisez par contre c'est une analyse c'est une analyse on va
dire statique à partir du statut du dp kg à partir du je sais pas si vous avez des fichiers de
récoyer mon pitton ou quoi que ce soit bah c'est avec ça qui définit les les files mais enfin les cv
par contre qui sont potentiellement présents mais mais c'est déjà un je trouve un bon début d'avoir
au moins ce genre de de choses dans son pipeline de conteneur pour pour au moins ne pas se retrouver
avec des trucs trop trop chelou donc utiliser les trucs officiels et et utiliser donc un truc
comme clair au quai pour pour analyser moi j'ai l'impression en effet que c'est scan de sécurité
d'image sont pas encore généralisé et que en effet il ya pas mal de gens qui sont passés à
au conteneur en production enfin docker en production parce que les conteneurs en production
il y avait d'autres qui le faisaient mais j'ai j'ai l'impression qu'en fait la sécurité des images
est pas pris et pas comme on dirait pas pris au sérieux et et pour l'instant on n'a pas encore
beaucoup d'outils en effet tu sais de là mais finalement on n'a pas énormément qui nous
permettent d'assurer la sécurité des conteneurs et on sait qu'il ya des failles en plus on sait
qu'on peut sortir d'un conteneur quand on peut qu'on peut faire des escaliers de sécurité et là je
pense qu'on a beaucoup d'infra qui sont basés là dessus qui sont peut-être pas forcément
sécurisés j'espère que ça va venir mais je sais pas comment après la sécurité c'est un gros
sujet sur les conteneurs déjà je pense que si on a vraiment des besoins de vraie isolation et
entre des sas pour des questions de sécurité sans être méchant on évite de partir sur du
conteneur ça c'est de bas ce qu'il ya plus de chance des évations de privé je les choses comme
ça donc là dessus oui docker à moins sécurisé qu'une vm conteneur en général lui c'est principe
en fait on enlève une couche d'abstraction donc c'est assez assez logique ensuite est ce que
ben perso moins les images quand c'est moi qui les utilise j'essaie de lire au moins de survoler
voir si je vois pas des trucs trop moches ou des choses qui tournent avec des utilisateurs des choses
comme ça après est ce que je les lis dans les détails j'en ai eu sur les lignes de code non
surtout que souvent les points remace sur un script bashe très grand après j'utilise très
peu d'images de hocaurs personnellement je déploie celle de mes de des développeurs mais c'est
que je dis je les connais pour ce qui est des scannes au ref a bien conscience des scannes comme
comme explique à cb1 qui sont totalement statiques donc c'est des choses sur qui se battent sur vos
librairies et vos choses comme ça les choses comme ça ils sont disponibles en peu près partout
quand même chez que sur gitlab je les avais c fonctionne sur ecr d'amazon vous pouvez les
activer aussi donc ça commence à être assez populaire à ce niveau là ça c'est bien pour suivre
votre niveau de nombre de failles critiques pas critique après faut bien être conscient d'une
chose c'est que votre application si dedans vous avez fait une erreur vous avez foutu une xx une
xss vous avez une injection à sucre possible le scan ne voit pas vous la détecter votre truc pour être
mis en prod et le truc de sécurité faut dire oui ça c'est un plus entre guillemets à l'époque
il s'était déjà on pouvait scanner il y a un outil chez puis s'appelle db scannes je crois qui
permet de scanner vos paquets de pkg local par rapport à la base dcve voilà c'est la même chose pour
du conteneur et automatiser mais il faut avoir bien conscience que ça c'est uniquement pour
statique et c'est bien pour suivre notamment on va dire que vos mises à jour ne soient pas trop
dépassés et là dessus par contre je pense que docker a un vrai rapport à rapporter c'est que vu
qu'on est censé détruire en permanence reconstruire avec ce des choses là on devrait pas avoir moins
peur des montées en version de librairie ou d'autres donc du coup on doit pouvoir justement passer
ces mises à jour plus souvent qu'avant ou avant les mises à jour on va pas se cacher sous un
applicatif souvent c'était faut mettre à jour la libre ouais mais attends si jamais ça pète
ce programme là c'est la merde laque docker on peut plus facilement se permettre de la mettre
à jour quitte à revenir au tag précédent en extrémengeance mais là dessus je pense que docker
peut étrangement apporter quelque chose au niveau de la sécurité mais il faut faire attention après
et bien garder en idée que les tests statiques c'est bien pour vérifier du coup qu'on n'est pas
trop outdate au niveau des librairies qui sont pas trop troués et faut garder quand même et tout ce
qui est pentest etc c'est quand même une bonne pratique de pentest son application régulièrement
avec du bug bounty maintenant ça s'intègre très bien dans un cycle de la bop si j'ose dire de dire
il ya une phase où on craint l'environnement pour le bug bounty où il ya un bug bounty d'un mois avant
que ce soit passé totalement dessus des choses comme ça c'est des choses qui sont importantes
je pense à garder en tête de coeur là dessus et pas magique et il fait pas de miracle tu peux nous
parler un petit peu des bug bounty pour les gens qui ne connaissent pas ces bug bounty oui alors du
coup globalement pour la sécurité il ya un principe qui est assez ancien de dire on va on va payer
des gens souvent on payait une société on leur disait bah vous allez sur notre application on vous
donne les url on vous donne les white list yp si il y a besoin et vous envoyer quelqu'un qui va essayer
de vous hacker donc c'est ce qu'on appelle souvent un white hat qui du coup est gentil et fait ça
du coup c'est son métier en fait il va essayer de trouver le trou dans votre application et de vous
attaquer ensuite il va au final rapport il va vous dire bah là t'as fait une file SQL tiens
je t'ai mis un lien vers la doc pour le corriger et en fait ça c'est assez chiant dans la mesure où
fallait voir des entreprises d'audits c'était toujours très cher c'était un peu complexe à
mettre en place c'était planifié des mois à l'avance j'étais dans une banque où ça devait
être planifié deux mois à l'avance donc vous imaginez bien qu'aujourd'hui avec le cycle
de la bosse quand on dit alors là pour ça c'est deux mois avant de mettre en prod tu vois tu fais
ça va être compliqué quand même donc aujourd'hui il ya ce qu'on appelle les bug bounty c'est tout
simplement on va on va dire on va avoir une plateforme qui est une plateforme de bug bounty on
va dire bah tenez moi j'expose à votre communauté puisque c'est une communauté de hackers cette
URL ces applicatifs là et c'est une mea k et en fait ils vont pas être émunérés à la mer
classique c'est à dire on va pas leur dire tu seras payé 1000 balles pour avoir essayé ça pendant
une semaine c'est tu vas te payer si tu trouves une file et selon assez vérité de la file si la
personne n'arrive à accéder à tout votre site en route vous doutez bien que c'est un peu plus
compliqué vous allez donner un bounty donc vous allez donner du coup une récompense pour dire
ben bravo t'as trouvé cette file on te donne tant d'argent donc c'est assez bien parce que c'est
plus flexible que les pen test à l'ancienne entre guillemets et c'est c'est aujourd'hui assez assez
répandu ça fonctionne plutôt bien j'ouvre une parenthèse débat est ce que c'est pas un peu
l'hubé l'hubérisation des wight hat un petit peu dans l'idée oui c'est ça dans l'idée on passe le
cachet merci pour cette précision du coup on va parler d'un autre problème qu'en plus on
voit sur la communauté enfin vous ne le voyez pas mais moi je le vois alors l'objectif du
conteneur alors il n'en a peut-être pas parlé mais ce qui préconisait c'est un service un conteneur
un process un conteneur et il y a quand même des gens qui pensent que les conteneurs ça peut être
comme dvm finalement et qui foutent plein de choses dedans donc je sais que harwann veut nous en
parler je te laissez la parole oui parce que j'ai pêché j'ai j'ai j'ai un moment dans ma vie
fait un espèce de fat conteneur qui faisait 3 gigas qui était formidable il faisait tout c'est
c'était beau mais je comprends aussi enfin je suis pas arrivé à faire ça juste pour le défi
c'est il y a en fait il y avait un vrai besoin business et il faut savoir que là où je travaille on
fait du ond prémisse donc le prémisse c'est quoi c'est la capacité de reproduire ce qu'on fait en
sas mais dans une infrastructure qu'on ne connaît pas et si pendant longtemps ça on s'est et on s'est
débrouillé à faire à faire ça avec avec des scriptantibles et tout qui marchaient mais bon
forcément les gens qu'on avait en face n'étaient pas toujours à l'aise avec avec avec ça et donc
des fois on allait un peu dans le mur bah docker et c'est de quand on s'est dit mais en fait ça va
être trop bien on va alors fournir un conteneur qui fait tout comme ça les mecs ils ont juste à
faire un docker run et moi je fais plus de support et dans ma tête c'était c'était c'était la
fête du stp je me disais que c'était vraiment vraiment le un truc de ouf et et dans les faits
ça a vraiment marché il y a énormément de clients qui trouvaient ça trop cool ils disaient
ça fait trois gigas on s'en fout vas-y en voilà mais c'est trop facile à installer j'ai juste à
faire ça et ça passe ouais ouais t'inquiète et en fait du coup je comprends qu'on puisse arriver
à faire ça même si c'est pas une bonne pratique mais en vrai il ya alors je vous rassure depuis
on fait plus ça ça mais ça quand même durait je pense bien si si c'est moi quoi on s'est reposé
dessus et mais par contre il ya il ya des éditeurs c'est leur vraie stratégie je sais pas si vous
connaissez la solution discourse mais par exemple discours ça vient avec un conteneur qui y a
tout dedans quoi il ya du n gx du post gré ça compile ça compile en rubis ça enfin et et en vrai
je comprends pourquoi ils font ça parce que j'ai été dans le même cas c'est trop bien discourse
t'y connais rien tu et tu lances le truc t'as même pas besoin de mettre de reverse proxy où je
sais pas quoi tu peux le mettre sur une machine à la con et ça va marcher nickel quoi donc donc en
fait si je comprends l'intérêt l'intérêt quelque part je en fait on va absolument à tout l'opposé
de ce pourquoi les conteneurs enfin et d'aucœur à essayer de pousser donc des des des mini des
mini des mini conteneurs qui sont monotages etc avec très peu de process dedans et mais en vrai
mais en vrai on se rend compte que ça arrange quand même pas mal de gens des fois d'aller dans
ce sens là et je sais qu'il ya plein d'autres éditeurs alors j'ai pris discours en exemple
mais je sais qu'il ya qui a qui a qui a d'autres d'autres solutions qui font exactement la même
chose juste pour en revenir aussi moi je me souviens qu'au tout début quand on faisait du ond
de la prime est pourquoi on a on était passé par cette fat image c'est que on avait demandé
vite fait aux clients qui voulaient faire du docker et on se rendait compte qu'ils faisaient tous des
trucs hyper différents et on s'était dit voilà ça va être relou si on doit supporter enfin si on
doit faire le support de ça moi j'ai envie de faire du support sur notre solution pas sûr
comment ils vont exploiter le truc et et donc on s'était dit bah voilà avec une fat image on va pas
se poser la question de je sais pas quelle est leur version de coeur compose les études de
comment ils utilisent c'est qu'il y a un net ou soit on ne mougeant ça rien et et donc voilà
enfin et du coup ça c'est rigolo parce que c'est c'est clairement une mauvaise pratique mais on
se rend compte que ça que ça aide dans pas mal dans pas mal de cas et que certains éditeurs
reposent reposent d'être je sais pas si vous aussi vous avez pêché et mais aussi vous connaissez
des solutions qui qui ont aussi opté opté pardon pour pour un fat conteneur je vais prendre la
parole du coup parce que j'ai pêché deux fois j'ai pêché deux fois la première en instant en
discours parce que le forum des compagnons est basé sur discours et du coup j'ai découvert ça
alors en plus alors moi j'ai beaucoup de j'ai beaucoup de problèmes avec discours j'adore
discours mais la installation déjà c'est du fat conteneur et en plus c'est un langage de
template ing qui est un peu particulier donc dès qu'on veut le mettre à jour ou faire quelque
chose c'est pas facile c'est compliqué tout à fait il nous promet une mise à jour en un clic mais
des fois faut aller sur la machine faut recharger un script faut rebuilder l'app et puis voilà ça
prend ça prend des plombes et surtout bah ça se calpate parce que tout est dans un seul
conteneur donc si jamais je veux séparer la base de données du serveur d'application je peux pas
c'est clairement pour moi il y a un problème et puis j'ai fait ça aussi avec git lab puisque
git lab propose une version avec un conteneur alors git lab c'est la double open non seulement
c'est un fat conteneur mais c'est un fat conteneur qui est buildé au moment où tu le
lance avec des recettes chef donc bravo j'adore git lab mais pour le coup là si si vous plaît
arrêter de faire ça arrêter de faire ça donc donnez nous des docker compose je sais pas moi
fait des images immuables mais arrêtez avec vos recettes chef qui se lance au moment où le
conteneur se lance enfin je sais pas du coup j'en suis revenu un git lab maintenant j'instable sur
des serveurs et ce que tu expliques pour moi c'est clairement ce qu'il faut pas faire avec un conteneur
pour le coup vraiment prendre une machine virtuelle parce que là du coup l'intérêt c'est
pourquoi prendre un conteneur et pourquoi pas les sur une machine virtuelle où tu paquets
d'une image de machine virtuelle et tu la lance mais moi je peux te dire pourquoi les clients
qui étaient intéressés pour faire ça ils avaient des systèmes de virtualisation qui étaient tous
différents il ya des mecs qui avaient du xen en plus du xen hyper vieux c'est il y a déjà xen
c'est vieux et il y en a qui étaient sur du 20 mois etc et et nous on voulait pas supporter
cette cette charge là nous notre taf c'est pas de faire en sorte que ça marche sur l mw sur
xen quoi notre taf c'est de faire de la data visualisation quoi et donc du coup du coup du
coup effectivement notre conteneur ressemblait à une vm mais mais l'avantage c'est que bah deux
coeurs étant quand même je pense aujourd'hui hyper popularisé je ne pense pas qu'il y a de boîte
qui qui passe quand même totalement à côté sauf pour des quatre spécifiques bah ça nous a
rangé vachement et étudiant écrivé le truc avec chef moi j'ai fait exactement la même chose avec
mon fatconteneur et en fait le bulle du fatconteneur c'était les fameux les fameux script en
cible enfin playbook en cible qui qui se jouait donc j'avais un legeur qui devait faire les trois
gg à quoi enfin je je sais plus exactement mais et en fait je comprends pourquoi enfin d'un point de
vie business nous ça nous a ouvert énormément de portes de faire ça et et et maintenant on est
on est plus à ce stade là donc maintenant on a des on a les petits conteneurs que que je
t'écrivais un peu plus tôt dans le podcast et en fait pour dire aux gens de commencer vite en
fait on leur fournit un espèce de docker compose hyper simple où il n'y a pas de config fancy et
on lui dit regarde tu tu tu prends ce docker compose tu te tu te log sur deux que rôtes pour
récupérer des images on t'a donné des accès et et ça va tourne mais mais du coup c'est c'était
probablement plus facile intellectuellement de se dire oh bah si j'ai juste un docker
poule à faire un docker rône c'est quand même bien mais après juste pour le cas partuel
githlab c'est dit au fait githlab globalement faut bien avoir conscience que c'est toute une
fra à l'aigu redis avec la base de données avec un frontaine des plein d'autres choses et que
de base quand vous installez githlab 90% du temps vous utilisez ce qu'on appelle la version
omnibus qui est en fait une version ils ont tout pas 4g avec chef qui va installer tous les
différents des différents services et qui va vous simplifier la vie au niveau de l'installation
quand vous avez pas des gros workloads quand vous avez des gros workloads faut pousser un peu le
truc et là je pense que les gens ont fait l'image de coeur de githlab ils ont juste pris omnibus mais
en soi githlab si on voulait faire les choses proprement sur le docker il faudrait reprendre
la version githlab non omnibus lancer tous les services et les interconnecter lancer sa petite
base de données lancer son petit redis et ces choses là en plus faut voir que c'est un énorme
hack en plus à la base de plusieurs process dans un temps de coeur puisque à la base il y a pas de
système des nids il n'y a pas système 5 il n'y a pas système des il n'y a pas ou autre et en gros
de coeur ils ont conçu le truc comme ça ils le disaient même ils disaient on a mis un truc hyper
basique qui lance un piad et basta et de façon c'est comme ça que c'est censé tourner parce que
c'est pas fait pour faire des fêtes de monnaie justement et du coup ce qui veut dire que tous
les éditeurs qui font ce genre de choses ils sont obligés d'installer un truc fake du genre
super visor des ou autres démons qui va prendre le piad unique et qui derrière va gérer des sous
process à s'assurer et ce truc là en plus le pire c'est que voilà moi ça décale j'ai pu voir
un peu sur le bien-être c'est un peu moins vrai sur quand on fait du docker sur du bair métal par
exemple mais le problème aussi c'est que bah typiquement quand on met ça dans un orchestrateur
la réaction de l'orchestrateur la manière qu'à l'orchestrateur d'aller voir comment se
contente le conteneur quel est son état et quelles sont les actions qu'il faut faire dessus genre
est ce qu'il faut le risquer du lait est ce qu'il faut le mettre sur une machine ce qu'il faut le
relancer etc. ça dépend vachement de la réaction du système d'ili dans enfin du stémique on n'est pas
un du coup dans le dans le conteneur et du coup ça moi j'ai déjà eu des cas où d'aider me filer une
image avec du super visor d et en fait on était en galère pour prédire alors dans tel cas
super visor d il va me renvoyer ça dans tel cas il va me renvoyer ça et du coup en fait on avait
même des cas où l'appli enfin ça m'était en danger la stabilité de l'appli parce qu'on était
pas sûr du coup de ce que cuvernet est à aller faire en fonction de ce que super résorder les
fermes ça pose plein plein plein de problèmes voilà c'était mais ça mais c'est une vraie limite
oui mais mettre du fatcontaineur en plus dans un orchestrateur ton voeux enfin je veux dire
ah oui là c'était pas un fatcontaineur c'était juste que le dev avait choisi de mettre super
résorder parce que je sais pas il avait voulu faire tourner un truc à côté de son process c'était
pas la même définition du fatcontaineur mais c'était le effectivement il voulait faire tourner
deux process au lieu d'un on arrive justement au moment où on se pose la question est ce qu'on
doit tout conteneuriser bien justement pour moi quand on commence à faire du fatcontaineur
à mettre plusieurs process à l'intérieur c'est que déjà on n'est pas pas bien parti il faut se
poser la question de pourquoi finalement on veut tout mettre dans ce containeur là et est-ce que
le containeur c'est la bonne solution parce pour moi clairement fatcontaineur avec tout dedans
faut pas le faire quoi enfin je sais pas non seulement faut pas le faire mais en plus on sort
du concept d'image immuable qui est vachement bien qui comme je disais tout à l'heure d'amir si
tu as un problème tu jettes ton conteneur et puis pouf là avec ces espèces de fatcontaineurs qui
se à moitié build au lancement eh ben déjà ton image immuable tu t'assois dessus et ensuite
quand ton conteneur tu le jettes le prochain qui arrive c'est dans dix minutes quoi donc t'as le
temps de voir les choses passer hein le train il a le temps de passer trois fois enfin nous on pensait
quoi de ce truc là justement l'idée de finalement de sortir du conteneur pour faire autre chose avec
et absolument vouloir rentrer dedans pour moi effectivement c'est un soucis de mettre plusieurs
process dans un conteneur pour une raison très simple c'est qu'au final tu casses un peu comme
on le disait avant le fonctionnement de docker entre guillemets qui évolue qui est dire on a un
on a un process on a un pi id et c'est lui qui fait tourner applicatif au final il y a tellement de
choses qui reposent sur ce paradigme là dans le jeu à boire vous commencez à être bien chargé que
ben ça pose problème parce que ben il y a plein de choses qui sont prévues pour ça le monitoring est
souvent prévu pour ça ben les systèmes de cycles de vie sont prévu pour ça le cycle de vie
d'un conteneur c'est il tourne le process à un soucis ou quelque chose il est tué on en redémarre
autre mais là du coup comme vous êtes deux qui sont liés ils sont liés à autre chose potentiellement
un autre check etc ils vont peut-être qu'ils sont raisons donc vous allez faire des haques vous
c'est pas assez pas propre et c'est pas voulu alors qu'en vrai un conteneur c'est pas ce qui coûte
en ressources justement donc il n'y a pas de raison de le faire pour moi ça c'est vraiment un
truc à ne pas faire en conteneur et après il y a une autre chose que je rajouterai et qu'il a je sais
qu'il y a des détracteurs etc mais moi c'est mon point de vue c'est de faire tourner tout ce qui
est être full comme des bases de données dans des conteneurs parce qu'à mon sens déjà ben
tu as des problèmes d'aio on va pas se le cacher souvent et ben si tu me mets dans un cluster
ou quelque chose ben le cycle de vie il est totalement pété aussi une base de données ça
n'a pas le cycle de vie d'une application c'est un cycle de vie qui est totalement à part et
pour moi ça c'est très important de le respecter entre guillemets je sais pas toi ce que tu en
penses du coup h1 oui justement c'est ça c'est ça que je voulais évoquer aussi c'est qui
d'une de ouais d'un maillet squel d'un mongo et ben qu'est ce que est ce que c'est une bonne
pratique de mettre ça dans des conteneurs ben c'est sûr que en dev il n'y a pas de débat ça
sauve vraiment la la mise de pouvoir démarrer un mongo en deux secondes sans avoir à se prendre
la tête à installer quoi que ce soit etc mais mais c'est vrai que sur de la prod il se pose
vraiment la question et puis même quand tu commences à avoir des choses un petit peu un petit peu
complexes avec des orchestrateurs etc que tu veux persister des données bah ça peut enfin ça
c'est un sujet du coup en termes de perte en réplication tout ça bref le la dessus moi je
comprends qu'on puisse le faire mais je vois je vois énormément de problèmes associés à ça
je le souviens une époque qui avait pas mal d'articles qui étaient sortis sur les en particulier
le problème que tu pouvais avoir si tu faisais ton aide de la base d'un container à cause des
types de file system qui étaient disponibles avec docker à l'époque pas certainement avec d'autres
et en fait j'avais tellement flippé sur les conséquences et la situation que le
le gars racontait j'aimerais bien enfin j'ai pas l'article en tête il s'est retrouvé avec de la
corruption de données mais vraiment hardcore et ils avaient eu toutes les peines du monde à
restaurer la base de données en détail et tout et je me souviens que cet article m'a marqué c'est
devenu ma référence par rapport à ce sujet là et depuis j'ai jamais fait tourner un seul truc
en state full là enfin même dans mon sein boulot sur la comité c'était du full state less toutes
les bases de données c'était les bases de données gérées par le fournisseur de claude et on s'y tenait
quoi enfin pourtant il y a eu des pressions il y en a eu un des gens qui voulaient tout mettre dans
cube parce que ils avaient l'image de coeur shiny qui faisait tourner leur service de cache préféré
qui était trop belle trop sympa mais ça c'est le truc ouais je suis complètement d'accord avec vous
c'est enfin je ne veux pas d'accord avec damir puisqu'il était dans cette position là et tu posais
la même question er 1 c'est le le state full en dehors des conteneurs tout à l'extérieur et du
coup pour ça se dirait est-ce-dire et c'est une des grosses limites à la conteneurisation à mon sens
c'est que pour ce genre de choses on est toujours obligé d'avoir du bairne métal ou de la virtu
pour faire les choses plus stable quoi alors tu parles en plus de gestionner de cache mais c'est
typiquement le genre de base de données que tu peux mettre dans un agréga ou bernet is parce que
justement les données tu peux les perdre c'est pas trop trop grave c'est gênant mais c'est pas trop
grave après je dirais les bases de données ça dépend du type de base et de ce qu'elle contient
et surtout la taille qu'elle font ce qu'en effet les grosses bases de données avec beaucoup de
données je pense que la corruption peut arriver facilement par contre les petites bases de données
moi typiquement j'ai mis une base de données post gris que elle dans un dans un agréga open shift
pendant trois ans à la tournée en prod sans aucun problème le pod je l'ai arrêté je ne sais combien
de fois pour le tester aucune corruption de données après la base de données elle faisait
moins de cinq à dix méga donc c'est des toutes petites bases et je pense que dans ce cas là
avoir des toutes petites bases au sein de l'agréga ça peut être ça peut être une bonne idée mais
après si tu commences à avoir en effet des grosses bases où tu dois le redonder là je serai en effet
très très frileux même si la gestion la gestion du disque et des volumes sont de plus en plus
performantes avec les conteneurs et avec les agrégas mais pour l'instant en tout cas moi j'ai
tendance à de plus en plus dès que je peux utiliser le stockage objet et sortir du stockage
disque quoi qu'il arrive d'autre façon mais après pour moi en tout cas le problème il n'y
pas de technique moi c'est juste un problème encore une fois de cycle de vie moi je pour moi le
conteneur doit avoir un cycle de vie qui est spécifique au conteneur et j'ai pas en je mets
pas le c'est un peu une organisation de travail je ne mets pas tout ce qui est base de données et
tout dans un cluster Kubernetes par exemple parce que c'est pas déjà c'est pas fait pour ça même
si oui ça fonctionne surtout c'est à des petites bases mais surtout c'est que t'as un cycle de vie
qui est tellement différent je trouve ça c'est pas c'est pas très bon pour la pour la pour la
gestion entre guillemets de son cluster de ses potes etc si on voulait détruire les refaire c'est
pas c'est une question là de cycle de vie et ça mais après j'essaye aussi de sortir un maximum
après moi je travaille beaucoup en ce moment avec AWS donc du coup et escaloué donc du coup quand
j'ai une base de données je la sors sur un size manager et je fais ligne d'endor parce que il y a
des systèmes dédiés puisque la sauvegarde ça sera une gestion à part parce que des choses comme
ça après je vais peut-être parler un peu du cas d'usage qu'on a nous c'est une base de données par
clients et du coup quand tu commences à avoir 300 400 500 clients est ce que tu vas aller sur de la
base manager sur 500 base manager une base manager avec des 500 schémas ces questions là non
les a pas encore tranché je dois avouer pour l'instant on est parti sur d'autres façons les bases
ne sont pas très grosses on va les mettre dans cube et si vraiment elle grossisse on se pose la
question mais pour l'instant je sais pas trop mais parce que ça reste des petites bases encore une
fois nous n'est pas sur des gros volumes je vais aller dans ton sens c'est là où je suis effectivement
chaque client à son instance mongo dans sa stack et c'est du coup c'est du docker mais on est aussi
sur des volumes relativement relativement petit et du coup voilà mais je fin je en fait on fait
ça parce que ça y est c'est vraiment cette histoire des échelles aussi on a comme je disais un
bon se pose la question de comment tu tu gères ça et aujourd'hui ça nous rend bien bien service
mais je en tout cas moi je ne suis pas totalement satisfait de ce truc là quoi alors je vais on
arrive vers la fin de cette émission je vais vous demander qu'est ce que vous ne compte ne
riseriez pas pour le moindre qu'impossible pour donner un peu des exemples de ce que on devrait
pas contener les donc il y a les bases de données il y a un grand débat là dessus et le pour ne pas
contener les et à une large audience je suis aussi partie de ces gens là même si je compte
les certaines bases je ne compte pas toutes les bases données mais est ce qu'il y a d'autres cas
pour lesquels justement les contenants on ne doit pas les utiliser d'après vous un exemple qui me
vient je sais pas pourquoi celui en premier les bastions c'est besoin de faire un bastion un rebond
alors que ce soit ssh ou autre technologie j'ai pas tous les exemples en tête là tout de suite mais
il est typiquement parlé de sortir d'un conteneur c'est des choses qui se font encore priori très
bien je me lique la bastion il ya d'or d'une vm ou d'une machine complètement dédiée isolée
je vois pas trop je vois pas trop ce que le conteneur vient d'autre cas d'ailleurs rappelons le mettre
mettre du ssh dans un conteneur c'est une très très très mauvaise idée ne le faites pas
sauf si vous savez ce que vous faites du coup moi ce que je bah après moi je reste un peu sur
ma position mais qui est plus comme j'ai une organisation de train une manière de faire
après je travaille vraiment sur des trucs généralement à très grosse échelle donc c'est pas
forcément même problématique des petites bases de données ça existe pas la plus petite elle doit
faire 15 gigas donc c'est vraiment et c'est une très petite donc du coup c'est pas les mêmes
on va dire les mêmes dimensions mais moi je pense ça pas tout simplement pas conténériser
tout ce qui est du coup stateful c'est une vision des choses après je suis on peut être pour on
peut être contre j'essaye au maximum en tout cas de m'y tenir même si des fois il peut y avoir des
exceptions et je sais comme zé christophe de le déplacer soit dans du s3 soit un autre service
manager soit au pire une partie en yas mais en tout cas ouais là dessus j'essaie d'être assez
intransjusant mais sinon pour être un peu plus troll je ne conteneuriserai pas un master AD Windows
dans un windows core qui est dans docker parce que voilà les conteneurs windows moi
c'est trop lourd je trouve mais bon c'est encore un autre débat mais c'était la petite point de
troll bien sûr pour la fin moi j'ai pas j'ai pas d'idées qui me viennent en tête là comme ça
parce que je rejoint un peu d'amiens même si j'en utilise je suis pas hyper satisfait mais
ouais dès que c'était de fou le jeu j'ai l'impression que ça enfin on fait un truc un peu
contre courant un peu comme les fêtes les fêtes d'image on peut les faire mais avant c'est pas
c'est pas ouf et donc donc après ce que je conteneurise au et pas c'est pas trop j'imagine que dès
que probablement essayer de faire des trucs qui jouent peut-être un peu trop avec du hardware
ou quoi que ce soit ça doit pas être très malin non plus en fait non je sais trop rien
bon mais je crois qu'on va clôturer là dessus si vous n'y voyez pas d'inconvénient je pense
qu'on est arrivé au bout en plus ça fait plus d'une heure alors que d'habitude on atteint l'heure
avec les actus là on atteint l'heure sans les actus autant dire cet épisode est très long alors
si tu es arrivé jusqu'ici ben c'est que le sujet des conteneurs t'intéresse et c'est ce que
on a dit à plus de convaincre à utiliser les conteneurs si tu les utilises pas déjà et
que tu veux apprendre à les utiliser ou à te former je te mets un lien dans la description c'est
le premier lien en description sur une formation c'est la formation de cocaignes mine sur justement
docker donc avec cette formation tu pourras apprendre à te former et tu pourras apprendre pas
à pas avec lui à utiliser docker et en plus il a été assez sympa pour nous filer un bon et avec
ce bon tu vas pouvoir obtenir 20% de réduction sur sa formation donc c'est le premier lien en
description et puis moi je te souhaite une bonne formation je vais donner un petit mot de la fin
avant vous cette fois ci et je vais dédier cet épisode de podcast à canton donc canton si tu
m'écoutes cet épisode il est pour toi le contenu en est pas magique les techniques ne sont pas magiques
ça vient avec des plus des moins il ya des contraintes il ya des des avantages des simplifications
faut pas oublier tout ça faut essayer de comprendre un peu ce qu'on fait de prendre du recul
pas hésiter des fois à dire bah je ne sais pas j'ai m'en saigner du coup voilà ça c'est mon petit
mot de la fin un peu long et pour ceux qui ont tenu je la boire du coup avec paradigme bah je
leur souhaite bon courage pour demain matin non bah c'est assez intéressant c'est rigolo de voir
les différentes expériences sur le sujet et comment comment c'est utilisé par les uns et les autres
vu qu'on a quand même des contextes du quotidien qui sont assez assez différents et c'est
assez intéressant du coup de changer là dessus je vois quand même qu'on converge quand même sur
pas mal de pas mal de points donc c'est c'est quand même rassurant ou pas je ne pense pas rien mais
oui comme dit le disait damien surtout pas de dogme sur le sujet il ya tout tout dépend du contexte
de ce qu'on en fait du besoin et du business et puis pour finir le mot de la fin ça sera gourd
bon moi comme mot de la fin je vais évoquer un nom de techno on n'a pas évoqué de manière à donner
de la matière à les proposer derrière ceux qui connaissent pas c'est cryo on n'a pas parlé de cryo
mais quand on parlait de sortir de docker on a évoqué podman pour faire tourner les les conteneurs
de manière générale mais cryo permet aussi de faire tourner dans cuban et test c'est un runtime
de conteneurs pour cuban et test qui peut remplacer le démon docker voilà de qui laisse là dessus
parce que c'est pas l'objet de redevelopper mais c'est ça donne un truc à étudier par la suite
tout à fait je pense qu'on pourrait faire un épisode spécial alternative à docker et autre
chose pour les déplier et voir moi j'espère que cet épisode vous a plu et si tu n'es pas encore
abonné aux compagnons du dévops et si tu ne pas rejoins encore la communauté bah rejoins nous
on est tous sympathiques et on pourra tous discuter ensemble de pourquoi on doit utiliser les conteneurs
et pourquoi on doit surtout pas utiliser les conteneurs et bien bonne journée et bonne soirée à
tous à bientôt merci d'avoir écouté radio dévops n'oublie pas de noter l'épisode plus la
note sera élevée et plus sera mis en avant dans les applications tu peux aussi le partager ça
nous aidera à le diffuser et à rendre le mouvement plus visible si tu as envie de discuter du mouvement
alors rejoins nous dans la communauté des compagnons du dévops à bientôt la baladeau
diffusion des compagnons du dévops et produit par l'hydra