18008 sujets

Questions générales et questions de débutants

Docker & volume avec Windows/WSL2

Bonjour à tous,

J'utilise de plus en plus Docker pour mes environnements de travail locaux, et en ce qui concerne le conteneur de mon application web, j'aime bien mettre en place un volume qui pointe sur le répertoire de travail local vers le /www du conteneur. De cette façon, toutes les modifications que j'effectue dans le code sont immédiatement répercutées sur mon app. Sans ce volume, il faut sinon à chaque fois refaire un docker-compose up --build pour redémarrer et relancer le build :

version: '3'

services:
  www:
    # ...
    volumes:
      # Chemin local du projet web : Chemin dans le conteneur Apache
      - /mon/chemin/local:/var/www


Cette technique fonctionne parfaitement bien sur mon Mac, mais avec Windows, mon conteneur devient très lent : il faut une 20aine de secondes pour exécuter une requête HTTP.
Cela viendrait de la manière dont les systèmes de fichiers de Windows et Linux communiquent.
Avec Wamp, le même projet s'exécute 100 fois plus vite... Smiley lol

Sur ma machine Windows 11, j'ai installé WSL2, mais je pense que je l'utilise mal ; il semblerait qu'il faille stocker les fichiers de son projet au sein du système de fichiers WSL 2, et c'est ce que je ne fais pas. Si certains par ici travaillent avec des volumes Docker sous Windows, je suis preneur de conseils Smiley smile

Quelqu'un saurait m'expliquer simplement comment faire en sorte que mon volume pointe vers le code de mon projet web local, en utilisant WSL2 ? Avez-vous un retour à propos des performances ?

Merci d'avance !
Administrateur
A priori, sous Windows il s'agit d'une émulation donc les lenteurs sont bien réelles par rapport à Linux. On le constate lorsqu'il y a des accès disque, au volume, avec un certain nombre de fichiers en oeuvre, par exemple dans des gros projets PHP. Il ne semble pas y avoir de solution magique, à part utiliser (un vrai) Linux par exemple.
On a la possibilité d'installer une distribution Debian depuis le Microsoft Store et de l'utiliser avec WSL2. Il faut que j'essaie cela lundi.

Il semblerait que WSL2 soit un secteur du disque réservé, et Debian pourrait fonctionner dessus, tout en étant intégré à Windows. Il suffirait de monter mon projet au sein de WSL pour profiter de meilleures performances, mais j'ai l'impression que dans ce cas-là aussi, on se heurte au même problème...
Modifié par Loraga (09 Aug 2023 - 11:55)
Modérateur
Salut,

Rodolphe a écrit :
.... à part utiliser (un vrai) Linux par exemple.


+1

@loraga : Windows pour le développement (hors environnement Microsoft), bof.... Pour installer quoique ce soit, c'est chiant. Ce n'est pas pour rien qu'il y a WAMP, XAMP, Laragon par exemple. Ça fait bien longtemps, que je n'utilise plus windows pour développer. Je suis même quasi sûr qu'avec une VM, un bureau léger et un environnement docker sera mieux qu'avec Windows natif. Depuis la version 10, Windows s'est beaucoup amélioré. C'est devenu un excellent OS. Mais en ce qui concerne le développement, ce n'est pas ça.

Loraga a écrit :
On a la possibilité d'installer une distribution Debian depuis le Microsoft Store et de l'utiliser avec WSL2. Il faut que j'essaie cela lundi.

Il semblerait que WSL2 soit un secteur du disque réservé, et Debian pourrait fonctionner dessus, tout en étant intégré à Windows. Il suffirait de monter mopn projet au sein de WSL pour profiter de meilleures performances, mais j'ai l'impression que dans ce cas là aussi on se heurte au même problème...


Pour moi, c'est du bricolage. Autant partitionner et installer une Debian. Ce n'est pas compliqué quand on connait. En plus, on a largement plus de facilité et de liberté que ce bidouillage. Quand j'entends Docker sur windows, je dis : bonne chance ! Je connais un dev qui a jeté l'éponge il y a quelques années. Il en avait ras-le-bol de peu de possibilités que Windows lui offrait. Alors, pendant un temps, il a tourné sur une vm. Puis un autre ras le bol. Depuis, il utilise un fork d'Arch. Perso, je ne suis pas fervent de cette distribution. Mais revenir sur Windows pour dev, même pas en rêve pour lui aussi.

J'ai un windows sur ma machine principale. Mais je ne m'en sers pas pour développer.

ps : cette semaine, j'ai discuté avec un propect. Je lui ai demandé à propos de Linux. Il m'a certifié qu'avec Windows, le projet ne peut pas tourner. L'année dernière, j'ai fait 3 missions où Windows ne peut pas faire tourner les projets.
Modifié par niuxe (05 Aug 2023 - 15:05)
Effectivement, je le constate aussi avec mon Mac : c'est bien mieux. Mais je n'ai pour l'instant pas d'autre choix que de bosser avec Windows au sein de mon équipe.
Je compte bien passer sous Debian dès que possible, mais là n'est pas le propos de ce post. Je demande plutôt s'il y a des solutions avec Windows et si oui, lesquelles.
- D'autres utilisateurs dans le même cas ont-ils un retour à ce sujet ?
- Est-ce qu'il y a des choses à mettre en place que je n'aurai pas fait ?

S'il s'avère qu'il n'y a aucune solution, soit. Mais j'aimerais explorer au maximum le fonctionnement de Docker avec Windows afin de savoir si c'est la solution que l'on doit mettre en place au sein de mon équipe.

J'ai imaginé deux trucs qui pourraient permettre à Docker de fonctionner plus efficacement sur Windows :
- Une extension VSCode qui s'occupe, à chaque enregistrement d'un fichier, d'aller le mettre à jour sur l'image Docker. Ainsi, on n'utilise pas le système de Volume, et on met à jour l'image sans devoir la build. L'opération serait forcément plus rapide qu'un build complet, et on aurait là des performances supérieures ou égales à un Wamp. Problème : je n'ai pas trouvé d'extension qui fait cela !
- Une partition ext sur mon disque dur. Bon, il faudrait que Windows puisse lire les fichiers, c'est pas gagné, mais si mes projets se situaient dessus et que le volume Docker pointe sur cette partition, ça devrait marcher...

Je pense que la solution de l'extension serait une solution viable, qu'en pensez-vous ?
Modérateur
Loraga a écrit :
Une extension VSCode

Peu probable que VSC ou même un autre éditeur/ide améliore les perfs.

Loraga a écrit :
d'aller le mettre à jour sur l'image Docker.

L'image ? Quand elle est créée, on n'y touche plus. On lance des containers (docker-compose).

Loraga a écrit :
Ainsi, on n'utilise pas le système de Volume, et on met à jour l'image sans devoir la build.


Heuu non... Le systeme de volume sert à faire un partage entre dossier du container et le dossier physique/en local. 


docker run ... -v chemin/dossier/local:chemin/dossier/dans/le/container ...


Loraga a écrit :
S'il s'avère qu'il n'y a aucune solution, soit. Mais j'aimerais explorer au maximum le fonctionnement de Docker avec Windows


Comme je le dis si bien : bonne chance. C'est connu que Docker sur windows c'est chiant (compliqué) à mettre en place et c'est lent. Or, dans un environnement Unix/Unix-like c'est très facile et performant.

Attention, si tu comptes mettre en prod images et containers, tu as des failles de sécurité. En exemple, il y a eu CVE-2019-5736
Modifié par niuxe (06 Aug 2023 - 03:09)
Hello,

J'ai pu me débrouiller avec WSL2 et j'avais effectivement loupé une bonne partie de la compréhension de son fonctionnement. J'ai pu installer Debian depuis le Microsoft Store et je l'ai configuré pour qu'il s'exécute par défaut avec WSL. Désormais, avec la commande 'wsl' depuis PowerShell, j'ai directement accès à un Debian natif. De ce que j'ai compris, Windows exécute un env. Linux natif en utilisant une virtualisation légère.

J'ai pu ainsi faire quelques tests de performance en exécutant une app PHP/Symfony. Si mon app se trouve sur mon disque Windows et que le volume du container pointe sur un répertoire du disque Windows, j'ai en effet des perfs horribles : en moyenne 43 secondes pour une simple requête HTTP.

Par contre, si je déplace mon repo local dans mon Debian sous WSL2, et que je docker-compose up depuis mon Debian, là, ça marche vraiment bien : en moyenne 95ms pour la même requête HTTP, et en plus, je peux modifier mon code sans avoir à build à nouveau pour que mes modifications soient prises en compte.
Cela nécessite juste d'installer l'extension VSCode WSL afin de pouvoir travailler au sein de WSL avec VSCode.
Il faudra aussi reconfigurer son env. local, notamment Git, sur le Debian, mais rien de bien compliqué.

Il y a pas mal d'infos dans la doc de VSC, notamment ici et là Smiley smile

Je pense que WSL2 apporte finalement la solution pour exécuter du Docker avec Windows, c'est assez récent et les perfs semblent réellement meilleures par rapport à la première version de WSL. En tout cas, c'est intéressant ! Je bosse avec depuis le début de la semaine et je n'ai pour l'instant pas de retour négatif à son sujet.
Modérateur
Salut,

Bravo ! Mais bon, obligé d'utiliser vsc et pour installer le bordel. C'est compliqué tout de même. En tout cas merci pour ta réponse instructive.
JetBrains propose un fonctionnement similaire avec WSL2, je pense (j'espère) que c'est le cas pour les principaux IDE du marché. En tout cas, cette solution répond parfaitement à mon besoin personnel, appréciant VSC. Je n'ai pas trouvé cela trop compliqué à mettre en place si l'on a les infos, du moins, pas plus que d'installer et de configurer un Wamp ^^

J'ai tout de même rencontré une petite galère avec xDebug, qui n'a pas été simple ! En fait, la configuration n'est pas compliquée (voir ce lien GitHub pour l'exemple) mais le parefeu de Windows Defender empêche l'activation des points d'arrêts de xDebug. Horrible !

Je n'aurais jamais trouvé la solution si je n'étais pas tombé sur cette issue qui indique devoir exécuter ces deux commandes depuis PowerShell en admin :

Set-NetFirewallProfile -Profile Private -DisabledInterfaceAliases "vEthernet (WSL)"
Set-NetFirewallProfile -Profile Public -DisabledInterfaceAliases "vEthernet (WSL)"

Ces commandes fonctionnent sous Win 11. Et là, magie, les hitpoints fonctionnent Smiley lol

Maintenant, j'ai mes apps PHP sous docker, avec un Debian local, et un xDebug qui fonctionne. Passé cette configuration, c'est très confortable au quotidien !
Prévenir un modérateur
Répondre au sujet
Aller à