Comment auto-héberger JupyterLab en 2026 : jetons, noyaux et notebooks persistants

La démonstration JupyterLab la plus simple prouve qu’un processus écoute sur le port 8888. La production exige des preuves plus solides. Elle doit réussir ce scénario même après le remplacement du conteneur : se connecter avec un jeton, démarrer un noyau, exécuter une cellule de notebook, enregistrer le résultat, reconnecter le WebSocket et rouvrir le notebook.

JupyterLab est déployé dans un but précis : disposer de notebooks dans le navigateur, à proximité des données et des ressources de calcul. Son piège de déploiement le plus fréquent est que le proxy interrompt les WebSockets des noyaux ou que les notebooks montés appartiennent à root. La gestion de l’URL publique et la persistance de l’état doivent donc recevoir la même attention que le démarrage de l’image.

Prouver que JupyterLab résiste à un remplacement

Inventoriez chaque artefact durable : notebooks, données, environnements et fichiers de dépendances reproductibles. Montez /home/jovyan/work avant l’initialisation, écrivez des données d’exemple inoffensives, puis remplacez le conteneur afin de prouver que ce chemin est réellement persistant. Incluez la configuration qui modifie l’interprétation des données stockées, et pas uniquement le répertoire le plus volumineux.

Définissez la rétention, copiez les sauvegardes hors de l’hôte et exécutez une restauration en environnement vierge. Le test JupyterLab est terminé lorsque les notebooks, les données et les spécifications d’environnement sont restaurés et qu’une cellule représentative produit le résultat attendu. Si les snapshots font partie du plan, utilisez les recommandations sur le PITR et les snapshots pour documenter ce que chaque mécanisme permet de restaurer.

Définir d’abord les critères de réussite de JupyterLab

Ne laissez pas l’image JupyterLab déterminer accidentellement l’architecture de production. L’image fournit un processus sur le port 8888 ; le stockage, le routage et les exigences externes nécessitent toujours des cycles de vie définis avec soin. L’exigence du runtime local est explicite : des mounts de données et des ressources de calcul dimensionnées pour les workloads de notebooks. Gardez son cycle de vie explicite afin que le déplacement de JupyterLab entre plusieurs hôtes ne modifie pas silencieusement son comportement.

Le déploiement est prêt pour des tests plus approfondis lorsqu’il peut se connecter avec un jeton, démarrer un noyau, exécuter une cellule de notebook, enregistrer le résultat, reconnecter le WebSocket et rouvrir le notebook. Suivez la transaction dans les logs et surveillez la RAM et le CPU des noyaux, les copies de données, l’entraînement des modèles et les processus de language server, plutôt que l’interface web de JupyterLab. Ces observations indiquent si la topologie actuelle isole le bon composant.

Cinq vérifications plus fiables que la healthcheck du conteneur

Le compte rendu de release de JupyterLab doit contenir des faits, pas un simple « ça a l’air bon ». Enregistrez le digest de l’image sélectionnée, le checksum de la configuration, le hostname public et le résultat horodaté des opérations suivantes : se connecter avec un jeton, démarrer un noyau, exécuter une cellule de notebook, enregistrer le résultat, reconnecter le WebSocket et rouvrir le notebook. Utilisez des données d’exemple hors production afin que la vérification puisse être exécutée après chaque déploiement.

Prouvez séparément deux événements du cycle de vie. Le remplacement d’un conteneur doit préserver le fonctionnement normal ; une récupération en environnement vierge doit montrer que les notebooks, les données et les spécifications d’environnement sont restaurés et qu’une cellule représentative produit le résultat attendu. Pendant l’exécution des vérifications, mesurez la RAM et le CPU des noyaux, les copies de données, l’entraînement des modèles et les processus de language server, plutôt que l’interface web de JupyterLab, et conservez le résultat comme enveloppe de référence pour cette version.

Testez également une condition refusée ou invalide : soumettez une entrée inoffensive proche de la limite de ressources ou de format associée à cette frontière : le proxy interrompt les WebSockets des noyaux ou les notebooks montés appartiennent à root. JupyterLab doit échouer de manière diagnostiquable et ne doit pas écraser un état sain. Rétablissez la condition valide, relancez l’exemple et joignez les logs pertinents après masquage des informations sensibles. Ces artefacts fournissent des éléments concrets pour décider d’un futur rollback.

Lancer JupyterLab avec des valeurs par défaut observables

Le premier conteneur doit être facile à supprimer et à recréer. Conservez les données hors de la couche inscriptible, liez le port 8888 uniquement là où le proxy peut l’atteindre et transmettez la configuration au runtime.

docker run -d \
  --name jupyterlab \
  --restart unless-stopped \
  -p 127.0.0.1:8888:8888 \
  -v jupyterlab-data:/home/jovyan/work \
  -e JUPYTER_TOKEN=replace-with-a-long-random-value \
  quay.io/jupyter/minimal-notebook:latest

Figez l’image après le test initial. Lisez l’erreur de démarrage la plus ancienne plutôt que le dernier message de redémarrage, vérifiez chaque mount avec docker inspect et suivez les logs pendant que vous vous connectez avec un jeton, démarrez un noyau, exécutez une cellule de notebook, enregistrez le résultat, reconnectez le WebSocket et rouvrez le notebook. Cette séquence permet de distinguer une mauvaise commande d’image d’un problème de dépendance ou de permissions.

Ne donnez pas l’accès à tout l’hôte à JupyterLab

Fermez la fenêtre d’initialisation dès que le premier administrateur de confiance existe. Le piège concret de JupyterLab consiste à désactiver le jeton sur un notebook exposé à Internet ou à monter de larges chemins de l’hôte ; la limite la plus sûre consiste à conserver l’authentification par jeton, à ne monter que les données prévues et à ne pas exposer un terminal privilégié de l’hôte sans précaution.

Traitez JUPYTER_TOKEN en fonction de son rôle dans JupyterLab : gardez les valeurs sensibles hors de Git, documentez les effets de la rotation et ne remplacez jamais un exemple public en production. Le réseau privé doit transporter les identifiants des dépendances, et les rôles dans JupyterLab doivent accorder uniquement l’action minimale utile. Ne faites pas apparaître les corps de requêtes sensibles ni les réponses des providers dans les logs courants.

Tester JupyterLab depuis l’extérieur du serveur

Choisissez le hostname JupyterLab définitif avant que les utilisateurs n’enregistrent des callbacks ou des paramètres client, puis acheminez le notebook server via HTTPS avec la prise en charge des WebSockets. La route de la plateforme doit terminer TLS une seule fois et cibler le port privé 8888.

Exécutez la transaction d’acceptation depuis l’extérieur. Si le client n’atteint jamais JupyterLab, utilisez la checklist de validation SSL pour vérifier le DNS et le certificat. Si la requête atteint JupyterLab mais que le proxy interrompt les WebSockets des noyaux ou que les notebooks montés appartiennent à root, cessez de modifier les redirections du proxy et inspectez plutôt la frontière propre à l’application.

Des logs qui répondent à la question suivante

Utilisez la séquence « se connecter avec un jeton, démarrer un noyau, exécuter une cellule de notebook, enregistrer le résultat, reconnecter le WebSocket et rouvrir le notebook » comme smoke test JupyterLab après chaque déploiement. Ses métriques de support sont la RAM et le CPU des noyaux, les copies de données, l’entraînement des modèles et les processus de language server, plutôt que l’interface web de JupyterLab ; déclenchez des alertes lorsque ces ressources approchent d’un seuil qui dégrade l’action de l’utilisateur.

Le principal risque lors d’une modification vient du fait que les packages de l’image de base, les extensions de notebooks et les fichiers d’environnement nécessitent un test de reproductibilité avant toute mise à niveau. Une release sûre démarre à partir d’un snapshot restaurable et valide chaque changement d’état irréversible avant de déplacer le trafic. Lorsque le proxy interrompt les WebSockets des noyaux ou que les notebooks montés appartiennent à root, conservez suffisamment longtemps le conteneur défaillant pour lire sa configuration et sa première erreur.

Un déploiement Dockup nécessite toujours un test d’acceptation JupyterLab

La couche plateforme de JupyterLab se compose du port 8888, de l’ingress, de TLS, de la configuration du runtime, du stockage et de l’accès aux dépendances. Dockup peut reproduire ces éléments pour sa propre infrastructure ou pour un serveur connecté par le client.

L’opérateur termine ensuite la couche produit : acheminer le notebook server via HTTPS avec la prise en charge des WebSockets ; appliquer cette règle d’accès — conserver l’authentification par jeton, ne monter que les données prévues et ne pas exposer un terminal privilégié de l’hôte sans précaution — ; puis exécuter « se connecter avec un jeton, démarrer un noyau, exécuter une cellule de notebook, enregistrer le résultat, reconnecter le WebSocket et rouvrir le notebook ». Enregistrer ce test avec le déploiement évite de confondre le provisioning automatisé avec la disponibilité de l’application.

Foire aux questions

De quoi JupyterLab a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur JupyterLab sur le port 8888 via une seule origine HTTPS. L’exigence du runtime local est explicite : des mounts de données et des ressources de calcul dimensionnées pour les workloads de notebooks. Ne considérez pas JupyterLab comme prêt tant que vous ne pouvez pas vous connecter avec un jeton, démarrer un noyau, exécuter une cellule de notebook, enregistrer le résultat, reconnecter le WebSocket et rouvrir le notebook.

Quelles données JupyterLab faut-il inclure dans une sauvegarde ?

Conservez /home/jovyan/work et incluez les notebooks, les données, les environnements et les fichiers de dépendances reproductibles dans le même manifeste de récupération. Une restauration JupyterLab en environnement vierge n’est réussie que lorsque les notebooks, les données et les spécifications d’environnement sont restaurés et qu’une cellule représentative produit le résultat attendu.

JupyterLab nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de JupyterLab et conservez le port 8888 sur la route interne. Appliquez correctement le paramètre JupyterLab : acheminez le notebook server via HTTPS avec la prise en charge des WebSockets. Pour JupyterLab, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent du client vis-à-vis de l’origine.

Comment tester une mise à niveau de JupyterLab ?

Restaurez l’état actuel de JupyterLab dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les packages de l’image de base, les extensions de notebooks et les fichiers d’environnement nécessitent un test de reproductibilité avant toute mise à niveau. Conservez l’image JupyterLab précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.