Mise en place d'une API Rest pour la configuration

[vrahier]

Bonjour,

La gestion partielle de la configuration en base de données de la version 1.5.0 du dossier web nous pose problème.

En effet, nous avons automatisé avec Ansible l'installation et la maintenance de l'application dans notre système d'information. Le stockage de la configuration dans la base de données est problématique car elle nous oblige à modifier les informations de configuration directement en base, ce que nous souhaitons éviter.

Une solution à notre problème serait de mettre en place une API Rest que nous pourrions appeler pour définir notre configuration.

Pensez-vous que cela serait envisageable ?

Merci et bonne journée, Valentine Rahier, Institut Agro Rennes-Angers

[cdubois54]

Bonjour,

Je ne connais pas bien Ansible mais nous avons effectué des essais concluant avec Jenkins, ArgoCD (Kubernetes). L'application est prévue pour être déployée automatiquement par une configuration minimale via application.properties (comme précédemment) devant être finalisée, par la suite, via l'interface web par un utilisateur au profil "admin". Vous n'utilisez pas ce profil ?

L'accès à la base de données via une API Rest (ne serait-ce que pour l'accès à la table "preferences_application") n'est pas prévu actuellement.

Cordialement

[emmanuel-benoit]

Bonjour,

Nous n'utilisons pas - et ne souhaitons pas utiliser - le profil "admin" (sauf éventuellement en préprod pour déterminer quelle configuration appliquer).

De notre point de vue, la configuration d'une application ne devrait pas être effectuée par une suite de clics non reproductibles dans une interface web, particulièrement dans le cas d'une application comme MDW dont le but est principalement de visualiser des données.

Il s'agit donc, pour nous, d'une régression : l'installation et la configuration de manière entièrement automatique de l'application ne sont plus réalisables sans aller "bidouiller" manuellement la base de données, ce qui devrait être évité autant que possible.

Nous pourrions éventuellement faire une PR pour rendre de nouveau possible la configuration des divers paramètres de l'applicatif via une source autre que la base de données (fichier properties, variables d'environnement, peu importe) sans pour autant invalider le travail que vous avez fait sur la configuration en base.

Si cela ne vous semble pas envisageable, nous modifierons nos scripts Ansible pour qu'ils aillent attaquer la base directement ou écrirons une quelconque verrue qui s'en charge, ce qui est sale et n'est pas rendu plus simple par les paramètres de type SECRET_STRING, mais tant pis.

Cordialement, Emmanuel BENOÎT, IARA

[cdubois54]

Bonjour,

Bien sûr si nous avons exporté la configuration dans l'interface, notre point de vue est différent. Principalement dans le but d'éviter autant que possible d'avoir à intervenir sur les fichiers clés du processus de déploiement (potentiellement pour une simple modification esthétique) et de permettre le changement de la configuration instantanément sans redémarrage.

Une solution éventuelle serait de pouvoir mettre à jour, au démarrage de l'application, les paramètres de la table "preferences_application" depuis le fichier application.properties. Un paramètre : db.preference.sync = true/false Puis chaque préférence applicative sous la forme : db.preference.PREFID = VALEUR

Au démarrage de l'application un bean récupère ces paramètres dans le fichier, met à jour la table (dynamiquement en fonction du type de la PREFID) et force la mise à jour des instances quand cela est nécessaire (via la table preferences_service_sync). En cas de multi-instance mdw, un fingerprint stocké en base permettrait d'empêcher des update en parallèle ainsi que la mise à jour de la configuration quand cela n'est pas nécessaire.