Commit 5bd001da authored by remy's avatar remy
Browse files

update to adoc txt files

parent 75e1c834
# TP : Calculer avec singularity
Martin Souchal
* Présenté pour la premiere fois aux JDEV 2017
* Prséenté à l'APC en janvier 2018 pour la journée conteneurs.
* Présenté à l'APC en janvier 2018 pour la journée conteneurs.
## Présentation
prez/prez.html
......@@ -9,7 +9,7 @@ prez/prez.html
## TP : créer un conteneur singularity
Générer le TP :
```bash
asciidoctor -d book -a toc singularity.txt
asciidoctor -d book -a toc singularity.adoc
```
mpi-ping.c : code MPI pour le TP.
......
= LXD pour le calcul
:icons: font
Alexandre Dehne Garcia <alexandre.dehne-garcia@inra.fr>
Utilisation de LXD version 2.14, disponible ici : https://linuxcontainers.org/ [LXD Website].
TIP: Les fichiers utilisés dans le document sont disponibles dans le dépot git suivant : https://gitlab.in2p3.fr/souchal/tp-singularity
Dans ce TP nous allons installer des conteneurs Ubuntu 17.04 (Zesty Zapus) et CentOS 7. Ce TP a été prépéparé de telle sorte qu'il soit jouable sur n'importe quel serveur ou machine virtuelle avec un linux récent et un LXD récent (préférer une Ubuntu 17.04). Nul besoin de cluster ou de grosse infra.
Les conteneurs LXC sont habituellement utilisés comme des conteneurs machines (cf présentation). Contrairement aux autres technologies de conteneurs qui ont souvent une niche d'application, LXC est très versatile. Il sait quasiment tout faire mais parfois/souvent en moins bien. C'est le revers de la médaille.
Les conteneurs machines HPC n'ont pas forcément d'intéret dans une TP de 1h30. Nous allons donc nous servir d'LXD pour faire tourner un code MPI sur des machines qui n'ont pas de MPI installé.
IMPORTANT: Ce TP à été rédigé pour Linux exclusivement. Aucune partie du TP ne nécessite les droits administrateurs !
:toc: right
:chapter: first
Comment générer cette doc au foramt html :
[source]
asciidoctor -d book -a toc singularity.txt
== Se familariser avec les dépôts d'images
Pour le TP LXD, on part du principe que LXD est installé et configuré par votre gentil adminsys. Puisque LXC/LXD est par conception bien sécurisé et qu'il est possible de le brider à convenance, tous les adminsys honnètes vous l'installeront sans rechinier. Après installation, l'initialisation de LXD se fait via cette commande :
[source]
lxd init
Nous la verrons par la pratique plus tard dans le TP.
LXD se basse sur des images pré-configurées par les mainteneurs des différents linux. Ces images sont signées et sûres.
Pour connaitres les dépôts déjà configurés, tapez :
[source]
lxc remote list
----
+--------------------+------------------------------------------+---------------+--------+----------+
| NOM | URL | PROTOCOLE | PUBLIC | STATIQUE |
+--------------------+------------------------------------------+---------------+--------+----------+
| images | https://images.linuxcontainers.org | simplestreams | OUI | NON |
+--------------------+------------------------------------------+---------------+--------+----------+
| local (par défaut) | unix:// | lxd | NON | OUI |
+--------------------+------------------------------------------+---------------+--------+----------+
| ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | OUI | OUI |
+--------------------+------------------------------------------+---------------+--------+----------+
| ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | OUI | OUI |
+--------------------+------------------------------------------+---------------+--------+----------+
----
* Le dépôt image contient une foule de linux et pour chacun de nombreuses versions.
* Le dépôt local, comme son nom l'indique, correspond au dépôt d'images appartenant au LXD local (ici, c'est le dépôt utilisé par défaut par LXD).
* Le dépôt ubuntu et unbuntu-daily sont des images ubuntu destinées au cloud. Elles viennent donc avec LXD installé par défaut.
Vous pouvez lister les images contenues dans un dépôt à l'aide de cette commande :
[source]
lxc image list ubuntu:
lxc image list images:
:chapter: two
== Démarrer son premier conteneur
Pour créer un premier conteneur d'ubuntu 17.04 nommé <votre login> (ici login=t0), il suffit de taper :
[source]
lxc init ubuntu:17.10 t0
On peut ensuite vérifer la liste des containers locaux avec la commande :
[source]
lxc list
Il suffit maintenant de démarrer le conteneur t0 :
[source]
lxc start t0
lxc list
On peut aussi démarrer et créer un conteneur, centos7 cette fois-ci et nommé <login>cos7, en une seule commande :
[source]
lxc launch images:centos/7 t0cos7
lxc list
Vous remarquerez que si on regarde les images contenues dans le dépôt local on a les images ubuntu 17.04 et Centos 7.
[source]
lxc image list local:
Par défaut tout est local dans LXD (configuration au moment du "lxd init"), on peut donc aussi écrire :
[source]
lxc image list
Les images locales ont été mise en cache par LXD afin d'éviter de les télécharger à chaque création de conteneur. Ce mecanisme de cache a été décidé à l'initialisation de LXD (LXD init) et peut être désactivé à tout moment. On pourrait aussi effacer une image du cache grâce à son empreinte (à éviter dans le cadre du TP):
[source]
lxc image delete 7a7ff654cbd8
Finalement, on ne travaillera pas sous Centos. On va donc détruire le conteneur <login>coq7:
[source]
lxd delete t0cos7
:chapter: three
== Faire tourner une code MPI sur une serveur qui n'a pas MPI
==== installer MPI dans le conteneur
Il y a deux manières de lancer une commande sur un conteneur en marche
* ouvrir un shell via la commande "shell" de lxc et taper vos insrtuctions :
[source]
lxc shell t0
apt update
exit
* demander à lxc de le faire pour vous via la commande exec:
[source]
lxc exec -- apt install cmake gfortran openmpi-common openmpi-bin libopenmpi-dev
==== Compiler et lancer le programme MPI dans un seul conteneur
2 choix sont possibles :
* faire apparaitre le file système de la machine hôte par montage (comme on le ferait sous docker).
* transférer les sources dans le conteneur. Afin de voir d'autres fonctionnalités de LXC, c'est cette dernière solution qui est choisie via le push/pull de la commande "file" de lxc.
[source]
lxc file push mpi-ping.c t0/root/
lxc exec t0 -- mpicc mpi-ping.c -o ./mpi-ping
lxc exec t0 -- mpirun -np 20 --allow-run-as-root --mca btl ^openib ./mpi-ping
On peut aussi sauver l'output dans un fichier directement dans le contenur et le rappatrier par la suite :
[source ]
lxc exec t0 -- sh -c "mpirun -np 20 --allow-run-as-root --mca btl ^openib ./mpi-ping > mpi-ping.out"
lxc file pull t0/root/mpi-ping.out ./
Enfin, on peut mettre le binaire mpi-ping dans le path du conteneur :
[source]
lxc exec t0 -- cp mpi-ping /usr/bin/
=== Faire tourner un code MPI sur plusieurs conteneurs
Pour cette étape nous allons simuler 3 noeuds de calcul (node1, node2 et node3) et un noeud maître t0 (<login> pour vous). Et comme on est joueur, les noeuds de calcul vont tourner à l'intérieur du noeud maître. C'est ce qu'on appelle des conteneurs imbriqués ou nested conteners. LXC est fait pour ça. Dans notre cas on aura même un nested LXD car t0 est géré par LXD et à l'intérieur de t0 un autre LXD gérera les noeuds de calcul. LXD est aussi fait pour faire tourner des LXD imbriqués.
C'est parti !
==== Configurer le noeud maitre et lui permettre d'acceuillir les noeuds de calcul
Tout d'abord il faut autoriser t0 à accepter l'imbrication de conteneurs en devenant lui même hôte. On se rend compte que LXC/LXD est totalement configurable. Il est possible de brider toutes les fonctionnalités en fonction des besoins et de la sécurité attentue.
[source]
lxc config set t0 security.nesting true
(on aurait aussi pu rajouter l'option "-c security.nesting=true" au moment du launch ou de l'init de t0)
TIP: toutes les options sont ajustables suivant la syntaxe "set" : lxc config set <CONTAINER> <KEY> <VALUE>. Et pour connaitre la valeur d'une option, il suffit de faire un "get" : lxc config get <CONTAINER> <KEY>
Et maintenant, il suffit de configuer le LXD qui tourne dans t0 :
[source]
lxc exec t0 -- lxd init
Toujours choisir "yes" ou les options par défaut :
----
Do you want to configure a new storage pool (yes/no) [default=yes]? yes
Name of the new storage pool [default=default]: default
Name of the storage backend to use (dir, btrfs) [default=dir]: dir
We detected that you are running inside an unprivileged container.
This means that unless you manually configured your host otherwise,
you will not have enough uid and gid to allocate to your containers.
LXD can re-use your container's own allocation to avoid the problem.
Doing so makes your nested containers slightly less safe as they could
in theory attack their parent container and gain more privileges than
they otherwise would.
Would you like to have your containers share their parent's allocation (yes/no) [default=yes]? yes
Would you like LXD to be available over the network (yes/no) [default=no]? yes
Address to bind LXD to (not including port) [default=all]: all
Port to bind LXD to [default=8443]: 8443
Trust password for new clients: jdev
Again: jdev
Would you like stale cached images to be updated automatically (yes/no) [default=yes]? yes
Would you like to create a new network bridge (yes/no) [default=yes]? yes
What should the new bridge be called [default=lxdbr0]? lxdbr0
What IPv4 address should be used (CIDR subnet notation, “auto” or “none”) [default=auto]? auto
What IPv6 address should be used (CIDR subnet notation, “auto” or “none”) [default=auto]? auto
LXD has been successfully configured.
----
==== configurer les noeuds de calcul
===== node1
On démarre node1 dans t0 et on le configure pour MPI comme précédement pour t0
[source]
lxc exec t0 -- lxc list
lxc exec t0 -- lxc launch ubuntu:17.04 node1
lxc exec t0 -- lxc exec node1 -- apt update
lxc exec t0 -- lxc exec node1 -- apt install cmake gfortran openmpi-common openmpi-bin libopenmpi-dev
lxc exec t0 -- lxc file push mpi-ping node1/usr/bin/
lxc exec t0 -- lxc exec node1 -- mpirun -np 20 --allow-run-as-root --mca btl ^openib /usr/bin//mpi-ping
Puis on copie node1 pour créer node2 et node3 :
[source]
lxc exec t0 -- lxc copy node1 node2
lxc exec t0 -- lxc copy node1 node3
lxc exec t0 -- lxc list
lxc exec t0 -- lxc start node2
lxc exec t0 -- lxc start node3
lxc exec t0 -- lxc list
lxc exec t0 -- lxc exec node2 -- mpirun -np 20 --allow-run-as-root --mca btl ^openib /usr/bin//mpi-ping
Enfin, on permet la connexion sans mot de passe :
[source]
lxc exec t0 -- ssh-keygen -t rsa -b 4096 -C "t0Master"
lxc exec t0 -- lxc file push /root/.ssh/id_rsa.pub node1/root/.ssh/authorized_keys
lxc exec t0 -- lxc file push /root/.ssh/id_rsa.pub node2/root/.ssh/authorized_keys
lxc exec t0 -- lxc file push /root/.ssh/id_rsa.pub node3/root/.ssh/authorized_keys
[source]
lxc exec t0 -- ssh node1
exit
lxc exec t0 -- ssh node2
exit
lxc exec t0 -- ssh node3
exit
==== lancer le job MPI sur les noeuds
Il aurait été préférable d'installer un scheduler mais le temps imparti au TP ne le permet pas. On va donc indiquer manuellement les noeuds de calcul à mpirun.
Déterminer les IP des noeuds de calcul :
[source]
lxc exec t0 -- lxc list | grep node | awk 'BEGIN {ORS=","};{print $6}'
[source]
lxc exec t0 -- mpirun -np 12 --allow-run-as-root --mca btl ^openib --host 10.46.85.64,10.46.85.174,10.46.85.60, mpi-ping
[source]
lxc exec t0 -- mpirun -np 3 --allow-run-as-root --mca btl ^openib --host 10.46.85.64,10.46.85.174,10.46.85.60, mpi-ping
[source]
lxc exec t0 -- lxc config set node1 limits.cpu 4
lxc exec t0 -- lxc config set node2 limits.cpu 4
lxc exec t0 -- lxc config set node3 limits.cpu 4
[source]
lxc exec t0 -- mpirun -np 12 --allow-run-as-root --mca btl ^openib --host 10.46.85.64:4,10.46.85.174:4,10.46.85.60:4 mpi-ping
Et voilà, on aurait aussi pu installer un cluster dans un cluster grâce à LXD : une autre vision du BYOE...
\ No newline at end of file
= Créer un conteneur avec Singularity
:icons: font
Martin Souchal <souchal@apc.in2p3.fr>
Utilisation de singularity version 2.4, disponible ici : http://singularity.lbl.gov[Singularity Website].
TIP: Les fichiers utilisés dans le document sont disponibles dans le dépot git suivant : https://gitlab.in2p3.fr/souchal/tp-singularity
Pour récupérer les fichiers vous pouvez cloner le dépot git :
[source, bash]
git clone https://gitlab.in2p3.fr/souchal/tp-singularity.git
Dans ce TP nous allons installer un conteneur Ubuntu sur une machine CentOS 7. Il est possible d'adapter ce TP sur n'importe quelle autre OS Linux récent, il faudra remplacer yum install par le gestionnaire de paquet de la distribution hôte.
IMPORTANT: Ce TP à été rédigé pour Linux exclusivement. Une partie du TP nécessite les droits administrateurs (sudo)
:toc: right
:chapter: first
== Mon premier conteneur
* Installation de singularity
* Création du conteneur
* Travailler dans le conteneur
=== Installation de singularity
[source, bash]
git clone https://github.com/singularityware/singularity.git
cd singularity
./autogen.sh
./configure --prefix=/usr/local --sysconfdir=/etc
make
sudo make install
L'aide de singularity est accessible via la commande suivante :
----
singularity help
USAGE: singularity [global options...] <command> [command options...] ...
GLOBAL OPTIONS:
-d|--debug Print debugging information
-h|--help Display usage summary
-s|--silent Only print errors
-q|--quiet Suppress all normal output
--version Show application version
-v|--verbose Increase verbosity +1
-x|--sh-debug Print shell wrapper debugging information
GENERAL COMMANDS:
help Show additional help for a command or container
selftest Run some self tests for singularity install
CONTAINER USAGE COMMANDS:
exec Execute a command within container
run Launch a runscript within container
shell Run a Bourne shell within container
test Launch a testscript within container
CONTAINER MANAGEMENT COMMANDS:
apps List available apps within a container
bootstrap *Deprecated* use build instead
build Build a new Singularity container
check Perform container lint checks
inspect Display container's metadata
mount Mount a Singularity container image
pull Pull a Singularity/Docker container to $PWD
COMMAND GROUPS:
image Container image command group
instance Persistent instance command group
CONTAINER USAGE OPTIONS:
see singularity help <command>
For any additional help or support visit the Singularity
website: http://singularity.lbl.gov/
----
=== Création de l'image
Comme avec docker, la création d'un conteneur passe par l'écriture d'un fichier décrivant la configuration du conteneur.
Singularity et Docker utilisent des formats de fichiers différents, toutefois il est possible de transformer un conteneur Docker en conteneur Singularity.
Nous allons commencer par créer un conteneur avec la méthode Singularity. Nous verrons comment passer d'un conteneur Docker à un conteneur Singularity dans un second temps.
Il faut installer la base du systeme d'exploitation que nous voulons avoir à l'intérieur du conteneur. Pour cela on a deux solutions :
. on écrit un fichier de "recette" qui va contenir une description de ce que nous voulons dans le conteneur.
. on crée le conteneur à partir d'un fichier Dockerfile ou d'une image docker.
==== 1) Fichier recette singularity
Commencez par créer un fichier texte nommé example.def et indiquons que nous voulons utiliser la dernière version d'Ubuntu :
.example.def
----
Bootstrap: docker
From: ubuntu:latest
----
Dans Singularity 2.4, par défaut l'image crée est immuable pour permettre la reproductibilité. Il faut donc ajouter l'option --writable lorsqu'on teste un nouveau conteneur. Testons la création de notre conteneur décrit dans le fichier example.def :
IMPORTANT: La commande suivante nécessite d'avoir les droits administrateurs (sudo). Si vous ne les avez pas, passez au point 2.
[source, bash]
sudo singularity build --writable example.img example.def
Pour ajouter plus de logiciels dans le conteneur on peut lancer des commandes directement à l'intérieur du conteneur, ou en utilisant la variable %post dans le fichier de recette :
[source, bash]
sudo singularity shell -w example.img
[source, bash]
%post
apt-get update && apt-get -y install wget build-essential
Le fichier example.def ressemble maintenant à ca :
.example.def
----
Bootstrap: docker
From: ubuntu:latest
%post
apt-get update && apt-get -y install wget build-essential
----
Nous avons demandé d'installer les outils de compilations standard pour pouvoir en disposer dans le conteneur.
Relancons le build :
[source, bash]
sudo singularity build --writable example.img example.def
On peut écrire d'importe quelle commande bash dans le fichier de bootstrap. Par exemple, créons un répértoire dans le conteneur qui contiendra nos données :
.example.def
----
Bootstrap: docker
From: ubuntu:latest
%post
apt-get update && apt-get -y install wget build-essential
mkdir /data
----
==== 2) Depuis Docker
Si vous n'avez pas les droits d'administration sur votre machine, vous pouvez passer par une image docker existante :
[source, bash]
singularity build example.img docker://sysmso/docker-openmpi
Nous avons maintenant un conteneur prêt à l'emploi qui contient un compilateur et un répertoire de travail. Nous pouvons commencer à travailler dans le conteneur.
=== Travailler dans le conteneur
Nous avons maintenant un conteneur basique qui contient les outils de compilations.
Nous pouvons alors entrer dans le conteneur et lancer un shell pour voir le résultat :
[source, bash]
singularity shell example.img
Singularity: Invoking an interactive shell within container...
Singularity.example.img> $
Singularity.example.img> $ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Singularity.example.img> $ exit
Pour sortir du conteneur, tapez exit. La version de gcc dans le conteneur est la 5.4.
Par défaut vous lancez un shell dans votre conteneur en lecture-seule, donc vous ne pourrez pas installer de logiciels supplémentaire dans votre conteneur :
[source, bash]
singularity shell example.img
Singularity.example.img> $ apt install vim
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libgpm2 libpython3.5 vim-common vim-runtime
Suggested packages:
gpm ctags vim-doc vim-scripts vim-gnome-py2 | vim-gtk-py2 | vim-gtk3-py2 | vim-athena-py2 | vim-nox-py2
The following NEW packages will be installed:
libgpm2 libpython3.5 vim vim-common vim-runtime
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 7682 kB of archives.
After this operation, 35.1 MB of additional disk space will be used.
W: Not using locking for read only lock file /var/lib/dpkg/lock
W: chmod 0700 of directory /var/cache/apt/archives/partial failed - SetupAPTPartialDirectory (30: Read-only file system)
Pour lancer un shell dans un conteneur en écriture, il faut utiliser l'option -w, a condition que le conteneur ait été crée avec l'option --writable :
[source, bash]
singularity shell -w example.img
Singularity.example.img> $ apt install vim
La commande ne devrait pas marcher, car vous n'êtes pas root.
WARNING: Attention, avec singularity, vous ne pouvez pas changer d'utilisateur dans le conteneur : l'utilisateur hors du conteneur est le même dans le conteneur. Pour être root dans votre conteneur, il faut donc être root sur la machine hôte.
Vous pouvez executer les commandes suivantes dans le conteneur pour voir la différence avec votre système :
[source, bash]
singularity shell -p example.img
Singularity.example.img> $ top
Si vous executez la commande top en dehors du container, vous avez beaucoup plus de processus. A l'intérieur du conteneur vous êtes isolés du reste de la machine avec l'option -p.
Par défaut lorsque vous lancez un shell dans votre conteneur, vous avez accès à tous les fichiers de votre machine locale :
[source, bash]
touch toto.txt
singularity shell example.img
Singularity.example.img> $ ls
Singularity.example.img> $ toto.txt
Si vous voulez lancer un shell sans que le conteneur puisse avoir accès aux fichiers locaux, vous pouvez utiliser l'option -H pour utiliser un autre repertoire comme /home :
[source, bash]
mkdir -p /tmp/temp_home_${USER}
singularity shell -H /tmp/temp_home_${USER}:/home/${USER} example.img
Singularity.example.img> $ ls
WARNING: L'intêret du conteneur est de produire un résultat reproductible dans n'importe quel environnement : il est par conséquent important de s'isoler au maximum du système de fichier local (des fichiers cachés pourraient avoir une influence sur le code que vous exécutez).
Pour ajouter des fichiers à l'intérieur de votre container, vous pouvez rajouter une section %files :
----
%files
tp-singularity/mpi-ping.c /data/mpi-ping.c
----
Votre fichier singularity complet ressemble maintenant à ça :
.example.def
----
Bootstrap: docker
From: ubuntu:latest
%files
tp-singularity/mpi-ping.c /data/mpi-ping.c
%post
apt-get update && apt-get -y install wget build-essential
mkdir /data
----
Relancez le build, et votre fichier sera inséré dans le conteneur :
[source, bash]
sudo singularity build example.img example.def
singularity shell example.img
Singularity.example.img> $ ls /data/mpi-ping.c
Nous avons maintenant un conteneur qui contient nos outils de compilation et notre fichier à compiler.
<<<
:chapter: two
== Executer votre container sur un cluster de calcul
=== Créons un container avec une application et son environnement
Le conteneur que nous avons crée contient Ubuntu avec notre environnement de compilation. Allons plus loin et ajoutons une application MPI compilée dans le container.
Pour cela nous allons avoir besoin d'installer openmpi dans le container. Dans ubuntu, pour avoir le paquet openmpi il faut utiliser le repository universe.
Voilà ce que donne le fichier singularity final avec toutes les dépendances requises :
.example.def
----
Bootstrap: docker
From: ubuntu:latest
%runscript
mpicc /mpi-ping.c
%files
tp-singularity/mpi-ping.c /data/mpi-ping.c
%environment
VARIABLE=MEATBALLVALUE
export VARIABLE
%labels
AUTHOR souchal@apc.in2p3.fr
%post
apt-get update && apt-get -y install software-properties-common wget build-essential sgml-base rsync xml-core openssh-client
add-apt-repository universe
apt-get update && apt-get -y install cmake git gfortran openmpi-common openmpi-bin libopenmpi-dev
apt-get clean
mkdir /data
----
Pour information, voici l'équivalent de ce fichier avec Docker :
.Dockerfile
----
FROM ubuntu:latest
RUN apt-get update && \
apt-get install -y wget software-properties-common build-essential sgml-base rsync xml-core openssh-client && \
apt-get clean
RUN add-apt-repository universe && \
apt-get update && \
apt-get -y install cmake git gfortran openmpi-common openmpi-bin libopenmpi-dev && \
apt-get clean
RUN mkdir /data
ENTRYPOINT ["echo","Le runscript est la commande par défaut du conteneur !"]
ADD ./mpi-ping.c /data/mpi-ping.c
----
On peut maintenant contruire le container :
[source, bash]
sudo singularity build example.img example.def
Le runscript peut être executé avec la commande run :
[source, bash]
singularity run example.img
On peut ensuite compiler le fichier mpi-ping.c avec le compilateur inclus dans le conteneur :
[source, bash]
singularity exec example.img mpicc tp-singularity/mpi-ping.c -o ./mpi-ping
Une fois la compilation terminée, on lance le test avec mpirun et le fichier que nous venons de compiler :
[source, bash]
mpirun -np 20 singularity exec example.img ./mpi-ping
WARNING: La commande mpirun doit être disponible sur la machine hôte, c'est cette commande qui va dispatcher le conteneur sur les CPU physiques de la machine. De plus il faut que la version locale de MPI soit compatible avec celle utilisée pour compiler le fichier dans le conteneur.
=== Lancer un programme conteneurisé en batch
Il faut envoyer votre conteneur sur le cluster, par exemple via scp.
* Avec Torque Scheduler, avec 8 coeurs sur le même noeud :
.job.sh
----
#!/bin/bash
#PBS -N SINGULARITY
#PBS -l nodes=1:ppn=8,mem=2gb,walltime=24:00:00
export SCRATCH="/scratch/$USER.$PBS_JOBID"
mpirun /usr/local/bin/singularity exec /home/${USER}/example.img /usr/bin/mpi-ping >> output.txt
----
Le résultat :
.output
----
mpi-ping: ping-pong
nprocs=8, reps=10000, min bytes=0, max bytes=0 inc bytes=0
4 pings 5
6 pings 7
0 pings 1
2 pings 3
4 pinged 5: 0 bytes 0.36 uSec 0.00 MB/s
2 pinged 3: 0 bytes 0.36 uSec 0.00 MB/s
0 pinged 1: 0 bytes 0.37 uSec 0.00 MB/s
6 pinged 7: 0 bytes 0.36 uSec 0.00 MB/s