A l’occasion du premier article de la série sur notre stage, Flavie a présenté les différentes missions que nous réalisons chez Oslandia avec une introduction à QWC2, une application web cartographique Open Source permettant de publier des cartes réalisées avec QGIS Desktop. Il a notamment été fait mention de l’intention de développer de nouvelles fonctionnalités dans cette application.

Avant de pouvoir contribuer à ce logiciel, il a fallu dans un premier temps s’approprier l’architecture technique de l’application afin de pouvoir l’utiliser et découvrir ses fonctionnalités. Dans cet article, je vais vous présenter plus précisément la pile applicative nécessaire pour utiliser QWC2. J’aborderai également le principe d’automatisation des tâches d’installation avec Ansible. Nous verrons aussi que l’environnement QWC2 bénéficie de plusieurs micro-services qui peuvent permettre d’appliquer une gestion des droits plus fine sur les projets que vous souhaitez publier. Enfin, nous nous poserons la question de la simplicité de publication de projets QGIS par un public non développeur et nous proposerons des solutions envisageables.

Déployer…

 

Le déploiement d’une application QWC2 nécessite au minimum un serveur sur lequel on retrouve :

• des données
• QGIS Server
• un serveur web
• QWC2

Pour les données, on peut utiliser un Système de Gestion de Bases de Données Relationnelles (SGBDR) tel que PostgreSQL avec son extension spatiale PostGIS. On a également la possibilité d’avoir des fichiers directement sur le serveur, comme des Shapefiles. Les projets QGIS publiés sont configurés selon ces données, un fichier de service peut être utile pour paramétrer l’accès à la base de données.

QGIS Server est une application FastCGI qui fournit à un serveur Web les différentes couches et objets d’un projet QGIS sous forme de flux (WMS, WFS, OGC API). La symbologie du projet QGIS est conservée par le serveur, le rendu cartographique sera donc identique entre l’application QGIS Desktop et l’application Web. WYSIWYG (What You See Is What You Get) !

Plusieurs instances de QGIS Server peuvent être installées grâce à Systemd pour paralléliser les traitements en utilisant au mieux les processeurs de la machine sur laquelle on installe l’application. En utilisant le load-balancing (répartition des charges), le serveur Web peut diriger les requêtes vers les différentes instances de QGIS Server pour gagner en performance et en rapidité de réponse. En retour, QGIS Server retourne par exemple un flux WMS (une image) ou le résultat d’une requête GetFeatureInfo (les attributs d’un objet).

Le serveur Web utilisé dans notre cas est Nginx. Il sert des fichiers situés sur le serveur en fonction de « routes » définies dans sa configuration. Nginx communique également avec QGIS Server en lui passant les paramètres des requêtes effectuées côté client (ex: clic sur un objet de la carte pour récupérer les informations de celui-ci).

Aussi, Nginx envoie au navigateur Web du client les fichiers de l’application QWC2. Celle-ci est auparavant « buildée » (construite) sur le serveur grâce aux gestionnaires de paquets JavaScript yarn et npm. L’application QWC2 utilise les frameworks React et Redux pour la gestion de l’interface utilisateur et OpenLayers pour la cartographie.

On retrouve ci-dessous le schéma de l’architecture décrite :

Pour paramétrer QWC2, nous nous sommes basés sur l’application de démonstration disponible sur le dépôt Github. Il existe différents fichiers de configuration pour personnaliser l’application :

• un fichier pour définir les plugins à utiliser
• un fichier pour définir les systèmes de coordonnées utilisés et différents services
• un fichier pour définir les projets QGIS de l’application

Une fois tous ces fichiers correctement paramétrés, l’application peut ainsi être construite et prête à être servie par Nginx.

Ces différentes tâches de déploiement ont été réalisées une à une avec une phase de test pour chacune.

Automatiser…

 

L’application QWC2 étant fonctionnelle, on peut maintenant essayer de l’installer sur un autre serveur en répétant toutes les opérations ci-dessus sans se tromper, désinstaller, réinstaller, changer la configuration pour que « ça marche »… Eh non ! Il existe des outils d’automatisation des tâches qui permettent de réaliser une même installation plusieurs fois sur plusieurs machines différentes. On trouve des avantages certains à cette automatisation :

• répétabilité : on fait exactement la même chose sur toutes les machines
• adaptabilité : on peut prévoir des variables pour différencier les machines (distribution Debian ou Ubuntu ?)
• maintenabilité : la prise en main du déploiement est plus simple avec toutes les tâches décrites et on peut facilement y apporter des modifications

L’automatisation de notre déploiement a été réalisé avec Ansible. C’est une solution qui permet de configurer le déploiement de plusieurs logiciels sur une machine grâce à des fichiers de configuration au format YAML. Un fichier principal, appelé playbook, définit les rôles utilisés lors du déploiement. Pour chacun des rôles, on crée un fichier décrivant les tâches à réaliser (ex: installer un paquet, créer un utilisateur, copier un fichier sur le serveur, …). Enfin des fichiers de variables permettent de différencier les déploiements sur les serveurs.

Le déploiement se fait alors avec une simple ligne de commande !

Administrer…

 

En plus de l’application classique, il existe également des micro-services dans l’environnement QWC2. Ces micro-services sont des applications qui sont exécutées en continu sur le serveur. On peut les retrouver sur Github dans le dépôt qwc-services. Ceux-ci permettent d’ajouter différentes fonctionnalités à QWC2, notamment des droits d’accès aux ressources de l’application.

Dans notre cas, nous nous sommes intéressés à l’authentification d’un utilisateur. Pour cela, divers services et actions sont nécessaires :

• une base de données de configuration (pour stocker les utilisateurs, les groupes, les droits d’accès aux ressources, …)
• un service d’administration (pour créer les utilisateurs et définir les droits)
• un service d’authentification
• un service qui gère la configuration et l’accès à l’application en fonction de l’utilisateur connecté
• l’activation du plugin d’authentification dans l’application

La mise en place de ces services requièrent de configurer des fichiers pour définir la base de données utilisée, les adresses des différents services, etc…

Ces services peuvent être installés via un docker ou bien être configurés séparément avec uWSGI.

Publier…

 

Nous avons vu que QWC2 est une application hautement configurable. On peut donc déployer des applications très différentes les unes des autres au prix de beaucoup de temps passé sur la modification des fichiers de configuration. Aussi, il est nécessaire jusqu’à présent d’éditer à la main le fichier contenant les projets QGIS pour en ajouter un, puis de reconstruire l’application afin de prendre en compte ce nouveau projet. Ce processus n’est pas aisé et il faut avoir quelques notions de développement d’applications web. Ainsi, une personne souhaitant publier rapidement un projet sur le web ne pourra pas le faire facilement sans passer par l’édition de la configuration. Il faut donc repenser la manière dont les projets QGIS peuvent être ajoutés à l’application. L’une des solutions envisagées est le développement d’un plugin QGIS qui permettra à l’utilisateur grâce à une interface graphique de publier un projet sur lequel il travaille. Ce plugin est en cours de réalisation et reproduit les différentes étapes décrites dans la partie déploiement de cet article pour reconstruire l’application QWC2 avec le nouveau projet QGIS.

Contribuer !

 

Nous avons à présent une application QWC2 fonctionnelle avec des projets QGIS publiés. Dans un prochain article, nous verrons quelles fonctionnalités peuvent être ajoutées à l’application. Aussi, nous expliquerons les démarches à suivre pour contribuer à un projet Open Source, de la présentation à la communauté jusqu’à la publication d’une nouvelle fonctionnalité !