Microsoft has confirmed general availability for WSL containers, but Docker Compose is still missing from the stack. The company says it is making Compose a priority, yet within the WSL project the choice has not been settled between fully reimplementing Docker Compose or exposing the Docker API directly.

The direction now appears to favor direct API exposure, since the Docker engine is already present and working. Each WSLc session actually runs a standard, full Moby daemon (dockerd); the Unix socket used to reach it is simply not connected to any external entry point. In theory, Microsoft could just expose a listener to the Windows host. But a raw socket would bypass WSLc’s security controls, so the preferred approach is to deploy a filtered access point that intercepts and validates sensitive requests. Tests have been successful: Docker Compose, Dev Containers and Testcontainers all work fully. Some structural limits remain, however, including the lack of multi-architecture support, since the absence of QEMU/binfmt causes foreign binaries to fail.

Microsoft does not mention the community project wslc-compose, which provides a workaround through a Python package. It does cite other tools, including WSL Container Desktop and Lazywslc, both of which address another current WSLc limitation: the lack of a graphical interface for container management.

In the meantime, Microsoft has built a bridge with its EDR, which can extract activity from the WSLc environment and correlate it with host activity. An integration with Intune is also in place, allowing containers to be enabled or disabled and pulls to be restricted to approved registries.

On the networking side, WSLc uses a user-space architecture rather than the shared WSL VM model used by Docker Desktop. Instead of attaching VMs to a standard Hyper-V virtual switch, it creates one VM per container and sends packets as raw Ethernet frames through a virtual queue. A dedicated Windows user-space process continuously reads that queue and re-emits the requests onto the Windows network. This avoids the problems of the traditional WSL2 model — NAT and a separate IP per VM — which can interfere with VPNs and firewalls.

For persistence, each session has its own virtual hard disk storing the overall state of the environment directly on the Windows host. By default, a container’s writable layer is ephemeral, but volumes can preserve data. These are mapped to a host folder exposed to the VM via virtiofs. Microsoft also supports VHD volumes, where the source is not a shared Windows directory but a dedicated virtual disk file. Compared with shared folders, this enforces a strict storage limit, and formatting the volume as ext4 avoids issues with software that handles NTFS quirks poorly.

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.

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

The post Docker Compose, chaînon manquant des conteneurs WSL appeared first on Silicon.fr.