Docker Desktop a toujours utilisé des microVMs depuis 2016
En bref
- Docker Desktop (Mac et Windows) repose sur une microVM depuis son acquisition de Unikernel Systems en 2016, pas seulement depuis peu.
- Cette approche combine un minimal VMM basé sur les bibliothèques MirageOS avec un kernel Linux allégé, inspiré par des travaux antérieurs sur les unikernels.
- La distinction marketing entre « Docker traditional » et « microVMs » occulte que Docker Desktop a toujours isolé les conteneurs via une couche de virtualisation légère.
- Les conteneurs Linux en production restent pour la plupart partagés sur le même kernel, sans microVM.
Ce que dit la source
L'auteur réplique à l'engouement récent autour des microVMs (Firecracker, etc.) en révélant que Docker Desktop a intégré une approche de microVM dès 2016 via l'acquisition de Unikernel Systems. Le point clé : ce n'est pas une invention récente, mais une synthèse des technologies de unikernels (code minimal, kernel allégé) et des conteneurs Linux. Docker a construit une « library VMM » embarquée dans l'application Desktop, appelée d'abord hyperkit, puis Docker VMM, afin de faire tourner nativement Docker sur macOS et Windows sans expose un Linux complet ou nécessiter une infrastructure compliquée.
- Unikernels précédaient les microVMs actuelles : MirageOS réduisait le kernel à ses composants utiles, accélérait le boot (20 ms en x86) et prouvait leur sécurité via un challenge Bitcoin resté sans gagnant.
- Docker a combiné l'approche unikernel avec les conteneurs Linux via LinuxKit, un minimal distro embarqué dans la microVM, chaque processus tournant en son mount namespace.
- Le modèle Desktop isole le kernel Linux complet dans une microVM, rendant chaque CVE Linux sans conséquence pour le host (rootless sur tous les plateformes sans surcharge).
- Docker Sandboxes (2026) généralise cette isolation microVM pour les workloads sécurisés, chaque sandbox étant une microVM distincte, utilisée pour exécuter des agents comme Claude.
- La distinction est cruciale : Docker Desktop ≠ Docker Engine en production. Les conteneurs Linux en production partagent un kernel, sans microVM.
Dans les commentaires
Débat partag é, surtout des corrections factuelles et nuances plutôt que du désaccord idéologique.
- Le titre sème la confusion : plusieurs commentateurs critiquent l'imprécision. Le article traite uniquement Docker Desktop (macOS/Windows), pas Docker Engine ou les conteneurs Linux en production, ce qui invalide la généralisation implicite du titre.
- Quelques voix soulignent que la distinction actuelle entre « microVMs modernes » et ce que Docker faisait en 2016 est en grande partie un rebaptisage : QEMU + Virtualization.framework + kernel allégé sur macOS a toujours été une microVM de facto, juste sans le terme à la mode.
- Un commentateur note des failles de sécurité récentes dans Docker Sandboxes (CVE-2026-77179, CVE-2026-79994), contredisant partiellement la narration de sécurité renforcée.
- Préoccupation de confidentialité soulevée : Docker Sandboxes conserve les données 30 jours, ce qui inquiète un utilisateur sur les risques de données capturées via des produits gratuits.
- Débat sur la densité : l'isolation stricte par microVM coûte en efficacité mémoire (hot-plugging imparfait), ce qui peut être problématique en production dense.
Alternatives citées : Firecracker (AWS), rkt (anciennement, n'a pas gagné), wslc (Windows), VirtualBox (cité comme ayant une meilleure API historique)
Notre lecture
Article opportun mais accroche trompeuse. Le message réel, que Docker a résolu depuis 2016 l'isolation macOS/Windows via une approche de microVM, est valide et techniquement intéressant, mais ne s'applique qu'à Docker Desktop. En production Linux, les conteneurs partagent toujours un kernel. Le contexte actuel (buzz microVM, alternatives comme wslc) explique le besoin de clarifier cette histoire. À comprendre si tu utilises Docker Desktop et que tu soucies d'isolation, mais aucune action pour les équipes Linux en prod : ce qu'elles font depuis dix ans reste pertinent.