Atelier auto hébergement d'une instance panoramax

Bonjour,

Au point d’échange du 8 avril, on a évoqué le fait de faire un atelier pour discuter auto hébergement d’une instance GeoVisio (la brique technique derrière une instance Panoramax).

A ma connaissance, pour le moment, il y a des instances panoramax déployées :

  • en bare metal (l’instance OSM-FR)
  • avec un mix scalingo / VM OVH (instance IGN)
  • en docker compose (les instances Carto’Cité)
  • et il me semble dans un cluster Kubernetes (pour une instance de sogefi mais je ne suis pas certain, tu confirmes @vincent.robbe ?).

L’installation d’une instance n’est pas très compliquée, mais

  • pourrait être plus documenté
  • pourrait être plus automatisé
  • il y a pas mal de choix / considérations à prendre en compte en amont (le trafic prévu, taille du stockage prévu, machines disponibles, backup, ouverture de l’instance au public, …).
  • l’instance doit être mise à jour régulierement, et l’administrateur d’instance a quelques outils à sa disposition pour gérer l’instance

Qui seraient motivés pour faire un atelier la dessus, pour échanger entre personnes qui gèrent une instance ou qui ont envie d’en gérer ? Vous pourriez poser toutes vos questions, échanger sur les compromis des différents choix, nous donner des pistes d’amélioration de la documentation, échanger des tips, …

Si des gens sont motivés, je peux lancer un sondage en proposant des dates.

On peut faire l’atelier en anglais si c’est nécessaire (ou en faire plusieurs si des gens ne se sentent pas de le faire en anglais). Je poste aussi ce message en anglais pour ouvrir la discussion.


Hi,

A workshop about GeoVisio (the technical brick behind Panoramax) self-hosting has been asked at the last community meeting.

To my knowledge, at the moment, Panoramax instances have been deployed :

  • in bare metal servers (the OSM-FR instance)

  • with a scalingo + OVH VM mix (IGN instance)

  • using custom docker compose (Carto’Cité instances)

  • and I believe in a Kubernetes cluster (for a sogefi instance, but I’m not sure, can you confirm @vincent.robbe?).

Installing an instance isn’t very complicated, but

  • could be more documented
  • could be more automated
  • there are quite a few choices / considerations to take into account beforehand (expected traffic, expected storage size, available machines, backup, opening the instance to the public, …).
  • the instance should be regularly updated, and the admins has some tools to manage the instance

Who would be motivated to do a workshop on this subject, to share ideas between people who manage an instance or who want to manage one?

If people are motivated, I can launch a survey and suggest dates.

We can do the workshop in English if needed and if you manage to understand french accents.

4 Likes

Moi ça m’intéresse d’en savoir plus.

pareil j’aimerais en savoir plus

Ok, on peut faire un point à 3 pour le moment et en refaire un plus tard au besoin.

Je lance une proposition de dates pour avancer, si ca ne vous convient on peut faire ca à un autre moment sans soucis.

  • Mardi 30 avril 11h
  • Mardi 30 avril 15h
  • Jeudi 2 mai 10h
  • Jeudi 2 mai 15h
  • Vendredi 3 mai 15h
  • Lundi 6 mai 11h
  • Lundi 6 mai 15h
0 votant

ah et si vous pouviez me dire grosso modo ce dont vous aimeriez parler, ca me permettrait de préparer des choses.

Je sais pas si c’est le bon endroit, mais les allemands ont ouvert un sujet à propos de Panoramax et d’un serveur sur le forum OSM International Deutscher Panoramax Server? - Deutschland (Germany) - OpenStreetMap Community Forum

oui vu ca, on discute avec eux sur matrix, merci :pray:

bon vu les votes, on se fait ca vendredi 3 mai à 15h, ca te va toujours @StephaneP ?

Je suppose que ce sera en français ? Si c’est le cas, je serais intéressé par une version anglaise.

I’m assuming this will be in French? If so, I would be interested in an English version.

Oui, c’est bon pour moi.

Les points qui pourraient être intéressants :

  • Architecture d’une instance Geovisio
  • Tour d’horizon des différents types d’installation, différences, avantages, inconvénients
  • Gestion de l’authentification des contributeurs (Osm, keycloack) ← point important pour mon cas.
  • Installation, paramétrage, customisation, maintenance, maj, backup/restauration
  • Possibilités d’administration des comptes utilisateurs, des séquences, photos, etc…
  • Connexion au metacatalogue.

Ca fait déjà pas mal :slight_smile:

1 Like

we can do it in english if it’s ok for you @StephaneP (or we can do another session)

My english is not very fluent. You can explain in english, but maybe I’ll ask some questions in french.

That would be fine, I can also translate your questions. But we can also do several sessions if it helps.

The workshop will be on Jitsi Meet

Compte rendu de l’atelier qu’on a fait juste avec @StephaneP , on pourra refaire ça si il y a des demandes.

Questions

Stéphane P.:

  • Architecture d’une instance Geovisio
  • Tour d’horizon des différents types d’installation, différences, avantages, inconvénients
  • Gestion de l’authentification des contributeurs (OSM, keycloack) ← point important pour mon cas.
  • Installation, paramétrage, customisation, maintenance, màj, backup/restauration
  • Possibilités d’administration des comptes utilisateurs, des séquences, photos, etc…
  • Connexion au métacatalogue.

Comment s’y retrouver dans les repo gitlab ?

S. : Trop de répo, on ne sait pas par où commencer.

A.: On va faire un repo central pour expliquer tout, et on va faire une grosse passe sur la documentation pour améliorer l’embarquement.

Architecture

Différents hébergements

Il y a beaucoup de possibilité pour héberger une instance GeoVisio et toutes ses possibilités ont des compromis différents. Je connais 4 approches différentes pour le moment (et bien sur, elles peuvent être combinées/adaptées).

Full bare metal (OSM-fr)

Seveur bare metal hébergé dans un datacenter (Téléhouse 3). Proxmox pour découper en VM et services systemd basé sur un repo git mis à jour régulièrement.

Stockage sur disques (cf post sur le forum).

Avantages:

  • pas cher
  • maîtrise de la chaîne de bout en bout

Inconvénient:

  • Compétences infra requises pour correctement brancher les serveurs, faire les installations depuis 0, la configuration systemd, backuper/sécuriser
  • Compétences ops requises pour correctement superviser le service
  • pas mal d’actions manuels

Mixed Cloud (IGN)

Mix entre Scalingo pour déployer du code et héberger/backuper/protéger la base de donnes + VM OVH pour le traitement en tache de fond des images + stockage OVH S3.

Avantages:

  • peu de compétences infra requises (backup automatisés, sécurisation, monitoring, …)
  • déploiement continus

Inconvénient:

  • abstractions qui posent problèmes de temps en temps
  • très cher (stockage + instances de calcul)

Docker compose (Carto’Cité)

Service lancés via un docker compose (intégrant la bdd dans le docker compose ou non).

Avantages:

  • Un peu plus simple à déployer, pas besoin de faire la configuration systemd
  • potentiellement aussi bon marché que la solution bare metal si on déploie ca sur des serveurs bare metal et des disques physiques, plus cher si on passe par du cloud

Inconvénient:

  • Compétences docker requises pour correctement configurer le service
  • Compétences infra requises pour correctement backuper/sécuriser
  • Compétences ops requises pour correctement superviser le service
  • Difficile d’avoir du rechargement à chaud quand on livre une nouvelle version
  • Mono machine (mais c’est pas forcément important)

Kubernetes (Sogefi / Geovelo)

Déploiement sur un cluster kubernetes. Assez proche de la version docker compose, mais en plus compliqué. Permet d’automatiser plus de chose, et d’avoir du rechargement à chaud.

Avantages:

  • Intégration dans des SI existants
  • déploiement continus possible
  • rechargement à chaud sans interruption de service possible
  • très flexibles

Inconvénient:

  • Compétences k8s requises pour correctement configurer le service (et créer la configuration helm)
  • Compétences infra requises pour administrer un cluster kubernetes si on n’utilise pas du cloud
  • Compétences ops requises pour correctement superviser le service
  • Le prix dépend de l’hébergement et surtout du stockage utilisé

Installation, paramétrage, customisation, maintenance, maj, backup/restauration

Paramétrage / customisation

S. : via docker, c’est pas évident de faire des modifs (changement d’url de tuiles, …)

A. : il faut configurer ca via des variables d’environnement, pas via du changement de code.

S. : On n’utilise pas le site web.

A. : Ah en fait on a pas de moyen de configurer la visionneuse directement pour le moment, tout passe par le site web…

S. : On va voir si on peut mettre le site web, mais on pense vouloir utiliser le site web de toute façon, donc c’est peut être pas un problème.

Gestion de l’authentification des contributeurs (OSM, keycloack) ← point important pour mon cas.

Comment faire une instance où seuls les responsables de l’instance peuvent uploader des données ?

Sans keycloak/OAuth2

Le plus simple c’est de paramétrer l’api pour que seuls les utilisateurs authentifiés puissent uploader (API_FORCE_AUTH_ON_UPLOAD=true), puis, si on a pas configuré de système d’OAuth (via keycloak ou autre), on peut récupérer le token de l’utilisateur par défaut via la commande:

$ flask tokens default_account get 

Cette commande va renvoyer un token, qui pourra être utilisé pour envoyer des photos via la ligne de commande (ou via des appels API directement).

Par contre il n’est pas possible d’utiliser le site web pour faire ca.

Avec Keycloak

Pour un cas d’usage un peu plus évolué, où on veut créer quelques comptes au sein de l’organisation, le mieux est d’utiliser keycloak, et de configurer keycloak pour qu’il n’y ait que l’administrateur keycloack qui puisse créer des comptes.

On va essayer d’améliorer la documentation sur comment mettre en place un keycloak lié à GeoVisio.

Est ce qu’on peut utiliser des fonds de cartes raster ?

Oui, pour le moment on peut configurer un fond de carte + un fond d’ortho photo (et les 2 peuvent être vecto ou raster). Si on veut plus de choix (fonds de cartes vecto, fonds de cartes raster, ortho photo, …), il faut ouvrir une issue.

Mises à jour :

  1. stopper les background workers
  2. mettre à jour le code (docker compose pull, git pull, ou autre)
  3. migration du schéma de la bdd
  4. màj du code

Todo: il faut qu’on mette une section dans la doc geovisio pour bien indiquer les modifications d’infrastructures entre les versions.

Floutage

S. : ça éviterait de la confusion que SGBlur soit réintégré dans la partie gitlab
S. : le readme n’est pas à jour, dur de s’y retrouver

Backup restore

S. : Comment faire les backups de l’instance GeoVisio ?

A. : Pas évident de faire de la documentation la dessus vu que ça dépend beaucoup de la façon dont geovisio a été déployé.

Dans les grandes lignes il faut:

  • backuper la base de données
  • backuper les images principales (pas les dérivées)

Administration d’instance

Backoffice

S. : Est ce qu’un backoffice est prévu (pour supprimer des photos/séquences des utilisateurs/…) ?

A. : Oui mais c’est loin dans les priorités. Pour le moment l’équipe le fait en modifiant directement la base de données ou via des commandes flask.

S. : Pas évident de passer d’une photo à sa séquence

A. : il y a l’id de la séquence dans le petit i en bas à droite, mais il faut qu’on fasse un lien avec la séquence

S. : le petit i, je m’attendais à avoir des info de copyright, pas d’info sur la photo

A. : Pour un backoffice à pas cher, on pourrait aussi peut faire avoir une gestion des droits en bdd avec un super utilisateur, et qu’il puisse supprimer les séquences/photo direct depuis la page

=> il faut créer un ticket la dessus

Connexion au métacatalogue

Pour le moment ce n’est pas industrialisé, il suffit d’ouvrir une issue gitlab pour demander le référencement.
Il faut un Geovisio à jour (au moins la version 2.3.0) pour que les mises à jour différentielles soit supportées.

Pour l’instance OSM, tout repose sur ZFS, le stockage des photos (sur HDD), celui de la base de données postgresql et celui du reste du conteneur qui fait tourner geovisio (back+front) sur SSD.

Des snapshots quotidiens (instantanés) sont faits automatiquement, ils permettent de revenir en arrière.
Pour ce qui est stocké sur SSD (conteneurs, base de données), une synchro de snapshots est faite localement sur les disque dur, puis une autre synchro est faite à distance

Une journée entière d’activité est ainsi backupée en 10mn environ et est directement utilisable sans besoin de restauration :slight_smile:

Bonjour,

premier message sur ce forum pour vous dire que je viens de faire une install d’une instance Panoramax version docker-compose.yml (sans authentification ni floutage donc) via la doc du gitlab, qui est très bien faite: merci!
J’avais mis toutes les chances de mon côté en partant d’une installation fraîche de Debian 12 sur un petit laptop que je fais tourner sur réseau local uniquement. Le cas d’usage visé consiste à répertorier des plantations en agroforesterie (surfaces entre 0,5 & 5 ha, terrrains privés donc, pas de besoin de floutage) pour en mener un suivi transversal. Une remarque d’Antoine de Cartocité qui a réalisé la prise de trace et de vue sur les 2 parcelles en question sur la précision en Z m’a donné quelques idées sur des applications en Keyline design (gestion douce de l’eau suivant les courbes de niveau) pour des conceptions plus résilientes. J’en profite pour le remercier du temps consacré à m’évangéliser!
Il ne me reste plus qu’à me pencher sur JOSM.

Pour la stratégie de backup, je pense mettre dans le docker un script cron pour envoyer la base et les images raster sur un disque externe et une machine tierce lorsqu’elle est sur le réseau.

2 Likes

Très bonne nouvelle !

Au cas où, tu peux utiliser l’API de floutage d’OSM-FR car pas besoin que ça tourne au même endroit que l’instance elle-même.

On peut ajouter les photos de ton instance sur le méta-catalogue si tu es d’accord, il nous faut juste l’URL de l’API à interroger.

Hello Christian,
je ne suis pas sûr, mais alors pas sûr du tout que mes clients, majoritairement agriculteurs/ruraux souhaitent voir leurs exploitations ainsi exposées, et le laptop serveur ne tourne que lorsque je charge ou consulte des images (sans compter que configurer son accessibilité derrière ma box et assurer la sécurité, c’est le genre de dette technique dont je me passe volontiers => KISS). Je le conçois spécifiquement comme un outil de design en permaculture / suivi en agriculture, pas d’alimentation des communs. Par contre, individuellement, je suis tout disposé à uploader des traces faites à vélo sur l’instance OSM par exemple.

Aucun souci, c’est un usage assez particulier auquel on n’avait pas forcément pensé, mais bien content que ce qu’on fait puisse aussi servir à ça !

Et puis il faudrait entraîner l’IA pour flouter les vaches qui m’ont suivies sur une partie de la collecte :wink:

2 Likes