Connexion Premium

Microsoft dégaine ses conteneurs WSL (Linux) en version finale

Compose viendra, promis

Microsoft dégaine ses conteneurs WSL (Linux) en version finale

Illustration : Flock

Microsoft a donné le coup d’envoi officiel pour ses conteneurs WSL. Ils permettent de créer, exécuter et gérer des conteneurs Linux directement depuis Windows.

Au début de l’été, Microsoft a profité de sa conférence Build pour présenter un nouveau projet baptisé « WSL Container », avec une préversion dans la foulée. L’objectif était clair : fournir un moyen intégré et prêt pour l’entreprise de créer, exécuter et gérer des conteneurs Linux sur Windows, sans nécessiter d’outillage tiers supplémentaire.

Depuis le 29 septembre, la fonction est disponible en version finale. Microsoft n’y va pas par quatre chemins : « WSL est au cœur de notre engagement à faire de Windows le meilleur endroit pour construire, exécuter et gérer des charges de travail Linux. À mesure que l’IA, le développement cloud-native, les conteneurs et les écosystèmes open source continuent de converger vers Linux, de plus en plus de développeurs choisissent d’exécuter ces charges directement sur des appareils Windows ». Les conteneurs sont donc une évolution logique de WSL, affirme l’éditeur.

Petit point de rappel d’abord : qu’est-ce que WSL ? Le Windows Subsystem for Linux est un composant de Windows permettant de faire fonctionner directement une distribution Linux virtualisée. Plusieurs sont disponibles d’ailleurs dans le Microsoft Store, comme Ubuntu et Debian.

Source : Microsoft

Disponible directement dans la nouvelle version de WSL

Pour utiliser les conteneurs, pas besoin d’installer de nouveaux composants, car la nouvelle fonction fait simplement partie de la dernière mouture du WSL (3.0.1). On peut donc l’installer soit en récupérant le binaire depuis le dépôt GitHub, soit via la commande « wsl --update » dans le terminal.

Le produit livré hier soir repose sur deux briques. D’abord, l’outil wslc.exe qui sert à construire, lancer et déployer les conteneurs. Microsoft fournit en même temps un alias intégré container.exe pour reprendre les commandes habituelles. Ensuite, une API – sous forme de paquet NuGet Microsoft.WSL.Containers – pour permettre aux applications Windows natives de piloter ces conteneurs. L’éditeur donne comme exemple l’exécution locale de charges IA.

En matière d’architecture, chaque utilisateur a sa propre session, dont les privilèges peuvent être réglés, y compris de manière centralisée en entreprise. Le stockage, lui, peut se faire de trois manières : un VHD par session, des volumes reposant sur VHD ou des volumes de conteneurs reposant sur virtiofs, que Microsoft présente comme jusqu’à deux fois plus rapides que l’approche plan9 utilisée jusqu’à présent par WSL.

Quant au réseau, il est géré par un composant nommé Consommé, qui consiste en un processus s’occupant de tout ce qui touche au DNS, au routage et au mappage des ports. Cette approche doit notamment permettre de travailler plus facilement avec des VPN et des pare-feux.

Docker dans la ligne de mire

D’accord, mais pour quoi faire ? On trouve sur le site de Microsoft ou dans la presse des exemples d’utilisation. Le plus simple est celui d’une application Windows embarquant un composant Linux. Ainsi, un logiciel de bureau en C# peut lancer un conteneur servant un modèle d’inférence, communiquer avec lui puis l’arrêter à la fermeture. C’est l’exemple de charge IA locale donné précédemment par Microsoft.

Si le nom n’est jamais cité, Docker est directement dans la ligne de mire. Microsoft met en avant ses intégrations avec d’autres produits de son écosystème, Intune et Defender for Endpoint étant cités. L’arrivée des conteneurs WSL permet aux applications Windows de les exploiter directement, sans passer par des produits tiers (il faut quand même que WSL soit installé).

Il s’agit cependant d’une version 1.0, qui cible surtout les grandes entreprises dans lesquelles ce niveau d’intégration peut faire la différence. En outre, il y a des limites. Selon Microsoft, la fonction la plus demandée est la compatibilité avec Docker Compose, via la prise en charge directe des fichiers compose.yaml existants. L’entreprise affirme que ce support est « une priorité pour nos prochaines versions ».

La version finale apporte des nouveautés

Si vous avez testé les conteneurs WSL cet été, la version finale apporte bon nombre d’améliorations, notamment pour les commandes disponibles, qui en comptent une dizaine de nouvelles. Citons par exemple « wslc container restart » qui permet de redémarrer un conteneur en fonctionnement, « wslc system info » pour voir une vue de synthèse de l’environnement conteneur, ou « wslc network connect » pour attacher les conteneurs au réseau (ou « disconnect » pour les détacher).

Entre temps, des intégrations sont également apparues avec des partenaires ou des projets communautaires. Les conteneurs sont ainsi supportés (sans grande surprise) dans Visual Studio Code, dans lequel on peut déclarer wslc comme pilote par défaut pour créer et interagir avec les conteneurs WSL. Microsoft cite aussi Aspire, Lazywslc, WSL Container Desktop ou encore WSLc Remote. Ce dernier permet de lancer wslc depuis les distributions Linux prises en charge par WSL.

Microsoft ajoute que les investissements dans WSL continueront. « Au fil du temps, nous voyons Linux sous Windows évoluer au-delà d’un environnement de développement vers une plateforme d’exécution stratégique pour l’IA et les charges de travail natives cloud, participant aux mêmes cadres de sécurité, de gestion et de gouvernance d’entreprise que Windows », assure ainsi l’entreprise.

Commentaires (23)

votre avatar
je l'utilise pour du dev sur un prog C/C++ qui tourne sur windows et linux.
Ca m'a simplifié la vie. C'est super pratique pour tester sans avoir à se connecter à droite ou à gauche. Et on peut meme utiliser Visual Studio (le classique pas le code) pour compiler et debugger le prog linux
votre avatar
A part ceux coincer sur windows (cela en fait pas mal), pourquoi vouloir monter une usine à gaz plutôt que d'utiliser linux directement ?
votre avatar
pour tous les dev en entreprise dont le PC est sous windows
votre avatar
D'ou "a part ceux coincer sur windows"
votre avatar
Moi ce qui me pose problème avec WSL, c'est Windows. Il bouffe beaucoup trop de RAM.
votre avatar
Je crois que ces dev containers vont plus loin que Windows, tu peux composer un conteneur en quelques lignes de json, il y a des morceaux tout prêts.
Il y a une extension dans Visual Studio Code, tu ajoutes la définition de ton conteneur de dév en un fichier json rempli avec "Wizard", et quand tu lances le projet le conteneur s'ouvre tout seul (se télécharge et se construit et se lance).
Tout cela fait un ensemble pratique.

Tu ouvres un projet, et l'env associé avec toutes les dépendances est immédiatement disponible... Tu peux directement entrer dans un projet, même sans maitriser le jeu technologique et toutes ses dépendances.

Tu peux créer un projet, tout prêt, tes interlocuteurs pourront s'en servir immédiatement.

Par exemple, à la maison, j'ai récupéré un vieux truc en Angular 16. En quelques clics, j'ai composé un dev container adapté avec les vieilles versions de tous les outils. Comme cet env est décrit dans le code du projet, un prochain codeur peut immédiatement être opérationnel. Ce dév conteneur est aussi dédié à ce projet, donc suffisamment isolé pour que je le considère assez "sécurisé", même si toutes les dépendances ne sont pas de première jeunesse (point à creuser ou discuter, mais tu as l'idée générale).


Evidemment, Microsoft veut que ce soit transparent sous Windows. Mais c'est l'écosystème "dev containers" qui est pratique, quelque soit le système d'exploitation du poste de dév.
votre avatar
Rien de bien nouveau en soit (plus de 10 ans que ça existe) sa devient juste "natif" (façon de parler puisque la sous couche Linux est nécessaire) sous Windows.
Si il pouvait maintenant ajouter aussi l'équivalent de compose et une config simple pour faire tourner ça comme service sans session utilisateur qu'on en finisse avec les bricoles quand on a des projets containérisé censé tourner sur plusieurs OS.
votre avatar
Je crois que ces dev containers vont plus loin que Windows,
Les Dev Containers pour VS code existent depuis un moment déjà, et mes collègues qui s'obstinent à vouloir développer une application cloud (avec des conteneurs Linux inextricablement dépendants d'AWS) sur des PC Windows l'utilisent avec succès se débattent avec depuis un moment. Il me semble que ça marche titube via Docker Desktop.
votre avatar
Dans ce cas précis je ne vois pas trop la différence avec un projet dockerisé de manière classique sous WSL qui se lance aussi "tout seul" avec une commande docker. Si ce n'est peut-être la simplicité de ne même pas avoir à lancer une commande manuellement...
votre avatar

Il n'y a pas que le lancement qui soit facilité.

Dans mon cas, j'ai utilisé un Wizard pour créer le conteneur, il y avait tout un choix de conteneurs de départ, de librairies ajoutables. Ce fut trivial, de la création du conteneur, jusqu'à son exécution, et même quelques ajustements. Il existe probablement des images docker toutes prêtes, mais il faut les chercher, leur faire confiance, ajouter des librairies...
Ce dev conteneur a monté tout seul le code source, qui est pourtant dans un autre conteneur WSL (celui qui contient git).
Et mon dév conteneur est inclut dans le projet...
VisualCode sous Windows s'est mis au milieu et a tout géré.

Quand je vois la complexité habituelle pour créer/installer un env de dév directement exploitable, je trouve cela pratique.
Mais ce n'est pas la seule solution, heureusement.
votre avatar
moi j ai carrément virer wsl (ce qui libère de la mémoire en passant même arreté) apres plusieurs mois d'utilisation. WSL etait tres mal géré par l'ia Claude en ssh comme il sait tres bien le faire avec des vrais conteneurs LXC sur un proxmox par exemple. Plantage à répétitions. J'ajoute, de plus, que j'ai 4 ou 5 moteurs locaux d'IA local qui tournent direct sous windows, pas besoin d'une surcouche. les drviers CUDA nvidia existe pour windows. et oui comme dit 33A20158-2813-4F0D-9D4A-FD05E2C42E48 les devs containers existent déjà avant cette version , pratique via docker desktop et ça marche bien pour un usage simple mais sinon oui ça 'titille'
votre avatar
docker desktop n'est pas gratuit en entreprise , wsl si (si on part du principe que la licences windows vient avec le pc)
votre avatar
oui là effectivement. enfin , si t'es en entreprise et que tu fais des containers linux et que t'utilise wsl, tu sais te passer de docker desktop nan! sinon prenez un vieux pc/serveur et foutez-y un proxmox et faites du lxc.
votre avatar
ah non mais moi au boulot je suis sous linux donc m'en fou complet ^^ (même si en vrai j'aime vraiment bien wsl, ça marche vraiment pas mal (mon desk à la maison est sous windows (pas mal de soft win only malheureusement)

j'apportais juste cette précision sur le fait qu'il peu y avoir un marché (pour remplacer docker desktop justement).

après a la maison en dehors des clients, c'est full proxmox :) (je le pousse au boulot aussi mais ça passe pas , ils ont peut de pas avoir un truc stable et du support, du coup on paye des licences vmware une fortune pour pas grand chose vu que l'on utilise aucune des fonctions avancées de vmware (sauf DRS)
votre avatar
Oui. Même en entreprise, utiliser Docker en ligne de commande directement dans WSL est parfaitement gratuit. Docker Desktop n'est utile que pour les gens qui ne peuvent pas se passer du clicodrome, et ils sont apparemment nombreux, plein de développeurs senior dans ma boîte se liquéfient dès qu'on leur propose un utilitaire en ligne de commande. Je crains malheureusement que l'IA agentique va faire très mal au business model de Docker Desktop.
votre avatar
WSL, ça veut bien dire Windows Save Linux ? :D
votre avatar
S'ils pouvaient plutôt faire l'inverse, utiliser Linux pour faire tourner windows pour ceux qui pourraient encore en avoir besoin... Ça planterais la machine moins souvent, juste le contener.
votre avatar
Il existe un outil (je retrouve plus le nom) qui permet d'installer un windows sur linux, le faire tourner en parallèle et lancer les exe windows via le protocole rdp
votre avatar
utiliser Linux pour faire tourner windows
Il existe un outil
Winboat

github.com GitHub
votre avatar
Merci. C'était pas celui la que je connaissait mais ça à l'air d'être le même principe
votre avatar
C'était un peu de l'ironie, il ya les VM, et même la couche Proton.
votre avatar
C'était un peu de l'ironie
On avait compris, hein...
il y a les VM
Winboat n'est pas une émulation, il fait tourner un vrai Windows dans une VM. Il ajoute une couche (via RDP) pour afficher les fenêtres directement sur le bureau Linux. C'est exactement comme WSL mais dans l'autre sens. Et quand je dis WSL, je pense évidemment WSL 2, au cas où ;-)
la couche Proton
Qui lui du coup fait de la traduction d'API comme WSL 1. Pour les applications non-gaming, y'a le vénérable Wine sous-jacent aussi...
votre avatar
Merci pour la précision Winboat ;-)