Apptainer - Conteneur d’applications pour Linux

• Plateforme de conteneurs open source conçue autour de la simplicité, de la rapidité et de la sécurité
  • Optimisée pour les environnements HPC (calcul haute performance) et les systèmes partagés
• Fournit un format d’image de conteneur monofichier immuable (immutable), avec prise en charge du chiffrement et de la signature
• Se concentre sur la facilité d’intégration plutôt que sur l’isolation, ce qui permet d’utiliser directement les GPU, les réseaux haut débit et les systèmes de fichiers parallèles dans les environnements de cluster et de serveur
• Permet de récupérer tous les conteneurs depuis des registres OCI (Open Containers Initiative) et maximise la compatibilité avec Docker
  • Prend en charge le pull, l’exécution (run) et la construction (build) de la plupart des conteneurs présents sur Docker Hub sans modification
• Anciennement Singularity, renommé puis transféré comme projet de la Linux Foundation
• Grâce aux conteneurs monofichier basés sur SIF (Singularity Image Format), il est facile de les déplacer, déployer et partager
• Applique un modèle de sécurité sûr où les permissions utilisateur sont identiques à l’intérieur et à l’extérieur du conteneur, sans élévation de privilèges supplémentaire sur l’hôte par défaut
• Licence BSD

[galadbran]

Article unregistry mentionné dans les commentaires de Hacker News :
Unregistry – envoyer directement un "docker push" à un serveur sans registre | GeekNews

[GN⁺]

Avis Hacker News

• Notre équipe a essayé Apptainer sur un cluster de calcul pour la conception/vérification de puces, mais au final nous sommes revenus aux modules TCL (migrés vers Lua) traditionnels

  • Nous avons rencontré plusieurs problèmes.
    • D'abord, les conteneurs ne peuvent pas s'utiliser entre eux. Par exemple, si des outils comme Make, GCC, Git se trouvent chacun dans un Apptainer différent, en entrant dans celui de Make on ne voit plus GCC
    • Ensuite, si les artefacts produits dépendent de l'intérieur du conteneur, cela ne fonctionne pas correctement. En compilant un programme avec l'Apptainer GCC, le binaire généré se retrouve lié à des bibliothèques internes au conteneur et ne s'exécute pas, et il y a aussi eu des problèmes d'en-têtes C
    • Enfin, la variable PATH finissait sans cesse par être perturbée, ce qui empêchait de voir les chemins ou outils nécessaires à l'extérieur d'Apptainer
    • Globalement, l'idée était bonne, mais en utilisation réelle c'était surtout pénible, au point qu'il était bien plus simple d'utiliser directement un ancien OS (RHEL8)
  • Je considère Apptainer/Singularity comme proche de Docker (sauf qu'il n'y a pas de configuration réseau complète). On rencontre les mêmes problèmes avec les conteneurs Docker traditionnels.
    • Dans mon workflow HPC, j'utilise Apptainer comme un remplacement direct de Docker, et pour cet usage cela convient bien
    • Le plus gros avantage d'Apptainer, ce sont les conteneurs sans privilèges root. Cela empêche les configurations réseau complexes, mais c'est bien plus sûr dans des environnements mutualisés comme le HPC
  • Si votre principal reproche envers une appli conteneurisée est qu'elle se comporte comme un conteneur, alors c'est simplement la nature d'un conteneur
  • Il ne faut pas mélanger des morceaux de conteneurs, pas plus qu'on ne mélange des binaires de distributions Linux différentes
    • Idéalement, on utilise les conteneurs comme un environnement de développement intégré. Puisque le conteneur est un environnement isolé, tout ce que vous compilez doit rester dans son propre conteneur
    • Cela dit, on peut aussi créer plusieurs conteneurs à partir de la même image de base afin d'assurer la compatibilité des fichiers (mais uniquement si l'on y inclut toutes les dépendances nécessaires)

• C'est bien de voir Apptainer attirer l'attention. Dans certains cas, c'est meilleur que Docker, Podman et autres

  • Quand il faut exécuter plusieurs tâches dans un seul conteneur (ce qui n'est pas recommandé avec d'autres technologies de conteneur)
  • HPC (et certains environnements universitaires)
  • Prise en charge d'un modèle de distribution en fichier unique (sans prise en charge des deltas, toutefois)
  • Possibilité de signer chiffré des fichiers SIF sans serveur externe dédié
  • Très bon support GPU

• Docker permet aussi une distribution en fichier unique avec les commandes docker save et docker load.

  • Cela ne prend pas en charge les deltas, mais une solution récente appelée « unregistry » a été liée sur HN, et permet de faire du "docker push" et des mises à jour delta sans Docker Registry

• Apptainer et singularity ce sont tous deux couramment utilisés en HPC. Les deux proviennent de l'ancien projet Singularity, mais ils ne sont pas totalement identiques

  • Nous utilisons singularity sur plusieurs supercalculateurs (HPC), et certains chercheurs installent Apptainer en local
  • Nous avons récemment découvert un bug de fuseau horaire dans du code Python (matplotlib, xarray, etc.) : il y avait un problème avec singularity ce, alors qu'Apptainer fonctionnait correctement
  • Les nouvelles versions d'Apptainer ont une base de code similaire, mais les correctifs y arrivent plus vite. Par exemple, singularity écrasait le fuseau horaire utilisateur avec celui du système, ce qui causait le problème
  • Lien de référence : issue singularity #3686
  • Apptainer n'est pas un fork de l'ancien projet Singularity. Apptainer est le projet principal d'origine, dont seul le nom a été changé après un vote de la communauté. Il a ensuite rejoint la Linux Foundation
    • Le cas du fork concerne singularity ce, lorsque Sylabs a recruté le développeur d'origine et bifurqué le projet
    • Référence : community announcement
  • Malgré cela, la compatibilité des conteneurs est maintenue : ce qui est construit avec Apptainer peut être exécuté avec Singularity (et inversement)

• Apptainer, c'est en gros Singularity. L'article associé est ici

  • Quand on utilise un système partagé dans un cluster universitaire ou gouvernemental, Apptainer est presque toujours présent, alors que Podman/Docker le sont rarement
  • Dans ce genre d'environnement, il est souvent plus utile de bien s'entendre avec les administrateurs système et de comprendre comment le cluster fonctionne, plutôt que d'essayer d'utiliser des conteneurs
  • Je me demande pourquoi Docker/Podman sont moins utilisés, et pourquoi il vaut mieux éviter les conteneurs dans ce contexte. Est-ce à cause des performances ?

• Flatpak semble vouloir passer d'OSTree à une approche basée sur les conteneurs. L'avantage mis en avant serait l'existence d'un outillage conteneur bien maintenu. Mais je me demande en quoi cela diffère d'Apptainer

  • J'imagine que la spécificité de Flatpak est de permettre un contrôle fin du sandboxing des applications, notamment via une granularité des permissions avec xdg-dbus, afin de les faire fonctionner comme des applis natives
    • Je ne suis pas certain qu'Apptainer aille aussi loin en matière de séparation/isolement complet
    • Avec des outils comme containertoolbx, les différences entre approches conteneur deviennent assez peu importantes
    • Honnêtement, il y a beaucoup de chevauchement fonctionnel entre les outils, mais je trouve que ce n'est pas un problème en soi

• Dans mon environnement, l'objectif principal d'Apptainer n'a rien à voir avec le déploiement, l'isolation ou la disponibilité logicielle.

  • Notre cluster HPC impose un quota d'inodes par utilisateur, ce qui rend difficile l'installation de logiciels contenant énormément de fichiers (par exemple Anaconda)
  • Mais les images Apptainer sont des fichiers uniques basés sur squashfs, donc on peut en conserver plusieurs sans se soucier du quota d'inodes
  • Installer le même logiciel de manière classique est plus simple, mais le quota est alors épuisé en un rien de temps

• Je suis d'accord avec l'avis de Havoc. Le message est ambigu : on ne sait pas si Apptainer est un remplaçant de Flatpak pour le desktop ou s'il est destiné aux serveurs

  • C'est pour les serveurs. Mais la question elle-même est ambiguë
    • Apptainer sert à exécuter des applications CLI dans des conteneurs immuables et rootless
    • L'outil le plus proche est probablement Fedora Toolbx
    • L'usage principal d'Apptainer est le déploiement et la réutilisation d'outils de calcul scientifique. Il fonctionne sans privilèges root, le rootfs n'est pas modifiable par conteneur, le répertoire de travail est monté automatiquement, et le support GPU est bon aussi (je ne l'ai toutefois pas testé moi-même)
    • Référence : Fedora Toolbx

• Le nom « Apptainer » a une prononciation maladroite et donne une impression un peu bancale

• En tant que développeur, on peut chercher un outil de conteneurisation pour l'isolation

  • J'ai créé un outil basé sur Podman pour isoler différents projets de développement. Si cela peut être utile pour des tests de sécurité ou pour l'usage, le code et le billet de blog sont disponibles
  • Je me demande pourquoi toolbox ne suffisait pas
    • Personnellement, je trouvais toolbox convenable, notamment parce qu'il évite d'avoir à gérer plusieurs systèmes de fichiers cachés lors de l'installation d'environnements de développement par projet

• C'est très utile sur un cluster SLURM ou sur des serveurs sans privilèges root

  • Je l'ai moi aussi utilisé sur un cluster SLURM
    • La documentation officielle est bien faite, suffisante pour démarrer
    • En revanche, sans fakeroot ni sudo, il fallait construire Apptainer en local puis le transférer directement sur le serveur, ce qui était contraignant