Docker et machines virtuelles : ce qui les différencie vraiment
La réponse courte
Une machine virtuelle émule un ordinateur entier. Elle a son propre noyau, ses propres pilotes, sa propre copie complète d'un système d'exploitation, le tout posé sur un hyperviseur qui simule du matériel réel en dessous. Un conteneur Docker, lui, partage le noyau de la machine hôte et n'isole que ce qui se trouve au-dessus : le système de fichiers, l'arborescence des processus, la pile réseau. Cette seule différence explique presque tout ce qu'on remarque ensuite : les conteneurs démarrent en quelques millisecondes, les VM prennent plusieurs dizaines de secondes ; on peut faire tourner une dizaine de conteneurs confortablement sur un ordinateur portable qui peinerait avec trois VM.
Pourquoi partager un noyau change tout
Le noyau d'un système d'exploitation est la partie qui parle directement au processeur, à la mémoire et au disque. Démarrer une VM signifie démarrer un second noyau complet depuis zéro, exactement comme votre ordinateur démarre quand vous l'allumez, sauf que c'est dans une boîte simulée. Un conteneur ne fait jamais ça. Quand vous lancez docker run ubuntu, Linux ne démarre pas un nouveau noyau Ubuntu — il utilise les namespaces et les cgroups, deux fonctionnalités déjà intégrées au noyau Linux, pour faire croire à un processus (ou à un petit groupe de processus) qu'il a son propre système de fichiers, son propre nom d'hôte, sa propre liste de processus, et sa propre part de CPU et de mémoire, alors qu'il tourne en réalité exactement sur le même noyau que l'hôte.
C'est aussi pour ça que Docker sous Linux est natif et rapide, alors que Docker sous Mac ou Windows fait discrètement tourner une petite VM Linux en arrière-plan pour que les conteneurs aient un noyau à partager — parce qu'il n'y a sinon aucun noyau Linux disponible. Si vous vous êtes déjà demandé pourquoi Docker Desktop sur Mac consomme nettement plus de mémoire que ce que les conteneurs eux-mêmes semblent utiliser, c'est cette VM cachée qui fait le travail que Linux offre gratuitement.
Ce qu'on perd vraiment avec un conteneur
De l'isolation, mais pas autant qu'on pourrait le croire. L'isolation d'une VM est garantie par le matériel lui-même — l'hyperviseur utilise les fonctionnalités de virtualisation du processeur pour s'assurer qu'une VM ne peut vraiment ni voir ni toucher la mémoire d'une autre, même si l'OS invité à l'intérieur est compromis. L'isolation d'un conteneur est garantie par les règles de namespaces et de cgroups du noyau hôte — solide en pratique, mais une faille au niveau du noyau qui permet de s'échapper d'un conteneur a un chemin bien plus court vers l'hôte qu'une évasion depuis une VM. C'est la vraie raison pour laquelle les plateformes multi-clients sensibles à la sécurité (un fournisseur cloud qui fait tourner le code d'inconnus, par exemple) continuent d'utiliser des VM, ou des conteneurs qui tournent à l'intérieur d'une VM, plutôt que des conteneurs nus.
On perd aussi en flexibilité d'OS. Une VM peut faire tourner Windows sur un hôte Linux, ou une ancienne version de noyau à côté d'une récente, parce que chaque VM a vraiment son propre noyau. Un conteneur tourne toujours sur le noyau de l'hôte : on peut changer de distribution (un conteneur Ubuntu sur un hôte Debian ne pose aucun problème — ce ne sont que des fichiers et un gestionnaire de paquets) mais pas de noyau. C'est pour ça qu'il n'existe pas de "conteneur Windows" tournant sur un hôte Linux, quoi que prétende contenir l'image.
Pourquoi ça a autant compté pour la façon dont on livre les logiciels
Avant que les conteneurs ne se généralisent, "ça marche sur ma machine" était un vrai problème, constant — une application Python qui tournait très bien sur le portable d'un développeur cassait en production à cause d'une version de bibliothèque différente, d'un paquet système manquant, ou d'une différence d'OS que personne n'avait pensé à vérifier. Une image de conteneur embarque l'application et tout ce dont elle dépend — jusqu'à la version précise de chaque bibliothèque — dans un seul artefact qui se comporte de façon identique partout où il tourne, parce qu'il ne compte pas sur le fait que l'hôte ait déjà les bonnes choses installées. Une image de VM peut faire ça aussi, techniquement, mais au prix d'embarquer un OS entier à chaque fois, ce qui est lent à construire, lent à démarrer et lent à faire circuler sur un réseau.
Cette combinaison — démarrage rapide, images légères, comportement identique partout — explique pourquoi un seul serveur peut désormais faire tourner des dizaines de petits services indépendants en conteneurs au lieu d'une poignée de grosses VM monolithiques, et pourquoi "conteneuriser l'appli" est devenu une première étape aussi courante quand une équipe décide de moderniser sa façon de déployer.
Quand on a encore besoin d'une VM
Les conteneurs n'ont pas rendu les VM obsolètes — ils les ont juste déplacées à un autre niveau. Les fournisseurs cloud font toujours tourner vos conteneurs à l'intérieur de VM, parce que c'est là qu'ils obtiennent l'isolation garantie par le matériel entre les charges de travail de différents clients. Si vous avez besoin d'un système d'exploitation entièrement différent, ou de l'isolation la plus forte possible pour quelque chose de non fiable, une VM reste le bon outil. Les conteneurs ont résolu un problème précis, extrêmement courant — "packager et faire tourner un logiciel de façon cohérente, rapide, sans le poids d'un OS complet" — sans remplacer les autres raisons d'exister des machines virtuelles.
Comprendre cette distinction est aussi le moyen le plus rapide d'arrêter d'être perdu face à la moitié du vocabulaire de l'infrastructure moderne : un "node" Kubernetes est en général une VM, qui fait tourner de nombreux conteneurs ; un "pod" est un petit groupe de conteneurs qui partagent un namespace réseau ; et quand quelqu'un parle de "serverless", ce qui exécute réellement votre code est, la plupart du temps, encore un conteneur — juste un que vous n'avez jamais eu à démarrer vous-même.