Retour sur Windows et WSL

Après une année sur Linux, suivie d’une autre sur macOS, je suis de retour sur Windows. Pas parce que ces deux systèmes manquent de qualité – loin de là. Mais parfois, nos outils et nos besoins professionnels dictent nos choix.

Dans mon cas, je travaille dans un domaine où il est essentiel de pouvoir virtualiser des machines x86, sans compromis sur les performances et sans jongler avec des solutions complexes. Et, bien sûr, il y a toujours cette application spécifique, uniquement disponible sous Windows, qui a fini par m’y ramener.

Heureusement, ce retour ne signifie pas renoncer aux avantages de Linux. Avec les récentes évolutions de Windows Subsystem for Linux (WSL), il est désormais possible de combiner efficacement les deux environnements, tirant parti de leurs forces respectives, sans les contraintes habituelles.

Historique rapide de WSL

Avant que Windows Subsystem for Linux (WSL) ne voie le jour, travailler avec des outils Linux sous Windows relevait souvent de la débrouille. Pour ma part, mes premiers pas dans ce domaine ont commencé avec Cygwin, une solution qui, à l’époque, me semblait révolutionnaire. Pour info, la virtualisation n’était pas activée sur les postes de travail et l’accès aux bios bloqué.

Cygwin n’est pas un système Linux, mais une couche logicielle qui permet d’exécuter certains outils GNU/Linux sur Windows. À l’époque, cela me suffisait pour installer et utiliser des outils comme Ansible, même si cela demandait un peu de jonglage.

C’était loin d’être parfait. Certaines fonctionnalités complexes refusaient de fonctionner, et il fallait souvent bricoler pour contourner les limitations. Pourtant, cela me donnait un aperçu de ce que pourrait être une intégration native de Linux sous Windows. C’est là que WSL a changé la donne.

L’arrivée de WSL : un game changer

Quand WSL 1 est apparu en 2016, j’ai tout de suite voulu l’essayer. Contrairement à Cygwin, WSL proposait une véritable compatibilité avec les outils Linux, en traduisant les appels système Linux vers le noyau Windows. Plus besoin de jongler avec des solutions approximatives ou des workarounds douteux. Avec WSL, j’ai enfin pu exécuter mes scripts Ansible sans soucis majeurs.

Cependant, WSL 1 avait ses limites. Les performances n’étaient pas toujours au rendez-vous, et certaines applications nécessitant un accès profond au noyau Linux ne fonctionnaient pas. Malgré tout, c’était une avancée énorme pour les utilisateurs Windows.

WSL 2 : la révolution

En 2019, WSL 2 a bouleversé la donne. Contrairement à WSL 1, cette version utilise une machine virtuelle légère embarquant un véritable noyau Linux. Cela a apporté plusieurs avantages majeurs :

Compatibilité totale avec les outils Linux, y compris ceux qui nécessitent des fonctionnalités spécifiques du noyau.
Performances améliorées, notamment sur la gestion des fichiers.
Support natif pour Docker et d’autres solutions basées sur les conteneurs.

Avec WSL 2, je pouvais non seulement exécuter Ansible, mais aussi tester des environnements complexes, déployer des conteneurs et même travailler avec des bases de données exigeantes comme PostgreSQL.

Cependant, les premières versions de WSL 2 n’étaient pas parfaites et comportaient des limitations notables, en particulier sur la partie réseau et la virtualisation.

Initialement, chaque instance de WSL 2 utilisait son propre réseau NAT, ce qui compliquait l’accès aux services depuis l’extérieur ou entre WSL et Windows. La configuration réseau manuelle était souvent nécessaire, notamment pour exposer des ports ou connecter des services.
Non prise en charge des services Linux : Les premières versions de WSL 2 ne permettaient pas de faire tourner des services Linux en tâche de fond de manière fiable. Il fallait souvent relancer manuellement les services après chaque redémarrage de WSL.
Absence de virtualisation imbriquée :La virtualisation imbriquée (nested virtualization), essentielle pour exécuter des environnements comme Docker Desktop ou Vagrant dans une VM Linux sous WSL, n’était pas prise en charge au départ. Cela limitait l’utilisation de WSL pour certains workflows DevOps ou d’administration système avancés.

Voilà où j’en étais resté en 2022, avant mon passage à Linux.

Les Nouveautés de WSL depuis 2022

Depuis 2022, Windows Subsystem for Linux (WSL) a bénéficié de nombreuses améliorations, enrichissant l’expérience utilisateur et renforçant l’intégration entre Windows et Linux. Voici un aperçu chronologique des principales nouveautés :

Prise en charge de Systemd (2022) : Introduction du support de Systemd, le gestionnaire de services par défaut pour la plupart des distributions Linux, permettant une gestion plus native des services sous WSL.
Support des applications GUI Linux (2022) : Intégration de WSLg, permettant l’exécution native d’applications Linux avec interface graphique directement sous Windows, avec support de l’accélération matérielle GPU.
Libération automatique de la mémoire (Septembre 2023) : Implémentation de la fonctionnalité de récupération automatique de la mémoire, permettant à WSL de libérer la mémoire inutilisée, optimisant ainsi les performances du système.
Améliorations réseau : DNS Tunneling et mode miroir (Septembre 2023) : Introduction du DNS Tunneling et d’un mode réseau en miroir, améliorant la connectivité et la résolution des noms de domaine entre les environnements Linux et Windows.
Interface graphique pour la configuration (Mai 2024) : Lancement d’une application GUI pour les paramètres de WSL, simplifiant la gestion des distributions et des configurations sans recours à la ligne de commande.
Intégration de Red Hat comme distribution officielle (Novembre 2024) : Red Hat Enterprise Linux (RHEL) devient une distribution officielle supportée par WSL, renforçant l’interopérabilité pour les développeurs et les entreprises.

L’Application WSL Settings

Avec l’arrivée de l’application WSL Settings, Microsoft a franchi une étape importante pour rendre le Windows Subsystem for Linux (WSL) plus accessible. Cette interface graphique dédiée facilite la gestion et la configuration de WSL, notamment pour les utilisateurs qui préfèrent éviter la ligne de commande.

WSL Settings est une application GUI (Graphical User Interface) intégrée à Windows, conçue pour gérer les distributions Linux, les paramètres système et les fonctionnalités avancées de WSL. L’objectif est de simplifier l’utilisation de WSL, tout en conservant la flexibilité offerte par la ligne de commande pour les utilisateurs avancés.

Une particularité importante de WSL 2 est qu’il repose sur une machine virtuelle Hyper-V intégrée et cachée, inaccessible via les outils classiques de gestion Hyper-V de Windows. Cette machine virtuelle gère les ressources (CPU, mémoire, réseau, etc.) allouées à WSL. Avec WSL Settings, vous pouvez :

Ajuster la mémoire et les cœurs CPU alloués à la VM Hyper-V.
Configurer le mode réseau (NAT ou miroir) pour améliorer la connectivité.
Activer ou désactiver la virtualisation imbriquée (nested virtualization), indispensable pour exécuter Docker ou d’autres environnements virtualisés dans WSL.

Ces paramètres étaient auparavant gérés par des options avancées, souvent mal documentées. L’application WSL Settings permet désormais de les manipuler simplement, sans toucher à des fichiers obscurs ou exécuter des commandes complexes.

De plus, le fichier /etc/wsl.conf est au cœur de la configuration de WSL. Il permet de définir des paramètres des distributions, comme l’intégration réseau, la gestion des systèmes de fichiers ou l’activation de fonctionnalités spécifiques comme la virtualisation imbriquée.

Exemple de fichier wsl.conf :

[boot]
systemd=true

Avec l’application WSL Settings, vous pouvez modifier ces paramètres sans ouvrir d’éditeur de texte ou manipuler directement le fichier.

wsl settings

Prise en charge de Systemd

Systemd est un système d’initialisation et un gestionnaire de services, présent sur la majorité des distributions Linux modernes. Il gère tout, depuis le démarrage des services essentiels jusqu’à leur surveillance en temps réel. Avant son support dans WSL, il était impossible d’utiliser Systemd de manière native, ce qui posait des problèmes pour les utilisateurs ayant besoin de services comme :

Bases de données (PostgreSQL, MySQL).
Serveurs web (Nginx, Apache).
Applications de file d’attente (RabbitMQ, Redis).
Serveurs d’applications comme Celery ou des environnements Node.js.

Sans Systemd, lancer ces services dans WSL nécessitait souvent des ajustements complexes ou des scripts d’initiation artisanaux.

L’intégration de Systemd dans WSL repose sur une réorganisation de la gestion des processus Linux. Lorsqu’il est activé, Systemd devient le processus PID 1, ce qui lui permet de gérer les services comme dans un environnement Linux natif. Voici comment l’activer et l’utiliser dans WSL :

Configurer Systemd dans /etc/wsl.conf Pour activer Systemd, il suffit d’éditer le fichier /etc/wsl.conf de la distribution concernée :
```
[boot]
systemd=true
```
Ensuite, redémarrez la distribution pour appliquer les changements :
Terminal window
```
wsl --shutdown
```
Lancer et gérer des services Une fois Systemd activé, vous pouvez utiliser les commandes habituelles pour gérer les services.

La prise en charge de Systemd est une aubaine pour les développeurs travaillant dans des environnements Linux, mais contraint à travailler depuis un poste Windows.

Virtualisation imbriquée

L’introduction de la virtualisation imbriquée (nested virtualization) dans Windows Subsystem for Linux (WSL) est une avancée importante pour les développeurs et administrateurs système. Cette fonctionnalité permet d’exécuter des machines virtuelles à l’intérieur de l’environnement WSL, ouvrant la voie à des workflows avancés directement sur votre poste de travail, sans devoir déployer des ressources sur des serveurs distants.

Dans mon cas, cette nouveauté va me permettre de tester des rôles Ansible avec Incus (le fork communautaire de LXD) directement sur mon poste Windows, sans avoir à jongler avec des machines virtuelles externes. En parallèle, elle va aussi m’offrir la possibilité de manipuler des images avec des outils comme libguestfs, un élément essentiel pour mon travail avec les éditeurs souhaitant intégrer notre plateforme cloud.

Qu’est-ce que la virtualisation imbriquée ?

La virtualisation imbriquée consiste à exécuter une machine virtuelle ou un hyperviseur à l’intérieur d’une autre machine virtuelle. Dans le cadre de WSL, cela signifie que la machine virtuelle Hyper-V sous-jacente peut elle-même héberger d’autres machines virtuelles ou conteneurs. Cela permet de créer des environnements complexes dans WSL sans passer par des outils externes comme VirtualBox ou VMware.

Limites et points d’attention

Bien que puissante, la virtualisation imbriquée peut consommer beaucoup de ressources. Voici quelques points à garder en tête :

Assurez-vous que votre machine dispose de suffisamment de RAM et de cœurs CPU pour gérer les environnements imbriqués.
Les performances des VM imbriquées, bien que bonnes, peuvent être légèrement inférieures à celles obtenues avec une virtualisation classique directement sur la machine hôte.

Conclusion

Revenir sur Windows après deux années passées sur Linux et macOS aurait pu sembler un compromis. Mais grâce aux progrès de Windows Subsystem for Linux (WSL), ce retour s’est transformé en une opportunité de combiner le meilleur des deux mondes. WSL offre désormais un environnement Linux natif, intégré à Windows, tout en conservant les performances, la simplicité et la compatibilité qui me sont indispensables dans mon travail quotidien.

Les avancées récentes, comme la prise en charge de Systemd, permettent enfin de gérer des services comme si l’on était sur un serveur Linux classique, ce qui est indispensable pour développer et tester efficacement des applications et des workflows complexes. La possibilité d’exécuter des applications GUI Linux directement sous Windows a également éliminé le besoin de jongler entre plusieurs machines.

Avec des fonctionnalités comme la virtualisation imbriquée, je peux maintenant développer des rôles Ansible en local avec Incus ou manipuler des images via libguestfs (d’ailleurs je devrais en faire un guide), tout cela sur une seule machine. Plus besoin de dépendre de ressources distantes ou de compromis frustrants.

L’arrivée d’une interface graphique avec WSL Settings et l’intégration de Red Hat Enterprise Linux montrent également que Microsoft s’adresse à des utilisateurs variés, qu’ils soient développeurs, administrateurs ou intégrateurs. Toutes ces évolutions font de WSL un outil complet et mature, parfaitement adapté à des besoins professionnels exigeants.

En 2024, WSL est bien plus qu’une simple passerelle entre Windows et Linux. C’est une solution puissante qui répond à des besoins concrets, en offrant une flexibilité que je n’avais jamais imaginée il y a quelques années. Que vous soyez dans le développement, l’intégration ou simplement curieux d’explorer les deux écosystèmes, WSL mérite votre attention. Pour moi, c’est un incontournable.

Si ca vous tente de l’installer, c’est par là. J’ai tout expliqué même pour le mode déconnecté.