--- tags: Candyce, Onyxia, SSPCloud --- # Notes Onyxia / Candyce Sur recommandation de Bastien Guerry de la DINUM, j'ai (Nicolas Thiéry) assisté le 12 octobre 2021 à un [atelier](https://www.eventbrite.fr/e/billets-openlab-onyxia-n2-415380352817) sur le logiciel Onyxia et son instance [SSPCloud](https://onyxia.lab.sspcloud.fr/home) développé par l'INSEE. La mission d'Onyxia est de mettre les technologies cloud (calcul, données) au bout des doigts des équipes de scientifiques des données. Enjeux, technologies utilisées, approche, stratégie, éthique, il y a un bel alignement avec Candyce; c'est confortant quand plusieurs groupes aboutissent indépendamment aux mêmes conclusions :-) Maintenant le taf c'est de débrouiller l'écheveau pour comprendre en profondeur les deux projets, notamment en terme de recouvrement ou complémentarité de leur cœur mission et de public visé, pour trouver une bonne articulation entre eux et chercher les opportunités de collaboration et de mutualisation. Dans les notes ci-dessous, j'essaye de résumer ma compréhension -- forcément limitée à ce stade -- d'Onyxia. N'hésitez pas à intervenir, modifier, commenter, compléter. ## Cœur technique Le cœur technique de Candyce, c'est de provisionner des environnements virtuels configurables: depuis son navigateur web, l'utilisateur configure un environnement à l'aide d'un assistant, en choisissant des ressources (carnets Jupyter, code, petites données) et une collection de logiciels de calcul, appelée «image logicielle». Cela fait, l'utilisateur peut lancer l'environnement et y accéder toujours depuis son navigateur web. L'utilisateur peut aussi partager sa description d'environnement avec une simple url pour que d'autres utilisateurs puisse lancer leur propre instance de l'environnement. Techniquement, l'exécution se fait dans le navigateur (JupyterLite) ou dans un conteneur docker sur l'infra kubernetes Candyce, avec dans les deux cas persistence des données sur l'infra Candyce. Onyxia suit le même principe, mais pour des besoins plus avancés, notamment côté données: l'utilisateur définit son environnement virtuel -- ou datalab -- en composant plusieurs *services* à l'aide d'un assistant. Un premier service est dédié au calcul/traitement: comme dans Candyce, une image logicielle. D'autres services sont dédiés aux données (stockage, moteur de requêtes ou de recherche, ...), à l'automatisation (gestion de workflow, ...). Techniquement parlant: un data lab est une application kubernetes composée de plusieurs conteneurs docker, dans un namespace dédié. Avec accès à des ressources physiques lourdes: GPU, ... ## Résumé, forcément caricatural Candyce: démocratiser les environnements virtuels: «Docker+conda pour les nuls» Onyxia: démocratiser les data labs virtuels: «Kubernetes pour les nuls» Candyce: - besoins simples, massifs en nombre; - besoins spécifiques enseignement Onyxia: - besoins spécifiques science des données ## Quelques éléments communs de stratégie - Autonomiser les équipes, les communautés - Baisser les barrières d'accès à la technologie - premier pas d'ingénierie technique: fournir une infra, des assistants de configuration. - deuxième pas d'ingénierie sociale: mettre en place une dynamique communautaire de partage: s'appuyer sur les utilisateurs experts pour faire émerger des environnements et ressources de qualité au plus près du métier prêts à l'emploi pour tous. => Communs numériques FAIR - Lutter contre l'enfermement propriétaire, les silos, y compris vis-à-vis de nos solutions: modularité, interopérabilité, collaboration, - Fournir non seulement une infra de référence, mais surtout le logiciel sous-jacent que toute autre partie puisse déployer elle même pour les besoins non couverts par l'infra de référence (limites de la mission de cette infra, besoins spécifiques de ressources physiques, protection des données, ...). ## Opportunités de collaboration - Collaboration passive par les bénéfices partagés des contributions àl'écosystème commun Exemple: l'amélioration de l'accessibilité de JupyterLab bénéficiera à Onyxia. - Collaboration sur les communs numériques FAIR: - images logicielles - matériel pédagogique - ... Par exemple avec des catalogues mutualisés? - Publicité croisée, notamment pour orienter au mieux les utilisateurs potentiels, en fonction de leurs besoins - Permettre une migration en douceur d'un service à l'autre: usages simples sur Candyce => usages compliqués sur Onyxia - Réutilisation de composants? (ex: gestionnaire d'environnement) - Partage de bonnes pratiques - Ateliers communs? - Partage d'expérience, notamment sur comment expliquer ce type de projet complexe. ## À faire - Tester l'usage d'Onyxia / SSPCloud en alternative à colab dans nos enseignements avec des besoins en GPU / données - Pour répondre aux besoins pressants - Pour évaluer l'adéquation aux besoins, notamment en terme de simplicité d'usage. - Question pour Bastien/DINUM: en quoi Onyxia ne réponds pas déjà aux besoins d'Etalab pour le programme 10%? - Étudier l'articulation avec MyDocker de CentraleSupélec ## Notes en vrac ### Présentation: Onyxia et sspcloud: qu'est-ce? Par: Romain Lesur, vice directeur data-science à l'INSEE #### Onyxia Un logiciel open-source exploitant les techno cloud pour fournir un datalab Origines il y a six ans: - besoins interne d'infrastructure à l'INSEE GPU et parallélisme, explosion des outils et frameworks, ... - tirer profils des technos cloud? - Idée: construire un datalab (datalab.sspcloud.fr) - Construit dans un garage à l'INSEE; serveurs dans la maison - Généralisation en un service inter-ministériel (AgentConnect) - Soutenu par Bercy, ... - Stratégie d'ouverture du code source: Onyxia.sh, licence MIT, soutenu par DINUM/Etalab, ... - TOSIT: association de grandes entreprises françaises et ministères (armées, ...) ADN: - favoriser l'autonomie des équipes data - de l'expérimentation à la production (dont devop/dataop/...) - aucun enfermement propriétaire - dont envers Onyxia lui-même - interopérabilité; possibilité de déployer Onyxia sur n'importe quel cloud; exemple: - modulaire, extensible, ... - images-datascience: volonté de constructions d'images communautaires de confiance #### SSPCloud Une instance d'Onyxia: - Utilisée par des formations en Data Science (dont CentraleSupélec) - Limitation: garanties "best efforts"; à ce stade, les CGU imposent de ne l'utiliser que pour traiter des données ouvertes - Possibilité d'héberger des hackatons sur demande - Ouverture: AgentConnect; sinon ajout à la main des noms de domaines pour lesquels les membres peuvent se créer un compte, typiquement pour les EPIC. #### Encore plus en vrac À définir: - notion de «service» - Exemples: - Images Jupyter Préciser: - définition des images Technologies: - kubernetes: «système d'exploitation à l'échelle d'un cluster» la conteneurisation permet notamment, dans une même architecture de serveurs, permettre deux catégories d'usages: - libre accès - batch - S3: stockage cloud natif compatible hadoop Apport de S3: accès à du stockage via une API web, adapté pour les services cloud; permets aux applicatifs d'être responsable de la connexion à la donnée -> autonomisation. D'où séparation traitement vers données. Exemple: permettre de distribuer un traitement en pleins de petits traitements sur plusieurs serveurs accédant tous à la même donnée. Tendance de fond: le modèle de colocalisation données/traitement (hadoop, hdfs, ...) est en voie de disparition car cher à entretenir et empêche le découplage entre capacité de traitement (e.g. GPU) et capacité de stockage. Exemple à l'INSEE: il n'y a pas de besoins suffisants forts en volumétrie pour justifier un service type hadoop. - Catalogue de services traitement, données, automatisation: jupyter, vscode, postgresql, elastic, gestionnaire de workflow. - Un espace projet est un namespace kubernetes où les membres du projet peuvent déployer les services (traitement, donnée, ...) dont il a besoin. Moralement le gestionnaire de projet d'Onyxia est un wizard pour construire une application kubernetes helm chart + gestion des tokens. Analogue du gestionnaire d'environnement de Candyce comme wizard pour construire des environnements.yml, mais pour les applications. Avec possibilité de partage de l'application (notamment par lien) / et contribution à un catalogue d'application. L'espace projet a un système de fichiers associé et un gestionnaire de secrets. Outil Trelo(?) de monitoring de l'application - Stratégie données: - S'abstraire du modèle du système de fichier - Découpler le schéma des données de leur traitement: le schéma est côté donné plutôt que côté traitement. Techno: HiveMetaStore - Stratégie: Les services sont temporaires et arrêtés automatiquement. S3 est la source de persistence. Idée: favoriser le data-op reproductible - Possibilité de partage d'applications / catalogue d'applications - Urbanisation Onyxia / gitlab / grafana / ... Stratégie de déploiement par une DSI: chaque utilisateur déploie ses propres services dans ses projets? Ou l'administrateur déploie des services partagés accessibles depuis chaque projet? Enjeux: Simplicité w.r.t. isolation w.r.t. autonomie. Exemples extrêmes: chacun son Jupyter; un seul GitLab partagé. Réponse au cas par cas en fonction du type de service et des besoins locaux. Gestionnaire de ressources physiques à l'échelle du projet, avec possibilité de définition de quotas simples par l'administrateur. Sur SSPCloud: gestion a posteriori. GPU: - Images GPU ready spécifique - Expérience d'orchestration de telles images, avec gestion spécifique Suivi de consommation; gestion de la refacturation? Support actuel minimal, mais intérêt pour développer dans cette direction. Trino: service de requête SQL distribué, se basant sur la scalabilité de kubernetes. #### Questions Besoin de colocalisation partielle? Nécessité d'avoir du S3 physiquement proche, même si sur service distinct?