JupyterHub с SystemUserSpawner не работает - PullRequest
Новая
       5

JupyterHub с SystemUserSpawner не работает

0 голосов
/ 26 февраля 2019

Я пытаюсь запустить JupyterHub на виртуальной машине, используя dockerspawner.SystemUserSpawner, порождающий экземпляры Jupyter Lab.

В моем jupyterhub_config.py есть следующие (дополнительные) строки: 

c.Spawner.default_url = '/lab'
c.Spawner.cmd = ['jupyter', 'labhub']
c.JupyterHub.spawner_class = 'dockerspawner.SystemUserSpawner'

(плюс строки для bind_url и hub_ip).Все остальное должно быть по умолчанию.

После запуска (jupyterhub -f /etc/jupyterhub/jupyterhub_config.py) и входа в браузер я сталкиваюсь с ошибкой 500.Журнал командной строки выглядит следующим образом: 

[D 2019-02-26 16:55:37.869 JupyterHub dockerspawner:644] Getting container 'jupyter-testuser'
[D 2019-02-26 16:55:37.873 JupyterHub dockerspawner:629] Container 8bf627d status: {'Dead': False,
     'Error': '',
     'ExitCode': 1,
     'FinishedAt': '2019-02-26T15:55:29.518823812Z',
     'OOMKilled': False,
     'Paused': False,
     'Pid': 0,
     'Restarting': False,
     'Running': False,
     'StartedAt': '2019-02-26T15:55:28.446881243Z',
     'Status': 'exited'}
[W 2019-02-26 16:55:37.874 JupyterHub web:1667] 500 GET /hub/user/testuser/ (www.xxx.yyy.zzz): Spawner failed to start [status=ExitCode=1, Error='', FinishedAt=2019-02-26T15:55:29.518823812Z]. The logs for testuser may contain details.
[D 2019-02-26 16:55:37.875 JupyterHub base:880] No template for 500

Затем сам JupyterHub застревает в (бесконечном?) Цикле, пытаясь порождать контейнер каждые 10 секунд.

Игнорирование пропущенных 500шаблон, я был немного мудрее из сообщения о состоянии контейнера, но docker logs jupyter-testuser показывает: 

....
[C 2019-02-26 15:55:29.360 SingleUserLabApp notebookapp:1707] Running as root is not recommended. Use --allow-root to bypass.
[D 2019-02-26 15:55:29.360 SingleUserLabApp application:647] Exiting application: jupyter-notebook

Когда я изменяю jupyterhub_config.py, чтобы включить 

c.Spawner.cmd = ['jupyter', 'labhub', '--allow-root']
c.DockerSpawner.remove = True

все работает, нос нежелательным предупреждением: я теперь root в контейнере, и любой файл, который я создаю в домашнем каталоге, принадлежит не testuser, а (Docker container) root.Внутри самой виртуальной машины testuser не может, например, удалить эти файлы.

(обратите внимание на c.DockerSpawner.remove = True: если я не включу это, JupyterHub застревает в предыдущем контейнере, который не '--allow-root)

Документация предполагает, что начальная конфигурация должна быть правильной, и --allow-root не требуется для стандартного стека докеров (я, очевидно, здесь использую стандартную jupyterhub/singleuser:0.9).

Для сравнения, использование dockerspawner.DockerSpawner работает нормально.

Я не вижу, что мне не хватает, или где искать дополнительные параметры отладки.Поэтому любые предложения приветствуются.

Jupyter (Hub) версии 0.9.4 в Ubuntu 18.04.2

1 Ответ

0 голосов
/ 27 февраля 2019

Ошибка в c.Spawner.cmd (c.Spawner.cmd = ['jupyter', 'labhub']).

Это запускает контейнер Docker с аргументами jupyter labhub, аналогично запуску его из командной строки как docker run jupyter/singleuser:0.9 jupyter labhub (с некоторымидополнительные переменные среды).

Однако Docker будет читать первый аргумент после имени контейнера как CMD, а не как аргумент CMD в файле Docker.То есть Dockerfile для основной записной книжки (и, следовательно, для jupyter / singleuser) имеет следующее: 

# Configure container startup
ENTRYPOINT ["tini", "-g", "--"]
CMD ["start-notebook.sh"]

Это запустит точку входа с помощью следующей команды, то есть tini -g -- start-notebook.sh, за которой следуют заданные аргументыдо docker run.Однако, поскольку этот первый аргумент заменяет CMD, то выполняется tini -g -- jupyter, а labhub передается в качестве аргумента jupyter.Последний обходит скрипты start-notebook.sh и, следовательно, start.sh, которые фактически заботятся об обработке настроек идентификатора пользователя внутри контейнера.То есть эти стартовые скрипты не позволяют root фактически запускать команду jupyter.Пропуск сценариев не помешает этому, и команда jupyter запускается от имени пользователя root с проблемами, указанными в вопросе.

Есть два возможных выхода из этого;мне неясно, какой из них предпочтительнее:

  1. , включая start-notebook.sh или start.sh в настройке c.Spawner.cmd (я выбрал start.sh): 

    c.Spawner.cmd = ['start.sh', 'jupyter', 'labhub']

    Это заменит команду start-notebook.sh на start.sh (что, как правило, нормально; первая - небольшая обертка вокруг второй), а затем jupyter labhub будет предоставлено в качестве аргументов start.sh.Это именно то, что нужно.

  2. установите переменную среды JUPYTER_LAB_ENABLE, а отключите c.Spawner.cmd: 

    #c.Spawner.cmd = ['start.sh', 'jupyter', 'labhub']
c.SystemUserSpawner.environment = {'JUPYTER_ENABLE_LAB': '1'}

    start.sh просматривает переменную среды JUPYTER_ENABLE_LAB (которая передается через SystemUserSpawner через контейнер Docker) и запускает лабораторию, когда эта переменная установлена ​​(таким образом, ее не нужно устанавливать на '1' обязательно).В этом случае нет необходимости передавать дополнительные аргументы в контейнер Docker или сценарий start.sh, следовательно, c.Spawner.cmd отключено.

...