Conteneuriser une application Shiny avec {shiny2docker} : guide étape par étape

Étape 1 : Préparer une application Shiny simple

Tout d’abord, nous avons besoin d’une application Shiny à conteneuriser. Nous allons écrire un fichier app.R de base qui définit une interface utilisateur (UI) et un serveur. Dans un projet réel, vous pourriez avoir des fichiers ui.R et server.R séparés ou une structure d’application plus complexe, mais {shiny2docker} fonctionne avec n’importe quel répertoire d’application Shiny standard.

# app.R -- a simple Shiny app 
# (Make sure this file is in its own directory, e.g., "myapp/app.R")

library(shiny)

# Define UI for the application
ui <- fluidPage(
  titlePanel("Hello Shiny!"),
  sidebarLayout(
    sidebarPanel(
      # Input: Slider for the number of bins in the histogram
      sliderInput("bins", "Number of bins:",
                  min = 1, max = 50, value = 30)
    ),
    mainPanel(
      # Output: Histogram plot
      plotOutput("distPlot")
    )
  )
)

# Define server logic for the histogram
server <- function(input, output) {
  output$distPlot <- renderPlot({
    # Draw the histogram using the 'waiting' column of the faithful dataset
    x <- faithful$waiting  
    bins <- seq(min(x), max(x), length.out = input$bins + 1)
    hist(x, breaks = bins,
         col = "#75AADB", border = "white",
         xlab = "Waiting time to next eruption (mins)",
         main = "Histogram of Old Faithful waiting times")
  })
}

# Combine the UI and server into an app and run it
shinyApp(ui = ui, server = server)

Une brève explication du code ci-dessus : c’est l’exemple classique de Shiny où l’utilisateur peut ajuster le nombre de classes pour un histogramme. Nous utilisons faithful$waiting (le jeu de données du geyser Old Faithful intégré à R) comme données. L’application dispose d’un contrôle par curseur pour le nombre de classes et affiche un histogramme qui se met à jour en fonction du curseur. Si vous enregistrez ce code dans app.R et exécutez shiny::runApp("app.R"), vous devriez voir l’application fonctionner en local.
Maintenant que notre application Shiny est prête dans un répertoire (par exemple, nous avons enregistré app.R dans un dossier nommé myapp/), nous sommes prêts à la conteneuriser avec {shiny2docker}.

Étape 2 : Générer un Dockerfile avec {shiny2docker}

Le package {shiny2docker} va inspecter notre application et produire un Dockerfile (ainsi qu’un fichier .dockerignore). Assurez-vous que votre répertoire de travail est défini sur le dossier contenant l’application Shiny (par exemple, définissez-le sur le répertoire myapp que nous avons créé, soit avec `setwd` ou idéalement, pour les utilisateurs de Rstudio dans un projet Rstudio).
Dans une session R, exécutez ce qui suit :

# In the R console, with working directory set to the Shiny app folder (e.g., "myapp")
library(shiny2docker)

# Generate a Dockerfile for the Shiny app in the current directory
shiny2docker(path = ".")

Après avoir exécuté shiny2docker(path = "."), vous devriez voir des messages dans R indiquant qu’un Dockerfile est en cours de création. Par défaut, cela créera deux fichiers dans votre répertoire d’application :

• Dockerfile – un fichier texte contenant les instructions pour construire une image pour votre application Shiny.
• .dockerignore – un fichier texte spécifiant les fichiers à exclure du contexte de build Docker (des entrées courantes peuvent inclure .Rproj.user, renv/library/, etc., que {shiny2docker} remplit automatiquement).

Examinons ce que fait {shiny2docker} lors de la génération du Dockerfile :

• Il recherche un fichier lockfile renv.lock existant dans le répertoire. S’il en trouve un (ce qui signifie que vous avez déjà utilisé {renv} pour verrouiller les dépendances), il l’utilisera. Sinon, {shiny2docker} créera un lockfile pour vous en analysant,entres autres, vos appels library() afin de déterminer les packages (et versions) nécessaires. Dans notre application simple, la dépendance principale est le package shiny lui-même (ainsi que les packages R par défaut comme datasets). Le lockfile garantit que le conteneur installera la même version de shiny (et des autres packages) que celle utilisée localement.
• Il écrit un Dockerfile qui utilise généralement une image Docker de base adaptée à Shiny. Dans de nombreux cas, ce sera l’image rocker/geospatial, qui inclut R, Shiny et de nombreux outils préinstallés. L’utilisation d’une image de base préfabriquée nous évite de configurer manuellement R et Shiny dans le Dockerfile. Le Dockerfile commencera donc par FROM une version spécifique de rocker/geospatial (par exemple, rocker/geospatial:4.2.2 si vous utilisez R 4.2.2).
• Le Dockerfile inclura ensuite des instructions pour installer les bibliothèques système et les packages R. Grâce au fichier renv.lock, {shiny2docker} sait exactement quels packages R (et quelles versions) installer dans le conteneur. Typiquement, le Dockerfile fera quelque chose comme :
  • Installer renv dans le conteneur (pour pouvoir l’utiliser pour restaurer les packages).
  • Copier le fichier renv.lock (et éventuellement vos fichiers de projet R) dans le conteneur.
  • Exécuter renv::restore() pour installer tous les packages R requis aux versions verrouillées.
  • Copier vos fichiers d’application Shiny dans le conteneur (par exemple, app.R ou ui.R/server.R et toutes les ressources de l’application).
  • Définir les permissions de fichiers appropriées et les variables d’environnement pour l’application Shiny (si nécessaire).
• Enfin, le Dockerfile spécifiera une commande pour lancer l’application Shiny lorsque le conteneur s’exécute. En général, ceci se fait en appelant shiny::runApp() ou en utilisant la commande par défaut de Shiny Server. Par exemple, il pourrait utiliser un entrypoint qui exécute quelque chose comme :

  R -e "shiny::runApp('/srv/shiny-server', port=3838, host='0.0.0.0')"

Pour jeter un œil au Dockerfile généré, ouvrez-le dans un éditeur de texte. Il devrait ressembler à ceci (votre fichier exact peut différer légèrement) :

FROM rocker/geospatial:4.4.2
RUN apt-get update -y && apt-get install -y  make zlib1g-dev git && rm -rf /var/lib/apt/lists/*
RUN mkdir -p /usr/local/lib/R/etc/ /usr/lib/R/etc/
RUN echo "options(renv.config.pak.enabled = FALSE, repos = c(CRAN = 'https://cran.rstudio.com/'), download.file.method = 'libcurl', Ncpus = 4)" | tee /usr/local/lib/R/etc/Rprofile.site | tee /usr/lib/R/etc/Rprofile.site
RUN R -e 'install.packages("remotes")'
RUN R -e 'remotes::install_version("renv", version = "1.0.3")'
COPY renv.lock renv.lock
RUN --mount=type=cache,id=renv-cache,target=/root/.cache/R/renv R -e 'renv::restore()'
WORKDIR /srv/shiny-server/
COPY . /srv/shiny-server/
EXPOSE 3838
CMD R -e 'shiny::runApp("/srv/shiny-server",host="0.0.0.0",port=3838)'

L’exemple ci-dessus est une illustration de ce que le Dockerfile peut contenir. Les points clés sont qu’il utilise l’image de base rocker/geospatial (correspondant à votre version de R), copie le lockfile et l’application, installe les packages via renv::restore() et configure le conteneur pour exécuter Shiny Server afin de servir l’application. Notez que le port 3838 est exposé : c’est le port par défaut sur lequel Shiny Server sert les applications.
À cette étape, sans écrire vous-même la moindre instruction Docker, vous disposez d’un Dockerfile prêt à l’emploi. Passons maintenant à la construction de l’image Docker.

Étape 3 : Construire l’image Docker

Avec le Dockerfile en place, l’étape suivante consiste à construire l’image Docker pour votre application Shiny. Cette étape se fait dans le terminal (et non dans R). Ouvrez un terminal (ou utilisez l’onglet Terminal de RStudio) et placez-vous dans le répertoire contenant le Dockerfile (notre dossier myapp). Puis exécutez :

# Make sure you are in the directory with the Dockerfile
# Replace 'myshinyapp' with the name you want for your Docker image.
docker build -t myshinyapp .

Décomposons cette commande :

• docker build est la commande pour construire une image Docker.
• -t myshinyapp assigne le tag « myshinyapp » à l’image (vous pouvez choisir n’importe quel nom ; c’est ce que vous utiliserez pour exécuter le conteneur).
• . (point) à la fin indique à Docker d’utiliser le répertoire courant comme contexte de build, en cherchant le Dockerfile à cet endroit.

Docker va ensuite exécuter les instructions du Dockerfile. La première fois que vous lancez cette commande, il peut télécharger l’image de base (rocker/geospatial), qui pèse plsu de 1,5 Go. Ensuite, il installera les packages R nécessaires. Ce processus peut prendre un certain temps, surtout si votre application comporte de nombreux packages, mais pour notre application simple (qui ne nécessite que R de base et shiny), cela devrait être assez rapide.
Surveillez la sortie dans le terminal. Vous devriez voir Docker télécharger des couches, installer des packages, etc., et finalement afficher un message indiquant que l’image a été construite et taguée « myshinyapp:latest ». Si quelque chose ne va pas (par exemple, un package qui échoue à s’installer), les logs d’erreur apparaîtront. Dans notre cas, la construction devrait se terminer avec succès.
Astuce : Si vous modifiez votre application ou ajoutez des packages et que vous souhaitez reconstruire, vous devrez exécuter à nouveau docker build. Le cache Docker accélérera les reconstructions (les étapes non modifiées sont mises en cache), mais si vous ajoutez de nouveaux packages R, l’étape renv::restore() installera les nouveaux packages lors de la reconstruction.

Étape 4 : Exécuter l’application Shiny dans un conteneur Docker

Maintenant que l’image est construite, vous êtes prêt à exécuter votre application Shiny dans un conteneur. Exécuter le conteneur lancera un Shiny Server hébergeant votre application. Utilisez la commande docker run suivante :

docker run -d -p 80:3838 --name myshinyapp_container myshinyapp

Voici la signification de chaque partie :

• docker run est la commande pour démarrer un nouveau conteneur à partir d’une image.
• -d exécute le conteneur en mode « détaché » (en arrière-plan). Vous pouvez omettre -d si vous souhaitez l’exécuter au premier plan pour voir les logs, mais dans ce cas, vous aurez besoin d’un terminal séparé.
• -p 80:3838 mappe le port 3838 à l’intérieur du conteneur vers le port 80 sur votre machine locale. C’est essentiel : l’application Shiny est servie sur le port 3838 du conteneur, et cette option expose ce port afin que vous puissiez y accéder via http://localhost:80 dans votre navigateur web.
• --name myshinyapp_container donne un nom convivial au conteneur (optionnel mais utile pour gérer les conteneurs). Nous avons choisi « myshinyapp_container » ici.
• myshinyapp à la fin est le nom de l’image à exécuter (celle que nous avons construite et taguée à l’étape 3).

Après exécution, Docker démarrera le conteneur. Vous pouvez vérifier qu’il est en cours d’exécution en exécutant docker ps (qui devrait lister le conteneur en cours). Ouvrez maintenant votre navigateur web et allez à http://localhost:80. Vous devriez voir votre application Shiny d’histogramme s’exécuter, tout comme en local ! 🎉 Ajustez le curseur et l’histogramme se mettra à jour, mais notez qu’il s’exécute maintenant dans un conteneur Docker.
Si vous ne voyez rien ou si vous obtenez une erreur, vérifiez quelques points :

• Assurez-vous que Docker est effectivement en cours d’exécution et que le conteneur est opérationnel (docker ps devrait l’afficher).
• Si vous êtes sur un serveur distant, assurez-vous de visiter le bon hôte ou d’avoir effectué la redirection de port nécessaire. L’exemple ci-dessus suppose un développement en local.
• Consultez les logs du conteneur avec docker logs myshinyapp_container pour voir si l’application Shiny ou le serveur a imprimé des messages d’erreur au démarrage.

À ce stade, vous avez réussi à conteneuriser une application Shiny à l’aide de {shiny2docker}. L’application s’exécute dans un environnement isolé avec toutes ses dépendances gérées par renv et installées dans le conteneur.
Lorsque vous avez terminé, vous pouvez arrêter le conteneur avec docker stop myshinyapp_container et le supprimer avec docker rm myshinyapp_container. L’image Docker « myshinyapp » restera sur votre système (visible avec docker images), et vous pourrez la réexécuter à tout moment ou la pousser vers un registre de conteneurs si vous souhaitez la déployer ailleurs.