« ShinyProxy » : différence entre les versions

Aller à la navigation Aller à la recherche
1 503 octets ajoutés ,  24 février
Ligne 10 : Ligne 10 :


Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple).  
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple).  
ShinyProxy fera en sorte qu'un certain nombre de containers (à définir dans la configuration décrite à la fin de ce tutoriel) soient toujours disponibles pour de nouveaux utilisateurs qui se connecteraient à votre application. Il s'occupera également de supprimer les containers quand vos utilisateurs se déconnectent.


== Conteneurisation de votre appli Shiny ==
== Conteneurisation de votre appli Shiny ==
Ligne 157 : Ligne 159 :


== Configuration de l'application sur le serveur ShinyProxy de production ==
== Configuration de l'application sur le serveur ShinyProxy de production ==
La configuration de l'application se fait dans le fichier shinyapps.yml sur le dépôt privé https://github.com/EVS-GIS/isig-apps (un compte GitHub associé à l'organisation EVS-GIS est nécessaire). La branche prod de ce dépôt est synchronisée avec le serveur. Une erreur dans cette configuration pouvant potentiellement tout faire planter, cette branche prod est protégée et nécessite que vous fassiez une pull request validée par Samuel lorsque vous voulez mettre à jour cette configuration.
La configuration de l'application se fait dans le '''fichier shinyapps.yml sur le dépôt privé''' https://github.com/EVS-GIS/isig-apps (un compte GitHub associé à l'organisation EVS-GIS est nécessaire). La branche prod de ce dépôt est synchronisée avec le serveur. Une erreur dans cette configuration pouvant potentiellement tout faire planter, cette branche prod est protégée et nécessite que vous fassiez un '''pull request''' validé par Samuel lorsque vous voulez mettre à jour cette configuration.


L'intégralité des paramètres qu'il est possible de configurer est disponible [https://www.shinyproxy.io/documentation/configuration/#apps ici].
L'intégralité des paramètres qu'il est possible de configurer est disponible [https://www.shinyproxy.io/documentation/configuration/#apps ici]. Voici les principaux que je vous recommande de configurer : <syntaxhighlight lang="yaml">
    - id: mapdoapp # Identifiant unique de l'application
      display-name: "Mapd'O App" # Nom d'affichage
      container-image: ghcr.io/evs-gis/mapdoapp:latest # Image Docker à utiliser (bien utiliser un tag "latest" pour faciliter la mise à jour)
      port: 3838 # Le port à écouter dans le container (dépend du port choisi au moment de la création de l'image)
      minimum-seats-available: 3 # Le nombre de containers en attente d'utilisateur que ShinyProxy doit assurer
      container-env: # Définitions de variables d'environnement
        MA_VARIABLE_1: valeur1
        MA_VARIABLE_2: valeur2
</syntaxhighlight>N'hésitez pas à demander mon aide pour cette étape qui ne sera généralement à faire qu'une seule fois au moment du premier déploiement de l'appli. Dans certains cas où vous prévoyez un pic d'affluence sur votre appli (un cours ou une conférence par exemple), vous pouvez ajuster le <code>minimum-seats-available</code> pour éviter du temps de chargement à vos visiteurs.


== Mise à jour d'une appli ==
== Mise à jour d'une appli ==
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier le fichier de configuration (décrit ci-dessus). Il suffit de pousser la nouvelle version de votre image sur votre registre (avec le tag latest), puis de lancer le job "Mise...... " sur Jenkins pour forcer le redémarrage des containers d'attente déjà lancés.
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier le fichier de configuration (décrit ci-dessus). Il suffit de '''pousser la nouvelle version de votre image sur votre registre''' (avec le tag latest), puis de '''lancer le job ''Mise à jour d'une application en production sous ShinyProxy'' sur Jenkins''' pour forcer le redémarrage des containers d'attente déjà lancés.
[[Catégorie:Tutoriel]]
[[Catégorie:Tutoriel]]

Menu de navigation