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 en 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 conserve 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.

Le 1er septembre, Mark Harmstone a publié WinBtrfs 1.10 , le pilote qui fait lire et écrire des partitions Btrfs à Windows. Et je trouve qu'il était temps, parce que la version précédente datait quand même de mars 2024.

Le principe, lui, n'a pas bougé. Vous avez un disque formaté en Btrfs, celui de votre Linux en dual-boot par exemple, et plutôt que Windows l'ignore totalement comme votre date ignore vos textos le lendemain, celui-ci arrive dans l'explorateur de fichiers avec sa petite lettre de lecteur, en lecture comme en écriture. Ce driver pour le système de fichiers Btrfs a été réécrit from scratch, sans reprendre une seule ligne du noyau Linux, et c'est quand même du LGPL.

Alors regardons ce que cette 1.10 répare, parce que la liste vaut le détour. Déplacer un fichier d'un subvolume vers un autre faisait totalement planter le pilote, ce qui fait qu'il était compliqué de mettre un fichier à la corbeille. Laisser Steam créer plein de fichiers d'un coup le faisait aussi planter comme une merde, sans parler du fait qu'écrire sur un snapshot corrompait l'arbre d'extents.

Bref, c'était compliqué jusqu'alors, d'avoir un usage normal d'un disque formaté en Btrfs.

Cette nouvelle version répare aussi la préallocation, ce qui remet rclone d'aplomb, un blocage sur les liens durs, et une corruption mémoire liée à la surveillance du registre. Elle ajoute aussi l'écriture des bitmaps d'espace libre et des fichiers compressés en ligne, deux choses qu'elle savait jusqu'ici seulement lire. En échange, le RAID disparaît sur les périphériques amovibles (si vous en faisiez sur des clés USB, c'est finito pépito).

Reste à savoir comment Harmstone a fait pour nous pondre 370 commits en quatre semaines ? Est-ce la coke ? Est-ce la caféine ? Hé bien non, le README répond à cette question sans détour : C'est Claude d'Anthropic qui l'a, je cite, "grandement aidé" sur la chasse aux bugs et les revues de code. Il ajoute dans la foulée que tout le code a quand même été écrit à la main (wink wink ^^).

Maintenant, est-ce que vous avez besoin de ce driver ?

Chez Paragon, le produit Btrfs dédié est marqué "Legacy" et indisponible depuis octobre 2025, et dans leur suite qui reste vendue, Btrfs est encore en lecture seule. De son côté, WSL 2 sait aussi monter du Btrfs, car son noyau embarque le module, mais la documentation de Microsoft pose ses limites : ni clé USB ni lecteur de cartes, pas de partition du disque de démarrage, et un accès depuis Windows qui passe par un chemin réseau plutôt que par une lettre de lecteur.

Voilà pourquoi ce pilote incroyable n'a pas de réel équivalent.

Côté Windows, il y a quand même des petites surprises. Le pilote est bien signé et s'installe normalement, mais avec Secure Boot activé sur un Windows 10 ou 11, il peut refuser de se charger pour la simple et bonne raison que Microsoft a durci ses exigences de signature d'une façon que les pilotes libres n'ont pas encore réussi à régler. Il faut donc contourner la vérification, ou couper Secure Boot dans le BIOS. Ne vous inquiétez pas, Windows 11 demande en principe Secure Boot pour s'installer, mais tourne ensuite très bien sans. Cependant, je ne suis pas fan d'enlever des contrôles de sécurité sur l'ordinateur, donc, à vous de voir.

Et une fois le disque monté, ne le cherchez pas non plus dans la gestion des disques, car il n'y sera pas. Le pilote passe en fait par un faux périphérique bloc pour que le RAID fonctionne, et diskmgmt ne sait rien de tout ça. C'est donc dans l'explorateur que ça se passe, et nulle part ailleurs.

Et puis 370 commits en quatre semaines sur un pilote de système de fichiers, dont deux chemins d'écriture flambant neufs, ça reste quand même un peu chaud niveau vérification / bugs. Donc pensez bien à faire des backups avant d'installer ça.

Source : Neowin