Disponibilité générale actée pour les conteneurs WSL… mais n’y cherchez pas de fonctionnalité à la Docker Compose. Microsoft affirme en faire une priorité. Cependant, au sein du projet WSL, on n’a pas encore tranché entre réimplémenter complètement Docker Compose ou exposer directement l’API Docker.
Vers une exposition directe de l’API Docker On semble se diriger vers la deuxième solution, étant donné que le moteur Docker est déjà présent et fonctionnel. Chaque session WSLc exécute effectivement une version standard et complète de Moby (dockerd). Le socket Unix par lequel on y accède n’est simplement relié à aucun point d’accès externe.
Il suffirait donc théoriquement d’exposer un écouteur vers l’hôte Windows. Un socket brut contournerait toutefois les contrôles de sécurité de WSLC. L’option préconisée consiste ainsi à déployer un point d’accès filtré interceptant et validant les requêtes sensibles.
Les tests ont été concluants : Docker Compose, Dev Containers et Testcontainers fonctionnent complètement. Des limites structurelles demeurent néanmoins. Entre autres, il n’y a pas de prise en charge du multiarchitecture (l’absence de QEMU / binfmt fait planter les binaires étrangers).
Des passerelles avec Intune et Defender Microsoft n’évoque pas le projet communautaire wslc-compose, qui offre un palliatif sous la forme d’un package Python. Il mentionne en revanche d’autres, dont WSL Container Desktop et Lazywslc. Tous deux résolvent une autre limite actuelle de WSLc : l’absence d’une interface graphique de gestion des conteneurs.
Lire aussi : Build 2025 : WSL, un passage symbolique en open source En attendant ces ajouts, Microsoft a créé une passerelle avec son EDR, qui peut extraire l’activité de l’environnement WSLc et la corréler à celle de l’hôte. Une jonction est également établie avec Intune, qui peut activer et désactiver des conteneurs, ainsi que restreindre les tirages à des registres approuvés. Une architecture réseau en espace utilisateur Alors que Docker Desktop tourne dans la VM WSL partagée, WSLc crée une VM par conteneur.
Il ne les attache pas à un commutateur virtuel Hyper-V classique : elles envoient leurs paquets sous forme de trames Ethernet brutes via une file d’attente virtualisée. Un processus Windows dédié en espace utilisateur lit cette file en continu et réémet les requêtes sur le réseau Windows. Cela évite les problèmes que le modèle WSL2 traditionnel – NAT, avec une IP distincte par VM – pose avec les VPN et les pare-feu.
Plusieurs options pour le stockage persistant Chaque session dispose de son propre disque dur virtuel qui stocke l’état global de l’environnement. Il est stocké directement sur l’hôte Windows. Par défaut, l’espace d’écriture d’un conteneur est éphémère.
Des volumes permettent de conserver les données. Ils sont mappés à un dossier sur l’hôte, exposé à la VM via virtiofs. Il en existe une variante : les volumes VHD, où la source n’est pas un dossier Windows partagé mais un fichier disque virtuel dédié.
Par rapport aux dossiers Windows partagés, cela permet d’imposer une limite de stockage stricte. Et le formatage en ext4 évite les problèmes avec les logiciels qui gèrent mal les particularités de NTFS. Illustration générée par IA