Closed blaisegeo closed 2 years ago
Bonjour;
Après avoir bien relu les documentations et les problèmes rencontrés, j'ai décidé de tester en attribuant un nom de sous-domaine au serveur hébergeant geotrek-rando-v3, alors qu'il n'avait jusqu'ici qu'une IP. En faisant ensuite une reconfiguration de geotrek-admin (qui a malheureusement fait sauter la configuration SSL - HTTPS, mais c'est une autre histoire), l'affichage des itinéraires sur geotrek-rando-v3 s'est mis à fonctionner correctement.
C'est bien écrit dans la documentation de geotrek-admin, dans les "Informations à préparer avant l'installation" ( https://geotrek.readthedocs.io/fr/latest/installation.html#information-to-prepare-before-installation ): le serveur où se trouve geotrek-admin peut avoir un nom de domaine ou bien simplement une IP; par contre le serveur sur lequel est installé geotrek-rando doit impérativement avoir un nom de domaine; ça ne fonctionne apparemment pas avec simplement une IP). (Ceci est d'ailleurs un peu dommage, ça limite un tout petit peu lorsqu'on veut faire des tests)
OK bien vu. Je ne sais pas (plus ?) pourquoi Geotrek-rando ne fonctionne pas sur une IP. De mémoire par contre il lui faut du HTTPS, au moins pour la partie mobile en PWA.
Dans tous on arrive toujours à se faire un petit sous-domaine même temporaire pour les tests.
Mais à clarifier et préciser dans la doc si ce n'est pas possible de le faire tourner sur une IP.
Bonjour;
Je me permets de réouvir cette "issue" car je suis à nouveau confronté au même problème.
Comme indiqué plus haut, avec la version Geotrek-rando v3.1.2, j'étais arrivé à faire fonctionner le système après avoir défini un nom de domaine pour le serveur où tournait Geotrek-rando-v3.
Il y a quelques semaines, j'ai installé la version v3.4.0. J'ai bien paramétré le site dans tous les sous dossiers sous le répertoire /customization. Tout fonctionnait, sauf l'affichage des itinéraires, même problème que mon premier post plus haut: au bout d'un moment où ça tourne dans le vide, le navigateur internet affiche "504 Gateway Time-out".
Je viens d'installer la toute dernière version v3.5.2 et j'ai toujours exactement le même problème.
Les serveurs Geotrek-admin et Geotrek-rando sont bien en https forcé automatiquement.
Ce qui est curieux, c'est si je prends l'url qui est affichée une fois l'erreur obtenue, par exemple: https://sousdomaine.domaine.com/trek/2743-Col-du-Soufre , que je rafraîchis cette page, et que juste après, à partir d'une connexion ssh sur un tout autre serveur, je lance la commande: $ wget https://sousdomaine.domaine.com/trek/2743-Col-du-Soufre alors, la page s'affiche enfin correctement dans le navigateur internet, comme si ça l'avait débloquée !?!
Je pense que j'ai encore un problème de configuration, de nginx je suppose, mais celui de quel serveur ? Admin ou rando ? Je ne trouve toujours aucune piste intéressante dans les logs des serveurs, mise à part le Time-out.
Auriez-vous s'il vous plait un exemple fonctionnant du fichier: /etc/nginx/sites-available/geotrekrand.conf du serveur Geotrek-rando et du fichier: /opt/geotrek-admin/var/conf/nginx.conf du serveur Geotrek-admin ?
Merci pour tout éclaircissement.
La conf NGINX de https://rando.ecrins-parcnational.fr. Attention il y a toute une partie lié au fait qu'on expose encore nos données sous la forme de GTR v2 et pour Geotrek-mobile :
server {
location / {
proxy_pass http://localhost:82;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
##### Debut GTR v2 et GTM v3
# Pour ouvrir les geojson (et gpx et kmz en passant, utile ?) dans le navigateur plutôt que de les télécharger
# Pour l'accès à l'API statique de GTR v2
include mime.types;
types {
application/json geojson;
application/gpx+xml gpx;
application/vnd.google-earth.kmz kmz;
font/ttf ttf;
font/woff2 woff2;
}
# GTM v3 languages
if ( $http_accept_language ~ ^(..) ) {
set $lang $1;
}
# Access to GTM v3
location ~ ^/mobile/(.*)$ {
root /home/geotrek/RE/datamobil/;
try_files /$lang/$1 /nolang/$1 =404;
#try_files /$http_accept_language/$1 /nolang/$1 =404;
# Ajouter les headers de contrôle d'accès CORS
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
}
# Access to GTR v2 data
location ~ ^/(api|media|static|zip|meta)/ {
root /home/geotrek/RE/data/;
}
##### Fin GTR v2 et GTM v3
server_name rando.ecrins-parcnational.fr;
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/rando.ecrins-parcnational.fr/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/rando.ecrins-parcnational.fr/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = rando.ecrins-parcnational.fr) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name rando.ecrins-parcnational.fr;
return 404; # managed by Certbot
}
La conf NGINX de notre Geotrek-admin. Attention, je ne suis pas forcément exactement à jour des recommandations des dernières versions, revues suite à ce ticket : https://github.com/GeotrekCE/Geotrek-admin/issues/2670.
Il vaut mieux repartir du template bien à jour : https://github.com/GeotrekCE/Geotrek-admin/blob/master/conf/nginx.conf.in
Activer le SSL avec certbot, puis reporter les ajouts de Certbot dans la surcouche de ton template dans /opt/geotrek-admin/var/conf/nginx.conf.in
# Generated by dpkg installation. DO NOT MODIFY MANUALLY.
# Instead, run "sudo dpkg-reconfigure geotrek-admin"
# or edit /opt/geotrek-admin/var/conf/nginx.conf.in
upstream ui_server {
server unix:/tmp/gunicorn-geotrek.sock fail_timeout=0;
}
upstream api_server {
server unix:/tmp/gunicorn-geotrek_api.sock fail_timeout=0;
}
map $http_origin $allow_origin {
"~*" $http_origin;
default "";
}
add_header Access-Control-Allow-Origin $allow_origin;
server {
server_name url.ecrins-parcnational.fr;
server_name_in_redirect on;
server_tokens off;
access_log /var/log/nginx/geotrek_access.log;
error_log /var/log/nginx/geotrek_error.log;
client_max_body_size 10M;
location /static {
expires 1d;
alias /opt/geotrek-admin/var/static;
}
location /media/upload {
expires 1d;
alias /opt/geotrek-admin/var/media/upload;
}
location /media_secure {
internal;
expires 1d;
alias /opt/geotrek-admin/var/media;
}
location / {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
keepalive_timeout 0;
location ~ ^/api {
proxy_pass http://api_server;
proxy_read_timeout 300s;
}
proxy_pass http://ui_server;
proxy_read_timeout 300s;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/url.ecrins-parcnational.fr/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/url.ecrins-parcnational.fr/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = url.ecrins-parcnational.fr) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name url.ecrins-parcnational.fr;
return 404; # managed by Certbot
}
# Add redirection FROM IP to domain - Camille
server {
server_name yy.xx.www.zzz;
return 301 https://url.ecrins-parcnational.fr;
}
nous constatons le même problème.
Je ne sais pas si ça a un lien mais sous chromium nous avons l'erreur suivante :
WorkboxError.js:28 Uncaught (in promise) bad-precaching-response: bad-precaching-response :: [{"url":"https://monurl/_next/server/middleware-manifest.json","status":404}]
Par ailleurs il semble y avoir un blocage lors l'appel à mondomaine.xx/_next/data/Fsi8uZKtrjy2RyHiXF5S0/fr/trek/mon_trek
J'ai aussi cette erreur dans la console en production (https://rando.ecrins-parcnational.fr) et sur le serveur de test (https://gtr3demo.ecrins-parcnational.fr), mais sans problème de chargement des pages.
Merci beaucoup pour le retour rapide et les fichiers de conf, Camille !
Côté Geotrek-rando, pour le fichier /etc/nginx/sites-availabe/geotrekrando.conf , j'ai exactement le même contenu, mis à part que j'utilise le port 8080 (celui de geotrek-rando par défaut je crois) dans la directive "proxy_pass", et que ne n'ai pas toute la section "DebutGTR v2 et GTM v3", et évidemment les noms de sous-domaine et de domaine sont différents.
Côté Geotrek-admin, j'avais au début, dans la section "map", la ligne qui est commentée ci dessous. Elle n'était pas commentée, je l'ai commentée et j'ai ajouté la ligne juste au-dessus, pour coller à ton exemple (j'ai déjà vu cette proposition sur d'autres "issues"):
map $http_origin $allow_origin { "~*" $http_origin;
default "";
}
Ensuite, la seule autre différence était que dans la directive "server_name", j'avais à la fois l'IP et le nom de sous-domaine, de domaine, séparés par un espace. Dans le doute, j'ai enlevé l'IP pour que ça ressemble parfaitement à ton exemple. Mis à part le nom de sous-domaine et de domaine, j'ai maintenant ces deux fichiers de conf rigoureusement identiques aux tiens.
j'ai bien fait un:
$ sudo nginx -t
puis un:
$ sudo systemctl reload nginx.service
sur les deux serveurs, pour tester les conf des 2 nginx et les recharger.
Peine perdue, toujours le même comportement, que je précise par rapport à ce que j'ai indiqué plus haut:
Toujours pareil, en faisant un wget sur l'url de la page de l'itinéraire qui devrait s'afficher, cela débloque la page du navigateur bloquée, si c'est fait avant qu'elle arrive en erreur. Idem si j'utilise deux navigateurs différents (Firefox et Chrome par exemple): si je consulte sur les deux navigateurs geotrek-rando-v3 et que je clique sur des itinéraires, cliquer sur un itinéraire dans un navigateur débloque et affiche la page d'un itinéraire qui n'arrivait pas à charger dans l'autre navigateur.
Vraiment du mal à comprendre d'où cela peut venir. Peut-être une configuration autre que celles de nginx ?
A notre avis, cela n'a rien à voir avec ta configuration NGINX. @amandine-sahl au PnCévennes a un soucis similaire qu'elle n'avait pas avec les versions précédentes (version 3.1 par exemple). En regardant dans la console du navigateur, la génération du rendu serveur d'une page par Next.js prend énormément de temps la première fois (mondomaine.xx/_next/data/Fsi8uZKtrjy2RyHiXF5S0/fr/trek/mon_trek), voire n'aboutit pas. Si on arrive à le générer une fois, alors la page s'affichera très rapidement les fois suivantes (cas quand tu as fait un wget sur la page).
Mais pour le moment, on ne voit pas d'où vient ce problème. Surtout que je ne l'ai jamais eu sur notre serveur de test, ni de démo...
Il semblerait qu'il y ait un soucis avec l'outil wretch utilisé pour générer le cache serveur Node.js quand une route renvoie un résultat supérieur à 1 Mo. Ce soucis est identifié au niveau de wretch et node.js mais pas solutionné actuellement. Ce qui expliquerait que l'on n'ait jamais rencontré le soucis sur notre serveur de démo ni notre serveur de production.
Pour confirmer cela, on vient de packager une nouvelle version de test (https://github.com/GeotrekCE/Geotrek-rando-v3/pkgs/container/geotrek-rando-v3%2Fgeotrek-rando-staging/11118734?tag=v3.5.3-beta1) avec l'ajout d'un paramètre pour désactiver le cache serveur (https://github.com/GeotrekCE/Geotrek-rando-v3/pull/529/files).
@blaisegeo, peux-tu tester de déployer cette version sur ton serveur ?
Pour cela il faut que tu modifies le fichier .env
à la racine de ton Geotrek-rando-v3-installer et modifies l'URL du dépôt du package par : IMAGE=ghcr.io/geotrekce/geotrek-rando-v3/geotrek-rando-staging:latest
puis que tu relances un docker-compose pull && docker-compose down && docker-compose up -d
. Tu passeras alors sur la version de test.
Dans ton fichier global.json
, il faut ajouter le paramètre "enableServerCache": false
puis redémarrer ton image avec docker-compose restart
.
Tu n'auras alors plus de cache. Le portail devrait alors être lent, mais le chargement des pages devrait fonctionner.
Tiens nous au courant, cela permettra de confirmer ou non les pistes que l'on investigue actuellement.
Merci pour le retour.
J'ai donc maintenant ce fichier .env à la racine:
IMAGE=ghcr.io/geotrekce/geotrek-rando-v3/geotrek-rando-staging:latest PORT=8080 CUSTOMIZATION_DIRECTORY=./customization MEDIAS_DIRECTORY=./medias
J'ai bien mis le paramètre: "enableServerCache": false dans le fichier global.json
J'ai exécuté les commandes: docker-compose pull && docker-compose down && docker-compose up -d
Maintenant, la page d'accueil s'affiche, mais sans la barre de boutons permettant de sélectionner les randos à pied, à VTT, etc !
J'avais créé des raccourcis sur la page d'accueil pour afficher la carte avec les activités de seulement une structure (raccourcis qui amenaient bien à la carte générale) de ce type:
https://sousdomaine.domaine.com/search?practices=4,5,6&structures=1
Ces raccourcis entrainent maintenant une page: "500 Internal Server Error"
On avance peut-être, j'essaie de comprendre pourquoi je n'ai plus la barre de boutons des activités sur la page d'accueil.
Problème de CORS sur la page d'accueil dans la console de Chrome ou de Firefox:
GEThttps://sousdomainegeotrekadmin.domaine.com/api/v2/touristicevent_type?language=fr&fields=id,type,pictogram XHRGEThttps://sousdomainegeotrekadmin.domaine.com/api/v2/touristicevent_type?language=fr&fields=id,type,pictogram CORS Missing Allow Origin
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://sousdomainegeotrekadmin.domaine.com/api/v2/touristicevent_type?language=fr&fields=id%2Ctype%2Cpictogram. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant
J'essaie de voir si je peux résoudre ça dans le fichier nginx.conf du serveur geotrek-admin.
Et l'erreur suivante aussi:
resolver.js:30 GET https://sousdomainegeotrekadmin.domaine.com/api/v2/touristicevent_type?language=fr&fields=id%2Ctype%2Cpictogram net::ERR_FAILED 404
Si je mets dans la barre d'adresse d'un navigateur l'url: https://sousdomainegeotrekadmin.domaine.com/api/v2/touristicevent_type?language=fr&fields=id%2Ctype%2Cpictogram Ca me donne: "Cette page n'a pas été trouvée".
Alors que l'url: https://sousdomainegeotrekadmin.domaine.com/api/v2/ a l'air de fonctionner, elle renvoie un contenu json.
On voit qu'il essaie d'appeler la route des types d'évenements touristiques. Peut-être que tu n'en as aucun et donc ça le fait galérer.
Il y a un paramètre pour désactiver le module "Evenements", passe le à false
: https://github.com/GeotrekCE/Geotrek-rando-v3/blob/main/frontend/config/global.json#L8
Ca fonctionne en mettant:
"enableTouristicEvents": false,
dans le fichier global.json
La barre de boutons est revenue, et maintenant le détail de chaque itinéraire s'affiche correctement !
Merci beaucoup pour la réaction rapide et la solution !
OK donc toi aussi tu as bien un soucis avec le cache. Du coup ça fonctionne, ça confirme le soucis. Par contre tu as du désactiver le cache, et donc ton portail va fonctionner mais beaucoup plus lent, car il va appeler toutes les routes tout le temps...
Donc il faut que l'on trouve une solution pour faire fonctionner le cache, et là c'est plus complexe car cela remet en cause le système de cache actuellement utilisé... A suivre.
Mes deux serveurs Geotrek-admin et Geotrek-rando tournent sous des ESX Vmware. Le problème pourrait-il venir de là ? Es-tu dans la même configuration avec des instances de machines virtuelles ?
Je pense que cela n'a rien à voir. C'est un soucis au niveau de l'outil utilisé pour générer le cache serveur Node.js au niveau de Geotrek-rando.
Mais là, je me pose une question que j'aimerai vérifier dans ton contexte.
Si tu remets le cache (enableServerCache
à true
) mais que tu laisses les événements touristiques désactivés ("enableTouristicEvents": false,
), est-ce que le soucis de chargement des pages revient ?
Dans le cas contraire, cela permettrait de cibler le soucis qui vient potentiellement de l'ajout des événements touristiques ?
Je viens de comprendre pourquoi tu avais des erreurs de CORS sur les routes des événements touristiques, tant que ce module n'était pas désactivé au niveau de Geotrek-rando. Car ce module EVENTS est activé par défaut, mais ton Geotrek-admin n'est pas à jour, donc ces routes ne sont pas disponibles... Pour activer le module EVENTS, il faut être en version 2.70.0 minimum de Geotrek-admin, comme indiqué dans les notes de version : https://github.com/GeotrekCE/Geotrek-rando-v3/releases
Mais bon, cela n'empêche pas que je suis intéressé de savoir si tu réactives le cache en gardant le module Events désactivé, si tu as de nouveau les soucis de pages qui ne se chargent pas ?
Si j'active à nouveau le cache, en gardant "enableTouristicEvents" à false, alors je retombe sur mon comportement initial: l'affichage des détails des itinéraires ne fonctionne pas et se termine par un Time-out.
Merci pour l'info à propos du module EVENTS, effectivement, nous sommes toujours en version 2.59.0 du côté de Geotrek-admin. J'essaierai à nouveau lorsqu'on aura rattrapé la dernière version à jour.
OK donc le soucis de cache ne vient pas du module EVENTS. A creuser donc... Merci pour le retour.
Retour complémentaire de @Chatewgne déplacé dans ce ticket :
Actuellement, il semble que l'ajout d'une nouvelle étiquette sur un itinéraire cause une erreur 500 temporaire sur Rando v3 lorsqu'on se rend sur la page détail de cet itinéraire :
nodeserver_1 | TypeError: Cannot read properties of undefined (reading 'id')
nodeserver_1 | at /app/src/.next/server/chunks/3677.js:707:83
nodeserver_1 | at Array.map (<anonymous>)
nodeserver_1 | at /app/src/.next/server/chunks/3677.js:706:80
nodeserver_1 | at Object.Ja [as useMemo] (/app/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:27:240)
nodeserver_1 | at exports.useMemo (/app/node_modules/react/cjs/react.production.min.js:23:113)
nodeserver_1 | at DetailsUIWithoutContext (/app/src/.next/server/chunks/3677.js:534:39)
nodeserver_1 | at d (/app/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:33:498)
nodeserver_1 | at bb (/app/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:36:16)
nodeserver_1 | at a.b.render (/app/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:42:43)
nodeserver_1 | at a.b.read (/app/node_modules/react-dom/cjs/react-dom-server.node.production.min.js:41:83)
Cela semble lié au cache car si je down/up l'application, le problème disparaît.
Réponse de @camillemonchicourt :
Je n'ai pas le soucis sur Rando Écrins (https://rando.ecrins-parcnational.fr/trek/980102-Le-lac-de-Vallonpierre).
Mais on vient de voir un soucis important avec le cache Node.js sur plusieurs instances (PNC et PNV), évoqué ici : https://github.com/GeotrekCE/Geotrek-rando-v3/issues/460
Pour le confirmer on a sorti une version de test (https://github.com/GeotrekCE/Geotrek-rando-v3/pkgs/container/geotrek-rando-v3%2Fgeotrek-rando-staging/11118734?tag=v3.5.3-beta1), permettant de désactiver le cache, en intégrant cette PR : https://github.com/GeotrekCE/Geotrek-rando-v3/pull/529
Pas encore de solution pour le cache, car on n'a pas encore identifié où se situait le soucis, potentiellement un problème lié au fait que node-wretch a un soucis identifié quand une route renvoie un résultat supérieur à 1 Mo.
Réponse de @Chatewgne :
D'accord !
Je trouve ça pratique d'avoir une option pour choisir de désactiver le cache
(Il faudrait rajouter le settings dans la documentation, si il est gardé dans une release "normale" https://github.com/GeotrekCE/Geotrek-rando-v3/blob/main/docs/knowledge/caching.md#nodejs-application-cache)
Réponse de @camillemonchicourt :
Oui oui on gardera le paramètre dans la prochaine release et on le documentera. Là c'est un test pour identifier le soucis du cache Node.js. Bon, sans le cache ça rame, donc pas souhaitable en prod, mais utile pour des tests. On a commencé à réfléchir et faire quelques tests de mettre du cache au niveau de l'API pour certaines routes particulièrement longues comme celle des "thèmes", mais à creuser plus tard.
Là le plus urgent est de voir pourquoi le cache Node.js bugge dans certains cas. 2 solutions sont envisagées : remplacer le cache géré par node-wretch par un cache NGINX ou Redis.
OK, alors on a pu faire un tour des soucis de cache rencontrés.
On a bien des soucis sur le cache géré par la librairie wretch
qui avait déjà été identifiée comme fragile et peu maintenue.
Wretch est basé sur Node-fetch. Mais on ne peut pas mettre à jour Node-fetch car wretch n'est pas compatible avec la dernière version de Node-fetch.
Après différents tests, l'incompatibilité identifiée est entre :
Quand on publie une nouvelle version de Geotrek-rando, celle-ci utilise la dernière LTR de Node.js. Récemment Geotrek-rando est ainsi passé de la version 14 à 16 de Node.js. Pour bien fonctionner avec la version 16 de Node.js, il faudrait mettre à jour Node-fetch en version 3. Mais wretch n'est pas compatible avec Node-fetch version 3 et cette librairie est peu utilisée et peu maintenue.
Donc pour le moment, on fixe la version de Node.js en version 14 (https://github.com/GeotrekCE/Geotrek-rando-v3/pull/531).
Mais comme cela avait déjà été identifié, la solution viable à moyen terme est de revoir le système de cache pour remplacer la librairie wretch par un cache serveur géré par NGINX ou Redis.
Le retour à la v14 de Node.js a été mis en place dans la version 3.5.3. Testé OK au Parc national des Cévennes. Merci de tester et nous faire des retours si cela corrige le problème du cache @blaisegeo et @Chatewgne ?
Bonjour;
Version 3.5.3 installée, testée sans rien changer à la conf: ça affiche une carte centrée sur les Ecrins et le détail des itinéraires s'affiche correctement.
Copie des fichiers de conf (sous-répertoires dans /customization) de la version 3.5.2 vers la version 3.5.3 (ainsi que du sous-répertoire /medias/): retour au look qui avait été fait sur la 3.5.2, centrage de la carte sur le territoire (Vanoise), par contre l'affichage des détails des itinéraires tourne dans le vide un moment, puis retour à l'erreur initiale: 504 Gateway Time-out.
Dans globals.json, "enableTouristicEvents" et enableServerCache" avaient été passés de false à true; ils ont été remis à false (docker toujours arrêté puis relancé après chaque modif) sans plus de succès pour l'affichage du détail des itinéraires.
A l'install, les versions n'ont pas de ficher .env à la racine. Sur cette dernière tentative avec la 3.5.3, le fichier e.nv.example a été copié en .env . Sans plus de succès.
Le serveur Geotrek-Admin est toujours en version 2.59.0 .
Quand on redémarre la version 3.5.2 mise à jour avec les infos ci-dessus d'il y a une semaine ou deux, le comportement redevient ok (affichage du détail des itinéraires), même si il y a peut-être un petit problème de lenteur dû au cache désactivé.
Merci d'avance pour toute piste à tester pour avancer.
Il faut que tu laisses enableServerCache
à true
mais bien que enableTouristicEvents
et enableOutdoor
soient à false
si tu es en Geotrek-admin 2.59.0.
Tu n'as pas besoin du fichier .env
.
Normalement cela devrait fonctionner comme ça en 3.5.3.
Si tu as encore des erreurs, il faudrait voir ce que renvoie la console, et sinon ce que renvoie les logs (docker-compose logs
) ?
Dans global.json: enableServerCache mis à true enableTouristicEvents mis à false Il n'y avait pas encore de ligne enableOutdoor, elle a été rajoutée et mise à false. Fichier .env à la racine supprimé.
Conteneur docker arrêté puis relancé: $ ~/.docker/cli-plugins/docker-compose up -d
Affichage des logs aux différentes étapes du test, toujours la même sortie y compris une fois que le Time-out est arrivé: $ ~/.docker/cli-plugins/docker-compose logs geotrek-rando-v3-installer-main-nodeserver-1 | yarn run v1.22.15 geotrek-rando-v3-installer-main-nodeserver-1 | $ NODE_ENV=production node ./src/server.js geotrek-rando-v3-installer-main-nodeserver-1 | > Ready on http://localhost:3000
Console du débuggueur de Firefox: Ouverture de la page d'accueil: 2 lignes: --- ligne 1: Impossible d’inscrire/mettre à jour un service worker pour la portée « https://randov3.mondomaine.com/ » : l’accès au stockage est limité dans ce contexte en raison des paramètres de l’utilisateur ou du mode de navigation privée. workbox-window.prod.es5.mjs:1:4668 --- ligne 2: Uncaught (in promise) DOMException: The operation is insecure. main-0c7fb9c3eb94486857b8.js:1
Affichage de la carte générale pour une activité (rando à pieds par exemple): pas d'erreur dans la console du débuggueur de firefox.
Clic sur un icone d'itinéraire: avertissement dans la console: MouseEvent.mozPressure est obsolète. Veuillez utiliser plutôt PointerEvent.pressure. leaflet-src.js:28:5
Clic sur le bouton "Afficher le détail": rien dans la console tant que ça tourne dans le vide avec une page blanche (qqes dizaines de secondes); ni quand ça affiche la carte générale à nouveau tout en continuant à essayer de charger, puis une fois que l'erreur Time-out apparait, dans la console, 3 lignes: --- ligne 1: GEThttps://randov3.mondomaine.com/trek/2743-Col-du-Soufre GEThttps://randov3.mondomaine.com/trek/2743-Col-du-Soufre [HTTP/1.1 504 Gateway Time-out 60086ms] --- ligne 2: L’encodage de caractères du document HTML n’a pas été déclaré. Le document sera affiché avec des caractères incorrects pour certaines configurations de navigateur si le document contient des caractères en dehors de la plage US-ASCII. L’encodage de caractères de la page doit être déclaré dans le document ou dans le protocole de transfert. --- ligne 3: GEThttps://randov3.mondomaine.com/favicon.ico [HTTP/1.1 404 Not Found 115ms]
OK la conf semble bonne. En effet ta page d'accueil, la page de recherche, les fiches des contenus touristiques, les filtres, les pages statiques semblent bien fonctionner. Ce sont seulement les pages détail des fiches randos qui ont un soucis chez vous, à priori avec le cache.
Je ne sais pas pourquoi, et comme votre API v2 de Geotrek-admin est bloquée à votre URL je ne peux pas tester chez moi.
Notre principale piste est que tu n'as pas déployé la mise à jour. 2 possibilités :
docker-compose pull && docker-compose down && docker-compose up -d
docker images
permet de lister les images et de voir quel package elles utilisent.En passant, pensez à faire régulièrement du nettoyage dans les images arrêtées qui restent sur la serveur, avec la commande docker image prune -a
. Voir https://github.com/GeotrekCE/Geotrek-rando-v3/blob/main/docs/installation.md#manage-docker-images-storage-on-disk pour plus d'infos sur le sujet.
De mon côté le problème est toujours présent...
Le site fonctionne pendant quelques minutes à quelques heures puis soudainement plus aucune page n'est accessible, erreur 502 sur l'intégralité du site
J'ai 2 Rando v3 avec le même problème, déployés sur le même serveur, via l'installeur en version 2.0.1.
Admin en version 2.69.0 Config rando v3
{
"searchResultsPageSize": 10,
"mapResultsPageSize": 250,
"maxPoiPerPage": 50,
"maxTouristicContentPerPage": 50,
"apiUrl": "https://admin.snowmap.espacenordiquejurassien.com/api/v2",
"baseUrl": "https://snowmap.espacenordiquejurassien.com",
"googleAnalyticsId": "G-ZXLEKFKNH8",
"applicationName": "Espace Nordique Jurassien: Ain - Doubs - Jura",
"fallbackImageUri": "/medias/logo-short.png",
"enableSensitiveAreas": true,
"enableServerCache": true,
"enableTouristicEvents": false,
}
Admin en version 2.73.0 Config rando v3
{
"searchResultsPageSize": 10,
"mapResultsPageSize": 250,
"maxPoiPerPage": 50,
"maxTouristicContentPerPage": 50,
"apiUrl": "https://geotrekadmin.parcdesvolcans.fr/api/v2",
"baseUrl": "https://decouverte.parcdesvolcans.fr",
"applicationName": "Découverte, parcs des Volcans d'Auvergne",
"fallbackImageUri": "/medias/android-splashscreen.png",
"enableServerCache": true,
"enableTouristicEvents": false,
"enableOutdoor": false
}
J'ai tenté plein de configurations différentes d'après vos conseils dans cette conversation mais rien n'y fait...
J'utilise la configuration nginx suggérée dans la doc en changeant le port puisque les deux applications sont sur le même serveur et doivent avoir chacune leur port.
J'utilise bien la version 3.5.3
Aucun logs dans docker-compose au crash
Juste les entrées suivantes dans le error.log nginx
2021/12/20 10:39:36 [error] 36006#36006: *37376 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 185.116.129.199, server: decouverte.parcdesvolcans.fr, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8686/", host: "decouverte.parcdesvolcans.fr"
2021/12/20 10:39:38 [error] 36006#36006: *37376 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 185.116.129.199, server: decouverte.parcdesvolcans.fr, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8686/", host: "decouverte.parcdesvolcans.fr"
2021/12/20 10:39:49 [error] 36006#36006: *37376 connect() failed (111: Connection refused) while connecting to upstream, client: 185.116.129.199, server: decouverte.parcdesvolcans.fr, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8686/", host: "decouverte.parcdesvolcans.fr"
2021/12/20 10:41:45 [error] 36006#36006: *37380 connect() failed (111: Connection refused) while connecting to upstream, client: 185.116.129.199, server: decouverte.parcdesvolcans.fr, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8686/", host: "decouverte.parcdesvolcans.fr"
Toute suggestion sera la bienvenue, merci
Merci Camille pour les pistes sur ton dernier message.
Je me suis aperçu que je ne passais pas correctement d'une version à une autre car j'oubliais de faire le: docker-compose pull && docker-compose down avant de relancer une image.
J'ai également bien fait le ménage de toutes les images qui ne servaient plus.
Maintenant, le détail des itinéraires s'affiche correctement si la directive "enableServerCache" est réglée à false dans le fichier global.json. Pour contre, en la mettant à true, ça retombe sur le comportement initial: Gateway Time-out sur l'affichage des détails des itinéraires. Je n'arrive pas à déterminer si ce problème de cache vient de la configuration du serveur sur lequel tourne Geotrek-Rando-v3 ou alors de celle du serveur sur lequel tourne Geotrek-Admin, ou bien si le problème vient plutôt de Geotrek-Rando-v3.
Salut @Chatewgne, alors j'ai essayé sur https://admin.snowmap.espacenordiquejurassien.com/api/v2, mais le CORS semble limité sur ce serveur.
Par contre en tapant sur https://geotrekadmin.parcdesvolcans.fr/api/v2, cela me semble bien fonctionner sur ma démo : https://gtr3demo.ecrins-parcnational.fr/trek/3-TEST-itineraire-2-(Makina).
Avec cette configuration :
{
"searchResultsPageSize": 10,
"mapResultsPageSize": 250,
"maxPoiPerPage": 50,
"maxTouristicContentPerPage": 50,
"enableSensitiveAreas": false,
"enableOutdoor": false,
"enableTouristicEvents": false,
"portalIds": [],
"apiUrl": "https://geotrekadmin.parcdesvolcans.fr/api/v2",
"baseUrl": "https://gtr3demo.ecrins-parcnational.fr",
"fallbackImageUri": "https://upload.wikimedia.org/wikipedia/fr/d/df/Logo_ecrins.png",
"touristicContentLabelImageUri": "https://upload.wikimedia.org/wikipedia/fr/d/df/Logo_ecrins.png",
"applicationName": "Geotrek-rando DEMO",
"enableIndexation": false,
"enableServerCache": true
}
Bon, si tu dis que ça fonctionne au début puis ensuite non, alors peut-être que ça va pas tenir non plus sur mon serveur de DEMO, mais alors je vois encore moins pourquoi.
Et @blaisegeo, cela ressemble au problème initial de cache, mais c'est étonnant qu'il y ait encore le soucis.
Pour aller plus loin, il nous faudrait les accès à vos API Geotrek-admin, avec le CORS ouvert sur *.
Camille, j'ai ouvert temporairement les accès API sur notre serveur Geotrek-Admin si tu as le temps de t'y pencher. Je ne vois pas vraiment de différence avec celui du parcdesvolcans ci-dessus, mis à part qu'il y a un peu moins de paramètres, ce qui est sans doute dû à une version antérieure de Geotrek-Admin de notre côté. Par avance, merci.
@blaisegeo, en effet je me suis branché sur votre API et je n'arrive pas non plus à faire afficher une fiche rando : https://gtr3demo.ecrins-parcnational.fr/trek/2399-Col-d-Aussois-(2914-m) 😭
Le système de cache actuel semble vraiment poser soucis. Bizarre qu'en étant repassé à Node.js version 14, on ait encore les soucis, mais là je vois pas...
Salut,
c'est bon j'ai résolu mon problème de stabilité, qui était dû à ma gestion des docker-compose
, je vois d'ailleurs que je ne suis pas la seule à avoir eu ce problème (catégorie "Improvements" dans le dernier changelog 3.5.3 :') )
Merci pour le test @camillemonchicourt qui m'a quand même permis d'éliminer des pistes.
Concernant le problème de cache que j'ai relevé sur les étiquettes, il est effectivement toujours présent. Mais pas grave car les applications sont utilisables en désactivant le cache, il n'y a pas encore suffisament de données pour impacter les perfomances. Donc viable en ce qui me concerne le temps d'attendre la résolution du problème de cache en profondeur.
Merci !
OK donc ça avance. Je ne vois pas pourquoi il reste un soucis de cache sur les étiquettes et désactiver le cache reste quand même très problématique pour la navigation, mais à creuser donc. On regardera plus spécifiquement au niveau des étiquettes si il y a un autre soucis. Reste aussi le mystère du PnVanoise.
Corrigé dans la version 3.6.0 en revoyant la génération du cache Node.js
Pour référence, il y a avait un soucis avec le cache : lorsque le système mettait une requête en cache, il clonait la réponse de celle-ci. Dans le cas d'une réponse dépassant la taille limite de 15kb, node.js utilisait un buffer pour streamer la réponse. La version copiée possédait donc également un buffer copié, mais celui-ci n'était jamais consommé, ce qui bloquait le traitement du buffer de la réponse principale.
Désormais le cache ne stocke que les réponses complètes en format texte, il n'est donc plus touché par cette limitation.
Bonjour ,
Désolée de ré-ouvrir ce sujet mais je crois que nous rencontrons depuis hier, des problèmes similaires sur notre Geotrek Rando V3 "test" https://geotrek-rando-test.le64.fr/
Certains liens ne fonctionnent plus, soit nous retombons sur la page d'accueil, soit nous obtenons l'erreur 504 Gateway Time-out.
J'ai lu que nous pouvions tenter d'ajouter dans le fichier global.json "enableServerCache": false or true mais pouvons-nous laisser sur false si cela fonctionne mieux ou est-ce une solution temporaire ?
De plus nous avons tenté la commande docker-compose down && docker-compose up -d mais les bugs persistent.
Notre version de Geotrek Admin est la 2.82.2 et celle de notre Geotrek Rando V3 ne me semble pas être la dernière (image id : d3f8ff9a7009)
Merci d'avance pour votre aide. Bonne journée.
Je pense que le soucis est différent. Peut-être lié à des contenus manquants ou des spécificités que l'on aurait pas encore identifié. Il vaut mieux ouvrir un nouveau ticket et faire référence à celui-ci car celui-ci mélange trop de choses et on s'y perd.
Et si tu as un exemple de page qui pose soucis, pour être plus précis et tenter de reproduire le problème ?
ok @camillemonchicourt
Nous avons fait une demande auprès de Makina, j'attends leur retour et si ça ne fonctionne toujours pas j'ouvre un nouveau ticket.
Bonjour; J'ai installé Geotrek-rando-v3 sur un serveur selon la procédure conseillée: dans un conteneur Docker avec une passerelle proxy nginx. Ce Geotre-rando-v3 va chercher les données sur un autre serveur où est installé un Geotrek-admin (qui est en production). Après quelques configurations, Geotrek-rando-v3 semble vouloir tomber en marche, mais je butte encore sur un problème.
1/ La carte générale des randos s'affiche bien avec les bonnes données venant du serveur Geotrek-admin. 2/ En cliquant sur l'icône d'une rando ça ouvre un micro popup avec photo, bref descriptif et bouton "Afficher les détails". 3/ En cliquant sur ce bouton, le logo de chargement au milieu de la page web tourne pendant quelques dizaines de secondes, puis l'affichage du navigateur remet la carte générale, mais le logo de chargement du navigateur (dans la barre des boutons du navigateur internet) tourne toujours. 4/ Après environ quelques dizaines de secondes encore, le navigateur affiche une page blanche avec une des deux erreurs suivantes: 504 Gateway Time-out ou 502 Bad Gateway
Cependant, si à la fin de l'étape 3/ (lorsque le navigateur retourne à la carte principale après avoir infructueusement essayé d'afficher la fiche d'un itinéraire, mais est toujours en train de charger) on clique à nouveau sur l'icône d'un itinéraire, puis sur le bouton "Afficher les détails", alors à ce moment là, la fiche et la carte de l'itinéraire s'affichent correctement !
Je répète que les deux serveurs Geotrek-admin et Geotrek-rando-v3 sont sur 2 serveurs différents (2 instances VMWare distinctes chez un hébergeur professionnel). Le serveur Geotrek-admin a bien un nom de domaine, mais pas le serveur Geotrek-rando-v3 qui n'a qu'une adresse IP. Geotrek-admin est en version 2.59.0 Goetrek-rando-v3 est en version 3.1.2
Le fichier de conf de nginx sur Geotrek-admin a dû être légèrement mis à jour pour s'adapter au CORS à cause de l'utilisation de deux serveurs distincts. Le fichier redirect.json utilisé pour générer l'image Docker est le suivant:
{ "rules": [ { "source": "/rando-a-pied/les-3-lacs", "destination": "/trek/43748-Les-3-Lacs", "permanent": true }, { "source": "/rando-a-pied/:name", "destination": "/search?rawText=:name" } ] }
J'avais cru comprendre qu'il fallait écrire une règle de redirection pour chaque URL de parcours pour récupérer les parcours de la version 2 à la version 3 comme défini dans le premier bloc, mais finalement non, ce parcours ne marche pas plus que les autre en l'appelant via la carte, et tous les parcours semblent fonctionner "à peu près" - comme indiqué plus haut - avec le second bloc de redirection. Par contre ils ne fonctionnent pas du tout si ce fichier est vide.
Une piste pour arriver à me débarrasser de cette erreur (ou plutôt de ces 2 erreurs alternativement) s'il vous plait ? J'ai parcouru les précédentes issues sans vraiment trouver un problème identique, mis à part peut-être celui-ci: https://github.com/GeotrekCE/Geotrek-rando-v3/issues/264 mais qui ne m'a pas aidé à résoudre mon problème. J'ai regardé les fichiers de logs d'erreur de nginx sur les deux serveurs, sans trouver quoique ce soit de bien explicite encore. J'ai également surveillé les charges CPU sur les deux serveurs lorsque la page du navigateur affiche le logo de chargement pendant quelques dizaines de secondes, et rien d'anormal. Je peux transmettre des détails de fichiers de conf au besoin.