Categories: docker Tags: rstudio blogdown

7 min read

Personnalisation d'un docker

March 10, 2025

Présentation de Rstudio

Rstudio est un IDE permettant de faire du R et d’éditer R Markdown pour inclure du code R dans le document, de l’exécuter et d’avoir le rendu dans la page.

Cet IDE est plein de fonctionnalités que je détaillerais dans un autre article.

Contexte

J’avais utilisé Rstudio, il y a à peu 2 ans , pour faire du R et éditer mon blog ; et n’ayant pas vraiment pris le temps de lire le mode d’emploi , c’était un véritable chantier dans le dossier de travail , et 2 ou 3 ans plus tard , je ne me souvenais plus en j’en étais.

En voulant ré installer Rstudio , et reprendre le projet ou il en était, je constatais que c’était toujours le bazars . Je me suis souvenu qu’il y avait des équipes qui travaillaient sur du rstudio en docker. Avec des dockers à la carte avec des packages R pré-installés.

Comme si , faire tourner rstudio en docker allait arranger mes affaires… finalement oui , j’ai fini par comprendre comment bien m’en servir .

Bref, j’ai adapté une image de RStudio-server pour y installer le package blogdown.

C’est parti de l’article de Dave Tang qui traité de rstudio-server.

Adaptation

Je vais simplement reprendre son Dockerfiles , et ajouter blogdown dans les packages, et supprimer des éléments qui sont adaptés à son environnement à lui .

Il me manque tout de même la persistance des packages R , mais ce n’est pas grave, on peut reconstruire une image avec les packages manquant , le principe ici étant d’avoir un RStudio-server avec blogdown.

Le Dockerfiles

L’image de base est celle développée par l’équipe rocker, c’est une image optimisé construite sur une debian like. On appelle cette image avec FROM rocker/rstudio:4.2.3

Viennent ensuite les LABEL.

La série de commande envoyée au système de base debian (c’est une ubuntu en réalité), avec RUN apt pour la mise à jour du système , et l’installation des packages utiles, tel que git , pandoc (c’est un convertisseur de document très puissant), il y a une version pandoc en ligne.

Les librairies de chiffrement openssl, de compression lzma, de manipulation d’images libmagick.

Et l’installation des packages R qui nous intéressent dont blogdown, avec la commande RUN Rscript -e “install.packages(c(‘rmarkdown’, ’tidyverse’, ‘workflowr’, ‘blogdown’));”.

Il faudra que j’ajoute shiny au prochain build. Il n’y a pas de mystère la construction d’une image, ou tout autre type de développement se fait par itération d’erreur, c’est toujours en faisant des erreurs que l’on apprend.

FROM rocker/rstudio:4.2.3

LABEL "com.ordinatous.vendor"="<contact@ordinatous.com>"
LABEL version="1.1"
LABEL description="image de test rstudio avec blogdown"

RUN apt clean all && \
    apt update && \
    apt upgrade -y && \
    apt install -y \
    pandoc \
        git \
    cmake \
    libhdf5-dev \
libcurl4-openssl-dev \
    libssl-dev \
    libxml2-dev \
    libpng-dev \
    libxt-dev \
    zlib1g-dev \
    libbz2-dev \
    liblzma-dev \
    libglpk40 \
    libgit2-dev \
    libgsl-dev \
    patch \
    libmagick++-dev && \
    apt clean all && \
    apt purge && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
RUN Rscript -e "install.packages(c('rmarkdown', 'tidyverse', 'workflowr', 'blogdown'));"

WORKDIR /home/rstudio

Etant donné que m’a précédente utilisation de Rstudio , était un véritable bazars, je n’ai pas osé copier mon profil, ni mes préférences , ne sachant pas trop ou j’allais.

Construction de l’image

docker build -t ordinatous/rstudio:v1.1 .

Vérification

Je vérifies la présence de l’image.

docker images
REPOSITORY                               TAG       IMAGE ID       CREATED       SIZE
ordinatous/rstudio                       v1.1      c972c0af0fc6   6 days ago    2.68GB
registry.ordinatous.local:5000/rstudio   latest    c972c0af0fc6   6 days ago    2.68GB

On voit 2 images , curieusement je n’ai pas réussi à lancer celle que j’ai construit, le prétexte était tout trouvé pour créer mon registre d’images auto-hébergé.

Les étapes de l’installation du registry et de l’autoritée de certification sont traîtés dans cet article

Normalement cette commande aurait permis de tester l’image: bash docker run --rm -p 8888:8787 -d --name rstudio_server \ -v /home/ordinatous/test_rstudio/:/packages \ -e PASSWORD=password \ -e USERID=$(id -u) -e GROUPID=$(id -g) \ ordinatous/rstudio:v1.1:local A savoir que l’utilisateur par défaut est : rstudio , mais l’on peut définir un autre utilisateur, mais ce n’est pas très utile , l’image semble optimisée pour que le volume (dossier local) ne soit pas utilisé par l’utilisateur root.

Ainsi il semble également que définir le USERID et le GROUPID ne soit plus utile.

Few moment later, 🍾 le registre est créé.

Je vais donc tagger puis pousser l’image vers le registre.

### tag bash docker tag ordinatous/rstudio:v1.1 registry.ordinatous.local:5000/rstudio

push

docker push registry.ordinatous.local:5000/rstudio:latest

Je pourrais supprimer l’image local pour gagner de la place, puisque je vais en reconstruire une , mais pour rappel cette image contient un système de base ubuntu, avec R d’installé, et d’autres packages pour seulement 2,68GB , alors en comparaison d’une VM.

Le choix est assez vite fait.

Exploitation avec portainer

C’est une chose que je voulais tester depuis longtemps , car ça donne de nouvelles possibilités.

Contrairement à ce que je préconisais: créer un dossier pour le projet afin d’y garder les fichiers …😅 , ça n’a pas raté , le Dockerfiles est dans mon home ..

Avec portainer je vais pouvoir configurer le docker, et ensuite il va me permettre le dupliquer et le modifier.

Création du docker

  1. Choisir l’environnement
  2. Sélectionner Containers
  3. Add Containers
  4. Le nommer
  5. Sélectionner le registre, ici local
  6. Sélectionner l’image, ici rstudio:latest
  7. Dans le cas présent , j’ai utiliser la fonction de dupplication pour montrer la configuration.

Mappage des ports

C’est tellement évident, que ça ce passe d’explication..

  1. Port de l’hôte
  2. Port du container

Configurations avancées du container

Beaucoup de choses sont déjà défini par défaut lors des constructions précédentes de l’image. Je déconseille fortement d’y toucher.

  1. Commands and logging : inutile de modifier dans notre cas.
  2. Volumes : c’est ici que l’on va définir les options de montages. Je n’ai pour l’instant pas compris, pourquoi , j’arrivais à écrire dans lithium , et pas dans packages.
  3. Network : configuration totalement facultative, excepté le mode bridge, tout ce fait automatiquement.
  4. Environment variables : idem modifications facultatives, j’avais testé la modification du mot de passe pour voir , et ça a fonctionné. A part peut être la TZ , pour Time zone , afin d’éviter un horodatage incohérent dans le dossier monté.
  5. Labels : ne pas y toucher , c’est ce qui a été défini à la construction de l’image.
  6. Restart policy : la politique de redémarrage du container , dans mon cas c’est un docker que je souhaite lancer à la demande , je choisi unless-stopped.
  7. Runtime & Resources : Inutile de modifier quoi que ce soit , mais c’est ici que l’on peut outre passer la politique d’isolement d’un docker . Pour accéder totalement au ressouces de la machine hôte comme la carte réseau, ou le partage de la mémoire.
  8. Capabilities : Ce sont les capacités qui ont été donné au docker lors de sa construction, évitez d’y toucher au risque d’avoir de gros effets de bord.

Démarrage du docker

Je sais qu’il a démarré , sans quoi je ne me serais pas amusé à écrire , mais est-ce qu’il va redémarrer ? On voit qu’elle a quitté avec un code 0 , ce qui est bon signe , il n’y a pas eu d’erreurs.

Je viens de penser, que ça ne vous prouve pas que blogdown était bien installé.. il suffit de lire le Dockerfile pour comprendre que oui.

Elle démarre bien 🤘

J’avais tenté de faire une entrée DNS , et une redirection avec le reverse-proxy mais j’ai un 502 bad gateway , alors je vais y aller en IP.

L’interface web est accessible , les crédentials sont bien rstudio et le mot de passe que j’ai défini.

J’étais d’ailleurs en train d’utiliser blogdown , quand j’ai compris que la commande

blogdown::serve_site()

appelait un script livereloadJS qui semble communiquer sur le port 443, ce que je n’avais pas anticipé , et ça me casse ma mise en page. L’une des fonctionnalités intéressante de Rstudio, et en particulier de blogdown , c’est de visualiser en temps réel le rendu du document durant l’édition.

Test d’écriture système de fichiers local

Point intéressant a vérifier , le propriétaire des fichiers, donc l’accès en écriture.

  1. pwd pour montrer que je suis bien dans /home/rstudio
  2. date pour vérifier la TZ , c’est pas à l’heure
  3. touch cestpasalheure pour créer un fichier

En ssh sur la machine distante , je constate que le fichier existe bien.

J’en suis bien propriétaire. Comme défini à la construction du docker.

Je vais écrire dedans.

Vérification depuis rstudio-server.

Conclusion

Nous avons vu comment :

  • modifier une image et la construire

  • la tagger

  • la pousser vers un registre (local ou distant, c’est la même chose)

  • la lancer depuis portainer

    article de la mise en place d’un registry local , du RootCA , et l’édition des certificats.