đł LampBox passe en 2.1.0 !
Quelques semaines aprÚs la sortie de LampBox, la 2.1.0 est là : pas de changement d'architecture majeur, mais plutÎt une consolidation, avec des améliorations sur des comportements qui posaient problÚme dans certains contextes, et quelques ajouts qui manquaient pour que le mode reverse proxy soit réellement utilisable d'un bout à l'autre.
Le reverse proxy, enfin proprement
La version 2.0.x avait introduit une prise en charge partielle du reverse proxy, mais avec quelques angles morts qui avaient rendu le systĂšme un peu bancal en pratique. En particulier deux problĂšmes.
D'une part, la substitution de domaine dans la configuration ne se faisait pas correctement dans certains cas - dans le sens oĂč le domaine configurĂ© ne remplaçait pas le domaine dans les fichiers gĂ©nĂ©rĂ©s, ce qui conduisait, selon la configuration de l'environnement, des redirections ou rĂ©ponses erronĂ©es. C'est corrigĂ©.
D'autre part, les redirections phpMyAdmin en mode proxy partaient en vrille. phpMyAdmin possĂšde sa propre logique de gestion des chemins et redirections, qui ne s'entend pas toujours avec un reverse proxy en frontal. La gestion de ce cas est revue et ça redirige maintenant lĂ oĂč ça doit rediriger.
Enfin, j'ai ajoutĂ© des compose overrides dĂ©diĂ©s au mode proxy, ainsi qu'une gestion optionnelle de l'exposition du port MySQL. Autrement dit, on peut dĂ©sormais ajuster finement la stack en mode proxy sans devoir toucher au fichier docker-compose principal, ce qui est quand mĂȘme beaucoup plus propre.
La documentation a également été mise à jour pour refléter le nouveau flux de démarrage en mode reverse proxy.
La galĂšre SSL sous Windows / Git Bash
C'est par un pur hasard que je suis tombĂ© sur celui-lĂ , en tentant dans un environnement Windows avec Git Bash de gĂ©nĂ©rer des certificats SSL... ce qui plantait Ă cause d'un problĂšme de conversion de chemin comme seul MSYS â l'environnement Unix-like de Git Bash â pouvait en produire.
Pour ceux qui ne connaissent pas : MSYS (et MSYS2, dont Git Bash est un des dĂ©rivĂ©s) convertit Ă la volĂ©e certains chemins qui ressemblent Ă des chemins unix en chemins Windows, ce qui casse inopinĂ©ment certaines commandes. Ce genre de bug ne peut pas ĂȘtre observĂ© sous Linux ou macOS, et resterai invisible si on ne teste que sur ces plateformes, mais fait perdre une bonne heure Ă quelqu'un qui essaie LampBox sous Windows et n'arrive pas Ă comprendre pourquoi son certificat ne se gĂ©nĂšre pas.
La génération SSL prend maintenant ce cas en compte, et ça tourne nickel sous Git Bash/Windows. Si jamais il y a encore des galÚres, ne pas hésiter à me le faire remonter (par mail, commentaire ou issue).
HTTP/2 et la config Nginx
La configuration de Nginx mettait en oeuvre une syntaxe HTTP/2 qui était désormais dégagée dans les versions les plus récentes de Nginx. Les anciennes versions de Nginx l'acceptaient encore, mais c'est le genre de chose qui génÚre des warnings, qui finira par ne plus fonctionner, et qui donne une impression de configuration maintenue un peu à la va vite.
La directive http2 est désormais déclarée selon la syntaxe moderne, ce qui la rend compatible avec les versions actuelles et futures de Nginx sans avoir à y retoucher.
Gestion des versions MySQL/MariaDB
C'est peut-ĂȘtre le point le plus intĂ©ressant pour ceux qui utilisent LampBox sur des projets avec contraintes de version de base de donnĂ©es.
LampBox gĂšre maintenant des rĂ©pertoires de donnĂ©es sĂ©parĂ©s par version de MySQL/MariaDB. Ăa veut dire que si tu commutes d'une version Ă une autre, tes donnĂ©es ne sont pas dans le mĂȘme dossier - et il n'y a pas de conflits, pas de corruption silencieuse parce qu'on aurait dĂ©marrĂ© MySQL 8.0 sur des donnĂ©es initialisĂ©es par MariaDB 10.6.
En complément, des vérifications de compatibilité sont ajoutées dÚs le démarrage pour détecter le plus tÎt possible d'éventuelles incohérences avant que ça parte en erreur obscure au milieu d'une session.
En gros, la 2.1.0 ne réinvente pas LampBox, elle le rend simplement beaucoup plus robuste sur des situations assez concrÚtes : le reverse proxy est utilisable (sans devoir faire d'acrobaties), les utilisateurs Windows ne sont plus bloqués sur la génération SSL et la gestion des versions de BDD est enfin un peu plus sérieuse.
Les PR sont les bienvenues !
đ LampBox sur GitHub
đ Release v2.1.0
10 commentaire(s)
Je parviens à faire cohabiter 2 projets simultanés, un avec un nom de domaine et nginx, l'autre en localhost avec un port dédié.
Au dĂ©part, je croyais que tout se passait dans la LampBox, d'oĂč mes premiĂšres questions mais au final, je me suis dit qu'il fallait autant de LampBox que de projets. C'est vrai que c'est moins pratique du coup, mais si c'est sur la todo list, tout espoir n'est pas perdu :-p
Je ne vois que deux solutions (Ă glisser lors de la prochaine MAJ) :
- soit on lance un Nginx mappĂ© Ă chaque projet (monprojet.local:81 et monprojet.local:82) -> mais on perd une partie de l'intĂ©rĂȘt du reverse proxy
- soit je vire Nginx en reverse projet et je reviens à une version basée sur Traefik
La premiÚre solution se limite à deux variables en .env et une modification du docker-compose.yml Mais elle est peu élégante
La seconde solution est clairement la mieux mais va nécessité un sacré boulot de refonte. C'est néanmoins la solution la plus viable : let's go pour une prochaine version majeure :-p
Quand on lance deux projets en parallÚle, avec deux noms de domaines différents et en utilisant le proxy, nginx reste pour les 2 projets sur le port 80 et j'ai l'erreur suivante quand je lance le 2Úme projet :
Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint diapo-nginx (a263c3d4a6ccc460281c0c24b2e8d99cd9a32c5d473284cab93680a0499f4e4a): Bind for 0.0.0.0:80 failed: port is already allocated(le projet s'appelant "diapo").J'ai tenté de modifier les fichiers dans le dossier config mais ce n'est pas pris en compte.
J'ai bien deux fichiers .env avec des ports différents
HTTP_PORT=8088pour l'un etHTTP_PORT=8083pour l'autre. Chacun a son propre nom de domaine. J'ai renseigné le fichier hosts. J'ai vidé le cache. Mais rien n'y fait. Si tu peux me donner un tuyau...Ce n'est pas trÚs élégant : la fonctionnalité est dans la TODO :)
.env, mais on les enregistre oĂč et avec quels noms ? On ne peut pas donner le mĂȘme nom Ă plusieurs fichiers ???J'avoue, je suis un peu paumĂ© car quand je regarde les scripts en .sh, ils vont tous chercher un seul fichier
.envà la racine de lampbox.Petite question : comment fait-on, quand on a des projets sans base de données (style Bludit), pour ne pas lancer MySQL ?Feature en cours de développement, en intégrant un systÚme de profil à docker-compose.yml :-)
sudo resolvectl flush-caches,systemd-resolven'étant plus utilisé.Laisser un commentaire