« ShinyProxy » : différence entre les versions
| (6 versions intermédiaires par le même utilisateur non affichées) | |||
| 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 24 : | Ligne 26 : | ||
library(glourbi) | library(glourbi) | ||
options("shiny.port" = | # Dans cet exemple, l'application écoutera systématiquement sur le port 3838 | ||
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE) | |||
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server) | shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server) | ||
| Ligne 118 : | Ligne 121 : | ||
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. | Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. | ||
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"> | |||
~$ docker images | |||
REPOSITORY TAG IMAGE ID CREATED SIZE | |||
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB | |||
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB | |||
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB | |||
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB | |||
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB | |||
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB | |||
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB | |||
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB | |||
dockurr/windows latest c3419fd6e55a 2 months ago 384MB | |||
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB | |||
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB | |||
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB | |||
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque. | |||
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. | |||
=== Tester l'image === | |||
Pour tester son image, on peut utiliser la commande <code>docker run</code> : | |||
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code> | |||
* --rm : Supprimer le container lorsqu'il est arrêté. | |||
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container. | |||
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''. | |||
=== Faire du ménage localement === | |||
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage. | |||
=== 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 | == Configuration de l'application sur le serveur ShinyProxy de production == | ||
La configuration initiale de l'application doit être faite par l'administrateur du serveur. | |||
== 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 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]] | ||