Conteneurisation – Virtualisation

Article abordant la conteneurisation informatique

La virtualisation a été la première réponse aux ressources non utilisées des serveurs des entreprises informatiques.

Puis, depuis quelques années et, accompagnant le mouvement DevOps, nous avons pu voir l’émergence de ce qu’on appelle la conteneurisation.

Aujourd’hui, on l’associe très fortement à la technologie Docker.

Pourtant, la conteneurisation n’a pas été mise en place dans les 10 dernières années Docker date de 2013, au contraire Linux avait déjà son système de conteneurs LXC dès 2008.

La conteneurisation : Principe de fonctionnement

 La conteneurisation est un type de virtualisation beaucoup plus léger et extrêmement scalable (permettant d’être mis à l’échelle, de s’adapter) par rapport aux machines virtuelles traditionnelles.

Attention, cela ne signifie pas qu’il est nécessaire d’arrêter d’utiliser les machines virtuelles, bien au contraire.

Chaque technologie peut coexister car elle possède chacune un spectre d’utilisation spécifique mais aussi complémentaire.

Avant tout, il faut comprendre le fonctionnement de la conteneurisation. La conteneurisation 2 Pour rappel, la virtualisation reproduit, de manière virtuelle, l’intégralité d’un environnement, à savoir le matériel, le système d’exploitation puis ensuite toutes les applications

C’est donc un système intéressant dans des cas où l’on souhaite utiliser un système d’exploitation différent que celui d’origine ou si l’on souhaite recréer des bureaux virtuels. Par contre, lorsqu’il s’agit de mettre à disposition une application (un site comme Facebook par exemple) cela devient beaucoup plus gourmand.

En effet, Facebook ne se contente pas de déployer une seule machine virtuelle pour les sept milliards d’utilisateurs. Ils sont obligé d’en déployer des milliers pour gérer la montée en charge, la possible défaillance de certaines ou encore pour avoir des temps de réponses intéressants. Un utilisateur Français n’atterrira pas sur un serveur Américain mais plutôt Européen.

On peut donc assez rapidement imaginer que le processus est assez lourd à déployer et maintenir.

 C’est là qu’intervient la conteneurisation.

Conteneur – machine virtuelle

Un conteneur, comme une machine virtuelle, est un environnement clos. Cependant, il se contente d’isoler une partie de l’application et non pas un environnement complet !

Les différents conteneurs vont donc partager le même système d’exploitation et ne vont ré-implémenter que la partie applicative (par exemple Apache, PHP, NodeJS, MySQL, MongoDB, etc)

Voici deux schémas comparant les machines virtuelles et les conteneurs:

Schéma explicatif permettant de comparer le fonctionnement de la virtualisation par rapport à la conteneurisation
Schéma explicatif permettant de comparer le fonctionnement de la virtualisation par rapport à la conteneurisation

On voit, par le biais de ces deux schémas que la conteneurisation est beaucoup plus réutilisable que ne l’est la virtualisation.

Prenons deux applications au sein d’une même société. C’est deux applications utilisent toutes les deux la même version de PHP (librairie sur les schémas)

Si l’entreprise veut cloisonner ses applications, elle devra forcément passer par l’une ou l’autre des technologies.

La première l’obligera à utiliser deux machines virtuelles qui auront probablement la même configuration, simplement le contenu du site qui sera différent.

Pour la deuxième, la conteneurisation, et bien on pourra créer un conteneur avec la bonne version PHP et ensuite deux autres conteneurs qui auront le contenu du site. Ces deux derniers seront reliés au conteneur contenant la version de PHP. On gagne ainsi en maintenabilité et en flexibilité.

De même, si l’on souhaite mettre à jour la version PHP, sur des VMs (Virtual Machine ou machine virtuelle en français), il faudra modifier la configuration de chacune des VMs. Avec la conteneurisation, on ne modifiera que le conteneur PHP.

Et si on souhaite avoir deux versions PHP différentes, pas de soucis, on crée un nouveau conteneur et on l’associe au conteneur qui a besoin de la version PHP spécifique. Le mouvement DevOps Tout ceci peut sûrement te sembler flou et peu utilisable dans ton cas précis.

La conteneurisation s’inscrit très bien dans le mouvement DevOps qui vise à rapprocher les équipes de développement (les développeurs ou Dev) et de gestion des infrastructures (les opérateurs ou Ops)

Succinctement, ce mouvement est né de fortes problématiques de mise en production des applications.

D’une part, à cause des versions qu’utilisaient les développeurs sur leur poste de travail qui n’étaient pas les mêmes que celle sur les serveurs de production engendrant de très gros problèmes lors du déploiement.

D’autre part, sur le manque d’automatisation de certaines tâches et le besoin de mettre en production toujours plus vite, ce qu’on appelle le Time To Market, le temps de mise sur le marché.

Il faut savoir que Instagram délivre des centaines de nouvelles fonctionnalités chaque jour, il serait impossible de le faire si tous les processus n’étaient pas automatiser.

Le DevOps a donc été la réponse à ces problèmes et la conteneurisation étant l’une des technologies utilisait pour suivre ce mouvement. Automatisation des tâches

On retrouve notamment le CI (Continuous Integration ou intégration continue) et le CD (Continuous Deployment ou déploiement continu) qui sont des cycles permettant, pour le premier l’automatisation des tests et de la création d’un livrable (les fichiers que l’on peut ensuite mettre sur un serveur) et pour le deuxième l’automatisation de la mise en production des livrables créés par le cycle précédent.

Ces deux cycles vont donc permettre de créer ou mettre à jour seulement les parties nécessaires de l’application.

On va donc régénérer les conteneurs avec les fichiers à mettre en ligne et si besoin, on refera la génération des conteneurs ayant des versions de librairies différents. Le gain de temps est donc énorme par rapport à un redéploiement complet de machines virtuelles.

À titre informatif, une machine virtuelle prend entre quelques minutes à quelques dizaines de minutes pour être entièrement utilisable, un conteneur prendra seulement quelques secondes à quelques minutes.

Cette différence s’explique encore une fois sur la complexité qu’embarque une machine virtuelle. Poste de travail La conteneurisation étant légère et facile à mettre en place, il a été assez simple au développeur de montée en compétences sur la technologie.

Ainsi, il leur est possible de développer sur leur poste de travail, une application tout en utilisant la technologie de conteneurisation pour être au plus proche de l’environnement de production.

En harmonisant les processus, on a pu supprimer la friction qui existait avant entre les versions d’un poste de développeur et celle d’un environnement serveur.

Docker

Un acteur majeur: Docker Comment ne pas parler de Docker lorsqu’on parle de la conteneurisation ?

Docker est aujourd’hui, l’acteur majeur de cette technologie, même si d’autre comme Linux LXC existe.

Sorti en 2013, la technologie permet la création et la gestion des conteneurs tout en étant tournée vers l’Open Source.

Elle a rapidement connu un engouement et c’est aussi très bien intégrée à l’architecture micro-service utilisée pour le développement des nouvelles applications.

La seule contrainte de Docker et qu’il devra obligatoirement tourner sur un environnement Unix. Pas de panique, sur Windows, le logiciel Docker déploiera de manière transparente une machine virtuelle sous Linux pour te permettre d’utiliser le logiciel.

Sur les autres systèmes d’exploitations, Linux et Mac, tout sera donc natif !

Docker est une très belle technologie, mais quand est-il lorsqu’on doit gérer plus de 200 000 containers comme le fait Paypal ? Les orchestrateurs Lorsqu’on écoute un orchestre musical, il y a toujours un chef d’orchestre, celui qui, grâce à sa baguette et ses nombreux gestes, va être capable d’harmoniser les différents instruments entre eux, mais aussi le tempo à adopter.

Et bien dans la conteneurisation, c’est pareil !

Orchestration et conteneur

Lorsqu’on possède un volume important de conteneurs, on va rapidement devoir orchestrer tous les conteneurs entre eux mais aussi pouvoir les monitorer, c’est à dire, connaitre leur différents états, leur utilisation de ressources et pleins d’autres informations.

Souvent, quand on est dans une grande entreprise, on possédera plusieurs serveurs permettant de mettre en place des conteneurs, tout simplement car on ne peut pas avoir un seul serveur avec un million de Go de mémoire vive et un CPU sur-puissant.

D’ailleurs, si c’était possible ça ne serait pas utilisé, car cela représenterait un véritable problème en cas de défaillance du serveur.

Ce regroupement de serveur s’appelle un cluster, une grappe en français.

L’un des rôles de l’orchestrateur va t’être de dire à un conteneur précis de se lancer sur un serveur précis, tout ceci grâce à des règles que l’on met en place pour avoir une charge serveur égale sur l’ensemble de nos serveurs.

L’orchestrateur va aussi être en mesure de rapidement déployer de nouveaux conteneurs pour permettre d’assurer une montée en charge sur une application.

Imaginons un site e-commerce, il est possible que le trafic de ce site se condense de 17h à 19h. Ainsi le reste du temps, pas besoin d’avoir des gros serveurs qui consomment de l’énergie.

Grâce à l’orchestration et à la rapidité de mise en place des conteneurs (contrairement aux VMs), on va pouvoir déployer des conteneurs de manière instantannée pour supporter le trafic lorsqu’on détectera un pic de trafic et ces mêmes conteneurs seront éteints lorsque le trafic baissera. Tout ceci sera entièrement automatisé grâce à l’orchestrateur. Pas mal non ? Les acteurs de l’orchestration

Il y a de nombreux acteurs dans ce domaine-là.

Mais il existe tout de même des noms qui ressortent régulièrement et qui sont très largement répandus.

Docker Swarm est l’orchestrateur livré avec Docker. Ce n’est pas forcément le plus utilisé mais il a le mérite d’être entièrement fonctionnel avec Docker puisque provenant du même écosystème.

Kubernetes est certainement LE plus connu des orchestrateurs. Développé et soutenu initialement par Google puis donné à la Fondation Cloud Native Computing, la technologie est Open Source et possède une très large communauté. L’outil, complet, et aussi complexe à prendre en main.

Parmi les autres acteurs, on retrouvera évidemment les clouds comme Azur, Amazon ou encore Google. Le petit détail est que, ces 3 derniers utiliseront eux-même la technologie Kubernetes en arrière-plan pour gérer l’orchestration. Ils ne fourniront finalement qu’une interface simplifiée, pas la mise à disposition d’une nouvelle technologie.

Conclusion

Aujourd’hui, dans le monde du développement, la conteneurisation est une compétence devenue quasi incontournable.

En effet, quasiment toutes les propositions d’embauches mentionnent le mouvement DevOps ou la technologie Docker, c’est donc une carte à avoir dans sa main si l’on souhaite sortir son épingle du jeu.

Toutefois, la conteneurisation étant largement tendance, n’oublions pas que la virtualisation a encore de très beaux jours devant elle car elle reste, malgré tout, une technologie extrêmement puissante dans des cas où la conteneurisation est inefficace.

Thomas C

Formateur sur des parcours DWWM & CDA, j'ai décidé d'aller plus loin en te partageant mes connaissances en vitesse supersonic 🚀 Prends ta revanche sur la vie !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Formation Développeur Web