Contexte et objectifs

Docker Desktop 4.86 beta introduit un gestionnaire de machines virtuelles (VMM) interne. L’enjeu principal est d’éliminer les disparités de performance entre macOS, Windows et, à terme, Linux, qui proviennent aujourd’hui de solutions de virtualisation tierces (HyperKit, WSL 2, Hyper‑V). En centralisant la couche d’hypervision, Docker vise à réduire les temps de startup, à améliorer la récupération après incident, à optimiser les entrées‑sorties et le partage de fichiers, ainsi qu’à diminuer la consommation mémoire globale.

Architecture du nouveau VMM

Le VMM interne repose sur un noyau hyperviseur développé par Docker, intégré directement dans le processus Docker Desktop. Il exploite les primitives de virtualisation natives du système d’exploitation hôte : hypervisor.framework sur macOS, les API Hyper‑V sur Windows et, lorsqu’il sera disponible, les interfaces KVM sur Linux. Cette approche permet de créer une machine virtuelle unique qui héberge le moteur Docker, le daemon et le réseau, tout en conservant un accès direct aux ressources du disque via des pilotes de partage de fichiers optimisés. Le design élimine la chaîne de traduction « Docker → hyperviseur tiers → hôte », réduisant ainsi la latence d’I/O et le nombre de copies de mémoire.

Analyse des impacts de performance et limites

Les premiers benchmarks internes indiquent une amélioration de 15 % à 30 % du temps de démarrage des conteneurs, ainsi qu’une réduction de la consommation mémoire de 10 % à 20 % grâce à un pool de mémoire partagé entre le VMM et le daemon Docker. Le partage de fichiers, souvent goulot d’étranglement sous HyperKit, bénéficie d’un accès direct au système de fichiers hôte, ce qui se traduit par des débits I/O supérieurs de 2 à 3 fois sur les charges de travail intensives en lecture/écriture. Toutefois, le VMM reste en phase bêta : la prise en charge Linux n’est pas encore généralisée, et certaines extensions Docker Desktop tierces peuvent rencontrer des incompatibilités avec la nouvelle couche d’abstraction. De plus, la dépendance aux API de virtualisation propres à chaque OS impose des contraintes de mise à jour synchronisée avec les évolutions du système d’exploitation.