Shinyproxy: Ajout dynamique de spécifications post-démarrage

Créé le 17 oct. 2020  ·  5Commentaires  ·  Source: openanalytics/shinyproxy

Tout d'abord, merci d'avoir créé une plate-forme aussi géniale - cela semble répondre à presque toutes mes exigences !

Une chose que je recherche, cependant, est la possibilité d'ajouter dynamiquement des spécifications après le démarrage, afin que nous n'ayons pas à redémarrer manuellement le serveur pour ajouter une nouvelle application.

Je peux voir que ProxySpecs et ContainerSpecs (sur lequel ShinyProxy est basé) offrent un support pour cela à l'aide d'une requête POST, mais qu'il n'est explicitement pas pris en charge dans ShinyProxy . Y a-t-il une raison particulière à cela ? Est-ce quelque chose que vous seriez ouvert à ajouter ?

Les ProxySpecs et ContainerSpecs peuvent également être fournies au moment de l'exécution, via le corps d'une requête POST.
Remarque : ShinyProxy ne permet pas de fournir des spécifications au moment de l'exécution. Seules les spécifications du fichier application.yml sont acceptées.
La source

Mon plan est de le déployer sur un serveur et de permettre à des personnes spécifiques au sein de l'organisation d'enregistrer de nouvelles applications au nom de leurs équipes de projet, sans que j'aie à mettre ShinyProxy hors ligne (même pendant quelques secondes) pour ajouter une nouvelle application. Idéalement, cette interface de gestion existerait dans ShinyProxy, mais je suis heureux de créer mon propre petit tableau de bord pour gérer cela.

Je suis heureux de contribuer un peu de temps pour aider au développement de ceci, si nécessaire - je voulais juste vérifier s'il y avait une raison spécifique pour laquelle cela n'est pas pris en charge, et si vous seriez ouvert à avoir cette fonctionnalité.

J'ai jeté un coup d'œil à certains des anciens tickets et j'ai lu que l'un des problèmes avec cela est que certaines des autres configurations de serveur ne peuvent pas être rechargées à chaud, mais je me demande si cela pourrait être contourné en ajoutant un dynamic_specs attribut au fichier application.yml , afin que les utilisateurs puissent choisir s'ils souhaitent prendre en charge les spécifications dynamiques ou définies manuellement (mais pas nécessairement les deux, si cela introduit une complexité significative d'un point de vue architectural) ?

par exemple

proxy:
  port: 8080
  ...
  dynamic_specs: true
  specs: # Left blank, if `dynamic_specs` is true.

Merci beaucoup!

picture xtrasimplicity
👍1

Tous les 5 commentaires

Salut @xtrasimplicity Ceci peut être réalisé en utilisant notre opérateur ShinyProxy. Une description de haut niveau est proposée sur https://www.openanalytics.eu/blog/2020/10/12/shinyproxy-2.4.0/ et une documentation supplémentaire est disponible dans son référentiel Github dédié

tverbeke picture tverbeke le 17 oct. 2020
👍1

Merci, @tverbeke. J'ai jeté un coup d'œil rapide, mais cela semble plus centré sur Kubernetes. Cela fonctionne-t-il également avec Docker swarm/engine ?

Edit: De plus, cela semble un peu plus complexe que ce que j'avais en tête. Si je devais soumettre un PR pour ShinyProxy qui ajoute la prise en charge de l'ajout de nouvelles applications à l'aide de l'interface utilisateur d'administration (et de la persistance d'une telle configuration dans une base de données), seriez-vous prêt à la fusionner ?

xtrasimplicity picture xtrasimplicity le 17 oct. 2020

Salut @tverbeke , j'ai lu un peu plus ShinyProxy Operator et je pense avoir compris.

Bien que cela résolve la plupart de mes problèmes, ce serait bien de pouvoir déléguer l'ajout de nouvelles applications à des utilisateurs spécifiques qui pourraient autrement ne pas être familiarisés avec l'édition de fichiers de configuration, etc. accordez à quelqu'un un accès SSH (sous n'importe quelle forme, quelle que soit la restriction) au serveur exécutant ShinyProxy afin de modifier le fichier de configuration.

Pour cette raison, ce serait formidable de pouvoir ajouter de nouvelles applications à l'aide de l'interface utilisateur d'administration.

Théoriquement, et sans avoir _lourdement_ revu le code, _devrait_ être aussi simple que :

  1. Ajout de la possibilité de récupérer les définitions de spécifications à partir d'une base de données (sqlite devrait être suffisant ?), en plus du fichier de configuration.
  2. Mise à jour de l'interface utilisateur d'administration pour prendre en charge l'enregistrement de nouvelles définitions de spécifications et leur stockage dans la base de données.

Seriez-vous ouvert à une pull-request ajoutant de telles capacités ?

Merci!

xtrasimplicity picture xtrasimplicity le 21 oct. 2020
❤1

Salut @xtrasimplicity , Merci beaucoup d'avoir réfléchi. Nous travaillons sur un mécanisme pour déléguer l'ajout de nouvelles applications, mais dans un premier temps, il sera probablement piloté par une approche GitOps plutôt que via une interface utilisateur.

tverbeke picture tverbeke le 21 oct. 2020
👍1

Merci, @tverbeke. Savez-vous quand le mécanisme de délégation sera probablement prêt ? Ou puis-je en quelque sorte aider au développement de cela?

GitOps est utile, mais pouvoir le faire à partir de l'interface graphique serait également très utile pour les environnements où GitOps n'est pas vraiment utilisé !

xtrasimplicity picture xtrasimplicity le 28 nov. 2020
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

jat255 picture jat255  ·  3Commentaires
Bertusian picture Bertusian  ·  5Commentaires
dylancis picture dylancis  ·  3Commentaires
benkates picture benkates  ·  3Commentaires
jat255 picture jat255  ·  3Commentaires