7  FAQ

7.1 Nous contacter

Le lieu privilégié pour communiquer avec nous sur votre application est votre issue dédiée, qui a été ouverte lors de votre demande d’hébergement, vous pouvez la réouvrir si elle est fermée.

Sinon :

7.2 Questions sur le fonctionnement général de SK8

Sans passer par le catalogue, vous disposez d’un unique container pour votre application Shiny, tous les utilisateurs se connectent dessus, c’est plus léger pour nos servers et plus rapide au démarrage.

Le catalogue SK8 utilise ShinyProxy. En passant par l’url “catalogue” de votre application, pour chaque utilisateur de votre application un nouveau container Docker sera reconstruit. L’avantage est que les utilisateurs constateront moins de latence en utilisant l’application, l’inconvénient est que si votre container Docker est long à lancer, chaque utilisateur devra patienter plus longtemps pour voir l’application démarrer.

Le fonctionnement par catalogue (ShinyProxy) peut être nécessaire pour certaines applications dont les données sont obligatoirement gérées en dehors de l’application (mise à jour des données AVANT le lancement de l’application par exemple) ou causant des problèmes de conflits entre utilisateurs.

NB : il est souvent plus simple si c’est possible (et plus léger en stockage, mémoire, …), de faire un filtre sur les données côté server dans un observe par exemple, plutôt que d’activer le catalogue.

A noter Par défaut le catalogue n’est pas activé. Il ne le sera que si : 1. vous en faites la demande lors de votre inscription 2. votre application fonctionne déjà sans catalogue. A ce moment là nous activerons le catalogue et nous vous enverrons l’url à partager à vos utilisateurs.

En développement : il sera possible de demander la création d’un catalogue indépendant de celui de SK8 pour votre unité/département/projet de recherche.

Lien vers le catalogue SK8.

Si vous disposez déjà d’une application R-Shiny containerisé avec un Dockerfile, vous n’avez qu’à garder le fichier .gitlab-ci.yml pour intégrer votre application dans SK8.

Si vous disposez déjà d’un fichier .gitlab-ci.yml, il suffit d’ajouter à son contenu celui de SK8. Plus d’information

Si le site https://demande-hebergement.sk8.inrae.fr n’est pas disponible, vous pouvez directement créer une issue sur le support SK8.

A votre demande d’hébergement une issue a été créée. Vous pouvez aller voir son statut ici : https://forgemia.inra.fr/sk8/sk8-support/-/issues.

Vous pouvez nous écrire un message dans cette issue, toute l’équipe SK8 la recevra.

A noter tout de même que la création de templates dédiée est manuelle en fonction de vos spécifications, et que parfois nous partons en vacances, donc selon la période de l’année ça peut nous prendre un peu de temps pour vous répondre.

Mais si vous n’avez pas de nouvelles au bout de quelques jours vous pouvez évidemment nous contacter !

Comme le rappelle le site datapartage d’INRAE, les données produites par les EPST dans le cadre de leur mission de service public (données brutes, données élaborées et métadonnées produites par les salariés de l’établissement ou dans le cadre d’un contrat indiquant que ces données lui appartiennent) sont concernées par la loi dite “CADA” : elles doivent donc être rendues publiques (sauf exceptions légales) et librement réutilisables dès lors qu’elles sont considérées comme achevées.

De ce fait, il est nécessaire d’appliquer une licence ouverte aux données, algorithmes et codes de la recherche.

Pour vous aider à choisir une licence, vous pouvez vous référer à :

Vous devez également être vigilants aux licences de vos dépendances. R et shiny sont sous licence GPL2 / GPL3.

Il n’y a pas réponse universelle, mais les licences GPL3, MIT et CC-BY-SA répondent à la majorité des besoins. Les licences permissives (comme MIT) et copyleft (comme GPL3) autorisent la copie, la modification, la réutilisation et la publication du code. Cependant les licences copyleft sont plus strictes et obligent la distribution du code dans les mêmes conditions.

Vous pouvez ajouter facilement une licence à votre projet depuis R avec usethis::use_*_license(), ou depuis votre dépôt sur la forge, en cliquant sur [+] Add LICENSE.

L’équipe SK8 a fait le choix de développer un service non intrusif, aussi l’utilisation d’outils de suivi n’est pas prévue par nous. En revanche rien ne vous empêche d’utiliser un outil et d’intégrer le morceau de code permettant le suivi dans le code de votre application.

Par exemple la version gratuite de PanelBear a déjà été utilisé avec succès mais dont le service s’arrêtera au 1er mai 2023. Son successeur Cronitor RUM permet avec la version gratuite de monitorer jusque 5 sites.

Pour l’utiliser il vous faut :

  1. Créer un compte
  2. Enregistrer votre site
  3. Copier le snippet javascript fourni dans le dossier www,
  4. Inclure le snippet dans le ui avec la ligne : tags$script(src = "myssnippet.js"),

Pour savoir comment inclure un script javascript dans votre application : https://shiny.rstudio.com/articles/packaging-javascript.html

Actuellement, il n’est pas possible de disposer de données persistantes pour vos applications.
Toutes données générées ou uploadées sur votre application aura une durée de vie éphémère.

Concrétement, l’image Docker générée dans votre projet est instanciée plusieurs fois (containers) dans le cluster SK8 et sont redémarrées automatiquement en cas de problème (plantage…) avec l’image de base.

C’est un chantier en cours.

Du point de vue code RShiny, il est possible d’utiliser une API pour profiter de stockages externes à SK8 (par exemple API aws S3).

Si vous disposez d’un stockage de type stockage objet S3 (bucket, container,…), il est possible de l’utiliser dans votre application avec le package {aws.s3}.

Vous pouvez par exemple demander à avoir du stockage capacitif inrae en faisant une demande sur ariane, puis accessible sur https://cloud.inrae.fr/.

Voici un exemple pour vous connecter et lister un container cloud inrae basé à toulouse :

library("aws.s3")
Sys.setenv("AWS_ACCESS_KEY_ID" = "<VOTRE_ID_KEY>",
           "AWS_SECRET_ACCESS_KEY" = "<VOTRE_SECRET_KEY>",
           "AWS_DEFAULT_REGION" = "s3-tls", 
           "AWS_S3_ENDPOINT" = "stockage.inra.fr")

bucketlist()

Les variables VOTRE_ID_KEY et VOTRE_SECRET_KEY doivent être passées à Shiny en tant que variables secrètes CI/CD

Créer des variables secrètes

Une variable secrète (login, mot de passe, …) peut être créée depuis l’interface forgemia dans Settings -> CI/CD -> Variables.

Attention : il vous faut masquer (masked) la variable pour qu’elle soit secrète : https://forgemia.inra.fr/help/ci/variables/index#mask-a-cicd-variable

Des solutions plus sécuritaires sont possibles : https://forgemia.inra.fr/help/ci/secrets/index.md

Passer des variables à Docker

Si vous souhaitez passer des variables (secrètes) à la création de l’image docker cela est possible en réécrivant cette partie dans votre .gitlab-ci.yml. Pour ce faire, vous pouvez dupliquer le job Construire-l-application disponible ici ou juste réécrire la partie script de ce job (pour bénéficier d’éventuelles mises à jour du job par défaut SK8).

Par exemple ici avec $VOTRE_VARIABLE_CACHE :

Construire-l-application:
  script:
    - docker pull $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:latest || true
    - docker build --build-arg <NOM_DE_VOTRE_VARIABLE>="<$VOTRE_VARIABLE_CACHE>" --build-arg APP_NAME=$CI_PROJECT_NAME --build-arg APP_VERSION="SK8-$CI_COMMIT_SHORT_SHA" --build-arg AUTHOR="$CI_COMMIT_AUTHOR" --build-arg R_IMAGE="$R_DOCKER_IMAGE:$R_DOCKER_TAG_VAL" --build-arg RENV_VERSION="$RENV_VERSION_VAL" --cache-from $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:latest --tag $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:latest -f Dockerfile .
    - docker push $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:latest

Afin d’intégrer ces variables dans votre application (et les rendre donc accessibles via Sys.getenv()), il faudra personnaliser votre Dockerfile. Si vous n’en disposez pas, vous devrez alors récupérer le Dockerfile généré à la volée par SK8 lors de la construction de l’application en suivant la procédure décrite sur cette page, puis rajouter l’appel vers vos variables dans ce Dockerfile avant de l’inclure dans votre répertoire contenant l’application.

Par exemple ici toujours avec $VOTRE_VARIABLE_CACHE :

ARG VOTRE_VARIABLE_CACHE
ENV VOTRE_VARIABLE_CACHE $VOTRE_VARIABLE_CACHE

Passer des variables à Shiny

Si les variables sont passées à Docker il est possible de les récupérer dans Shiny avec un Sys.getenv("VOTRE_VARIABLE_CACHE").

Oui, bien sûr. Les jobs de configuration, eux, sont actifs sur toutes les branches.

En revanche le déploiement ne se fait que sur la branche main. Les jobs du pipeline qui concernent la gestion de l’application (01-Publier, 02-Annuler-dernière-mise-à-jour et 03-Dépublier) et les logs (Recevoir-les-logs-de-mon-app) ne se lancent que sur la branche main du repo.

L’architecture SK8 n’est pas en mesure de proposer une URL différente de <myapp>.sk8.inrae.fr

Vous pouvez cependant tout à fait envisager une redirection depuis une URL personnalisée. Il suffit de disposer d’un nom de domaine (ticket Ariane) puis de demander une configuration DNS pour que cette URL pointe vers votre application SK8 (ticket Ariane)

Effectivement le cas des formations, avec une application lancée par elève risque de poser probème si l’application est volumineuse.

Plusieurs solutions : - Si l’application est de taille relativement petite, pas de problème mais on vous conseille très fortement de communiquer le lien du catalogue pour votre application, ainsi chaque elève aura son container et les applications des uns et des autres seront isolées.

  • Si la taille de l’application est plus importante, vous pourriez envisager que les elèves aient accès à l’application en local, chacun sur son poste. Dans ce cas nous recommendons l’accès par Docker. Une fois Docker installé sur la machine de l’elève, il n’y a qu’à lancer la commande docker run -it -p 3838:3838 registry.forgemia.inra.fr/<Chemin du projet>:latest si l’application est publique. C’est préférable à un lancement depuis R car ça évite d’avoir à installer les packages et dépendances, et de résoudre des éventuels problèmes de versions de packages.

7.3 Erreurs constatées

C’est que vous avez dû cloner votre projet en ligne de commande et ne pas créer le projet associé.

Il faut ensuite créer un projet R (depuis RStudio : File > New projet > Existing directory et ne pas oublier de cocher Open in new session en bas à droite).

Vous pouvez maintenant fermer RStudio puis réouvrir votre projet soit en cliquant sur le fichier .Rproj qui a été créé, soit en lançant la commande rstudio monprojet.Rproj.

Le package d’où provient la fonction n’est pas détecté.

Vous pouvez utiliser la syntaxe suivante :

  • NomPackage::NomFonction à chaque appel de fonction, dans tous les codes R (à privilégier)
  • ou inclure l’appel à la librairie directement dans le fichier global.R: library(NomPackage) Pour une meilleure prise en charge de vos packages R, nous vous conseillons d’utiliser le package renv chez vous en local, et de commiter le fichier renv.lock

Au moment de la création de votre projet versionné via GitHub ou GitLab, vous pouvez rencontrer l’erreur suivante: “error ssh_askpass exec(/usr/bin/ssh-askpass) no such file or directory”. Il manque en fait le paquet ssh-askpass sur votre ordinateur. Sous Ubuntu, il suffit de l’installer via synaptic par exemple ou en ligne de commande avec apt-get:

sudo apt-get install ssh-askpass

Au commit suivant, à l’invitation, il faut taper yes et le problème est résolu.

Lors de la création de l’image Docker, il arrive que certains services soient temporairement inaccessibles.

Exemple :

W: Impossible de récupérer http://deb.debian.org/debian/dists/testing/InRelease  Délai de connexion dépassé [IP : 199.232.82.132 80]
W: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place.

Généralement, relancer le job en question permet de résoudre le problème.

A noter que le premier déploiement peut prendre quelques dizaines de minutes.

Vous devriez aussi avoir reçu un mail à la fin du job, si ça n’est pas le cas, allez voir les logs (cliquer sur le nom du job).

Si rien n’apparait de suspect à ce niveau, vous pouvez lancer le job “Recevoir-les-logs-de-mon-app” pour recevoir les logs de déploiement par mail.

Il se peut que le job se soit déroulé intégralement mais qu’il y ait eu des erreurs ou warnings à son exécution.

De plus vous devriez avoir reçu un mail à la fin du job, si ça n’est pas le cas, allez voir les logs.

Pour voir les logs, cliquer sur le nom du job.

Si rien n’apparait de suspect à ce niveau, vous pouvez lancer le job “Recevoir-les-logs-de-mon-app” pour recevoir les logs de déploiement par mail.

Au début de votre fichier server.R, vous pouvez rajouter ce code :

options(shiny.maxRequestSize = 20*1024^2)

(ici augmente la limite à 20MB).

Cela se produit généralement quand votre application n’est pas en ligne.
Il suffit d’activer la tâche 01-Publier dans le CI/CD.

Les jobs du pipeline qui concernent la gestion de l’application (01-Publier, 02-Annuler-dernière-mise-à-jour et 03-Dépublier) et les logs (Recevoir-les-logs-de-mon-app) ne se lancent que sur la branche main du repo. Pour pouvoir envoyer l’appplication sur un noeud kubernetes et ainsi la déployer, merci de passer (fusionner) votre code sur la branche main.