La première étape est d’identifier les besoins pour vos usages: ressources physiques, logiciels, interface, données.
En principe, toute interface permettant un usage depuis le navigateur peut être utilisée. Ainsi JupyterLab, VSCode ou des environnements de bureaux type XFCE ont déjà été déployés sur myDocker. De même, des interfaces comme RStudio ne devraient pas poser de difficulté. Il est aussi possible de créer des environnements accessibles par d’autres protocoles comme ssh.
Tout logiciel libre pouvant tourner sous Linux peut être en principe installé. Si vous avez besoin d’un logiciel non libre, contactez nous pour étudier s’il peut y avoir une solution technique et financière. De même dans le cas d’un logiciel tournant sous un autre système d’exploitation.
Il est aussi possible de prévoir l’inclusion de données directement dans l’environnement. Au delà de 1Go, nous contacter pour étudier ensemble les impacts éventuels et alternatives. Nous contacter aussi si le besoin en d’autres ressources est élevé (10+ processeurs, 10+Go mémoire, GPUs, 200+ étudiants).
Une fois ces éléments identifiés, nous recommandons de chercher une image et un environnement similaires et de consulter comment il ont été construits pour vous en inspirer. Vous pouvez pour cela consulter les environnements génériques listés sur ce site. N’hésitez pas le cas échéant à contacter le mainteneur pour avoir accès à leur configuration. Vous pourrez alors créer votre propre image et votre propre environnement en recopiant et adaptant la configuration.
La plupart des environnements utilisent un gestionnaire de paquets
comme apt, conda, pip, voire guix pour des besoins pointus de
reproductibilité. L’adaptation consistera alors simplement à adapter
la liste des paquets à installer. À titre d’essai préalable, vous
pouvez tester l’installation des logiciels directement dans
l’environnement d’inspiration.
Nous documentons ci-dessous quelques uns des éléments de configuration:
Informations Générales
Dans l’onglet «information générales» d’un environnement il est possible de spécifier un certains nombre d’informations comme le titre de l’environnement, sa description, son status (draft, test, ready c’est à dire stable, ou archived).
Extinction automatique de l’environnement
Il est possible de configurer une extinction automatique des environnements. Cette fonctionnalité est prévue pour les cas où l’on souhaite imposer une durée limitée d’accès à l’environnement (examen, accès à des ressources coûteuses, etc).
Si l’on utilise JupyterLab et si l’on souhaite juste que l’environnement s’éteigne automatiquement au bout d’un certain temps d’inactivité, une meilleure alternative est de déléguer cette tâche à Jupyter en spécifiant les options adéquates dans la commande de lancement de JupyterLab. Dans l’exemple suivant, les noyaux, les terminaux puis l’application JupyterLab tout entière s’éteignent automatiquement au bout de 20 minutes (1200 secondes) d’inactivité:
jupyter lab --no-browser --ip="0.0.0.0" --IdentityProvider.token={{PASSWORD}} --ServerApp.shutdown_no_activity_timeout=1200 --MappingKernelManager.cull_idle_timeout=1200 --TerminalManager.cull_inactive_timeout=1200Sessions
Il est possible d’indiquer des «sessions» pour les cours.
Sur l’instance myDocker@CentraleSupelec, où les serveurs sont loués à la demande, ces sessions permettent de réserver les serveurs aux horaires indiqués. C’est utilisé notamment pour de grands cours (plusieurs centaines d’étudiants simultanés) ou des cours utilisant des ressources lourdes (GPU). Ces sessions sont sujettes à validation par les administrateurs.
Sur l’instance myDocker@Paris
Informations Techniques
L’onglet “Informations techniques” permets de définir les caractéristiques techniques de l’environnement: l’image de départ, le ou les types (protocoles) de connexion et, par conséquent le ou les ports à ouvrir, la commande à lancer au démarrage, le nombre de CPU ou GPU et la mémoire à allouer.
Commande au lancement
Ce champ surcharge la valeur de la variable CMD de l’image
docker. Par convention, la plupart des images traitent cette variable
comme une commande à exécuter dans l’environnement au lancement de
celui-ci. Typiquement elle sert à lancer l’interface de
l’environnement comme, par exemple, Jupyter Lab:
jupyter lab --no-browser --ip="0.0.0.0" --IdentityProvider.token={{PASSWORD}}Cette commande sert aussi typiquement à passer à l’environnement des
secrets d’authentification générés par MyDocker ({{PASSWORD}} et
éventuellement {{USERNAME}}) pour restreindre l’accès à celui-ci.
Certaines images, notamment datant des débuts de myDocker, dévient de
cette convention: elles contiennent un script wrapper_script.sh --
défini comme entry point -- qui est exécuté au démarrage de
l’environnement. Le contenu de CMD permet alors de spécifier les
arguments du script, séparés par des espaces comme sur une ligne de
commande shell. Il s’agit typiquement de {{USERNAME}} {{PASSWORD}}.
Dossier personnel persistant
L’item «Sauvegarder le travail de l’étudiant» permet d’activer la persistance d’un dossier personnel de l’utilisateur dédié à cet environnement. L’item «Activer le répertoire personnel de l’élève» est similaire sauf que ledit dossier personnel est partagé avec les autres environnements.
Le «chemin du volume étudiant» est le chemin où le dossier personnel
est mis à disposition dans le conteneur. C’est typiquement
/home/jovyan pour une image basée sur la pile docker de Jupyter,
/home/mambauser pour une image basée sur mambaorg/micromamba.
Pour le déterminer, vous pouvez démarrer votre environnement avant
d’avoir configuré la persistance, ouvrir un terminal et taper pwd
pour obtenir le chemin du dossier courant.
Évolutions planifiées:
améliorer la terminologie dans l’interface pour plus de cohérence.
ajout d’un gestionnaire de volumes -- notamment pour héberger des grosses données, avec configuration souple de quels volumes sont montés dans les environnements.
Options d’affichage
L’onglet «Options d’affichage» permet de configurer comment l’utilisateur accède à l’interface du conteneur docker. Pour cela, on peut configurer un ou plusieurs boutons avec pour chacun un lien de connexion.
Cette connexion est sécurisée par une authentification par un mot de passe tiré au hasard et éventuellement un identifiant associé qui ont par ailleurs été transmis au conteneur au démarrage de celui-ci. Le traitement d’une telle authentification dépend de l’interface utilisée dans le conteneur docker (JupyterLab, ssh, ...). Idéalement, cette étape est automatisée, typiquement en transmettant le token via le lien. Par exemple, avec JupyterLab, on peut utiliser comme lien:
https://{{HOST['8888']}}/?token={{PASSWORD}}Sinon, ce sera à l’utilisateur de saisir manuellement le mot de passe et l’éventuel identifiant à l’ouverture de l’interface. Il faudra donc les avoir préalablement affichés: cela est possible en cochant les cases «Afficher le mot de passe» ou «Afficher l’utilisateur».
Il est aussi possible de configurer un affichage en mode texte à la place d’un bouton. Par exemple, lorsque l’environnement est conçu pour être accédé depuis un programme externe (ssh, ...), cet affichage permet de fournir à l’utilisateur la commande exacte à lancer, en tenant compte des paramètre de l’environnement: hôte, identifiant, mot de passe, etc.
Choix de construction de l’image
Un composant essentiel d’un environnement est l’image (docker) qui
contient tous les logiciels ou données requises. Il est par exemple
possible d’utiliser l’une des images docker fournies par la communauté
Jupyter
comme jupyter/scipy-notebook.
Il est aussi possible de construire sa propre image, typiquement en
partant d’une image existante et en y rajoutant les éléments
voulus. La construction d’une telle image est décrite par un fichier
Dockerfile; il s’agit essentiellement d’un script indiquant les
commandes à exécuter pour installer les logiciels et données voulues.
Construction d’image dans mydocker
On peut construire une telle image directement dans l’éditeur intégré
à mydocker (onglet Images). Cet éditeur permet alors de spécifier:
Des métadonnées sur l’image: titre, description, ...
Le contenu du
Dockerfile.(optionnel) le contenu d’un script de démarrage
wrapper_script.sh.(optionnel) une archive zip de contexte contenant une arborescence de fichiers.
Si l’on souhaite utiliser le script de démarrage wrapper_script.sh,
il faut inclure les lignes suivantes dans le Dockerfile:
COPY wrapper_script.sh /usr/local/lib/wrapper_script.sh
ENTRYPOINT ["/bin/ash", "/usr/local/lib/wrapper_script.sh"]Dans le cas contraire, il faut mettre (par exemple) un # dans
l’onglet wrapper_script.sh pour qu’il ne soit pas vide.
L’archive zip, si elle est fournie, est décompressée dans le dossier
où est construite l’image. On peut alors copier son contenu dans
l’image (mettons un dossier bla) avec des commandes comme:
COPY bla /blaConstruction d’image avec GitLab
Pour construire des images plus complexes, ou pour lesquelles on souhaite bénéficier de gestion de version, on peut s’appuyer sur une forge comme GitLab. De nombreuses images sont ainsi construites sur la forge GitLab de l’Université Paris-Saclay:
https://