Notebooks Jupyter hébergés et VS Code sur Kubernetes

Les blocs-notes Jupyter sont un outil puissant et populaire qui fournit un environnement informatique interactif, combinant code, visualisation des données et texte explicatif, facilitant ainsi le travail avec les données et le partage d'informations. Les data scientists utilisent les blocs-notes Jupyter pour diverses tâches tout au long du cycle de vie de l'analyse des données et de l'apprentissage automatique, telles que l'analyse exploratoire des données (EDA), le prétraitement des données, la visualisation, le développement de modèles, l'évaluation et la validation, etc. Pour la plupart de ces cas d'utilisation, il suffit installation de Jupyter Notebook sur votre ordinateur portable suffit pour commencer. Cependant, pour de nombreuses entreprises et organisations, ce n'est pas une option et nous avons besoin de blocs-notes Jupyter hébergés.

Pourquoi avons-nous besoin de blocs-notes Jupyter hébergés ?

1. Accès aux ressources : De nombreuses charges de travail liées à la science des données nécessitent une informatique lourde qui ne peut pas être prise en charge par les machines locales de DS ou de MLES. Les ordinateurs portables Jupyter hébergés peuvent fournir un accès DS/MLES à de puissantes machines et GPU.
2. Accès aux données et sécurité : Dans de nombreuses entreprises, les DS/MLE travaillent sur des projets impliquant des données sensibles qui ne peuvent pas être téléchargées sur l'ordinateur portable de l'employé. Ainsi, grâce aux blocs-notes Jupyter hébergés, les entreprises peuvent donner accès à des DS/MLE pour travailler sur des projets sensibles.
3. Reproductibilité et collaboration : Les blocs-notes Jupyter hébergés constituent un excellent moyen de partager du code exécutable et des résultats au sein d'une équipe. L'environnement de développement étant le même, les résultats sont reproductibles à 100 % et les membres de l'équipe peuvent collaborer sur des projets.

Comment une entreprise peut-elle fournir des blocs-notes hébergés à ses data scientists ?

Voici les options dont dispose une entreprise aujourd'hui pour donner accès à Jupyter Notebook à ses ingénieurs :

Fournissez une machine virtuelle à chaque data scientist :

Les DS/MLES peuvent configurer l'environnement et exécuter un serveur jupyter sur une machine virtuelle qui peut être utilisé pour exécuter les charges de travail. Voici un guide simple sur la façon dont vous pouvez exécutez jupyterlab sur une instance ec2.

👍 Avantages :
- Donne le contrôle total de la machine entre les mains d'une DS
- L'ensemble de l'environnement est persistant. La machine virtuelle peut être arrêtée et redémarrée dans le même état.

👎 Inconvénients :
- Coût élevé du cloud computing - Il n'y aura pas de fonction d'arrêt automatique. DS peut démarrer une machine virtuelle et rester inutilisée pendant une grande partie du temps, ce qui augmente les coûts.
- Difficile de gérer et de suivre un grand nombre de machines virtuelles de manière centralisée.
- DS doit configurer de nombreux éléments pour configurer le plan de travail permettant de démarrer l'expérimentation.
- Difficulté de reproductibilité - DS a peut-être installé un tas de packages qui ne sont plus suivis et la production du code qui s'exécute sur cette machine virtuelle prend beaucoup de temps.

Utilisez une solution gérée :

Une autre option consiste à utiliser une solution gérée telle qu'AWS Sagemaker, Vertex AI Notebooks ou Azure ML Notebooks. Bien que chacune de ces méthodes présente des avantages, voici quelques avantages et inconvénients en général.

Discutons de la signification de chacun de ces champs :

• Environnements persistants : Cela fait référence à la persistance de l'environnement python. (Si les installations du package pip et les environnements créés par l'utilisateur sont enregistrés ou non lors des redémarrages de Notebook)
• Installations root persistantes : Lorsque l'accès root est fourni à l'utilisateur, que les installations du package racine (par exemple apt install pkgs) soient conservées ou non lors des redémarrages de Notebook.
• Moniteur d'utilisation des ressources : Si l'utilisateur peut contrôler l'utilisation du processeur et de la mémoire depuis l'écran de l'ordinateur portable lui-même.
• Support du serveur de code : Si l'instance de bloc-notes peut être connectée à un serveur VS Code hébergé.
• SSH dans le conteneur : Possibilité de connexion SSH à un ordinateur portable en cours d'exécution et de connexion depuis la machine locale
• Arrêt automatique : Fonction permettant d'arrêter le bloc-notes après une « période d'inactivité ». Vertex fournit cette fonctionnalité dans sa version « Managed Notebooks ». Sagemaker propose un moyen d'arrêter les blocs-notes après une période d'inactivité, mais l'utilisateur doit configurer un « script d'initialisation » pour celui-ci au lieu d'une simple option de déploiement, ce qui crée un peu de friction pour l'utilisateur.
• Assistance multicloud : Cette fonctionnalité est exclusive à Truefoundry car vous pouvez exécuter le bloc-notes sur l'un des trois fournisseurs de cloud avec exactement la même expérience utilisateur.
• Personnalisation de l'image : Démarrage du bloc-notes avec un ensemble particulier de packages préinstallés.
• Monter un volume partagé dans un ordinateur portable : Les blocs-notes fournis par chacun des fournisseurs de cloud (AWS/Azure/Vertex) permettent de créer un volume distinct pour chaque bloc-notes, mais ne permettent pas de monter un volume partagé. Par exemple, imaginez qu'une entreprise possède un ensemble de données de 500 Go qui est utilisé par plusieurs data scientists pour différents cas d'utilisation. Désormais, chaque DS doit dupliquer ces données et payer le coût de plusieurs volumes, même lorsque les ordinateurs portables ne fonctionnent pas. Cela pourrait potentiellement entraîner des centaines et des milliers de dollars en coûts liés au cloud !
  Avec Truefoundry, vous pouvez monter un volume de type NFS en mode lecture seule sur plusieurs ordinateurs portables et ainsi réduire les coûts de duplication des données !

Ordinateurs portables JNHost sur Kubernetes :

Une autre option consiste à héberger des blocs-notes sur Kubernetes, mais elle comporte ses propres défis, car les data scientists ne peuvent pas interagir directement avec Kubernetes et ont besoin d'un logiciel intermédiaire fournissant une interface simple pour lancer les blocs-notes Jupyter. Voyons quelles sont les options disponibles dans ce domaine :

Opérateur de bloc-notes Kubeflow :
Kubeflow contribue à rendre les déploiements de flux de travail d'apprentissage automatique (ML) sur Kubernetes simples, portables et évolutifs. Il dispose d'un ordinateur portable fonctionnalité qui permet de gérer et d'exécuter facilement les blocs-notes.
Bien que Kubeflow soit un grand projet open source qui fournit de nombreuses fonctionnalités pour les cas d'utilisation de l'apprentissage automatique, il est très difficile d'installer et de gérer Kubeflow par vous-même.

👍 Avantages :
- Des ordinateurs portables pour DS faciles à lancer et à gérer
- Répertoire personnel persistant sauvegardé par un disque
- Option pour des images prédéfinies pour sklearn, pytorch et tensorflow, fournie avec toutes les dépendances installées.
- Base de code open source
- Bénéficiez d'une fonction d'élimination qui arrête les blocs-notes après un certain temps d'inactivité.

👎 Inconvénients :
- Difficile de configurer Kubeflow sur Kubernetes. L'installation et la maintenance de Kubeflow prennent beaucoup de temps
- Pour fournir des blocs-notes dans plusieurs régions, différents clusters Kubernetes doivent être créés et Kubeflow doit être installé sur chaque cluster - ce qui entraîne des coûts d'infrastructure et de maintenance élevés.
- Les packages Python ne sont pas persistants par défaut, ce qui signifie que vous devez installer des packages à chaque redémarrage
- Aucun moyen direct d'obtenir un accès root vers le conteneur [peut être utile pour plusieurs cas d'utilisation]
- L'arrêt des blocs-notes ne peut pas être configuré au niveau de chaque bloc-notes et constitue un cadre mondial.

Hébergez JupyterHub sur Kubernetes :
JupyterHub est une excellente configuration pour les cas d'utilisation multi-utilisateurs, ce qui permet une utilisation optimale des ressources. Le déploiement de JupyterHub sur Kubernetes peut être effectué à l'aide d'un projet open source appelé De zéro à JupyterHub avec Kubernetes :

👍 Avantages :
 - Plusieurs utilisateurs peuvent facilement travailler ensemble grâce à la prise en charge de l'authentification
 - Configurez facilement l'arrêt automatique pour les ordinateurs portables
 - Gestion facile des environnements

👎 Inconvénients :
- Difficile à configurer et à gérer. Nous devons configurer la mise en réseau, les volumes persistants, la mise à l'échelle et l'équilibrage de charge pour que JupyterHub fonctionne correctement.
- Difficile d'exécuter des charges de travail GPU sur différents types de GPU sur Jupyterhub. Par exemple, lisez ce.
- Les environnements ne sont pas persistants

Bien qu'il existe actuellement de nombreuses solutions, chaque solution comporte ses propres limites. Chez Truefoundry, nous avons essayé de combler cette lacune et avons essayé de créer une solution pour ordinateurs portables qui réponde à tous les besoins d'une DS tout en maîtrisant les coûts. Dans la section suivante, nous décrirons notre approche pour créer la solution pour ordinateurs portables et les défis auxquels nous avons été confrontés pour la créer.

L'approche de Truefoundry en matière de création d'une solution pour ordinateurs portables

Véritable fonderie est une plateforme de développement pour les équipes de machine learning qui permet de déployer des modèles, des services, des jobs et maintenant des blocs-notes sur Kubernetes. Vous pouvez en savoir plus sur ce que nous faisons ici. Notre motivation pour créer une solution pour ordinateurs portables était simplement de permettre l'expérimentation et le développement sur notre plateforme. Après avoir étudié toutes les solutions disponibles, nous avons décidé de résoudre les problèmes et les fonctionnalités manquantes des autres plateformes afin que les data scientists puissent bénéficier de la meilleure expérience possible sans encourir de coûts importants. Voici quelques-unes des choses que nous voulions activer :

1. Environnements persistants
2. Possibilité pour l'utilisateur d'installer les dépendances root de manière dynamique et de ne pas se limiter à quelques ensembles de dépendances.
3. Possibilité de fonctionner sur place dans certains cas car leur prix peut être considérablement inférieur. L'expérience peut être mauvaise dans certains cas, car la machine virtuelle peut être récupérée, mais nous avons constaté que cela était assez rare dans la pratique et que le rapport coût-bénéfice justifie les problèmes occasionnels.
4. Possibilité de configurer l'arrêt automatique pour réduire les coûts.

Développez à partir de Kubeflow Notebooks

Kubeflow prend en charge l'exécution de blocs-notes sur Kubernetes. Il fournit un certain nombre de fonctionnalités prêtes à l'emploi sur les ordinateurs portables. Cependant, nous voulions résoudre les problèmes que nous avons soulignés ci-dessus dans Kubeflow Notebooks et offrir une expérience fluide aux data cientists et aux développeurs.

Nous avons donc dû apporter des modifications au contrôleur de l'ordinateur portable, l'intégrer au backend de Truefoundry et faire apparaître les blocs-notes sur notre interface utilisateur.

Nous avons installé le contrôleur de bloc-notes mais nous avons rencontré quelques problèmes, à cause desquels nous avons dû apporter des modifications au contrôleur kubeflow-notebook-controller :

1. L'élimination (fonction d'arrêt automatique pour les ordinateurs portables) ne fonctionne pas avec les points de terminaison personnalisés. Kubeflow Notebook Controller s'est appuyé sur certains formats de terminaux pour que la sélection fonctionne. Cela limite la capacité de l'utilisateur à définir le point de terminaison de son choix.
2. Même délai d'élimination sur l'ensemble du cluster. Cela signifie que vous ne pouvez définir un « délai d'inactivité » que pour les blocs-notes au niveau du cluster. Vous ne pouvez pas définir de valeurs de délai d'expiration différentes pour différents blocs-notes.
3. Le l'environnement Python par défaut n'est pas persistant

Nous avons résolu les deux problèmes ci-dessus et lancé le contrôleur pour ordinateur portable TFY
et l'a publié en tant que référentiel public de cartes Truefoundry sous forme de helm-chart. Vous pouvez trouver le tableau ici.

Interface utilisateur pour créer, démarrer et arrêter des blocs-notes :

Nous avons créé une interface utilisateur facile à comprendre pour permettre aux data scientists de démarrer des blocs-notes. L'utilisateur peut personnaliser le délai d'inactivité (durée d'inactivité après laquelle le bloc-notes sera arrêté), la taille du volume persistant (taille du disque qui stocke l'ensemble de données et les fichiers de code), les ressources (exigences en matière de processeur, de mémoire et de GPU) et faire tourner le bloc-notes !

Avec tous ces changements, nous avons lancé le v0 de nos carnets.

Mais nous sommes encore loin d'une bonne expérience utilisateur, voyons les avantages et les inconvénients de cette approche :

👍 Avantages :
- Répertoire personnel persistant [tous les fichiers et packages seront conservés]
- Le délai d'inactivité (Cull Timeout) par ordinateur portable peut être configuré
- Lancez le bloc-notes en quelques clics
- Lancez facilement un ordinateur portable avec des GPU

👎 Limites :
- L'environnement Python n'est pas persistant (tous les paquets installés disparaissent au redémarrage du pod)
- Aucun moyen d'installer des packages nécessitant un accès root
- Aucune méthode appropriée pour gérer plusieurs environnements à des fins d'expérimentation
- Impossible de configurer un point de terminaison pour le bloc-notes [ajouté dans la prochaine version]

Il est désormais essentiel de résoudre ces limites, car elles bloquent de nombreux flux de travail des Data Scientists, ce qui peut être aussi simple que d'installer des « apt-packages » tels que ffmpeg.

Résolution des problèmes critiques liés au flux de travail des utilisateurs

Jusqu'à présent, nous utilisions le images prédéfinies pour Jupyterlab fourni par Kubeflow. Mais puisque nous devons résoudre le problème des environnements non persistants, en autorisant l'accès root et en installant des apt-packages. Nous avons besoin de notre propre ensemble d'images Docker.
Voyons donc comment nous avons résolu ces problèmes !

• Environnements non persistants : L'objectif était de rendre l'environnement Python de base persistant afin que les utilisateurs puissent facilement utiliser des blocs-notes pour leurs cas d'utilisation.

- A modifié le script d'initialisation de l'image docker et a cloné l'environnement conda de base dans le répertoire personnel et l'a nommé base de Jupiter
- Ajoutez un fichier .condarc et définissez $ MAISON répertoire comme chemin d'environnement par défaut
- Modifiez le fichier .bashrc pour activer le base de Jupiter environnement par défaut

• Installer les packages apt
  L'utilisateur a la possibilité de fournir une liste des packages apt qu'il souhaite préinstaller avec l'image.
  Nous ajoutons ensuite une étape de construction et créons une image personnalisée qui est fournie avec tous les packages mentionnés préinstallés dans le bloc-notes !

• Fournir un accès root
  Dans de nombreux cas, l'utilisateur a besoin d'un accès root pour installer certains packages et essayer certaines choses rapidement. Pour cela, nous avons créé deux images pour chaque type d'image.
  truefoundrycloud/jupyter : dernière version et truefoundrycloud/jupyter : dernier-sudo. Où les images avec sudo fournissent à l'utilisateur un accès sudo à n0 mot de passe.
  Cela a été fait en installant le binaire sudo et en ajoutant l'utilisateur à la liste des sudoers comme décrit dans ce lien.

Remarque : étant donné que nous exécutons des blocs-notes sur Kubernetes avec le répertoire personnel monté, seul le répertoire personnel sera persistant. Les installations des packages racine ne seront pas persistantes lors des redémarrages des pods. Veuillez lire ce pour mieux comprendre la même chose.

En résolvant ces problèmes, nous avons résolu la plupart des problèmes rencontrés par les utilisateurs et avons fourni une expérience décente sur les ordinateurs portables. Mais avec le temps, nous avons constaté que les utilisateurs étaient confrontés à quelques défis que nous décrirons dans la section suivante.

Problèmes d'utilisabilité dans les blocs-notes

• Difficile de surveiller l'utilisation des ressources (processeur et mémoire pour un ordinateur portable) : Le noyau meurt très souvent en raison de problèmes de mémoire insuffisante. Nous rencontrons souvent des scénarios où nous exécutons un bloc-notes et où le noyau meurt pour l'une ou l'autre raison, ce qui peut être difficile à déboguer.

• La modification de l'environnement Python peut parfois conduire à un mauvais état où le le serveur portable ne parvient pas à redémarrer. Cela peut se produire pour plusieurs raisons, par exemple si quelqu'un va désinstaller jupyterlab le colis. L'environnement étant persistant, le bloc-notes ne démarre pas (une fois que le bloc-notes actuel est arrêté)
• Il est possible de gérer plusieurs environnements. Mais l'utilisateur doit ajouter manuellement l'environnement conda à spécification du noyau et assurez-vous que spécification du noyau est configuré correctement, ce qui peut poser problème.

Résoudre les problèmes d'utilisabilité

Ajout de mesures d'utilisation des ressources au bloc-notes :
Nous avons ajouté les mesures d'utilisation des ressources au bloc-notes en installant l'extension moniteur du système jupyterlab = 0.8.0 et a configuré ses paramètres dans le script d'initialisation en passant des arguments lors du démarrage du serveur Jupyterlab.

...


laboratoire Jupyter \
...
--resourceUseDisplay.mem_limit=$ {mem_limit} \
--resourceUseDisplay.cpu_limit=$ {cpu_limit} \
--resourceUseDisplay.TRACK_CPU_PERCENT=True \
--ResourceUseDisplay.MEM_WARNING_THRESHOLD=0,8


Voici à quoi cela ressemble sur l'interface utilisateur :

Séparer le noyau qui exécute le serveur Jupyterlab du noyau d'exécution

Nous devons nous assurer que, quelles que soient les modifications apportées par l'utilisateur dans le répertoire personnel, le portable redémarre toujours sans problème. Pour cela, nous avons utilisé l'environnement anaconda « de base » de /opt/conda le répertoire dans lequel démarrer le serveur Jupyterlab.
Parallèlement, nous avons créé un environnement distinct dans $ MAISON répertoire, mais cela ajoute un noyau du base environnement conda aux listes de noyaux.

Pour résoudre ce problème, nous avons installé nb_conda_kernels pour gérer les noyaux Jupyter. Nous avons configuré le script d'initialisation pour nous assurer que seuls les environnements Python persistants apparaissent dans la liste du noyau.

laboratoire Jupyter \
...
--CondaKernelSpecManager.conda_only=Vrai \
--CondaKernelSpecManager.Name_Format= {environnement} \
--CondaKernelSpecManager.env_filter=/opt/conda/* »


Ainsi, nous avons la garantie que le serveur de l'ordinateur portable démarrera toujours avec les modifications apportées par un utilisateur à l'intérieur du bloc-notes.
Cela facilite également la gestion de plusieurs noyaux. Il vous suffit de créer un nouvel environnement conda à l'aide de la commande conda create -n myenv et il commence à apparaître dans la liste des noyaux.

Ajout de la prise en charge de Code-Server

Alors que les ordinateurs portables Jupyter résolvent un certain nombre de problèmes. Il cesse d'aider pour un certain nombre de tâches :

1. Développement de services tels qu'une simple application Gadio ou Streamlit. Les utilisateurs peuvent écrire et exécuter le code dans Jupyter Notebook, mais ne peuvent pas afficher le service dans le navigateur.
2. Si un utilisateur travaille sur un projet dont le code est empaqueté dans plusieurs fichiers, l'environnement Jupyterlab n'est pas adapté à ce développement.

Compte tenu de ces limites, nous avons décidé de résoudre le problème. Nous avons ajouté la prise en charge du serveur de code afin de fournir une expérience IDE complète aux utilisateurs dans le navigateur.

En ajoutant la prise en charge de VS Code, nous permettons aux utilisateurs d'effectuer les opérations suivantes :

1. Développez et testez des services sur votre navigateur lui-même avec le proxy de redirection de port de VS Code. Cela signifie que vos services sont déployés hôte local : 8000 peut être mis à disposition sur $ {URL_BLOC-NOTES} /proxy/8000
2. Gérez facilement le code avec les packages appropriés, car cela fournit une expérience IDE complète.
3. Utilisez toutes les extensions VS Code les plus connues pour augmenter votre productivité.
4. Déboguez facilement les applications en les exécutant en mode débogage et en appliquant des points d'arrêt.

Cela a été fait en ajoutant une autre image Docker. Voici un schéma qui montre les images Docker de Truefoundry.

Accès SSH à votre ordinateur portable/VSCode :

Dans la plupart des cas, Hosted VS Code peut résoudre le problème. Mais il peut arriver (en particulier pour les ordinateurs portables Jupyter) que l'utilisateur soit bloqué et ait besoin d'un accès direct au conteneur qui exécute son serveur Jupyter Notebook/VS Code.
Nous avons donc simplifié les choses en installant un serveur SSH dans chacun des blocs-notes et pour vous connecter à votre conteneur, vous devez exécuter une commande simple et saisir votre mot de passe :

ssh -p 2222 jovyan@test-notebook.ctl.truefoundry.tech


La puissance de cet outil peut être améliorée avec votre extension VS Code appelée Explorateur à distance où vous pouvez ouvrir directement tous les fichiers de votre VS Code !
Cliquez ici pour en savoir plus

L'expérience utilisateur finale :

Avec toutes les fonctionnalités intégrées à notre solution pour ordinateurs portables, voici à quoi ressemble notre formulaire de déploiement d'ordinateurs portables :

Comparaison des prix

Enfin, comparons les prix de chacune des solutions gérées avec Truefoundry.

Comme Truefoundry fonctionne en déployant sur le cloud du client en connectant son cluster Kubernetes, voici la tarification de Truefoundry exécutée sur différents fournisseurs de cloud.

Dans le cas de Truefoundry, vous pouvez réellement économiser beaucoup d'argent car :

• Nous ne facturons aucun coût supplémentaire en plus du coût des machines virtuelles
• Nous prenons en charge l'exécution de blocs-notes sur des instances ponctuelles pour les charges de travail hors production, en plus de 50 à 60 % plus de coûts liés au cloud.

Conclusion

Il s'agissait d'une brève description de nos efforts pour créer la solution pour ordinateurs portables. Vous pouvez rejoindre notre Les amis de Truefoundry Canal Slack si vous souhaitez discuter en profondeur de notre approche ou si vous avez des suggestions.

Si vous souhaitez essayer notre plateforme, vous pouvez vous inscrire ici !