Conteneur VS VM

Dans ma précédente explication en deux minutes, je suis passé rapidement sur les deux choix possibles qui s’offrent à nous en termes de virtualisation. Revenons un peu plus sur ce choix et comparons rapidement les deux.

VM

Avant tout, il est important de rappeler que VM signifie Virtual Machine et une VM, ça porte plutôt bien son nom. En réalité, le principe de virtualisation est possible, car nous avons créé des logiciels tels que VMware ou VirtualBox par exemple qui ont pour objectif de faire semblant d’être une machine physique réelle et tangible.

Ce genre de programme, que l’on appelle souvent des hyperviseurs, ce sont eux réellement qui abstraisent notre machine physique en une fausse machine avec des faux composants matériels émulés sur lesquels nous pouvons lancer des machines virtuelles. En d’autres termes, le nec le plus ultra de l’hyperviseur est celui qui fake tellement bien être une machine physique que les machines virtuelles le croient et fonctionnent sans problème.

Les VM ont plusieurs avantages. On peut par exemple découper un serveur très puissant en plein de petits serveurs virtuels que l’on peut louer à des clients (c’est ce que l’on appelle des VPS). On peut aussi grâce à la virtualisation tester et déployer des applications sur plusieurs OS différents. On pourrait ainsi créer une VM Windows, une autre Windows serveur et une dernière sur Ubuntu par exemple et déployer ce que l’on veut sur chacun de ces environnements.

Mais le plus gros avantage de cette virtualisation, c’est-à-dire sa versatilité, et aussi son plus gros défaut. Créer une VM, ça peut prendre beaucoup de temps, car comme tout travail de faussaire, cela implique de mettre en place et de reproduire tout ce que peut composer un ordinateur. De plus, nos ordinateurs de tous les jours n’ont pas été créés pour être des champions de la virtualisation. Il existe des systèmes d’exploitation dédiés à la gestion des VMs, beaucoup plus efficaces que nos OS de tous les jours, mais qui sont, en pratique, inutilisables pour les humains dans le travail quotidien d’un développeur ou d’un Ops par exemple.

Conteneur

De l’autre côté du navire, on a les conteneurs. Les conteneurs ont une différence fondamentale : ils se basent tous sur l’OS sur lequel on les lance. En réalité, un conteneur n’est qu’un processus avec des droits et des isolations particulières tournant sur un kernel Linux.

Pour autant, de notre point de vue de développeur, c’est quasiment la même chose qu’une VM : on duplique nos fichiers et installe nos dépendances dans le conteneur, l’exécution de notre programme est isolée et on peut dupliquer notre conteneur à l’infini. Sur certains logiciels de conteneur, on a même choisi l’OS sur lequel va tourner notre programme, comme pour les VM.

En réalité, dans le cas général des conteneurs, 99% du temps, on n’utilise que des OS basés sur le kernel Linux (Ubuntu, Debian, …) et ceux, même sur Windows ou Mac. Lorsque l’on utilise un système de conteneurisation sur Windows ou Mac, nous devons souvent installer un programme intermédiaire tel que Docker Desktop, par exemple.

La fonction de Docker Desktop est simple : fournir une interface graphique sympathique pour les haters de Docker et des lignes de commande, mais aussi, d’installer une VM Linux très simple sur laquelle vont tourner les conteneurs que l’on lance. Et oui, sur Windows ou Mac, vos conteneurs tournent tous sur une VM Linux, cachée. Sur un ordinateur Linux, les conteneurs sont directement lancés sur la machine.

Vous l’aurez compris, les conteneurs sont plus rapides, car ils se servent d’éléments du système d’exploitation pour simuler de l’isolation et de la virtualisation entre les différents conteneurs lancés sur un même système. C’est ainsi plus rapide de lancer une image de conteneur à la volée car ces derniers se lancent comme un simple processus et non pas besoin d’un logiciel simulant tout l’aspect matériel du système.