« ShinyProxy » : différence entre les versions

 
(Une version intermédiaire par le même utilisateur non affichée)
Ligne 157 : Ligne 157 :
=== Pousser l'image sur un registre ===
=== Pousser l'image sur un registre ===
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées).  
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées).  
Il faut d'abord se loguer sur le registre avec son login GitHub habituel, et un ''Personal Access Token'' en guise de mot de passe. Pour [https://github.com/settings/tokens/new obtenir un ''Personal Access Token''], rendez-vous [https://github.com/settings/tokens/new ici] et activez bien le droit <code>write:packages</code> pour votre token.  <syntaxhighlight lang="sh">
# La commande suivante est à lancer pour se loguer sur le registre. Il n'est pas nécessaire de la relancer à chaque fois.
docker login ghcr.io
# Pour pousser tous les tags de notre image sur le registre, on utilise ensuite la commande suivante.
docker push ghcr.io/evs-gis/mapdoapp -a
# Pour pousser seulement un tag spécifique, on préfèrera la commande suivante.
docker push ghcr.io/evs-gis/mapdoapp:latest
</syntaxhighlight>


== 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 un '''pull request''' validé par Samuel lorsque vous voulez mettre à jour cette configuration.
La configuration initiale de l'application doit être faite par l'administrateur du serveur.
 
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 à jour d'une application en production sous ShinyProxy'' 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 la configuration. 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. Si l'intégration continue a été correctement configurée, le job Jenkins de mise à jour devrait se lancer automatiquement dès que la nouvelle version de l'image arrive sur le registre.  
[[Catégorie:Tutoriel]]
[[Catégorie:Tutoriel]]