Windows, WSL et Docker, mode d’emploi

Cet article a été publié il y a 4 ans 4 mois 23 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Soit Qwant n’est pas encore assez doué, soit je n’ai pas trouvé l’intégralité des infos que je cherchais sur ce sujet. Et après avoir vu la vidéo de Thomas, dans laquelle il manque un ou deux morceaux, comme je suis moi-même en train de tester Ubuntu via le Windows Subsystem for Linux, me suis dit qu’il fallait tester moi-même, et vous faire un retour. Et ça n’a pas été forcément tranquille.

Une solution qui a quelques prérequis pénibles

Docker for Windows a un fonctionnement tout de même bien différent de sous Linux. Sous ce dernier, il fait encore appel partiellement à LXC, qui permet de « conteneuriser » l’application à l’exécution. Sous Windows, choix a été fait de reposer sur Hyper-V, la couche de virtualisation de Windows. Hors, cette couche nécessite une version « Pro » au minimum de Windows, donc exit tous les Windows vendus avec les laptops grand public du marché. Pour ma part, j’utilise une version entreprise LTSC, vous savez pourquoi, donc c’est bon.

Le deuxième prérequis apparent est là encore une décision détestable : demander de créer/disposer d’un compte sur le Docker Hub pour pouvoir récupérer Docker Desktop for Windows. Alors même que la version Linux et Mac n’en demandent pas autant. Devoir filer une fois de plus des infos persos, à une boite américaine de surcroit, pour un truc opensource et gratuit, non merci. Fort heureusement, j’ai fini sur un article anglais par trouver le lien direct vers l’installeur, qui fonctionne parfaitement, comme quoi demander un compte alors qu’on verrouille pas le direct download est juste de la malhonnêteté. Ce qui est « drôle », c’est que l’article en question conseille tout de même la création du compte, arguant que ça permet le téléchargement d’images. Se peut-il que le rédacteur se soit planté en utilisant « download » plutôt que « upload », à savoir téléversement, c’est à dire déposer des images sur le Hub, qui là oui demande un compte ? Mais la plupart des images sont publiques sur le Hub, donc pas besoin de compte pour les télécharger.

Enfin bon, c’était entre autres le gros point qui manquait dans la vidéo de Thomas, le reste, ça ne va être grosso modo que de la transcription. J’ai le temps d’écrire, le téléchargement prend 1Go pratiquement…

Configuration de Docker for Windows

A l’installation l’utilitaire propose de cocher une case « Use Windows containers instead of Linux containers », que j’ai laissé décoché évidemment. Il faudra se délogguer de votre session à la fin de l’installation, un peu comme sous Linux ou il faut relancer la session pour prendre en compte l’ajout de votre utilisateur au groupe docker pour que le démon accepte que vous l’utilisiez.

Le démarrage et le redémarrage du service Docker sont longs, très longs comparé à Linux, je soupçonne qu’en fait en dessous c’est une machine virtuelle Hyper-V qui est démarrée/redémarrée, et c’est pas rapide (ça expliquerait aussi la taille du téléchargement ceci dit). Je dis ça parce qu’une des premières choses à faire est d’aller dans les options de Docker (clic droit sur la baleine dans la barre des tâches, puis « Settings »), Pour décocher la télémétrie (Usage statistics, encore cette saloperie), et cocher « Expose daemon on tcp://… without TLS », c’est lui le plus important en fait.

Une fois validé, il vous demandera certainement de redémarrer, faites donc et patientez de longues secondes…

Configuration du client Docker dans WSL

L’installation du client docker (et uniquement lui) est gérable de manière tout à fait classique via la documentation officielle, à savoir ajout de la clé GPG, ajout du dépôt, et installation du client. Faut-il vraiment remettre les commandes ? Allez :

Il faut ensuite paramétrer l’environnement pour indiquer au client docker de taper sur le démon Windows qu’on a exposé un peu plus tôt. Pour ça, direction le fichier ~/.bashrc ( je préfère utiliser ~/.bash_aliases qui permet d’être plus indépendant de la distribution, et le bashrc d’Ubuntu est configuré pour charger celui-ci s’il existe), et ajouter une ligne dedans :

On le recharge ( source ~/.bashrc ) et roulez jeunesse. Un petit docker info devrait vous rassurer :

Mes soupçons se confirment, c’est bien une machine virtuelle Linux qui est utilisée avec un noyal 4.9.x comme référence pour le démon Docker.

Reconfiguration WSL pour les volumes

Ah, oui, en l’état ça fonctionne, vous pouvez démarrer du container à foison, mais pour la gestion des volumes c’est pas encore tout à fait ça. En effet, par défaut sur WSL les volumes de Windows sont « montés » dans le dossier /mnt/c, /mnt/d, etc. Et ceux-ci ne sont pas utilisables avec Docker, on va voir pourquoi :/

Il faut pour ça commencer par reconfigurer WSL, via un fichier de configuration /etc/wsl.conf avec le contenu suivant :

En fait, le « root », quand il n’est pas renseigné c’est /mnt. Vous commencez à voir où on va ?

Fermez la session, parce qu’il faut qu’on redémarre ensuite le service « LXSSManager », c’est le service système qui se charge de l’environnement WSL (oui, cherchez pas la logique du nom). Pour ça, j’ai une habitude fâcheuse mais très rapide depuis plusieurs années, c’est le raccourci clavier Win+R, services.msc :

Quand on relance, les volumes C:\, D:\ etc… ne sont plus montés dans /mnt/c/… mais directement dans /c/…, et ça tombe bien, puisque c’est le même point de montage dans la machine virtuelle de Docker Desktop. Il aura donc les bonnes informations pour aller créer/récupérer ses volumes. Attention, ça veut donc dire qu’il faut placer ses volumes persistants non pas dans la session WSL mais bien dans l’arborescence Windows. Avec toutes les limitations que posent le système de fichiers NTFS (sur la casse, les permissions…) 🙁

Y’a pas à dire, Linux c’est quand même mieux (ou le WSL 2 ?)

Ça a été long, chiant, mais ça fonctionne parfaitement. Malgré tout, c’est un sacré bidouillage, et une consommation de ressources sans commune mesure avec un démon Docker linux natif. C’est pas pour rien non plus que je me suis débarrassé de Windows au boulot, avec toutes les contraintes que ça m’a apporté derrière.

Microsoft l’a bien compris, et les améliorations tirées de ses enseignements sur Azure notamment l’ont poussé à travailler sur un WSL 2.0 qui embarquera un vrai noyau Linux pour pouvoir cette-fois-ci prendre en charge la version Linux de docker de manière native, donc beaucoup plus léger qu’un système à base de VM Hyper-V. Oui parce que j’ai pas évoqué l’impact sur les performances, mais disons simplement que c’est bien pour construire ses applis et tester leur stabilité, mais c’est pas l’environnement rêvé pour valider les performances…

WSL a d’autres limitations via certains programmes qu’on pourrait aborder dans d’autres articles. Déjà celle de Docker est contournée 🙂