JupyterHub与SystemUserSpawner失败

Question

我试图在虚拟机上运行一个JupyterHub，使用dockerspawner.SystemUserSpawner，生成木星实验室实例。

我的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

事情确实有效，但有一个不必要的警告:我现在是容器中的根用户，我在主目录中创建的任何文件都不是由testuser拥有，而是由(Docker容器) root拥有。例如，在VM内部，testuser无法删除这些文件。

(c.DockerSpawner.remove = True上的注意:如果不包括这个，JupyterHub就会卡在上一个没有--allow-root的容器上)

文档表明，初始配置应该是正确的，标准的停靠堆栈不需要--allow-root (显然，我在这里使用的是默认配置，jupyterhub/singleuser:0.9)。

比较而言，使用dockerspawner.DockerSpawner可以工作得很好。

我不知道我缺少了什么，也不知道在哪里可以找到更多的调试选项。因此，欢迎提出任何建议。

Ubuntu 18.04.2版的木星(集线器) 0.9.4

Answer 1

错误出现在c.Spawner.cmd (c.Spawner.cmd = ['jupyter', 'labhub'])中。

这将使用参数jupyter labhub启动Docker容器，类似于以docker run jupyter/singleuser:0.9 jupyter labhub的形式从命令行运行它(带有一些附加的环境变量)。

但是，Docker将把容器名称后面的第一个参数读取为CMD，而不是作为Dockerfile中CMD的参数。也就是说，基本笔记本的Dockerfile (从而是jupyter/singleuser文件)具有以下内容：

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

这将使用next命令运行入口点，即tini -g -- start-notebook.sh，然后是给docker run的参数。但是，由于第一个参数取代了CMD，所以执行的是tini -g -- jupyter，其中labhub作为参数传递给jupyter。后者绕过了start-notebook.sh和start.sh脚本，它们实际上负责处理容器中的用户ID设置。也就是说，这些启动脚本阻止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。