JupyterHub vs JupyterLab: что деплоить на команду

Для чего создавался каждый

JupyterLab создавался как современная, расширяемая среда для интерактивных вычислений на одну персону, пришедшая на смену классическому Notebook. JupyterHub проектировался как платформа для предоставления этой среды (или классического Notebook) множеству пользователей в изолированном и управляемом виде.

В чём реально отличаются

Различие фундаментально: JupyterLab — это клиентское веб-приложение (интерфейс + сервер ядра), а JupyterHub — это шлюз (gateway), прокси и менеджер жизненного цикла для множества таких приложений.

Технически, при запуске JupyterLab вы получаете один процесс (или несколько, если сконфигурировано иначе), который обслуживает одного пользователя. Все файлы, переменные, запущенные ядра и состояние сессии принадлежат этому инстансу. Аутентификация, если она есть, часто реализована на уровне токена в URL.

JupyterHub состоит из нескольких ключевых компонентов: хаба (Hub), который управляет аутентификацией и пользователями; прокси, который маршрутизирует запросы; и споунера (spawner), который запускает и останавливает односерверные инстансы (которые могут быть JupyterLab) для каждого пользователя по запросу. Каждый пользователь получает свой изолированный процесс (или контейнер, или pod), часто с собственной файловой системой и квотами на ресурсы (CPU, RAM). Аутентификация централизована (OAuth, LDAP, GitHub и т.д.), а администратор может управлять пользователями, их окружениями и ресурсами.

Когда выбрать первый

Выбор в пользу развертывания просто JupyterLab (один инстанс) для команды оправдан в очень ограниченном числе сценариев. Во-первых, это маленькая, доверенная команда (2-5 человек), где все работают над одним проектом с общей файловой структурой и нет риска конфликта зависимостей или перезаписи файлов. Во-вторых, это прототипирование или временная задача, где скорость развертывания критична — поднять один контейнер с JupyterLab в Docker или на виртуальной машине можно за минуты. В-третьих, при жестких ограничениях на ресурсы: один общий инстанс потребляет меньше памяти и CPU, чем множество изолированных окружений JupyterHub. Однако минусы такого подхода очевидны: отсутствие изоляции, невозможность индивидуального управления пакетами, риск “падения” сервера для всех из-за ошибки одного и сложность с аутентификацией.

Когда выбрать второй

JupyterHub — это выбор для любой производственной или устойчивой командной работы. Конкретные критерии: команда больше 3-5 человек; необходимость разделения проектов, данных или версий библиотек между пользователями; требование интеграции с корпоративной аутентификацией (LDAP/AD, OIDC); необходимость гарантировать квоты на ресурсы, чтобы один пользователь не исчерпал всю память сервера; потребность в разных вычислительных окружениях для разных задач (например, один образ с TensorFlow, другой — с PySpark). Ключевой сценарий — развертывание в Kubernetes через проект Zero to JupyterHub. Это стандартный и наиболее надежный путь, который дает автоматическое масштабирование, устойчивость (поды перезапускаются при падении), использование Persistent Volume Claims для персистентного хранения данных каждого пользователя и легкое управление образами Docker для окружений. Минусы — значительная сложность первоначальной настройки и требование к инфраструктуре (работающий Kubernetes-кластер).

Могут ли работать вместе

Да, и это их стандартный и предполагаемый режим работы. JupyterHub не является альтернативным интерфейсом. Он выступает как оркестратор для JupyterLab. Пользователь аутентифицируется в Hub, после чего Hub через споунер (например, KubeSpawner в Kubernetes) запускает отдельный pod (или контейнер), внутри которого работает именно JupyterLab (или иной single-user server). Прокси JupyterHub перенаправляет пользователя в его личный, изолированный инстанс JupyterLab. Таким образом, команда получает преимущества многопользовательской управляемой платформы (JupyterHub), а каждый исследователь или инженер работает в привычном, мощном интерфейсе JupyterLab. Настройка образа Docker для этих инстансов — это отдельная важная задача, которая определяет, какие библиотеки, инструменты и расширения будут доступны пользователям в их JupyterLab.