Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
C Csan
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

Docker-in-Docker (DinD) capabilities of public runners deactivated. More info

  • CSAN
  • Csan
  • Wiki
  • soumission_poster

soumission_poster · Changes

Page history
les propositions sont dans un fichier à part authored May 10, 2021 by Remy Dernat's avatar Remy Dernat
Hide whitespace changes
Inline Side-by-side
Showing with 189 additions and 0 deletions
+189 -0
  • soumission_poster.md soumission_poster.md +189 -0
  • No files found.
soumission_poster.md 0 → 100644
View page @ c34775f9
# CSAN
## Les conteneurs
Les conteneurs sont, depuis quelques années, devenus une nouvelle
manière de distribuer des logiciels. L'intérêt est la facilité avec
laquelle il est possible de produire un environnement logiciel complexe
puis le réutiliser ailleurs.
De nombreuses critiques fondées sont apparues sur cette nouvelle méthode
de distribution. En effet, le nombre de vulnérabilités sont multipliées
par tout ce qui est inclus dans les nombreuses strates du conteneur,
contrairement à un package classique. Par ailleurs, l'environnement de
construction et d'exécution du conteneur sont une autre source de
vulnérabilité. La surface d'attaque est donc bien plus élevée.
Cela étant dit, les conteneurs offrent de nombreuses manières
d'embarquer de l'information, notamment par un environnement riche en
métadonnées. De plus, de nouveaux mécanismes et manières d'exécuter les
conteneurs sont progressivement apparus, avec par exemple la possibilité
d'éviter d'utiliser un démon lors de l'exécution ou bien en évitant
toute exécution sous root. Des « capabilities » et les « cgroups » se
sont progressivement enrichis, offrant un panel de possibilités pour
contrer toute escalade de privilèges.
## L'utilisation des conteneurs en environnement scientifique
L'ESR dispose de nombreuses ressources de calcul, répartis dans
plusieurs centres nationaux et régionaux, dans des laboratoires, ou bien
encore au travers de grilles et de cloud. L'idée d'utiliser les
conteneurs dans cet environnement très hétérogène a fait son chemin, de
part leur portabilité, mais la plupart des grands centres restent
frileux quant à l'utilisation des conteneurs.
Le 1^er^ constat ci-dessus fait évidemment partie des craintes, mais ces
derniers doivent également s'assurer que l'exécution se déroulera d'une
part de manière logique et produira des résultats cohérents et d'autre
part, de manière optimisée pour les ressources présentes ; que ça soit
pour des cartes graphiques particulières ou des mécanismes
d'accélération matériels autres (cartes FPGA, InfiniBand) et les
mécanismes d'interactions logiciel associés (drivers, Cuda, MPI\...).
La compatibilité de la couche logiciel du conteneur (versions et options
de MPI, Cuda...) avec le noyau et les pilotes chargés par l'hôte est
souvent un point délicat.
## Émergence d'une idée de contrôle accrue et de partage d'expérience
Dans la chaîne de distribution des conteneurs, un point central concerne
le « *hub* », en l'occurrence, le docker-hub[^1], maintenu par la
société docker. Sur cette plateforme de distribution, n'importe qui peut
envoyer une image et la proposer à l'ensemble de la communauté.
Quelqu'un de suffisamment expérimenté préfèrera toujours choisir une
image dite « certifiée » qui offre plus de garantie car souvent
construite avec soin par un acteur important. Sur un autre hub,
« quay.io »[^2], propriété de la société RedHat, un scan des images est
régulièrement effectué, permettant de chercher des vulnérabilités (CVE)
dans des bases de données, et un rapport permet de voir quels sont les
risques d'utiliser l'image scannée. Côté calcul, un
« *singularity-hub* »[^3] existe, reposant sur la technologie de
conteneurs Singularity, mais ce dernier n'est guère maintenu et ne
repose sur les épaules que d'une seule personne. En version Entreprise,
SingularityPro[^4] propose une librairie avec des images signées et
parfois réalisées par l'équipe même de Singularity et de partager ses
propres images.
Le projet européen BioContainers[^5], porté par Elixir[^6] est déjà une
avancée significative puisqu'il propose des conteneurs Singularity,
docker et tout un environnement logiciel (souvent avec conda[^7]), à
toute la communauté biologie européenne, comportant un catalogue de
métadonnées obligatoires, le tout intégré à un environnement logiciel
assez large (forge logicielle, tests et intégration continue,
intégration à des workflows, etc.)[^8].
Tous ces modèles ont chacun leur faiblesse : ils sont centralisés
(peuvent donc être la source d'attaque type DDoS), ne proposent pas tous
les mêmes fonctionnalités, avec des niveaux de sécurité plus ou moins
forts, et pour des périmètres d'utilisation différents.
Du côté de l'intégration avec des ressources de calcul, l'Institut
Français de Bioinformatique (IFB[^9]) a poussé la réflexion un peu plus
loin, puisqu'ils permettent de pousser directement vers les ressources
de calcul du code validé sur un dépôt, éventuellement sous forme de
conteneur[^10]. D'autres structures (laboratoires, mésocentres, ...)
proposent aussi, à leur niveau, des aides à la construction[^11], au
déploiement ou l'utilisation de conteneurs sur leurs ressources [^12],
[^13], [^14].
## Le modèle de distribution de Perl, R, TeX
Des modèles de distributions plus sécurisés et mieux contrôlés existent.
C'est le cas par exemple des dépôts apt pour la distribution debian ou
encore des Comprehensive Archive Network, tels que le CPAN[^15] (pour le
langage de programmation Perl) ou le CRAN[^16] (langage R) ou encore le
CTAN (TeX)[^17]. De nombreux « miroirs » permettent de s'assurer que la
ressource à télécharger est toujours disponible et d'y accéder
rapidement par la proximité de ces derniers.
Dans le cas du CRAN, un processus soigné permet de s'assurer que le
package est compatible avec des packages enfants, mais aussi parents
(dépendances et dépendances inverses), lorsque celui-ci est publié, mais
aussi lors des fréquentes mises à jour du langage, ou bien de
l'archiver[^18].
## Le projet CSAN
Ainsi a émergé l'idée du CSAN (Comprehensive Software Archive Network) :
reproduire le même schéma que pour la distribution de packages R ou
Perl, mais pour les conteneurs, en y apportant des métadonnées et des
fonctionnalités utiles telles que des connexions à des dépôts de codes,
permettant plus rapidement la publication de l'image et de manière
automatisée.
Les métadonnées peuvent ainsi permettre aux centres de calcul d'indiquer
si le conteneur tourne correctement chez eux, avec quelles versions et
options de librairie et si ces derniers valident son utilisation sur
leur centre.
Un projet gitlab est présent ici <https://gitlab.in2p3.fr/csan> ,
incluant un wiki[^19] et associé à un PoC :
[https://apccsan.in2p3.fr](https://apccsan.in2p3.fr/)
L'outil Harbor[^20] a été utilisé. Ce dernier est un projet de la
CNCF[^21]. Il permet de connecter plusieurs registres d'images, de
répliquer l'image sur un autre registre, d'accéder de manière
authentifiée au travers d'un annuaire LDAP, de définir des accès basés
sur les rôles (RBAC), de scanner et signer les images, de rajouter les
étiquettes (*labels*), des quotas, d'y accéder par une API restful, de
déclencher des actions par webhooks[^22]...
Ainsi, il est possible pour un centre de calcul ou toute personne de
confiance, de partager ses images de conteneurs avec les labels désirés,
pour indiquer par exemple une compatibilité avec un type d'architecture
matériel et logiciel, tout en publiant sur son propre registre sécurisé.
Le registre étant ensuite relié à Harbor, permettant ainsi un partage et
une capitalisation des pratiques.
Par ailleurs, l'outil Harbor étant décentralisé, il est possible de
faire communiquer plusieurs Harbor, permettant un maillage bien plus
large et une résilience plus forte de l'architecture[^23].
[^1]: https://hub.docker.com/
[^2]: https://quay.io/
[^3]: https://singularityhub.github.io/
[^4]: https://sylabs.io/singularity-enterprise/
[^5]: https://biocontainers.pro/
[^6]: https://elixir-europe.org/
[^7]: https://conda.io
[^8]: https://biocontainers-edu.readthedocs.io/en/latest/what\_is\_biocontainers.html
[^9]: https://www.france-bioinformatique.fr/
[^10]: https://gitlab.com/ifb-elixirfr/cluster/tools
[^11]: https://web.mbb.cnrs.fr/wicopa/
[^12]: https://deploymenthpc.sciencesconf.org/data/pages/slides\_Fede.pdf
[^13]: https://gricad-doc.univ-grenoble-alpes.fr/hpc/softenv/container/
[^14]: https://www.calmip.univ-toulouse.fr/spip.php?article728
[^15]: https://www.cpan.org/
[^16]: https://cran.r-project.org/
[^17]: https://ctan.org/
[^18]: HORNIK, Kurt. The comprehensive R archive network. *Wiley
interdisciplinary reviews: Computational statistics*, 2012, vol. 4,
no 4, p. 394-398.
[^19]: https://gitlab.in2p3.fr/csan/csan/-/wikis/home
[^20]: https://goharbor.io/
[^21]: https://cncf.io/
[^22]: https://fr.wikipedia.org/wiki/Webhook
[^23]: https://github.com/goharbor/harbor/wiki/Architecture-Overview-of-Harbor
Clone repository
  • Contacts
  • Fonctionnalités
  • Groupes de travail
  • JRES 2021 proposition
  • JRES 2021
  • cr_041021
  • cr_041122
  • cr_050721
  • cr_060921
  • cr_070621
  • cr_100521
  • cr_120421
  • cr_140222
  • cr_150321
  • cr_170122
View All Pages