Bonjour à tous,

Je dois exceptionnellement travailler sur un vieux site Prestashop 1.4 en PHP 5.2 et il faut donc que je mette en place un petit environnement local de travail qui puisse le faire tourner.

J'ai alors installé Docker aujourd'hui, et même si la mise en place des vieilles versions de Prestashop, PHP et MySQL a été assez simple, je galère vraiment sur un point : travailler sur les fichiers du conteneur qui fait office de serveur web.

Depuis le terminal du conteneur, je vois bien le contenu de mon dossier "www", mais depuis mon poste Windows, je ne parviens pas à y accéder. À la maison, je bossais sous MacOS, et j'avais totalement abandonné MAMP, XAMP car je trouvais Docker très pratique et simple à mettre en place.

Au boulot, je travaille avec une machine sous Windows 11 et Visual Studio Code. Idéalement, j'aimerais pouvoir :
- Accéder aux fichiers du conteneur depuis l'explorateur, et depuis VSC pour les éditer facilement
- Pourvoir y effectuer un git clone du projet
- Utiliser la clé SSH de mon poste Windows pour avoir les autorisations d'accès au repo

J'ai bien mes conteneurs de serveur web, MySQL et PHPMyAdmin qui fonctionnent ensemble, j'y accède via mon navigateur, mais je ne parviens pas à réaliser ces trois points. Sous MacOS, je n'avais pas de clé SSH mais je n'avais aucun problème à accéder aux fichiers depuis le Finder ou encore d'exécuter des commandes Git avec le compte local.

J'ai essayé l'extension VSC officielle de Docker, j'accède par ce biais aux fichiers du répertoire "www" du conteneur, je peux les modifier, mais ça demande de redémarrer le conteneur pour que les modifs soient prises en compte, et je ne parviens de toute façon pas à y utiliser git de cette manière.
Je me suis penché sur les volumes de Docker, je pensais pouvoir "lier" un répertoire de mon ordi au "www" du conteneur, hélas en vain ^^

Depuis l'explorateur Windows, j'ai cependant bien un point de partage nommé Linux, qui contient deux autres points, ils ressemblent bien à l'arborescence de base de deux machines Linux, mais je ne retrouve pas les mêmes répertoires (il manque home, www...)

Je pense que j'ai loupé un truc sûrement simple pour le coup. Certains d'entre vous sont-ils plus à l'aise sur Docker pour pouvoir m'aiguiller ?

Je précise que j'ai déjà sur mon poste un Wamp qui héberge les projets principaux, et un Xamp qui héberge une API, les deux communiquent ensemble et je ne suis pas très chaud pour y faire cohabiter ce vieux PHP ^^

Merci d'avance pour votre aide Smiley smile
Salut,

j'utilise assez peu docker et c'était tout sous debian (mon ordi et l'image docker), mais clairement les volumes permettent bien de dire qu'un répertoire local de ton ordi est monter à un autre endroit, c'est ce qui permet de faire de la persistance de données.
J'avais une notation de ce genre la :
volumes:
            - MonPathLocal/var/logs/php:/MonPathDocker/log/php


Après je ne sais pas dire si il y a des spécificités sur Windows ou pas (je suppose que oui Smiley bawling )

Ensuite pour git pareil je sais pas comment c'est fait sous Windows.. et je suis pas sur de bien comprendre ton problème.
Si ce n'est pas encore un repo git, un
git init .
devrait suffire pour transformer ton dossier en dossier git puis ensuite il faudra rajouter un remote. Si c'est deja un repo git il faut juste le clone a priori et je vois pas de problème Smiley ohwell
Pour l'accès ssh cela doit pouvoir se configurer dans "l'application" de ton remote git (gitlab, github, etc, je ne sais pas ce que tu utilises)
Si tu utilise Docker sur windows, tu as peut etre / surment du installer ubuntu windows Smiley smile

Et du coup il faut lancer ubuntu (fenetre dos) et tu as accès à ton "réseaux" docker sous forme de /www.

Ensuite tu peux faire la commande "explorer .exe ." avec le "." final, et cela t'ouvre dans ton exploreur windows, et tu peux l'ouvrir avec ton ide
Merci à vous deux pour ces infos !
En fait, et j'ai oublié de le préciser, je suis parti d'une image du Docker Hub que j'ai utilisé avec la commande docker pull.
À partir de là, on a bien accès à nos machines et ça marche très bien, mais dans ce cas d'utilisation, je n'ai pas réussi à arriver à mes fins. Je n'ai trouvé nulle part les fichiers du conteneur sur ma machine.

Du coup, je suis passé par un Dockerfile et j'ai refait exactement la même config, en utilisant des volumes, et c'était parfait ! Les fichiers se situent bien sur ma machine, j'ai pu git clone le projet et l'utiliser avec VSCode sans aucun problème.

Mathieuu a écrit :
Ensuite pour git pareil je sais pas comment c'est fait sous Windows.. et je suis pas sur de bien comprendre ton problème.

En fait, je n'avais accès qu'au terminal du container et d'ici, impossible de cloner le projet car ma clé SSH locale n'était pas chargée, et du coup le repo m'interdisait l'accès ^^

JENCAL a écrit :
Si tu utilise Docker sur windows, tu as peut etre / surment du installer ubuntu windows Smiley smile

En fait, j'ai installé Docker Dektop, puis j'ai juste dû installer WSL 2 pour que ça fonctionne. C'est tout !
Dans mon cas, je n'ai pas réussi à "lancer ubuntu", je n'ai pas compris à quoi correspond la "fenêtre dos".
Depuis le terminal du container, lancer la commande "explorer .exe ." ne fonctionne pas, elle est introuvable (peut-être manque-t-il une dépendance ?)

Bon, en tout cas, quelque chose m'échappe avec l'utilité du Docker Hub et de la commande docker pull. J'ai regardé la doc, ça parle bien de "télécharger une image", mais même en configurant des volumes via la ligne de commande, je n'ai a aucun moment vu les fichiers sur mon ordi.
Si jamais vous utilisez le Docker Hub mieux que moi, je suis preneur de conseils sur ce sujet là, il y a énormément d'images toutes faites qui sont intéressantes, mais à part avec un Dockerfile je ne vois pas du tout comment l'utiliser.

Merci pour votre aide !
Modifié par Loraga (15 Feb 2023 - 20:58)
A priori, la "fenetre dos" c'est le terminal (invité de commande) de windows.

Après avoir fait ton docker pull, je suppose que tu as lancé une commande (docker run) pour exécuter ton image dans un conteneur. Normalement à cette étape la tu peux indiquer les volumes que tu veux monter dans ton image avec l'option -v
Modérateur
Salut,

Mathieuu a écrit :
Normalement à cette étape la tu peux indiquer les volumes que tu veux monter dans ton image avec l'option -v


L'option -v doit avoir cette syntaxe (il y a un séparateur ==> : )

$docker run -it -v /chemin/vers/dossier/local:/chemin/vers/dossier/dans/le/container debian


Aussi, il est souvent utile d'utiliser plutôt docker-compose lorsqu'il y a plusieurs conteneurs à lancer (dans ton cas : php/prestashop, mysql, phpmyadmin). Il est préférable d'avoir plusieurs petits conteneurs qu'un gros conteur qui fait tout.
Modifié par niuxe (16 Feb 2023 - 12:32)
Salut Niuxe,

Merci pour l'info Smiley smile La syntaxe de Mathieu est correcte dans le cadre d'un fichier docker-compose, en yml

En fait, quand j'utilisais plus régulièrement Docker, je passais systématique par un docker-compose et un Dockerfile pour le build. Et je trouve que ça simplifie beaucoup les choses Smiley smile

Quel est alors l'intérêt de créer ses containers directement en ligne de commande, sans passer par le docker-compose ?
Modérateur
docker-compose est la simplification de la ligne de commande. Quand tu as un container à lancer, le shell suffit amplement. Par contre, lorsque tu as plusieurs containers, un docker-compose est plus pertinent.

ps: J'ai lu avec beaucoup d'intérêt ton sujet. Mais sur Windows et pour ce genre de sujet, je ne peux pas t'aider puisque je bosse dans des environnements Unix/Unix-like. Il faut savoir que pendant longtemps Docker sous Windows, c'était bonne chance. Depuis, la team Docker a fait un portage pour Windows.
Les infos que vous m'avez tous données ici m'ont déjà permis de comprendre beaucoup de choses, merci Smiley smile

Du peu de mes essais et de mes besoins, je trouve que Docker sous Windows est identique à l'expérience que j'ai eu sous MacOS. Il semblerait que ce soit lié au support de WSL 2 par Windows, ce qui aurait alors grandement amélioré les performances de Docker sur cet environnement Smiley smile
On m'a dit la semaine dernière "Oh, Docker avec Windows, bon courage" mais j'ai l'impression que ce temps est révolu aujourd'hui. Je n'ai cependant pas connu l'avant et n'ai pas de point de comparaison ^^
Modérateur
niuxe a écrit :

...Il faut savoir que pendant longtemps Docker sous Windows, c'était bonne chance.
...

Loraga a écrit :
..."Oh, Docker avec Windows, bon courage"
...

Smiley cligne

Bien que j'affectionne GNU/Linux, il faut avouer que windows 10 est une vraie réussite. Normal, Biloute et Ballmer ne sont plus là.... D'ailleurs, on me dit dans l'oreillette que pendant sa retraite Biloutte est train de lire et de corriger les rapports de bugs notamment les problèmes liés au round32.dll. Smiley troll

Plus sérieusement et à une époque, si tu voulais développer sereinement sous windows, c'était avec les outils que proposait Microsoft (asp/.net/C#/Sharepoint/etc.). En dehors de ça, c'était plus compliqué. exemple pas si loin que ça : php/apache/redis/mongodb/docker (on parle des liens symboliques ou des virtualhost ?). Je connais beaucoup de personnes dans mon entourage qui ont jeté l'éponge (pendant un certain temps avant de migrer) obliger d'utiliser une vm dans windows qui parfois, ce n'était pas une solution optimale).

Dans ma dernière mission, j'ai bossé avec une équipe de dév et leurs environnements de travail était composés de :
- Fedora
- Debian (moi seulement)
- Ubuntu (une personne)
- une personne avec son win 10
Modifié par niuxe (21 Feb 2023 - 18:00)
Je suis bien content qu'aujourd'hui, on puisse mettre en place un environnement de travail efficace rapidement, peu importe son système d'exploitation. Je n'ai pas connu ce temps où installer son environnement de travail était synonyme de galère ^^

Linux me fait de l'œil depuis un moment (je ne sais pas encore quelle distribution choisir, probablement Ubuntu pour démarrer), et même si je ne code plus beaucoup à la maison, je sais que je remplacerai mon robuste MacBook Pro de 2013 lorsqu'il sera obsolète ou plus fonctionnel. Bon, il n'a pour l'instant toujours aucun signe de faiblesse après 10 ans.
En tout cas, je ne rachèterai pas de Mac, et n'ayant pas de préférence entre MacOS et Windows, je pense passer le cap Smiley smile
Modérateur
Loraga a écrit :
(je ne sais pas encore quelle distribution choisir, probablement Ubuntu pour démarrer)


Ubuntu ? Depuis la 13.04, je le regarde d'un sale oeil Smiley hum . Je ne parle même pas des fiasco officiels de cette distribution qui parfois même te planter la machine à tout jamais. L'année dernière, j'ai travaillé sur une 22.04. Un jour, j'arrive au bureau et impossible de me connecter à ma session ! Et ça, c'était la 2e machine. La première machine était devenue inutilisable pour travailler (impossible d'installer l'environnement de travail). Après, le CTO s'est aperçu que ce n'était pas cette machine qui m'était allouée.

tu veux quelque chose de bien ? Debian ! Ah oui, tu vas devoir mettre les mains dans le cambouis. Mais une fois installé et paramétré à ta convenance, tu ne le regretteras pas. Attention, la courbe est plus ardue mais tellement bénéfique ! Sinon, tu peux faire comme moi. Pour une autre machine, j'utilise opensuse leap qui est très bien. En 9 ans que j'utilise OpenSuse, j'ai eu une seule fois un souci. Une mise à jour foireuse avec Wayland (moteur de rendu).

Aussi, évite les rolling release... ça t'évitera des ennuies (après une mise à jour, écran noir parce que tu n'es pas allé sur le site officiel pour lire comment faire cette mise à jour (coucou Arch, Manjaro, etc.))....

Pour ce qui est de la branche red Hat (Fedora, CentOS, OracleLinux, etc.), je ne connais pas le sujet. je ne peux pas te faire des retours.

Pour mon expérience personnelle avec Ubuntu :
- 8.04 j'ai peu connu
- 8.10 : bugs
- 9.04 : bugs (quand Canonical traffique pulse audio)
- 9.10: bugs (quand Canonical traffique pulse audio & gnome 2)
- 10.04 excellent
- 10.10 : pas connu
- 11.04 : bugs
- 11.10 : bugs
- 12.04: bien (Quelques soucis avec Gnome Shell)
- 12.10: pas connu
- 13.04 : pas connu
- 13.10 : pas connu
- 14.04 : pas connu (sauf qu'à l'installe, c'était un gros bug. OS inutilisable)
- 14.10 pas connu
- 15.04 & 15.10 - pas connu
- 16.04: installé sur une de mes machines qui depuis, elle n'est plus à jour depuis des lustres.

Loraga a écrit :
je pense passer le cap Smiley smile

Vas y fonce

edit: j'ai oublié de mentionner que Canonical ne va plus supporter les flatpack. Tu auras droit aux snap (leur solution). encore une fois, ils font cavalier seul et pour finir qu'ils abandonneront par la suite.... (ubuntu mobile/ubuntu distribué à travers le monde/unity/etc.).
Modifié par niuxe (24 Feb 2023 - 20:52)
Mon setup avec mon MacBook Pro est un peu particulier : le Mac est refermé, et il est connecté à un boitier ElGato qui permet de m'offrir le luxe de n'avoir qu'un câble à brancher pour profiter de deux écrans 24'', de la connectique USB clavier/souris/disque dur de sauvegarde, d'un port Ethernet, casque et micro. C'est méga pratique Smiley confused

Mon Mac n'est pas encore vraiment obsolète, mais ça arrivera. Je pensais alors le moment venu le recycler avec un Linux, parce qu'il a tout de même une bonne configuration matérielle, largement suffisante pour du dév web.
La réinstallation d'un nouveau système se fera sans encombre sur un Mac qui partage comme point commun avec Linux le noyau UNIX Smiley smile Mais je me demande si je vais parvenir à réinstaller l'utilitaire lié à mon boitier ElGato, qui permet de le faire fonctionner et de profiter de ce confort. Ce genre de logiciel n'est dispo que sur un Mac, et je doute qu'il soit développé pour Linux. À part ça, je crois que ce sont les seuls points bloquants que j'ai qui m'empêchent de passer sous Linux plus tôt Smiley lol

Merci pour ton retour sur Debian ; la seule expérience que j'ai avec, c'est sur des serveurs web ou avec des Raspberry, sans interface graphique donc. Je n'ai jamais pris le temps de faire plus de recherches à son sujet, et je t'avoue, en tant qu'ignare Linux, que j'ai toujours cru qu'on ne l'utilisait que pour des machines n'ayant pas besoin d'écran, et pas comme un ordinateur de travail qu'on peut utiliser au quotidien Smiley lol