Singularity

From Alliance Doc
Jump to navigation Jump to search
This page is a translated version of the page Singularity and the translation is 100% complete.
Other languages:

Utilisez plutôt Apptainer

Le contenu de cette page est désuet puisque Singularity n'est plus supporté. Consultez notre page wiki sur Apptainer.

Généralités

Singularity[1] est un logiciel libre (open source) créé par Berkeley Lab pour

  • utiliser de façon sécuritaire des conteneurs Linux sur des grappes Linux multiutilisateur;
  • donner aux utilisateurs le plein contrôle de leur environnement;
  • créer des paquets de logiciels scientifiques et les déployer sur des grappes différentes de même architecture.

Singularity permet la virtualisation du système d’exploitation sous la forme de conteneurs.

À la différence d’une instance (machine virtuelle), un conteneur

  • exige possiblement moins de ressources;
  • peut seulement exécuter des programmes conçus pour le même noyau (ici Linux) avec une même architecture matérielle.

Une instance peut exécuter plus d’un système d’exploitation et peut quelquefois servir à exécuter des programmes conçus pour des architectures CPU différentes.

Les conteneurs font usage des fonctionnalités Linux

  • cgroups pour limiter, contrôler et isoler l’utilisation des ressources (par exemple la mémoire vive, les disques I/O, l’accès au CPU);
  • kernel namespaces pour virtualiser et isoler les ressources du système d’exploitation d’un groupe de processus (par exemple les processus et les identifiants d’utilisateurs, les systèmes de fichiers, l’accès au réseau);
  • systèmes de fichiers Overlay pour donner l’apparence d’opérations d’écriture dans des systèmes de fichiers à lecture seule.

Contrairement à d’autres solutions de conteneurs comme Docker[2], Singularity permet d’utiliser les conteneurs de façon sécuritaire, particulièrement avec les grappes de calcul multiutilisateur.[3]

Disponibilité

Singularity est disponible sur nos grappes.

Si vous voulez utiliser Singularity sur votre propre ordinateur, consultez la documentation d’installation [4]. Vous devriez disposer d’une distribution Linux relativement récente (noyau de v3 10.0 ou plus).

Utiliser Singularity sur nos grappes

Charger un module

Chargez d’abord le module que vous voulez utiliser, par exemple 

$ module load singularity/2.5

Voyez les modules disponibles avec 

$ module spider singularity

Créer des images

Avant d’utiliser Singularity, vous devez créer une image (un conteneur). Cette image est soit un fichier, soit un répertoire dans lequel Linux est installé. Pour créer une image, utilisez la commande singularity build, soit

  • singularity build WHAT-TO-WRITE SPECIAL-URI-OR-PATH

où WHAT-TO-WRITE peut être

  • le nom du fichier de l'image Singularity (*.sif) où l'image construite sera écrite
  • un répertoire si vous construisez un bac à sable avec l'option --sandbox, généralement sur votre propre ordinateur Linux (avec un compte d'accès root)

et SPECIAL-URI-OR-PATH peut être

  • une adresse URI commençant par library:// pour construire à partir d'une bibliothèque de conteneurs,
  • une adresse URI commençant par docker:// pour construire à partir de Docker Hub,
  • une adresse URI commençant par shub:// pour construire à partir de Singularity Hub,
  • un chemin vers un conteneur existant,
  • un chemin vers un répertoire pour construire à partir d'un bac à sable,
  • un chemin vers un fichier de l'image Singularity (qui est une recette pour construire l'image).

Avertissement

Il est fortement recommandé de créer les images Singularity sur un ordinateur ou dans une instance

  • dont le système d'exploitation est Linux,
  • où Singularity est installé,
  • avec un accès à l'internet,
  • de préférence où vous êtes utilisateur racine (root), soit avec les permissions sudo.

Sans permissions sudo, sachez que toutes les permissions (de l'utilisateur et du groupe) pour l'image que vous créez deviendront celles définies pour le compte à partir duquel l'image a été créée. De façon générale, il est difficile de revenir aux permissions qu'il faut et donc, dépendant du contenu de l'image, il pourrait être impossible de la mettre à jour par la suite.

Par exemple, les commandes pour les images Debian et Ubuntu dpkg, apt-get et apt exigent les permissions root pour installer et mettre à jour des paquets. Si vous prévoyez devoir éventuellement installer ou mettre à jour des logiciels, créez votre image dans un système Linux où vous avez les permissions root.

Remarque : les images créées sur votre ordinateur personnel doivent être téléchargées sur la grappe pour que vous puissiez les utiliser.

Erreur de build avec une distribution Linux

Avec certaines distributions, vous pourriez recevoir cette erreur même si la mémoire est suffisante. 

$ WARNING: 'nodev' mount option set on /tmp, it could be a source of failure during build process
$FATAL: no memory left on device

Plusieurs distributions Linux récentes utilisent un système de fichiers en mémoire, ce qui pourrait limiter la taille d'un conteneur que vous voudriez construire. Pour plus d'information, voir la documentation Singularity.

Si c'est le cas, vous pouvez résoudre le problème en configurant la variable d'environnement SINGULARITY_TMPDIR pour qu'elle pointe vers un fichier du système de fichiers. 

$ SINGULARITY_TMPDIR="disk/location" singularity build IMAGE_NAME.sif docker://DOCKER-IMAGE-NAME

Créer une image sur une de nos grappes

Puisqu'il vous est impossible d'avoir les permissions sudo sur nos grappes, prenez connaissance de l'avertissement au paragraphe précédent. Les images peuvent être créées sur toutes nos grappes et sur les ordinateurs pour la visualisation (gra-vdi.computecanada.ca en date de février 2020). Veuillez tenir compte des particularités suivantes :

  • sur beluga.computecanada.ca, connectez-vous avec SSH et utilisez un nœud de connexion pour créer vos images;
  • sur cedar.computecanada.ca, connectez-vous avec SSH et créez vos images avec une tâche interactive; n'utilisez pas un nœud de connexion;
  • sur graham.computecanada.ca, connectez-vous avec SSH et utilisez un nœud de connexion pour créer vos images;
  • sur gra-vdi.computecanada.ca, connectez-vous avec VNC et utilisez une fenêtre de terminal pour créer vos images;
  • sur niagara.computecanada.ca, connectez-vous avec SSH et utilisez un nœud de connexion pour créer vos images;
    • IMPORTANT : Ne créez pas de lien avec /localscratch qui n'existe pas sur Niagara.

L'option à privilégier est d'utiliser gra-vdi.computecanada.ca. Dans les autres cas, nous observons les difficultés suivantes :

  • beluga, graham et niagara
    • il y a un maximum de mémoire RAM pouvant être utilisé avec les nœuds de connexion et
    • pas d'accès à l'internet avec les nœuds de calcul.
  • cedar:
    • les nœuds de connexion ne peuvent pas être utilisés et
    • comme il est très difficile de prévoir combien de mémoire RAM est nécessaire avec les nœuds de calcul, une erreur pourrait survenir; si c'est le cas, quittez la tâche interactive et essayez de nouveau avec plus de mémoire.

Créer une image avec DockerHub et Dockerfile

Le site Docker offre une interface de recherche pour identifier des images et exige parfois une authentification pour télécharger des images. Si vous obtenez des erreurs comme

  • requested access to the resource is denied
  • unauthorized: authentication required

il est possible que

  • votre URL Docker URL est incorrect et/ou
    • Remarque : pour vérifier l'URL, utilisez Docker Hub et cherchez l'image que vous voulez.
  • vous devez vous authentifier avec Docker pour télécharger l'image.
    • par exemple, il faut ajouter --docker-login après les commandes build ou pull.

Si par exemple l’URL du conteneur est docker://ubuntu, téléchargez le conteneur avec 

$ singularity build myubuntuimage.sif docker://ubuntu

Cette commande fonctionne sur un nœud de calcul de Cedar, mais pas avec Béluga ou Graham parce que leurs nœuds de calcul n'ont pas d'accès à l'internet. Nous ne recommandons pas de construire de grandes images Singularity sur les nœuds de connexion parce que ceci affecterait les autres utilisateurs et échouerait probablement en raison de l'utilisation intensive des CPU et de la mémoire vive. Les directives suivantes peuvent résoudre le problème.

  1. Téléchargez une image Docker sans la convertir à Singularity. Pour ce faire, vous pouvez utiliser l'outil download-frozen-image du projet moby. Ceci utilise peu de ressources de calcul et peut se faire sur un nœud de copie ou un nœud de connexion.
  2. Convertissez l'image Docker que vous avez téléchargée en une image Singularity. Ceci utilise beaucoup de ressources de calcul et devrait se faire sur un nœud de calcul et avec une allocation de mémoire et de CPU convenable.

En exemple, nous allons télécharger une image Singularity pour le paquet GQCP.

Sur un nœud de copie ou un nœud de connexion, téléchargez l'image Docker. 

$ cd ~/scratch
$ wget https://raw.githubusercontent.com/moby/moby/master/contrib/download-frozen-image-v2.sh
$ sh download-frozen-image-v2.sh gqcp gqcg/gqcp:latest
$ cd gqcp && tar cf ../gqcp.tar * && cd ..

Lancez une tâche interactive. 

$ cd ~/scratch
$ salloc --mem-per-cpu=2000 --cpus-per-task=4 --time=2:0:0

Sur le nœud de calcul alloué, construisez l'image Singularity. 

$ module load singularity
$ singularity build gqcp.sif docker-archive://gqcp.tar

Vous pouvez aussi utiliser un Dockerfile pour créer une image Singularity.

  • Créez d'abord une image Docker avec un document Dockerfile dans une instance ou sur votre machine Linux où vous avez les permissions sudo. Dans le répertoire où se trouve le Dockerfile, lancez la commande sudo docker build -t CC:latest .; le paramètre . demande à Docker de chercher le Dockerfile dans le répertoire courant. La commande crée une image Docker nommée CC et lui assigne une balise ayant la valeur latest; Docker assigne cette valeur par défaut à une image et même si vous n'utilisez pas cette balise, sa valeur par défaut sera latest.
  • La seconde étape est d'utiliser l'image Docker que nous avons créée ci-dessus comme source pour Singularity. Dans cet exemple, l'image Singularity cc_image_latest.sif est créée à partir de l'image Docker CC:latest.
    sudo singularity build cc_image_latest.sif docker-daemon://CC:latest

Il n'est pas nécessaire de spécifier le chemin pour l'image Docker puisque le démon Docker va automatiquement chercher l'image dans le registre Docker, mais il faut s'assurer d'utiliser le bon nom d'image et la bonne valeur pour la balise.

Créer une image personnalisée avec l'indicateur sandbox

L'indicateur sandbox vous permet de créer un conteneur à l'intérieur d'un répertoire où l'écriture est permise, ce qui permet de facilement modifier les conteneurs existants. 

$ singularity build --sandbox IMAGE_NAME/ docker://DOCKER-IMAGE-NAME

L'indicateur --writable permet d'apporter des changements dans le conteneur. 

$ singularity shell --writable IMAGE_NAME/

Le répertoire servant de bac à sable peut être converti en un fichier sif avec la commande build comme suit 

$ singularity build production.sif IMAGE_NAME/

Utiliser la commande sudo

Dans la documentation de Singularity sur comment construire un conteneur, on utilise la commande sudo parce que la commande build requiert souvent les permissions root de l’utilisateur racine (superutilisateur). Comme nos utilisateurs n’ont pas ce niveau de permissions, la commande sudo ne peut pas être utilisée. Vous n’avez généralement pas besoin d’un accès sudo si vous construisez une image préconstruite à partir de Singularity ou de Docker Hub. Si vous avez besoin des privilèges root pour construire une image, vous pouvez demander l’intervention du soutien technique ou encore installer Linux et Singularity sur votre propre ordinateur.

Il est fort possible que vous n’ayez pas besoin d’utiliser la commande sudo avec votre image. Voici ce qui se produira si elle n’est pas utilisée :

  • Singularity émettra un avertissement indiquant que l’image créée ne fonctionnera pas; il ne s’agit toutefois que d’un avertissement et l’image sera quand même créée.
  • Toutes les permissions pour le système de fichiers seront réduites aux permissions de l’utilisateur et du groupe Linux qui exécute singularity build, habituellement l’utilisateur et le groupe qui ont servi à la connexion.

Habituellement, vous n’avez pas à vous soucier de conserver les permissions à moins que

  • vous ayez à régulièrement mettre à jour et reconfigurer le contenu de l’image et
  • que les outils pour mettre à jour et reconfigurer le contenu de l’image exigent que les permissions ne soient pas modifiées.

Il est facile de mettre à jour ou d’installer de nouveaux logiciels avec plusieurs distributions Linux à l’aide de commandes comme

  • apt-get update && apt-get upgrade
  • apt-get install some-software-package
  • yum install some-software-package
  • dnf install some-software-package
  • etc.

Il est possible que ces commandes et d’autres ne s’exécutent correctement que si les permissions des systèmes de fichiers sont conservées.

La création d’une image pourrait ne pas se faire en raison de certaines restrictions du nœud avec lequel vous travaillez; en particulier, c’est le cas des nœuds de connexion. Si vous avez besoin d’assistance pour créer une image Singularity, contactez le soutien technique.

Utiliser Singularity

NOTE : Nous abordons ici l’utilisation de Singularity sans tenir compte de Slurm qui fait l’ordonnancement des tâches interactives ou en lots; pour des renseignements à ce sujet, consultez Exécuter des tâches.

Sauf quand vous créez votre image Singularity, vous ne pouvez pas utiliser la commande sudo pour exécuter des applications dans votre image. Il y a différentes façons d’exécuter ces applications :

  1. exécuter les commandes interactivement dans une session Singularity;
  2. exécuter une commande unique qui s’arrête lorsqu’elle est complétée;
  3. exécuter une instance conteneur pour exécuter des démons.

Exécuter les commandes interactivement

Pour des renseignements sur l’utilisation de la commande pour l’interpréteur Singularity, utilisez 

$ singularity shell --help

Dans l’exemple suivant avec le conteneur myimage.simg, 

$ singularity shell -B /home -B /project -B /scratch -B /localscratch myimage.simg

le résultat serait de

  • faire un bind mount de /home pour que tous les répertoires home soient accessibles (dépendant des permissions associées à votre compte);
  • faire un bind mount de /project pour que tous les répertoires project soient accessibles (dépendant des permissions associées à votre compte);
  • faire un bind mount de /scratch pour que le répertoire scratch soit accessible (dépendant des permissions associées à votre compte);
  • faire un bind mount de /localscratch pour que le répertoire localscratch soit accessible (dépendant des permissions associées à votre compte);
  • exécuter un interpréteur (par exemple /bin/bash)

Si cette commande réussit, vous pourrez exécuter des commandes interactivement à partir de votre conteneur en ayant accès à vos fichiers dans home, project, scratch et localscratch.

NOTE : Lorsque vous avez terminé, entrez exit.

Dans certains cas, vous ne voudrez pas que les variables d'environnement soient polluées par l’interpréteur; utilisez donc un environnement propre en ajoutant l’option -e comme suit 

$ singularity shell -e -B /home -B /project -B /scratch -B /localscratch myimage.simg

Sachez toutefois que vous devrez peut-être définir certaines variables de l’environnement de l’interpréteur, par exemple $USER.

Enfin, si vous utilisez Singularity interactivement sur votre propre ordinateur, vous devez vous assurer de satisfaire les conditions suivantes pour que les modifications apportées à l’image soient enregistrées sur le disque :

  • utiliser une image sandbox Singularity (c’est-à-dire utiliser un répertoire et non le fichier en lecture seule .simg)
  • utiliser l'option -w et
  • utiliser sudo.

Par exemple, créez d’abord votre image sandbox avec 

$ sudo singularity build -s myimage-dir myimage.simg

puis communiquez interactivement avec Singularity. 

$ sudo singularity shell -w myimage-dir

Lorsque vous avez terminé, créez ou mettez à jour le fichier simg avec 

$ sudo singularity build myimage-new.simg myimage-dir/

et téléversez myimage-new.simg sur une grappe pour pouvoir l’utiliser.

Exécuter une commande unique

Pour soumettre une tâche qui fait appel à des commandes dans un conteneur Singularity, il faut utiliser les commandes Singularity exec ou run.

  • la commande exec ne nécessite aucune configuration
  • avec la commande run, il faut configurer une application à l’intérieur d’un fichier de recette Singularity; ce sujet n’est pas abordé ici.

Les options pour la commande exec sont presque identiques à celles de la commande shell, par exemple 

$ singularity exec --help

Lorsqu’il ne s’agit pas d’une demande d’assistance, exec exécute la commande spécifiée dans le conteneur et quitte ensuite le conteneur, par exemple 

$ singularity exec -B /home -B /project -B /scratch -B /localscratch myimage.simg ls /

qui retourne le contenu du répertoire racine dans le conteneur. Notez que la version de ls est celle qui est installée dans le conteneur; si par exemple gcc de GCC était installé dans le conteneur myimage.simg, la commande suivante 

$ singularity exec -B /home -B /project -B /scratch -B /localscratch myimage.simg gcc -v

retournerait les renseignements sur la version de ce qui est installé dans le conteneur, alors qu’à l’invite de l’interpréteur usuel, 

$ gcc -v

retournerait la version de GCC chargée à ce moment sur la grappe.


Pour exécuter une commande unique de l’intérieur de votre conteneur Singularity, la commande exec est suffisante. N’oubliez pas de faire un bind mount des répertoires dont vous aurez besoin pour que votre tâche soit bien exécutée.

Singularity accepte aussi les variables d'environnement définies par l'utilisateur avec l'indicateur --env-file. En argument, nous passons à cet indicateur le chemin du fichier dans lequel sont définies les variables à utiliser dans le contexte Singularity. L'indicateur --env-file est particulièrement utile dans les cas où nous voulons utilliser l'indicateur -e avec singularity exec pour obliger un environnement propre.

Par exemple, pour utiliser la variable d'environnement PYSPARK_SUBMIT_ARGS dans le contexte Singularity, il faut créer un fichier (ici envfile) dans lequel la variable PYSPARK_SUBMIT_ARGS est définie. Il est possible de définir plusieurs variables dans le même fichier. 

PYSPARK_SUBMIT_ARGS='--driver-memory 96g  --driver-java-options "-verbose:gc  -XX:+UseSerialGC  -XX:-UseGCOverheadLimit" pyspark-shell'

Nous passons ensuite le chemin du fichier à la commande Singularity avec l'indicateur --env-file. 

$ singularity exec --env-file envfile  myimage.simg gcc -v

Dans l'exemple ci-dessus, nous supposons que envfile se trouve au même endroit où la commande Singularity a été exécutée; c'est pourquoi nous avons passé uniquement le nom du ficher plutôt que le chemin vers ce fichier.


Exécuter des instances de conteneurs

Pour exécuter des démons et des processus en arrière-plan dans un conteneur, n’utilisez pas la commande exec, mais plutôt les commandes Singularity instance.start et instance.stop pour créer et supprimer les sessions (les instances de conteneurs). En utilisant des sessions, Singularity s’assure que vos applications exécutées dans l’instance sont terminées quand la tâche se termine, peu importe la raison.

Pour démarrer une instance de session, lancez la commande instance.start suivie du nom de l’image (ici myimage.simg) et du nom de la session (ici quadrat5run). 

$ singularity instance.start myimage.simg quadrat5run

La commande instance.stop met fin à la session et à toutes les applications qui y sont associées. 

$ singularity instance.stop myimage.simg quadrat5run

En tout temps, vous pouvez voir la liste des sessions en cours avec 

$ singularity instance.list

qui fournit le nom du démon, son PID et le chemin pour l’image du conteneur.

Lorsqu’une session est en cours, les applications peuvent être exécutées avec les commandes Singularity shell, exec ou run en indiquant le nom de l’image suivi du préfixe instance:// accolé au nom de la session. 

$ singularity instance.start mysessionname
$ singularity exec myimage.simg instance://mysessionname ps -eaf
$ singularity shell myimage.simg instance://mysessionname 
nohup find / -type d >dump.txt
exit
$ singularity exec myimage.simg instance://mysessionname ps -eaf
$ singularity instance.stop mysessionname

Bind mount

Par défaut, une application exécutée dans un conteneur Singularity ne voit que les fichiers dans l’image du conteneur et ceux dans le répertoire courant. Les tâches Singularity doivent donc faire le bind mount des systèmes de fichiers dans lesquels se trouvent les fichiers avec l’option -B aux commandes shell, exec ou run. 

$ singularity shell -B /home -B /project -B /scratch -B /localscratch myimage.simg

$ singularity exec -B /home -B /project -B /scratch -B /localscratch myimage.simg ls /

$ singularity run -B /home -B /project -B /scratch -B /localscratch:/temp myimage.simg some-program

Ces commandes font un bind mount des systèmes de fichiers de l’image de conteneur myimage.simg  :

  • /home pour que tous les répertoires home soient accessibles (dépendant des permissions associées à votre compte);
  • /project pour que tous les répertoires project soient accessibles (dépendant des permissions associées à votre compte);
  • /scratch pour que le répertoire scratch soit accessible (dépendant des permissions associées à votre compte);
  • /localscratch pour que le répertoire localscratch soit accessible (dépendant des permissions associées à votre compte).

Dans le dernier énoncé, nous voyons comment modifier le nom du mount qui est visible dans le conteneur Singularity pour que /localscratch soit vu comme étant /temp dans le conteneur. Ceci peut être utile quand vous voulez utiliser un espace de stockage comme $SLURM_TMPDIR qui est directement attaché au nœud de calcul et qui est disponible dans une tâche. Le programme peut lui-même faire abstraction des détails en utilisant toujours /temp.

Dans la plupart des cas, il n’est pas recommandé de monter directement chacun des répertoires pour éviter des problèmes d’accès; montez plutôt le répertoire racine du système de fichiers, tel que décrit plus haut.

Problèmes connus pour le CHP

Applications MPI dans un conteneur

Si vous utilisez des applications MPI, rien de particulier ne doit être fait pour les tâches utilisant un seul nœud.

Pour utiliser plusieurs nœuds, vous devez :

  • vous assurer que votre application MPI est compilée avec la version OpenMPI qui est installée dans votre conteneur Singularity;
    • idéalement, cette version OpenMPI est 3 ou 4; la version 2 pourrait ou non fonctionner; la version 1 ne fonctionnera pas;
  • vous assurer que MPI dans le conteneur peut utiliser la même bibliothèque pour l'interface de gestion des processus que celle de la version MPI sur la grappe, par exemple PMI-2 ou PMIx;
  • vous assurer que le script de votre tâche Slurm utilise srun pour exécuter l'application MPI et que srun utilise une bibliothèque pmi qui est supportée par l'implémentation MPI dans le conteneur; n'utilisez pas mpirun ou mpiexec, par exemple
srun --mpi=pmi2 singularity exec /path/to/your/singularity/image.sif /path/to/your-program

MPI dans le conteneur ne supporte que PMI-2 (utilisez --mpi=pmix pour PMIx);

  • vous assurer que le script de votre tâche ne contient aucune commande pour charger un module;
  • installer dans votre conteneur le paquet slurm-client de votre distribution pour pouvoir interagir avec l'ordonnanceur Slurm;
  • avant de soumettre la tâche avec sbatch, dans l'interpréteur (shell) CC, chargez les modules suivants :
    • singularity
    • openmpi (il n'est pas nécessaire que la version corresponde à la version de OpenMPI dans le conteneur; idéalement, utilisez les versions 3 ou 4; la version 2 pourrait ou non fonctionner; la version 1 ne fonctionnera pas).

Enfin, assurez-vous qu'un paquet de réseautique haute performance soit installé dans votre image :

  • installez libpsm2 si le superordinateur utilise OmniPath,
  • installez UCX si le superordinateur utilise Infiniband.

Pour connaître les bibliothèques qui ont servi à la configuration de MPI sur la grappe, utilisez

  • ompi_info --config pour OpenMPI
  • mpiexec -info pour MPICH

Ces commandes indiquent les bibliothèques que vous utiliser pour installer MPI dans le conteneur Singularity.

Utiliser CUDA sur une grappe

Si vous utilisez des programmes qui utilisent la bibliothèque CUDA, assurez-vous que CUDA est installé dans votre conteneur Singularity.

Pour que CUDA fonctionne, il faut ajouter l'indicateur --nv. 

$ srun singularity run --nv container-name.sif [job to do]

Changer les répertoires Singularity par défaut

Vous pouvez changer le répertoire temporaire et le répertoire de mise en cache en définissant ces variables d'environnement avant de lancer Singularity :

  • SINGULARITY_CACHEDIR : répertoire pour l’écriture des fichiers temporaires, incluant ceux créés à la construction de fichiers image SquashFS,
  • SINGULARITY_TMPDIR : répertoire pour le téléchargement et la mise en cache des fichiers.

Dans cet exemple, on demande à Singularity d’utiliser l’espace /scratch pour les fichiers temporaires et la mise en cache. 

$ mkdir -p /scratch/$USER/singularity/{cache,tmp}
$ export SINGULARITY_CACHEDIR="/scratch/$USER/singularity/cache"
$ export SINGULARITY_TMPDIR="/scratch/$USER/singularity/tmp"

Ces commandes doivent être exécutées avant de lancer Singularity.

Voir aussi

Présentation faite par Paul Preney le 14 février 2018 ː

Références

  1. ↑ Site web Singularity, https://www.sylabs.io/docs/
  2. ↑ Site web Docker, https://www.docker.com/
  3. ↑ Documentation de sécurité Singularity, https://www.sylabs.io/guides/2.5.1/admin-guide/security.html
  4. ↑ Documentation d'installation Singularity, https://www.sylabs.io/docs/

GNU Compiler Collection, an open source compiler collection

Message Passing Interface

Retrieved from "https://docs.alliancecan.ca/mediawiki/index.php?title=Singularity/fr&oldid=136682"