云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载本篇以 Jupyter Docker Stacks 官方文档的 FAQdocs/using/faq.md为主线系统讲解容器化运行 Jupyter 应用时最常被问到的四个问题如何持久化环境与用户数据、为什么官方镜像不预装所有包、默认用户jovyan的来源与结构以及如何安全地授予容器内用户 rootsudo权限。读完本文你能够独立完成子镜像打包来固化依赖、用 bind mount 持久化工作文件并从 docker-stacks-foundation 入口脚本 的源码层面理解用户与权限机制的工作原理。一、如何持久化用户数据FAQ 开篇就把持久化拆成两种截然不同、处理方式完全不同的数据类型环境数据你通过mamba、conda、pip、apt-get等工具安装的包用户数据你自己创建的文件如 Python 脚本、notebook、文本文件等。1.1 环境持久化必须在构建期安装而非运行期安装在运行中的容器里安装包例如在容器终端执行pip install package是 FAQ 中特别强调的常见误区容器停止后这类变更不会保留到下一次运行。其原因是容器文件系统基于不可变镜像层运行期的写入发生在可写层容器销毁即丢失。正确的做法是创建一个继承自官方镜像的子镜像inherited image在构建 Dockerfile 时一次性安装包。官方文档给出的标准做法来自 docs/using/recipes.md 的配方如下。使用mamba install官方推荐ARG BASE_IMAGEquay.io/jupyter/base-notebook FROM $BASE_IMAGE RUN mamba install --yes flake8 \ mamba clean --all -f -y \ fix-permissions ${CONDA_DIR} \ fix-permissions /home/${NB_USER} # Install from the requirements.txt file COPY --chown${NB_UID}:${NB_GID} requirements.txt /tmp/ RUN mamba install --yes --file /tmp/requirements.txt \ mamba clean --all -f -y \ fix-permissions ${CONDA_DIR} \ fix-permissions /home/${NB_USER}该示例源文件位于 docs/using/recipe_code/mamba_install.dockerfile。pip用法完全类似docs/using/recipe_code/pip_install.dockerfileARG BASE_IMAGEquay.io/jupyter/base-notebook FROM $BASE_IMAGE # Install in the default python3 environment RUN pip install --no-cache-dir flake8 \ fix-permissions ${CONDA_DIR} \ fix-permissions /home/${NB_USER} # Install from the requirements.txt file COPY --chown${NB_UID}:${NB_GID} requirements.txt /tmp/ RUN pip install --no-cache-dir --requirement /tmp/requirements.txt \ fix-permissions ${CONDA_DIR} \ fix-permissions /home/${NB_USER}构建并运行子镜像docker build --rm --tag my-custom-image . docker run -it --rm \ -p 8888:8888 \ my-custom-image源码级补充——fix-permissions为何必不可少构建期安装发生在 root 上下文中装完必须修正权限否则运行期以非特权用户启动时无法读写。fix-permissions 脚本对传入目录执行两件事用find筛选出组不是${NB_GID}或缺少组读写权限的文件批量chgrpchmod grwX再对目录单独设置 setgid 位chmod gs使新建文件自动继承${NB_GID}组。该设计用find跳过已符合权限的文件避免图像膨胀massive image explosion这一点在脚本头部注释中有明确说明。基础镜像 Dockerfile 在构建阶段就安装了这个脚本。1.2 用户数据持久化bind mount 或 Docker Volume对于脚本、notebook 等用户文件FAQ 的答案是使用Docker bind mount或Docker Volume。官方运行文档 docs/using/running.md 的 Example 2 给出了可直接复制的 bind mount 示例docker run -it --rm -p 10000:8888 -v ${PWD}:/home/jovyan/work quay.io/jupyter/r-notebook:2026-07-28-v ${PWD}:/home/jovyan/work把宿主机当前目录挂到容器内/home/jovyan/work按Ctrl-C两次后容器被--rm销毁但挂载目录中的新文件和改动会保留在宿主机上容器内其他位置的改动全部丢失。需要注意的一个细节Jupyter 的root_dir默认是/home/jovyan新 notebook 会默认保存到这里而不是work子目录。若要改变默认目录可在启动命令中追加参数start-notebook.py --ServerApp.root_dir/home/jovyan/work如果挂载时遇到Permission denied典型场景宿主机目录属主是root而容器内jovyan用户无法写入官方文档在 docs/using/troubleshooting.md 的 Permission denied when mounting volumes 一节给出了两套方案运行时修正挂载目录属主以 root 启动容器并设置CHOWN_EXTRA环境变量入口脚本会在运行前执行chowndocker run --detach \ -v my-vol:container-dir \ -p 8888:8888 \ --user root \ -e CHOWN_EXTRAcontainer-dir \ -e CHOWN_EXTRA_OPTS-R \ quay.io/jupyter/minimal-notebook若挂载点在/home/之内也可以改用-e CHOWN_HOMEyes和CHOWN_HOME_OPTS-R。让容器内 UID/GID 与宿主机用户一致bind mount 会把宿主机权限原样带入容器因此可显式指定NB_UID/NB_GID同样需要--user rootdocker run -it --rm \ --user root \ -p 8888:8888 \ -e NB_UID1234 \ -e NB_GID5678 \ -v ${PWD}/test:/home/jovyan/work \ quay.io/jupyter/minimal-notebook:latest从 start.sh 的源码可以看到其实现当容器以 root 启动且NB_UID/NB_GID与当前用户不一致时脚本会用groupadd/useradd重建该用户并打印Update ${NB_USER}s UID:GID to ...日志测试用例 test_uid_change 验证了NB_UID1010后id输出为uid1010(jovyan)。二、为什么官方镜像不会预装你最喜欢的包FAQ 对这一问题的回答很直接用户群体庞大且需求各异把所有想要的包都装进去是不可能的。因此项目提供了多个镜像层级供选择策略是挑选与你需求最接近的镜像在该镜像之上用mamba/pip添加你自己的包即上文 1.1 的子镜像做法。挑选最接近的镜像这一步可以借助 docs/using/selecting.md 中的核心镜像族Core Stacks。从各 Dockerfile 的FROM语句看构建依赖树大致为docker-stacks-foundation (conda/mamba jovyan 用户 tini/start.sh) └── base-notebook (JupyterLab / Notebook / JupyterHub singleuser) └── minimal-notebook (git、curl、TeX Live 等工具) ├── r-notebook ├── julia-notebook └── scipy-notebook ├── tensorflow-notebook (含 CUDA 变体) ├── pytorch-notebook (含 CUDA 变体) ├── datascience-notebook └── pyspark-notebook └── all-spark-notebook例如 base-notebook 的 Dockerfile 显式继承docker-stacks-foundationpyspark-notebook 继承 scipy-notebookall-spark-notebook 再继承 pyspark-notebook。任何一个镜像都完整继承其所有祖先镜像的内容因此选更高层级的镜像意味着获得更多预装包但镜像也更大。对于 CI 或组织级定制官方建议优先拉取现成镜像确有系统级定制需求时再走自建镜像路线参见 docs/using/custom-images.md。三、jovyan用户是谁FAQ 给出了jovyan名称的出处源自 Jupyter 社区对该术语的定义最初在项目的 GitHub issue #358 的评论中被引用Jo·vy·an /ˈjōvēən/ noun – an inhabitant of JupyterJupyter 的居民Jovyan是 Jupyter 社区成员的一个特殊称谓同时被用作 Jupyter Docker Stacks 容器内的默认非特权用户 ID。源码中的实际定义。jovyan及其 UID/GID 在 images/docker-stacks-foundation/Dockerfile 中通过构建参数固化ARG NB_USERjovyan ARG NB_UID1000 ARG NB_GID100随后 Dockerfile 第 83-93 行 创建该用户useradd --no-log-init --create-home --shell /bin/bash --uid ${NB_UID} --no-user-group ${NB_USER}并把/opt/conda与/home/jovyan的属主设给jovyan:usersGID 100。相关环境变量在 第 55-65 行 写入镜像NB_USER、NB_UID、NB_GID、CONDA_DIR/opt/conda、HOME/home/jovyan。理解jovyan对日常操作的三个直接影响挂载路径bind mount 的容器侧路径通常写/home/jovyan/workUID 匹配宿主机用户 UID 与 1000 不一致时会出现权限错误需按上文 1.2 的NB_UID/NB_GID方案对齐可重命名入口脚本 start.sh 在 root 启动时会把jovyan重命名为NB_USER指定的名字并尽力把家目录内容复制或符号链接过去test_nb_user_change 验证了把用户改名为nayvoj后uid1000(nayvoj)且家目录属主正确。四、如何给容器内用户授予 rootsudo权限FAQ 对这一问题的答案是项目提供了一个启用 sudo的官方配方docs/using/recipes.md 的 Usingsudowithin a container 一节。背景是镜像默认禁用了NB_USER的密码认证这是刻意的设计避免镜像带着一个容易被遗忘的弱默认密码跑到公开主机上。授予容器内用户免密 sudo的方法是在 docker 命令行加上--user root与-e GRANT_SUDOyesdocker run -it --rm \ --user root \ -e GRANT_SUDOyes \ quay.io/jupyter/base-notebook官方明确警告只在信任该用户、或容器运行在隔离主机上时才应启用 sudo并建议阅读 Docker 官方文档中关于以 root 运行容器与用户命名空间重映射的安全说明。源码级实现。GRANT_SUDO的处理逻辑在 start.sh 第 137-140 行if [[ ${GRANT_SUDO} 1 || ${GRANT_SUDO} yes ]]; then _log_info Granting ${NB_USER} passwordless sudo rights! echo ${NB_USER} ALL(ALL) NOPASSWD:ALL /etc/sudoers.d/added-by-start-script fi这段代码只有在容器以 root 身份启动脚本第 49 行的id -u 0分支时才会执行若非 root 启动却设置了GRANT_SUDO脚本会打印警告container must be started as root to grant sudo permissions!第 189-191 行。此外第 134 行 还会把${CONDA_DIR}/bin前置写入 sudo 的secure_path保证sudo jupyter调用的是 conda 中的 Jupyter 而非系统版本——这由 test_sudo断言sudo id输出uid0(root)和 test_sudo_path断言sudo which jupyter指向/opt/conda/bin/jupyter两个测试用例共同验证。总结问题官方答案关键依据环境包如何持久化构建继承镜像构建期安装运行期安装不保留recipes 配方、mamba 示例 Dockerfile用户文件如何持久化bind mount 或 Docker Volume权限问题用CHOWN_EXTRA或NB_UID/NB_GID解决running.md Example 2、troubleshooting.md为什么不预装所有包需求多样、全装不现实选最接近的镜像再叠加selecting.md 镜像层级jovyan是什么社区称谓同时是容器默认非特权用户UID 1000GID 100foundation Dockerfile如何给 jovyan 授 root 权限--user root -e GRANT_SUDOyes仅在可信/隔离环境使用start.sh、sudo 配方赞分享云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载相关推荐Convex 用户认证与授权实战从 Auth0 登录到用户数据持久化Convex 用户认证与授权实战从 Auth0 登录到用户数据持久化 导读 本文基于开源仓库 convex backend 中的 users and auth数据库后端终极指南Jupyter Docker Stacks容器用户权限管理的完整实践 Jupyter Docker Stacks是一套开箱即用的Docker镜像集合专为数据科学和机器学习工作流设计。在容器化部署过程中合理的root与非r云原生开发工具数据科学AlohaMini进阶开发自定义控制算法与ROS节点扩展指南AlohaMini进阶开发自定义控制算法与ROS节点扩展指南 AlohaMini是一款开源双臂移动机器人具备电动升降功能为机器人开发者提供了丰富的扩展空间机器人具身智能硬件开发人工智能微调ROS上一篇如何用MediaCrawler一站式采集五大社交媒体平台数据下一篇AndroidCupsPrint终极指南如何在3分钟内完成移动设备打印部署创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考