¶ Introduction
Dans cette page vous allez apprendre à découvrir le concept de conteneurisation ! Je ne parlerais ni de Docker ni de Kubernetes en détails dans cette page mais je vais vous expliquer globalement quel est le concept de conteneur et en quoi cela diffère de la virtualisation “traditionnelle”.
¶ D'où vient le concept ?
La technologie de conteneur telle qu'on la connait aujourd'hui a vue le jour en 1979 avec la version 7 d'Unix et le système chroot, ce système permet d'isoler les processus en les “isolants” et en leur donnant des accès restreint (dossier, fichiers, etc…)
La technologie ne sera pas plus développé jusqu'au début des années 2000 avec les “jails” sur les environnements FreeBSD, on pouvait alors retrouver déjà à l'époque plusieurs “jails”/partitions sur le même système.
Ce concept a pas mal évolué au fil des années pour arriver sur les solutions LXC aux alentours de 2008 puis au développements de solutions comme Warden autour de 2011 ou Docker en 2013.
Aujourd'hui les solutions de conteneurisation dominent de plus en plus le marché de l'emploi avec une explosion d'environnements comprenant docker, kubernetes, hyper-v et j'en passe.
¶ Comment ça marche ?
Le concept en soit est très “simple” a comprendre.
Ci-dessous vous avez un comparatif entre les machines virtuelles & les conteneurs.
On observera les éléments suivants :
Une machine virtuelle pour fonctionner a besoin d'un logiciel dit “hyperviseur” (type 1 ou 2) & d'un “guest os”, autrement dit d'une système d'exploitation complet sur lequel faire tourner la machine virtuelle. Dans le schéma ci-dessus on pourrait ajouter entre l'hyperviseur et “l'infrastructure” un OS s'il s'agissait d'un hyperviseur de type 2.
De l'autre côté concernant les conteneurs, on observe la "même" dépendance concernant un logiciel permettant de faire tourner la solution (d'un côté l'hyperviseur de l'autre un “container engine”), la différence est que le container engine va simplement faire interagir les applications directement avec l'OS source.
Le container engine va alors s'occuper de récupérer les librairies nécessaire à faire tourner le contenu de l'application.
Exemple : Pour faire tourner un serveur minecraft vous avez besoin “uniquement” de Java & pas besoin des commandes ping, nslookup, etc…
L'avantage est donc considérable par rapport à de la virtualisation classique, cette solution avec un comparatif “mathématiques” nous permet de voir déjà que la conteneurisation est largement plus légère car OS+Logiciel+GuestOS > OS+logiciel+librairies (= Windows+Vmware+WindowsServer > Windows+Docker+librairies Python)
¶ Un exemple ?
Admettons l'idée suivante : vous voulez monter votre propre cloud avec NextCloud.
Si vous le faite avec de la virtualisation vous devez installer un OS de base (ou directement un hyperviseur de type1), vous devez ensuite sélectionner l'OS avec lequel faire tourner NextCloud (ex : debian), l'installer, etc…
Vous vous retrouverez alors avec votre OS de base qui prend des ressources logiciels & matériels (ex OS de base Windows 10 : 4Go de RAM) + le logiciel de virtualisation qui consomme des ressources aussi (ex : vmware workstation) + le système d'exploitation “invité” (le fameux “guest os”) Debian qui prendra des ressources logiciels & matériels (ex sans GUI : 512Mo de RAM) ajoutez à cela l'application NextCloud & vous avez déjà une machine “lourde”
En conteneurisation vous installez votre OS de départ (ex : Debian) + un logiciel de virtualisation par dessus (ex : Docker), le logiciel s'occupera ensuite d'aller chercher les librairies supplémentaires nécessaire à faire tourner Nextcloud et l'isolera.
La solution de conteneurisation vous permettra d'économiser : du temps, des ressources matérielles, de la prise de tête à rendre compatible votre OS de base avec l'application (ex : prise de tête de rendre un environnement Linux “stable” sur Hyper-V) mais également de l'argent car si vous virtualisez une machine Windows il faut une licence alors qu'ici un conteneur n'aura pas besoin d'une licence !