|
|
|
|
|
|
|
<img src="https://gitlab.in2p3.fr/CodeursIntensifs/DecaLog/-/wikis/img/logo-computeops.png" align="left" width="30"_>
|
|
<img src="https://gitlab.in2p3.fr/CodeursIntensifs/DecaLog/-/wikis/img/logo-computeops.png" align="left" width="30"_>
|
|
|
|
|
|
|
|
# Calcul scientifique en conteneurs
|
|
# Calcul scientifique en conteneurs
|
|
|
|
|
|
|
|
|
|
|
|
|
Le mouvement "DevOps" amène de plus en plus les développeurs à livrer leurs codes accompagnés d'une image de conteneur, ou d'un fichier permettant de reconstruire un tel conteneur (machines virtuelles légères). Ainsi, l'application peut être déployée beaucoup plus facilement, et dans un contexte d'exécution similaire à celui du développeur, sans nécessiter l'intervention d'un administrateur pour installer telle ou telle bibliothèque applicative. Docker est l'outil emblématique de ce mouvement.
|
|
Le mouvement "DevOps" amène de plus en plus les développeurs à livrer leurs codes accompagnés d'une image de conteneur, ou d'un fichier permettant de reconstruire un tel conteneur (machines virtuelles légères). Ainsi, l'application peut être déployée beaucoup plus facilement, et dans un contexte d'exécution similaire à celui du développeur, sans nécessiter l'intervention d'un administrateur pour installer telle ou telle bibliothèque applicative. Docker est l'outil emblématique de ce mouvement.
|
|
|
|
|
|
|
|
Ce concept diffuse maintenant à grande vitesse dans le monde du cloud et des super-calculateurs ; dans ce dernier cas, plutôt autour de l'outil Singularity. Pour se garder la possibilité d'utiliser ces ressources de calcul, et bénéficier nous aussi de la souplesse apportée par les conteneurs, il devient vital de préparer l'usage de ces conteneurs dans nos disciplines et dans nos grilles de calcul.
|
|
Ce concept diffuse maintenant à grande vitesse dans le monde du cloud et des super-calculateurs ; dans ce dernier cas, plutôt autour de l'outil Singularity. Pour se garder la possibilité d'utiliser ces ressources de calcul, et bénéficier nous aussi de la souplesse apportée par les conteneurs, il devient vital de préparer l'usage de ces conteneurs dans nos disciplines et dans nos grilles de calcul.
|
|
|
|
|
|
|
|
|
|
|
|
|
## Objectifs du projet
|
|
## Objectifs du projet
|
|
|
|
|
|
|
|
* Comparer les différentes technologies de conteneurs (docker, rocket, lxd, udocker, singularity, shifter) : effet sur les performances, la vectorisation, accès aux accélérateurs de calcul, sécurité, facilité d'administration et d'utilisation. Y'a-t-il un avantage décisif à dédaigner l'outil dominant (Docker) et à se tourner vers les alternatives "HPC" (Singularity, Shifter,...) ?
|
|
* Comparer les différentes technologies de conteneurs (docker, rocket, lxd, udocker, singularity, shifter) : effet sur les performances, la vectorisation, accès aux accélérateurs de calcul, sécurité, facilité d'administration et d'utilisation. Y'a-t-il un avantage décisif à dédaigner l'outil dominant (Docker) et à se tourner vers les alternatives "HPC" (Singularity, Shifter,...) ?
|
|
|
|
|
|
|
|
* Etudier l'inter-opérabilité des technologies. Notamment les images et les fichiers de reconstruction d'image. Par exemple, est-ce qu'un utilisateur pourrait développer sur son poste en Docker, puis déployer sur centre de calcul en Singularity ?
|
|
* Etudier l'inter-opérabilité des technologies. Notamment les images et les fichiers de reconstruction d'image. Par exemple, est-ce qu'un utilisateur pourrait développer sur son poste en Docker, puis déployer sur centre de calcul en Singularity ?
|
|
|
|
|
|
|
|
* Valider la compatibilité des conteneurs avec la grille.
|
|
* Valider la compatibilité des conteneurs avec la grille.
|
|
|
|
|
|
|
|
* Prototyper un outil de soumission de travaux (jobs) qui puisse déployer une application en conteneur indifféremment sur une machine personnelle, la grille, les clouds, les super-calculateurs... c'est à dire permettre à un physicien, via une interface unique, de faire tourner son application indifféremment sur son poste ou sur toute ressource de calcul à sa disposition.
|
|
* Prototyper un outil de soumission de travaux (jobs) qui puisse déployer une application en conteneur indifféremment sur une machine personnelle, la grille, les clouds, les super-calculateurs... c'est à dire permettre à un physicien, via une interface unique, de faire tourner son application indifféremment sur son poste ou sur toute ressource de calcul à sa disposition.
|
|
|
|
|
|
|
|
* Lors de l'éxecution des conteneurs en production sur un cluster, il est nécessaire d'utiliser un orchestrateur de conteneurs qui distribue les taches sur les ressources disponibles et à la demande. Plusieurs solutions existent (Docker Swarm, Kubernetes, Mesos,...), il faut donc suivre et comparer les technologies.
|
|
* Lors de l'éxecution des conteneurs en production sur un cluster, il est nécessaire d'utiliser un orchestrateur de conteneurs qui distribue les taches sur les ressources disponibles et à la demande. Plusieurs solutions existent (Docker Swarm, Kubernetes, Mesos,...), il faut donc suivre et comparer les technologies.
|
|
|
|
|
|
|
|
|
|
|
|
|
## Participants
|
|
## Participants
|
|
|
|
|
|
|
|
#### Porteurs
|
|
#### Porteurs
|
|
|
|
|
|
|
|
* 2023-XXXX : **Aurélien Baily-Reyre (LPNHE)**
|
|
* 2025-XXXX : **Richard Randriatoamanana (SUBATECH/Nantes)**
|
|
|
* 2019-2023 : Martin Souchal (APC)
|
|
* 2023-2024 : *Aurélien Baily-Reyre (LPNHE)*
|
|
|
* 2017-2019 : Cécile Cavet (APC)
|
|
* 2019-2023 : *Martin Souchal (APC)*
|
|
|
|
|
* 2017-2019 : *Cécile Cavet (APC)*
|
|
|
#### Participants IN2P3
|
|
|
|
|
|
|
#### Participants IN2P3
|
|
|
* APC : Cécile Cavet, Andréa Sartirana ?.
|
|
|
|
|
* IJCLab : Gerard Marchal-Duval, David Chamont.
|
|
* APC : Cécile Cavet, Andréa Sartirana ?.
|
|
|
* LPNHE : Aurélien Baily-Reyre, Olivier Dadoun, Victor Mendoza.
|
|
* IJCLab : Gerard Marchal-Duval, David Chamont.
|
|
|
* LPC : Fabrice Jammes.
|
|
* LPNHE : Aurélien Baily-Reyre, Olivier Dadoun, Victor Mendoza.
|
|
|
* IPHC : Jérôme Pansanel, Emmanuel Medernach.
|
|
* LPC : Fabrice Jammes.
|
|
|
* CC IN2P3 : Sébastien Gadrat et équipe C3.
|
|
* IPHC : Jérôme Pansanel, Emmanuel Medernach.
|
|
|
* SUBATECH : Richard Randriatoamanana.
|
|
* CC IN2P3 : Sébastien Gadrat et équipe C3.
|
|
|
|
|
* SUBATECH : Richard Randriatoamanana.
|
|
|
#### Partenaires externes
|
|
|
|
|
|
|
#### Partenaires externes
|
|
|
* ?? : Martin Souchal.
|
|
|
|
|
* Groupe de travail Aristote : contact pris (David).
|
|
* ?? : Martin Souchal.
|
|
|
* contact : V. Louvet
|
|
* Groupe de travail Aristote : contact pris (David).
|
|
|
* IDRIS : discussions en cours (David).
|
|
* contact : V. Louvet
|
|
|
* GENCI
|
|
* IDRIS : discussions en cours (David).
|
|
|
* IAS (Marc Dexet)
|
|
* GENCI
|
|
|
* INRAE (Alex Dehne-Garcia)
|
|
* IAS (Marc Dexet)
|
|
|
* CNES (Guillaume Eynard-Bontemps)
|
|
* INRAE (Alex Dehne-Garcia)
|
|
|
* CEA
|
|
* CNES (Guillaume Eynard-Bontemps)
|
|
|
|
|
* CEA
|
|
|
|
|
|
|
|
## Liens
|
|
|
|
|
|
|
## Liens
|
|
|
* [**_Master-projet DecaLog_**](https://gitlab.in2p3.fr/CodeursIntensifs/DecaLog/wikis/home)
|
|
|
|
|
|
* [**_Master-projet DecaLog_**](https://gitlab.in2p3.fr/CodeursIntensifs/DecaLog/wikis/home)
|
|
|
* [**_Wiki privé de ComputeOps_**](https://gitlab.in2p3.fr/CodeursIntensifs/ComputeOps/wikis/home) |
|
* [**_Wiki privé de ComputeOps_**](https://gitlab.in2p3.fr/CodeursIntensifs/ComputeOps/wikis/home) |
|
|
|
\ No newline at end of file |
