Docker Desktop n’est plus le passage obligé pour lancer des conteneurs Linux sur Windows. Depuis le 29 septembre 2026, Microsoft a intégré cette fonction à Windows Subsystem for Linux. Cette nouveauté s’appelle tout simplement les conteneurs WSL (WSL containers), pilotés par un nouvel outil en ligne de commande nommé wslc. Sur le papier, c’est natif sur Windows en s’appuyant sur WSL et la syntaxe des commandes est calquée sur celle de Docker. Dans cet article, je vous propose de découvrir ce que sont les conteneurs WSL, comment les installer et comment les utiliser au quotidien.
Si vous avez lu mon article Apple Container : bien débuter avec les conteneurs macOS, vous allez retrouver une démarche similaire : après Apple, c’est au tour de Microsoft de proposer son propre outil de conteneurs, intégré au système. Et si la conteneurisation est un terrain nouveau pour vous, la lecture de notre article Qu’est-ce que Docker et pourquoi l’utiliser ? vous donnera les bases (images, conteneurs, registres), qui valent aussi pour wslc.
Qu’est-ce que les conteneurs WSL ?
Les conteneurs WSL, abrégés WSLC pour les intimes, sont une fonctionnalité de WSL qui permet de construire, d’exécuter et de gérer des conteneurs Linux directement sous Windows. Désormais disponible en version stable sur Windows, Microsoft les a présentés lors de la conférence Build 2026 (j’en parlais dans cet article), puis une première préversion a été publiée le 29 juin 2026. La disponibilité générale est effective depuis le 29 septembre 2026, avec la version 3.0.1 de WSL.
Cette nouveauté s’articule autour de deux composants :
La CLI wslc.exe : un outil en ligne de commande pour construire des images, lancer des conteneurs, gérer les réseaux et les volumes. Tout au long de cet article, nous allons donc exécuter wslc.exe avec des arguments, tout en sachant que container.exe est un alias qui exécute le même binaire.
L’API WSL containers : un paquet NuGet (Microsoft.WSL.Containers) utilisable en C, C++ et C#, pour que des applications Windows puissent lancer et piloter des conteneurs Linux.
Dans cet article, c’est la partie CLI qui va m’intéresser plus particulièrement. Côté compatibilité, wslc exécute les images Linux que vous utilisez déjà avec Docker : celles de Docker Hub, mais aussi celles d’autres registres comme GitHub Container Registry (ghcr.io). Microsoft ne mentionne pas une compatibilité avec les images OCI, mais on peut lancer des images OCI. La syntaxe des commandes est également proche de celle de Docker : run, exec, logs, build, -p, -d, –rm… Donc, si vous avez l’habitude de Docker, vous ne serez pas perdu.
Une machine virtuelle par session
Comme WSL 2, les conteneurs WSL s’appuient sur une machine virtuelle Hyper-V légère, qui embarque le noyau Linux. Mais l’architecture est un peu différente de celle des distributions WSL. D’après l’article publié par Pierre Boulay, ingénieur chez Microsoft, chaque session wslc dispose de sa propre machine virtuelle. Le service WSL (wslservice.exe) ne garde pas la main sur cette VM : il crée un processus enfant, wslcsession.exe, qui s’exécute avec les droits de l’utilisateur. Les opérations sont donc effectuées dans un processus moins privilégié que le service WSL, ce qui renforce le cloisonnement entre les sessions de différents utilisateurs.
Cet article intéressant nous apprend également que
virtiofs est utilisé pour le partage de fichiers : il remplace le protocole Plan9 utilisé historiquement par WSL. Microsoft le présente comme environ deux fois plus rapide pour accéder aux fichiers Windows depuis Linux.
Il y a un mode réseau nommé consomme : oui, c’est bien son nom officiel. Il s’appelait auparavant VirtioProxy, et il est issu d’OpenVMM, le moniteur de machines virtuelles open source de Microsoft. Ce mode réseau relaie le trafic des conteneurs à travers Windows. L’objectif est que les conteneurs profitent du même environnement réseau que les applications Windows (VPN, proxy, politiques de sécurité).
Les données des sessions (images, conteneurs) sont stockées dans des disques virtuels VHD, dans le profil de l’utilisateur (%LocalAppData%\wslc\sessions).
Attention au niveau d’élévation de votre terminal ! En effet, wslc crée une session distincte selon que vous l’exécutez depuis une console standard ou depuis une console exécutée en tant qu’administrateur. Sur ma machine, cela donne deux dossiers : wslc-cli-Florian et wslc-cli-admin-Florian. Chaque session a sa propre machine virtuelle et son propre disque : les images, les conteneurs et les volumes créés dans l’une ne sont pas visibles dans l’autre. Si un conteneur ou un volume semble avoir disparu, vérifiez d’abord que vous utilisez le même type de console qu’au moment de sa création. Le plus simple est de choisir une fois pour toutes : une console standard suffit pour utiliser wslc.
wslc ou Docker Desktop : quelles différences ?
Jusqu’ici, pour exécuter des conteneurs sur Windows, il était fréquent d’installer Docker Desktop (et WSL 2 qui est une dépendance). La sortie de wslc est l’occasion de comparer rapidement ces deux approches.
Critèrewslc (conteneurs WSL)Docker DesktopÉditeurMicrosoftDocker, Inc.LicenceOpen source (dépôt microsoft/WSL)Propriétaire (gratuit sous conditions, payant en entreprise)InstallationIntégré à WSL (wsl –update)Logiciel à installerArchitectureUne VM par session utilisateurUne VM Linux (via WSL 2 ou Hyper-V)Interface graphiqueAucune interface officielle (projets communautaires)OuiDocker ComposePas encore (prévu)IntégréGestion en entrepriseParamètres Intune, modèle ADMX, Microsoft Defender for EndpointOutils d’administration propres à DockerMaturitéVersion finale depuis septembre 2026Mature, écosystème très large
wslc n’est donc pas (encore) un remplaçant complet de Docker Desktop. Il est déjà très pertinent pour exécuter des conteneurs isolés, tester une image ou disposer d’un environnement de développement, mais l’absence de Docker Compose est une vraie limite.
Installer les conteneurs WSL sur Windows
Prérequis
Pour utiliser les conteneurs WSL, les prérequis sont les mêmes que WSL. Donc, rien de spécial en soi. Il vous faut donc :
Windows 11, ou Windows 10 version 2004 (build 19041) ou ultérieure : les conteneurs WSL fonctionnent partout où WSL 2 est pris en charge.
La virtualisation activée : dans le firmware de la machine (Intel VT-x ou AMD-V), ainsi que la fonctionnalité Windows “Plateforme d’ordinateur virtuel”.
WSL en version 3.0.1 ou supérieure : c’est la première version qui intègre les conteneurs WSL en version finale.
Si WSL n’a jamais été installé sur votre machine, une seule commande suffit. Ouvrez une console PowerShell en tant qu’administrateur et exécutez :
wsl –install –no-distribution
Cette commande installe WSL et active les composants Windows nécessaires (dont « Plateforme d’ordinateur virtuel »), sans installer de distribution Linux. Redémarrez ensuite la machine Windows.
Si vous testez wslc dans une machine virtuelle (Hyper-V, Proxmox VE…), la virtualisation imbriquée doit être activée sur cette VM.
Mettre à jour WSL
Les conteneurs WSL sont livrés avec WSL lui-même : il n’y a pas de paquet séparé à installer. Mais il faut que votre WSL soit à jour, donc ouvrez une console et exécutez la commande suivante pour mettre à jour WSL :
wsl –update
Vous pouvez aussi télécharger le paquet d’installation depuis la page des releases du dépôt GitHub de WSL. Ensuite, vérifiez la version installée :
wsl –version
On voit bien que la version installée est désormais la 3.0.1.
Vérifier l’installation
Une fois WSL à jour, la commande wslc est disponible dans votre terminal. Affichez sa version, puis l’aide générale pour avoir un aperçu des commandes disponibles :
wslc version
wslc –help
Pour obtenir de l’aide sur une commande précise, ajoutez –help après son nom, par exemple wslc run –help. La commande wslc system info permet aussi d’afficher l’état de l’environnement de conteneurs. La commande précédente permet de voir qu’il y a déjà une bonne quantité de commandes disponibles.
Par la suite, vous pourrez aussi exécuter la commande ci-dessous pour afficher l’état de l’environnement de conteneurs.
wslc system info
Pour valider le bon fonctionnement de l’ensemble, lançons le traditionnel conteneur de test hello-world :
wslc run –rm hello-world
L’image est téléchargée, le conteneur s’exécute, affiche son message de bienvenue Hello from Docker!, puis s’arrête. C’est tout bon !
Premiers pas : exécuter et gérer des conteneurs avec wslc
L’environnement étant prêt avec wslc fonctionnel, apprenons désormais à l’utiliser de façon plus concrète.
Lancer un conteneur
Un peu sur le même principe que le test initial, commençons par lancer un conteneur Ubuntu éphémère, qui exécute une commande puis est supprimé dans la foulée. L’idée étant de vous rappeler quelques bases par rapport à la syntaxe des commandes.
wslc run –rm -it ubuntu:latest bash -c “echo Hello IT-Connect from wslc”
Quelques explications sur les options utilisées :
–rm : supprime automatiquement le conteneur dès qu’il s’arrête. Sans cette option, le conteneur resterait présent à l’état arrêté (et donc il pourrait être relancé). C’est idéal pour les conteneurs jetables, comme ici pour un simple test.
-it : ouvre une session interactive avec un terminal, utile pour interagir avec le conteneur.
ubuntu:latest : l’image à utiliser, avec son tag.
Passons à un cas plus concret : un serveur web Nginx exécuté en arrière-plan, avec une publication de port sur la machine locale.
wslc run -d –rm -p 8080:80 –name web nginx
L’option -d lance le conteneur en arrière-plan (c’est le mode détaché), -p 8080:80 publie le port 80 du conteneur sur le port 8080 de Windows, et –name web donne un nom au conteneur (ce qui permet de l’appeler par son petit nom pour agir dessus).
Vérifiez que le serveur web répond :
curl http://localhost:8080
Vous pouvez aussi ouvrir l’adresse http://localhost:8080 dans votre navigateur : la page d’accueil de Nginx s’affiche.
Note : la commande wslc events affiche en temps réel l’activité des conteneurs.
Lister, inspecter et entrer dans un conteneur
Le contenu web lancé précédemment est toujours en cours d’exécution, en arrière-plan. On peut le vérifier en listant les conteneurs en cours d’exécution. Plusieurs syntaxes sont possibles :
wslc container list
wslc ls
ID DE CONTENEUR IMAGE COMMANDE DATE DE CRÉATION ÉTAT PORTS NOMS
97ec4bbf3b03 nginx “/docker-e… Il y a 2 minutes Up 2 minut… 127.0.0.1:… web
Le raccourci wslc ls n’a pas d’équivalent direct chez Docker, où il faut utiliser docker ps ou docker container ls. Pour afficher aussi les conteneurs arrêtés, ajoutez l’option –all, ceci permet d’afficher les conteneurs sans tenir compte de leur état.
Pour exécuter une commande dans un conteneur en cours d’exécution, utilisez wslc exec :
wslc exec web cat /etc/os-release
PRETTY_NAME=”Debian GNU/Linux 13 (trixie)”
NAME=”Debian GNU/Linux”
VERSION_ID=”13″
VERSION=”13 (trixie)”
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.7
ID=debian
HOME_URL=”https://www.debian.org/”
SUPPORT_URL=”https://www.debian.org/support”
BUG_REPORT_URL=”https://bugs.debian.org/”
Pour ouvrir un shell interactif dans le conteneur :
wslc exec -it web bash
Vous pouvez ensuite exécuter des commandes directement depuis le terminal du conteneur. Par exemple, vous pouvez lister la racine web de Nginx.
Consulter les journaux d’un conteneur et afficher sa configuration détaillée (au format JSON) se fait avec ces deux commandes :
wslc container logs web
wslc container inspect web
Enfin, pour arrêter le conteneur :
wslc container stop web
Puisqu’il a été lancé avec l’option –rm, le conteneur est supprimé automatiquement.
Travailler avec les images
Pour lister les images présentes en local, exécutez cette commande :
wslc image list
Si vous avez suivi ce tutoriel jusqu’ici, plusieurs images devraient être retournées dans la liste :
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest e9567a94eddc Il y a 12 jours 162MB
ubuntu latest 5a0b35d45050 Il y a 2 semaines 100MB
hello-world latest e2ac70e7319a Il y a 6 mois 10.1kB
Pour récupérer des images depuis un registre, wslc ne se limite pas à Docker Hub. Il suffit de préciser le nom complet de l’image pour la télécharger depuis un autre registre. Par exemple GitHub Container Registry qui est également très souvent utilisé :
wslc pull ghcr.io/linuxserver/nginx:latest
latest: Pulling from linuxserver/nginx
6d063e04f3f4: Pull complete
f6a4c3e338ed: Pull complete
61995cfd0a4d: Pull complete
e2f56c0419a7: Pull complete
75ebdff3163d: Pull complete
7ac52f6446c9: Pull complete
83f1ad36470f: Pull complete
e78d8b221ea4: Pull complete
393d51d6a24d: Pull complete
696838da84a5: Pull complete
f8e9df4c981f: Pull complete
Digest: sha256:34e67960f3f818f3d87fdd773e328b53b24c91c64b4c1e4f6d7b22bc175ee174
Status: Downloaded newer image for ghcr.io/linuxserver/nginx:latest
ghcr.io/linuxserver/nginx:latest
La commande wslc image inspect affiche les métadonnées d’une image : architecture, variables d’environnement, ports exposés, labels, couches… Voici un extrait du résultat pour l’image précédente :
Deux informations intéressantes ici : wslc a automatiquement récupéré la variante amd64 de cette image multi-architecture, et le format de sortie est identique à celui de docker image inspect. Vos habitudes ne sont pas impactées !
Pour faire le ménage, vous pouvez utiliser la commande wslc image prune. Attention toutefois à son comportement, qui est le même que celui de Docker : sans option, elle supprime uniquement les images non taguées (les images orphelines, affichées avec le tag ). Si toutes vos images ont un tag, aucune ne sera supprimée :
wslc image prune
AVERTISSEMENT! Cela supprimera toutes les images non taguées.
Voulez-vous vraiment continuer ? [y/N] y
Espace total récupéré : 0B
Pour supprimer aussi les images taguées qui ne sont utilisées par aucun conteneur, il faut ajouter l’option –all. Pour supprimer une image précise, utilisez plutôt la suppression ciblée en spécifiant le nom de l’image à supprimer.
wslc image prune –all
AVERTISSEMENT! Cette opération supprimera toutes les images qui n’ont pas au moins un conteneur associé.
Voulez-vous vraiment continuer ? [y/N] y
wslc image rm hello-world
Construire une image
wslc sait aussi construire des images à partir d’un fichier de définition. Ce fichier peut s’appeler Containerfile ou Dockerfile, ce dernier étant le nom utilisé par Docker lorsque l’on lance un docker build.
À titre d’exemple, nous allons construire une image basée sur nginx:alpine, qui sert une page HTML personnalisée. Les commandes ci-dessous sont à exécuter dans PowerShell 7 : l’option d’encodage utf8NoBOM n’existe pas dans Windows PowerShell 5.1, et un fichier enregistré avec une marque BOM peut poser problème lors de la construction.
Commencez par créer un dossier de travail et la page HTML :
New-Item -ItemType Directory -Path C:\wslc-demo -Force | Out-Null
Set-Location C:\wslc-demo
@’
Démo wslc – IT-Connect
Cette page est servie par Nginx, dans une image construite avec wslc build.
Version 1
‘@ | Set-Content -Path .\index.html -Encoding utf8NoBOM
Puis créez le fichier Dockerfile dans le même répertoire et insérez ces trois lignes :
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80
Ce fichier indique que l’image de base de conteneur est nginx:alpine, que la page index.html remplace la page d’accueil par défaut de Nginx (car on l’écrase), et que le conteneur écoute sur le port 80.
Construisez l’image avec la commande wslc build. L’option -t permet de lui donner un nom, et le point final indique que le contexte de construction est le dossier courant :
wslc build -t demo-itconnect .
wslc image list
Il ne reste plus qu’à lancer un conteneur basé sur cette image, en publiant son port 80 sur le port 8081 de Windows :
wslc run -d –rm -p 8081:80 –name demo demo-itconnect
Start-Process http://localhost:8081
Votre page personnalisée s’affiche dans le navigateur.
Modifions maintenant la page, puis reconstruisons l’image sous le même nom :
wslc container stop demo
(Get-Content .\index.html) -replace ‘Version 1’, ‘Version 2’ | Set-Content .\index.html -Encoding utf8NoBOM
wslc build -t demo-itconnect .
wslc image list
La nouvelle image récupère le nom demo-itconnect:latest, et l’ancienne perd son tag : elle apparaît désormais avec le tag . C’est exactement le type d’image que wslc image prune supprime. Testez, vous verrez.
wslc image prune
AVERTISSEMENT! Cela supprimera toutes les images non taguées.
Voulez-vous vraiment continuer ? [y/N] y
Images supprimées :
supprimé : sha256:36ca8a7380dabb6900fbce084a74e495006a86d82b547ad47c4a977bb9ca72ea
Réseaux
Par défaut, un conteneur est isolé. wslc permet de créer des réseaux pour faire communiquer plusieurs conteneurs entre eux, et d’attacher ou de détacher un conteneur d’un réseau à chaud :
wslc network create demo-net
wslc network connect demo-net demo
wslc network disconnect demo-net demo
Persistance des données avec les volumes
Un conteneur est éphémère : ce qu’il écrit comme données disparaît avec lui. Si vous avez déjà utilisé Docker (ou une alternative), vous le savez. Pour conserver des données, il faut utiliser un volume, qui survit à la suppression du conteneur. Créons un premie volume nommé demo-data :
wslc volume create demo-data
wslc volume list
Vérifions la persistance avec deux conteneurs Alpine successifs. Le premier écrit un fichier dans le volume, puis il est supprimé grâce à l’option –rm. Le second, tout neuf, relit ce fichier. Le seul intérêt étant de valider le mécanisme de pertinance du stockage.
wslc run –rm -v demo-data:/data alpine sh -c “echo ‘Persistance OK’ > /data/test.txt”
wslc run –rm -v demo-data:/data alpine cat /data/test.txt
Persistance OK
Le second conteneur affiche « Persistance OK » : la donnée a bien survécu au premier conteneur.
Mais où ce volume est-il stocké ? La commande wslc volume inspect apporte la réponse :
wslc volume inspect demo-data
Voici le résultat JSON obtenu :
[
{
“CreatedAt”: “2026-10-01T11:20:18Z”,
“Driver”: “guest”,
“Labels”: null,
“Mountpoint”: “/var/lib/docker/volumes/demo-data/_data”,
“Name”: “demo-data”,
“Options”: null,
“Scope”: “local”
}
]
Premier enseignement : le pilote guest est utilisé par défaut et il indique que le volume est stocké dans la machine virtuelle de la session. Autrement dit, il est stocké dans le disque virtuel storage.vhdx présent dans %LocalAppData%\wslc\sessions\. Inutile de chercher un dossier demo-data dans l’Explorateur Windows : les données ne sont accessibles qu’à travers les conteneurs, notamment parce que le fichier storage.vhdx empêche un accès direct.
Au passage, petite remarque : le chemin /var/lib/docker/volumes est celui qu’utilise Docker Engine, ce qui laisse penser que wslc s’appuie sur un moteur compatible Docker dans sa machine virtuelle. Microsoft ne le précise pas dans sa documentation, mais bon, ça en a tout l’air.
Pilote guest ou pilote vhd ?
L’aide de la commande wslc volume create mentionne un second pilote : vhd. Avec lui, le volume n’est plus stocké dans le disque de la session, mais dans son propre fichier VHDX. Cela permet d’avoir un fichier indépendant.
Voici la commande pour créer un volume de 1 Go. Dans PowerShell, le suffixe 1GB calcule la valeur en octets à votre place (1 073 741 824) :
wslc volume create -d vhd -o “SizeBytes=$(1GB)” demo-vhd
Le volume prend alors la forme d’un fichier demo-vhd.vhdx, créé dans le sous-dossier volumes de la session (%LocalAppData%\wslc\sessions\\volumes). Il s’agit d’un disque dynamique : pour un volume de 1 Go, le fichier ne pèse qu’environ 36 Mo à sa création, et il grossit au fil des écritures.
Je trouve que le pilote vhd est intéressant pour isoler les données d’une application dans un fichier distinct, avec une taille maîtrisée, plutôt que de les mélanger au disque de la session avec les images et les conteneurs.
Récupérer les données d’un volume
Puisque les données d’un volume ne sont pas visibles depuis l’Explorateur, comment récupérer un fichier sur Windows ? Le plus simple consiste à passer par un conteneur temporaire, qui monte le volume, puis à utiliser la commande wslc container cp pour copier le fichier vers Windows.
wslc run -d –name extract -v demo-vhd:/data alpine sleep 300
wslc container cp extract:/data/test.txt C:\Temp\
wslc container stop extract
Le conteneur extract exécute simplement une pause de 5 minutes, le temps de copier les fichiers. La même commande fonctionne dans l’autre sens, pour déposer un fichier Windows dans un conteneur.
Si le volume est déjà monté dans un conteneur en cours d’exécution (un conteneur applicatif qui tourne en permanence, par exemple), inutile de créer un conteneur temporaire : vous pouvez cibler directement ce conteneur. Indiquez alors le chemin du point de montage à l’intérieur de ce conteneur, et non le nom du volume :
wslc container cp :/test.txt C:\Temp\
Vous pourriez être tenté d’ouvrir directement le fichier VHDX d’un volume, puisque Windows 11 sait monter ce format. D’une part, il est verrouillé tant que la session wslc est active. D’autre part, il contient un système de fichiers Linux que Windows ne sait pas lire (ext4 en général). Si la Gestion des disques vous propose d’initialiser le disque, refusez : cette opération rendrait le volume inutilisable.
Allouer des ressources et utiliser le GPU
Comme avec Docker, vous pouvez limiter les ressources d’un conteneur avec les options –cpus et –memory :
wslc run -d –rm –cpus 2 –memory 1g –name web-limite nginx
Il est possible que wslc affiche l’avertissement suivant : « Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap ». Pas d’inquiétude, le conteneur démarre bien et la limite de mémoire vive est appliquée. En revanche, l’utilisation du swap n’est pas limitée : le conteneur peut donc dépasser la limite de 1 Go en s’appuyant sur le swap de la machine virtuelle.
Pour vérifier que la limite est prise en compte, utilisez la commande wslc stats :
wslc stats
ID DE CONTENEUR NOM Pourcentage UC UTILISATION/LIMITE MEM MEM % NET I/O BLOQUER LES E/S PIDS
a6de0d089d23 we… 0.00% 20.84MiB / 1GiB 2.03% 796B / … 0B / 12.3kB 25
Le conteneur limité affiche bien une limite de 1 GiB, tandis que les autres peuvent utiliser toute la mémoire allouée à la machine virtuelle de la session. Contrairement à docker stats, qui actualise l’affichage en continu, wslc stats affiche un instantané puis rend la main (l’option –no-stream de Docker n’existe d’ailleurs pas). Petit détail qui montre que les traductions et Microsoft ce n’est toujours pas ça : la colonne “BLOQUER LES E/S” est une traduction maladroite de “BLOCK I/O”, qui désigne les lectures et écritures sur les périphériques de stockage.
Pour une vérification plus fine, vous pouvez lire directement les valeurs des cgroups dans le conteneur :
wslc exec web-limite cat /sys/fs/cgroup/memory.max
wslc exec web-limite cat /sys/fs/cgroup/cpu.max
La première commande doit retourner 1073741824 (soit 1 Go), la seconde 200000 100000, soit l’équivalent de 2 processeurs.
Les conteneurs WSL peuvent aussi exploiter le GPU de la machine, ce qui intéressera ceux qui font tourner des charges de travail d’IA en local. Voici l’exemple fourni par Microsoft, pour une carte NVIDIA. Je vous le mets à titre d’information, car je n’ai pas pu tester directement.
wslc run –rm –gpus all ubuntu bash -c ‘export PATH=$PATH:/usr/lib/wsl/lib; nvidia-smi’
Si tout fonctionne, la commande nvidia-smi affiche les informations de la carte graphique depuis le conteneur.
wslc : et Docker Compose ?
Docker Compose, c’est le grand absent de cette version finale. Il n’est pas encore possible de décrire une application multi-conteneurs dans un fichier YAML et de la déployer en une commande avec wslc. C’est bien dommage… Personnellement je déploie toutes mes stacks Docker de cette façon.
Microsoft en a conscience et indique en faire sa priorité : “Notre objectif est que wsl compose up fonctionne avec vos fichiers compose.yaml existants, sans modification. Nous avons commencé à travailler dessus et espérons en dire plus prochainement”, peut-on lire. On peut imaginer qu’une future version de wslc viendra rectifier le tir.
Exemple : déployer WordPress et MariaDB en ligne de commande
L’objectif est de reproduire ce que ferait un fichier Docker Compose : un réseau dédié pour que les deux conteneurs communiquent par leur nom, un volume par service pour les données, et un contrôle de l’état de santé (healthcheck) pour ne lancer WordPress qu’une fois la base de données prête. Docker Compose n’était pas pris en charge pour le moment, j’ai challengé Claude pour reproduire un comportement similaire avec un script PowerShell 7 (en particulier pour le healthcheck).
Le résultat indiqué ci-dessous est pleinement fonctionnel.
# Mots de passe aléatoires (24 caractères alphanumériques)
$DbPass = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 24 | ForEach-Object { [char]$_ })
$RootPass = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 24 | ForEach-Object { [char]$_ })
# Réseau et volumes
wslc network create wp-net
wslc volume create wp-db
wslc volume create wp-html
# Base de données MariaDB, avec healthcheck
wslc run -d –name wp-db –network wp-net `
-e MARIADB_DATABASE=wordpress `
-e MARIADB_USER=wpuser `
-e MARIADB_PASSWORD=$DbPass `
-e MARIADB_ROOT_PASSWORD=$RootPass `
-v wp-db:/var/lib/mysql `
–health-cmd “healthcheck.sh –connect –innodb_initialized” `
–health-interval 10s –health-retries 5 –health-start-period 20s `
mariadb:lts
# Attendre que MariaDB soit prête
do {
Start-Sleep -Seconds 3
$State = (wslc container inspect wp-db | ConvertFrom-Json)[0].State.Health.Status
Write-Host “MariaDB : $State”
} until ($State -eq “healthy”)
# WordPress, qui joint la base de données par son nom de conteneur
wslc run -d –name wp-app –network wp-net -p 8088:80 `
-e WORDPRESS_DB_HOST=wp-db `
-e WORDPRESS_DB_NAME=wordpress `
-e WORDPRESS_DB_USER=wpuser `
-e WORDPRESS_DB_PASSWORD=$DbPass `
-v wp-html:/var/www/html `
wordpress:latest
Start-Process http://localhost:8088
Quelques explications :
Les mots de passe sont générés aléatoirement et stockés dans des variables PowerShell. Pensez à les noter (affichez-les avec $DbPass et $RootPass) avant de fermer la console.
Le healthcheck s’appuie sur le script healthcheck.sh fourni dans l’image officielle de MariaDB. La boucle do… until interroge l’état du conteneur toutes les 3 secondes et attend qu’il passe à healthy. C’est l’équivalent de depends_on avec la condition service_healthy dans un fichier Compose.
WORDPRESS_DB_HOST=wp-db : WordPress joint la base de données grâce au nom du conteneur, résolu automatiquement sur le réseau wp-net.
Au bout de quelques secondes, l’assistant d’installation de WordPress s’affiche dans le navigateur. Une fois l’installation terminée, vous disposez d’un WordPress fonctionnel, exécuté dans des conteneurs WSL. La preuve en image !
L’absence de Docker Compose signifie aussi qu’il n’y a pas les commandes de gestion habituelles, comme docker compose restart. Ainsi, pour gérer le cycle de vie de l’application, nous devons miser sur d’autres commandes :
# Arrêter l’application
wslc container stop wp-app wp-db
# La relancer (la base de données en premier)
wslc start wp-db
wslc start wp-app
# Tout supprimer, données comprises
wslc container rm wp-app wp-db
wslc volume rm wp-db wp-html
wslc network rm wp-net
Gérer ses conteneurs WSL avec une interface graphique
Depuis le début, nous manipulons les conteneurs WSL via la ligne de commande. C’est normal, Microsoft ne fournit pas d’interface graphique pour wslc. En revanche, plusieurs projets communautaires et des intégrations sont déjà disponibles : ces projets ont vu le jour suite à la publication de la préversion il y a quelques mois.
Par exemple, l’extension Containers de VS Code, utilisée pour gérer des conteneurs depuis VS Code, prend désormais en charge wslc. Côté gestion via une interface graphique, il y a deux projets intéressants.
Le premier, c’est WSL Container Desktop : une application WinUI 3 conçue pour gérer les conteneurs WSL, des clusters Kubernetes (k3s) et des registres. Elle est disponible sur GitHub. Elle est vraiment pratique pour utiliser les conteneurs WSL en mode graphique.
Le second, c’est Lazywslc : un tableau de bord en mode texte (TUI) pour gérer vos conteneurs WSL depuis le terminal. Le projet est développé par Craig Loewen, responsable produit de WSL. Il est disponible sur GitHub. Bon, par contre, il ne détecte aucun conteneur sur ma machine.
Conclusion
Avec les conteneurs WSL, Microsoft comble un manque historique de Windows : exécuter des conteneurs Linux sans passer par un outil tiers. L’outil wslc est simple à prendre en main pour quiconque connaît Docker, il exécute les images existantes, qu’elles viennent de Docker Hub ou d’un autre registre, et il accepte vos fichiers Dockerfile.
À mon sens, wslc est déjà une vraie alternative pour tester des images, exécuter des conteneurs isolés ou monter des environnements de développement. Cela fonctionne bien et quand on est familier avec Docker et les conteneurs, c’est facile à prendre en main. À l’heure actuelle, il lui manque la prise en charge de Docker Compose pour prétendre remplacer Docker Desktop au quotidien. Microsoft y travaille.
FAQ
Qu’est-ce que wslc ?
wslc (wslc.exe) est l’outil en ligne de commande des conteneurs WSL. Intégré à Windows Subsystem for Linux depuis la version 3.0.1, il permet de construire, d’exécuter et de gérer des conteneurs Linux sous Windows, avec une syntaxe proche de celle de Docker.
Quelle est la différence entre wslc.exe et container.exe ?
Aucune sur le plan fonctionnel. container.exe est un alias fourni par Microsoft, qui exécute le même binaire que wslc.exe. Vous pouvez utiliser l’une ou l’autre commande.
Quelle version de WSL faut-il pour utiliser les conteneurs WSL ?
La version finale est intégrée à WSL 3.0.1. Mettez WSL à jour avec la commande wsl –update, puis vérifiez la version avec wsl –version.
Faut-il installer une distribution Linux pour utiliser wslc ?
Non, il est uniquement nécessaire de disposer de WSL sur la machine (wsl –install –no-distribution). Activer uniquement les composants de virtualisation, sans installer de distribution, est suffisant.
Les conteneurs WSL remplacent-ils Docker Desktop ?
Pas encore complètement : wslc ne prend pas encore en charge Docker Compose et n’a pas d’interface graphique officielle (même s’il y a un outil open source vraiment bien fait). Microsoft travaille sur une commande wsl compose up compatible avec les fichiers compose.yaml existants.
Les images Docker sont-elles compatibles avec wslc ?
Oui. wslc exécute les images Linux publiées sur Docker Hub et sur d’autres registres, comme GitHub Container Registry. Il construit aussi des images à partir d’un fichier Dockerfile ou Containerfile.
Où wslc télécharge-t-il les images par défaut ?
Lorsque vous indiquez un nom court comme nginx ou ubuntu, l’image est récupérée sur Docker Hub. Pour un autre registre, précisez le nom complet de l’image, par exemple ghcr.io/linuxserver/nginx.
Où sont stockés les conteneurs et les images ?
Les données sont stockées dans des disques virtuels VHDX, dans le profil de l’utilisateur (%LocalAppData%\wslc\sessions).
Existe-t-il une interface graphique pour wslc ?
Microsoft ne fournit pas d’interface officielle. Des projets comme Lazywslc (interface en mode texte) et WSL Container Desktop (application WinUI 3) comblent ce manque, et l’extension Containers de VS Code prend en charge wslc.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.