Alors faut-il faire de la conteneurisation sur de la machine virtuelle ou de la machine physique ?
C'est une question qui revient assez souvent, je vous propose qu'on l'aborde dans ce podcast.
C'est une question qu'on m'a posé très récemment dans un live, mais c'est aussi une question qui revient assez souvent dans les commentaires de la chaîne ou dans les lives,
et également en messages privés sur LinkedIn.
Donc la première chose en préambule, je trouve ce qui est important, c'est de voir un petit peu le contexte où on se pose cette question-là.
Donc d'une part, il y a deux choses.
Le contexte de l'entreprise, les nécessités de performance, les ressources financières qu'on a à notre disposition, il faut bien avoir tout ça en tête.
Et puis également le contexte de la personne qui vous pose cette question.
C'est une personne qui est réfractaire à un changement.
Ça sert pas à grand chose généralement de discuter avec la personne.
Vous pouvez en discuter un petit peu, mais généralement la discussion ne sera pas forcément très intéressante techniquement.
Néanmoins, ça veut pas dire que le projet est forcément fondé, mais si on pose cette question-là, c'est que déjà on a essayé de dire qu'on va passer à la containerisation,
donc ça sert à rien de se la poser juste pour remettre en cause la containerisation, il faut se la poser pour des vraies raisons.
L'autre élément qui est important à avoir également en tête, c'est que effectivement la containerisation, si on l'applique sur de la machine virtuelle,
bien sûr c'est un petit peu du gâchis, et de fait, qu'est-ce qui va se passer ?
C'est qu'on va lancer différents noyaux, on va affecter différents ressources, CPU et RAM pour chacune des VM.
Et derrière, on va lancer des containers dans ces VM, peut-être même plusieurs containers, mais on va forcément avoir de la perte si on réalise ce type d'opération.
Ou en tout cas, on n'aura pas tout de suite le bénéfice de la vraie containerisation clusterisée sur machine physique.
Alors du coup, vous me direz mais pourquoi éventuellement faire ce type d'opération ?
Alors pour moi, c'est juste une question de temps et d'adoption d'un changement qui est la containerisation.
Donc ça, c'est quelque chose qui est très important, je trouve à avoir en tête.
Et derrière, ce n'est pas un odin que d'aborder les choses comme ça.
Donc déjà, dans un premier temps, ce qu'on peut se dire, c'est peut-être qu'on fait déjà de la machine virtuelle.
Donc rien que le fait de containeriser sur de la machine virtuelle, peut-être que déjà vous n'allez non pas consommer forcément plus de ressources,
mais peut-être que vous allez déjà commencer à densifier, un temps soit peu, les applications que vous allez déployer.
C'est-à-dire que vous allez commencer à pouvoir mettre plusieurs applicatifs sur les mêmes VM, ce que vous ne faites pas forcément encore,
ou peut-être que vous vous le faites de manière extrêmement modérée, que vous allez pouvoir de fait le faire un petit peu plus.
Alors néanmoins, il ne faut pas se cacher des choses.
C'est que utiliser de la containerisation, ça nécessite, si vous utilisez par exemple Docker, d'avoir un Unjank,
consommer un petit peu de ressources, c'est pas de man, c'est un petit peu délicat.
Mais en tout cas, vous voyez que tout de suite, le gain n'est pas effectif quand on le réalise forcément avec la machine virtuelle.
Néanmoins, on peut quand même le faire, c'est-à-dire qu'on peut commencer à densifier un petit peu les choses.
Alors moi, je vous disais, c'est quand même plutôt une question d'adoption et une question de temps.
Donc là, c'est ce qu'on va voir tout de suite, c'est-à-dire que je fais personnellement ce type d'opération pour l'avoir déjà réalisé,
plutôt en deux temps.
Premier temps, ça va être l'adoption de la containerisation.
Et le deuxième temps, ça va être l'adoption de la clusterisation de containerisation.
Il faut bien s'indé les deux. En tout cas, me semble-t-il, c'est un sujet qui est assez intéressant,
sauf pour les sociétés qui veulent passer le pas, mais de manière assez importante,
on saute au-dessus du fleuve directement et on essaie pas juste de sauter au-dessus d'un petit cours d'eau.
Mais néanmoins, première chose, donc, c'est la containerisation.
Alors pourquoi la containerisation, l'adopter, c'est quand même un changement.
Tout simplement parce que déjà, ça monopolise différentes équipes.
Première chose, ce qu'il va falloir revoir dans cette phase d'adoption de la containerisation,
c'est le développement.
Donc, on va avoir des équipes de développeurs qui vont devoir commencer à apprendre à utiliser la containerisation,
que ce soit local, mais également à distance,
avec également l'apprentissage de nouveaux outils, tels que le docker file, par exemple,
pour pouvoir builder des images docker ou autres, en tout cas des images au format OCI.
Et puis également, avec le docker file, vient la capacité à pouvoir les faire de manière relativement légère,
ces images, donc il y a des bonnes pratiques à respecter,
et surtout des bonnes pratiques d'un point de vue sécurité.
Et ça, il faut les adopter à la fois par les équipes de dev,
les équipes d'ops peuvent accompagner pour expliquer un petit peu les choses,
comment ça fonctionne, un déploiement de containers,
quel est l'utilisateur qu'il utilisait par exemple, etc.
Donc ça, c'est des éléments qui sont assez importants,
déjà d'un point de vue pratique de développement.
Ensuite, il y a la pratique de déploiement.
Ce qui peut se passer, c'est que vous avez soit un pipeline de déploiement,
un CI-CD qui existe déjà, mais qui est embryonnaire,
et puis quand on va passer à la containerisation, on va intensifier vraiment les choses.
On va vouloir déployer beaucoup plus,
on va vouloir déployer un petit peu autrement et avec plus de fluidité,
et là, ça va apporter des changements nécessités,
soit d'adaptation, soit de création carrément de pipeline.
Pour y ajouter avec les pipelines,
on va parler des choses d'un périmètre qui peut être relativement étendu,
on va dire, avec des checks de sécurité, potentiellement,
avec des checks de test et des batteries de test qui peuvent être réalisées dessus.
Donc pour ça, il y a besoin de bien prendre en compte les évolutions qu'on doit faire
pour faire évoluer le déploiement et prendre en compte la containerisation dans le déploiement.
Et ça, ce n'est pas anodin, c'est quand même quelque chose qui est important,
qui est à cheval aussi généralement entre deux équipes, les devs et les ops, toujours.
Et donc, la manière dont on va aborder ça, avec le plus ou moins de pression que vont avoir les équipes
et la fluidité qu'on va pouvoir avoir en termes de communication entre les équipes,
ça va avoir un rôle impactant et structurant pour votre entreprise.
C'est-à-dire que si lorsqu'on aborde ce sujet-là, on met des pressions,
parce qu'on veut aller très vite et qu'on veut faire,
donc sur de la machine physique comme on parlait tout à l'heure
et en même temps, la clé de stérisation, etc.,
on aborde plein de sujets en même temps sur des délais qui peuvent être relativement courts,
eh bien ce qui va se passer, les équipes vont être tendues,
on va les faire travailler entre elles et c'est là où peut-être ça peut mal se passer.
Et du coup, ça va créer un passif entre les équipes, un historique,
ce qui fait que ça peut être structurant comme destructurant finalement.
Donc si ça se passe très bien, vous allez pouvoir avoir vraiment pratiqué du DevOps,
c'est-à-dire vraiment avoir une fluidité entre les deux équipes,
dev et ops, ou même des personnes qui vont pouvoir naviguer entre les uns et les autres,
avoir des modes de communication mis en place spécifiquement
pour trouver de la fluidité entre les deux, etc.
Donc ça, c'est quelque chose qui est important.
Et donc, l'élément, le troisième élément qui vient avec ça, c'est l'organisation,
on a parlé du build, on a parlé donc du build de développement,
on a parlé des pipelines CICD, mais il y a l'organisation.
Et ça, c'est important, c'est qu'il doit y avoir quelqu'un qui doit driver cette conteneurisation,
mettre en place des nomenclatures éventuellement pour comment taggent les images,
ou est-ce qu'on pousse les images, de quelle manière on va les pousser,
donc définir une registrie, sécuriser, etc.
Et donc là, il faut qu'il y ait un pilote dans l'avion,
ne serait-ce que sur cette thématique là, au moins au début pour guider les choses,
mettre en place des choses, et s'assurer ensuite avec le temps que les choses vont être maintenues.
Et ça, c'est quelque chose qui est relativement important,
et au-delà d'être important, c'est structurant,
c'est-à-dire ça va permettre éventuellement de tirer les équipes vers le haut
et de les faire travailler entre elles encore mieux que ça était le cas auparavant.
Maintenant, donc on a vu l'aspect conteneurisation,
et c'est à partir de ce moment là,
donc où je me dis, finalement, la virtualisation,
c'était pas cette problématique de conteneurisation,
ne reposez pas sur la problématique de virtualisation,
c'était pas un problème d'avoir des machines virtuelles finalement.
Et j'ai pu faire monter mes équipes en compétences,
y aller progressivement, et maintenant, dans un deuxième temps,
je vais pouvoir me dire, ok, je veux faire de la clusterisation de conteneurs,
tout simplement, par exemple, cubernétisme,
ça peut être du soir ou autre chose, peu importe,
c'est pas le sujet aujourd'hui,
mais derrière, on va se dire, ok,
comme lors de la vidéo précédente,
on a vu qu'il y a plein de fonctionnalités qui sont extrêmement intéressantes,
qui viennent avec les conteneurs,
notamment la haute disponibilité,
le scaling up, down, automatique, non-automatique,
l'auto-discovery pour le monitoring, etc.
Donc il y a plein de sujets qui viennent avec,
et ça, c'est extrêmement intéressant.
Et sur la clusterisation,
là encore, ça va être quelque chose qui va avoir une approche intéressante
pour les ops, notamment.
C'est-à-dire que, on va, du coup, cette fois-ci, se dire,
avoir de la machine virtuelle et faire un cluster de conteneurs
sur la machine virtuelle,
là, maintenant, ça devient beaucoup moins intéressant.
Il va falloir maintenir,
peut-être maintenir plein de machines, etc.
et ça apporte vraiment peu de choses,
puisqu'en fait, si on prend notre orchestrateur de conteneurs,
finalement, ils jouent le rôle de notre hyperviseur
au système d'hypervision, finalement.
Et surtout, on va éliminer toute la couche noyau
qu'on va avoir pour chacune des VM qui consomment de la ressource,
inutilement.
Donc là, on va se dire, OK, on parle là-dessus.
Et vient avec ça de sujets.
Donc on peut se dire, finalement, sur la clusterisation,
généralement, il y a des masters.
Là, on peut garder éventuellement de la machine virtuelle.
Attention quand même à garder des performances relativement importantes.
Si on parle sur Kubernetes avec OTCD,
il faut quand même avoir des latences relativement faibles en écriture.
Donc on va garder du SSD sur de la VM.
Il n'y a pas de souci, ça fonctionnera très bien.
Et puis, par contre, à côté, on va avoir des workers.
Et sur les workers, il y a deux cas de figure.
Soit on a le cas qui est un petit peu plus complexe,
c'est-à-dire on va gérer du stockage,
éventuellement du stockage local ou distribué sur Kubernetes.
Et là, dans ce cas-là, ça va être un petit peu différent
de l'autre cas de figure où on n'a vraiment aucun stockage.
Quand il y a du stockage, bon, il va falloir vraiment monter en compétences
sur la gestion, la performance de notre cluster,
notamment en matière d'exploitation de ce stockage.
Mais néanmoins, ce qui est très intéressant,
intéressant, pardon, dans les deux cas de figure,
mais le plus quand on n'a pas de stockage,
c'est de se dire finalement, nos machines physiques,
qu'est-ce qu'elles fournissent à nos conteneurs,
là finalement, du CPU et de la RAM.
Et là, on va avoir une couche, on va se démarquer assez facilement
du hardware sur lequel on se situe.
Et on va même peut-être pouvoir par exemple recycler
d'anciens matériels pour dire,
voilà, ce qu'il me faut, c'est du CPU et de la RAM.
La haute dispo que j'ai et qui est extrêmement opérationnelle
avec des latences relativement faibles dans mon cluster,
par exemple, Kubernetes,
eh bien ça va me permettre de faire abstraction,
ou en tout cas plus abstraction de ce que j'avais avant
en matière de virtualisation pour utiliser le hardware qui est en dessous.
Et pour ça, du coup, je vais pouvoir utiliser un petit peu ce que je veux en dessous,
peu importe moi ce que je cherche, c'est du CPU et de la RAM.
Et ça, c'est quelque chose d'intéressant.
Alors c'est le cas également pour la virtualisation,
par exemple, quand on va utiliser,
je ne sais pas, Proxmox, VMware ou peu importe,
c'est quand on va apporter du CPU et de la RAM.
Néanmoins, par moments, on va sentir quand même une accroche assez importante du hardware.
Là, ce qui est quand même beaucoup moins le cas avec Kubernetes,
on peut se sentir un petit peu libéré de cet aspect-là.
Mais bien sûr, en matière de virtualisation,
on peut faire l'association à l'hyperconvergé,
par exemple, ce genre de choses,
où finalement, on va raquer du serveur,
on ne se préoccupe pas trop de ce qu'on va faire tourner dessus,
si ce n'est qu'on sait qu'on le fait rentrer dans un cluster,
il apporte son CPU, sa RAM et du stockage,
et derrière, finalement, c'est parti.
Et donc là, on a vu les deux aspects,
et ces deux aspects, comme je vous disais,
pour moi, la réponse n'est pas forcément de dire
est-ce que c'est intéressant ou pas sur la machine virtuelle,
mais c'est plutôt dans quelles étapes on se situe et dans quelles phases on souhaite les réaliser.
Donc, premier temps containerisation,
deuxième temps clusterisation de container.
Voilà, donc j'espère que ce podcast vous a plu.
N'hésitez pas à vous abonner, que ce soit sur Apple, sur Android, peu importe.
Vous pouvez taper Ocha, à U.S.H. à Xavki, dans votre moteur de recherche.
Vous allez pouvoir également vous abonner par mail de fait,
sur la page que vous allez découvrir.
Et n'hésitez pas surtout à le faire découvrir autour de vous,
et moi je vous dis à très bientôt.
Ciao à tous !