云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载关联文档docs/changelog.md经 CHANGELOG.md 全文引入记录仓库中以 Pull Request 形式手动引入的破坏性与重要变更导读本文以 CHANGELOG.md 为骨架系统梳理 Jupyter Docker Stacks 项目从 2024 年 10 月至 2026 年 8 月的关键演进包括ROOT_IMAGE/BASE_IMAGE构建参数的破坏性重命名、Python 与 mamba 的版本升级、Spark 生态栈重构、镜像 digest 锁定与 cosign 签名、SBOM 发布、日志体系优化以及测试与 CI 流水线的持续改造。读者将理解每项变更的动机、影响范围哪些镜像受影响、以及它们在仓库源码中的真实落地位置从而为自己的镜像构建、升级与二次开发提供可验证的决策依据。一、这份 Changelog 记录什么docs/changelog.md并非独立撰写而是通过 Sphinx 的include指令将仓库根目录的 CHANGELOG.md 全文引入文档站其文档开头也明确指出本 Changelog 仅记录通过 Pull Request 手动引入仓库的破坏性Breaking和/或重要Significant变更所有镜像的完整清单manifests可在项目 Wiki 中查看。这意味着它刻意排除了日常依赖升级与常规修补聚焦于三类信息影响范围标注每条目都标注Affected:如all images、pyspark-notebook、docker-stacks-foundation、users building images locally帮助使用者快速判断是否需要关注破坏性/非破坏性分类Breaking表示可能影响现有构建与运行方式Non-breaking表示行为兼容的改进PR 追溯每条变更给出对应的 Pull Request 编号供深入查阅细节。仓库中还维护着配套的 wiki/ 目录Home.md、config.py、update_wiki.py 等用于自动生成各镜像的软件包清单页面与 Changelog 互为补充。二、破坏性变更升级前必须了解的事2.1 构建参数重命名ROOT_CONTAINER→ROOT_IMAGE、BASE_CONTAINER→BASE_IMAGE2024-10-09#2154/#2155对自定义构建镜像集的用户是破坏性变更所有 Dockerfile 中使用的构建参数由ROOT_CONTAINER、BASE_CONTAINER统一重命名为ROOT_IMAGE、BASE_IMAGE。在仓库源码中可以清楚看到当前的实际用法在 docker-stacks-foundation/Dockerfile 中ARG ROOT_IMAGEdefault_root_image定义默认根镜像并以FROM ubuntu:24.04sha256:... AS default_root_image作为默认实现最终FROM $ROOT_IMAGE允许构建时替换根镜像其余镜像则通过ARG BASE_IMAGE$REGISTRY/$OWNER/父镜像层层继承例如 base-notebook/Dockerfile 的ARG BASE_IMAGE$REGISTRY/$OWNER/docker-stacks-foundationpyspark-notebook/Dockerfile 的FROM $BASE_IMAGE默认scipy-notebookMakefile 中build/%目标也通过ROOT_IMAGE?default_root_image与PYTHON_VERSION?3.13提供命令行覆盖能力。如果你在自定义构建脚本或docker build --build-arg中仍使用旧的ROOT_CONTAINER/BASE_CONTAINER变量名需要同步改名参数语义不变ROOT_IMAGE仅作用于docker-stacks-foundationBASE_IMAGE作用于其余所有镜像。相关用法可参考 docs/using/custom-images.md 及其 custom_environment.dockerfile 示例。2.2 Python 版本阶梯3.12 → 3.13镜像栈的 Python 版本由docker-stacks-foundation统一控制两个关键节点2024-10-23#2072Breaking切换到 Python 3.12作用于所有镜像。注意这是触发 Spark 版本变更的直接原因——Python 3.12 与 Spark v3 不兼容项目因此随后引入 Spark 4.0 preview2025-08-15#2163Breakingdocker-stacks-foundation切换到 Python 3.13。从 docker-stacks-foundation/Dockerfile 可以看到ARG PYTHON_VERSION3.13控制安装的 Python 版本构建时可通过--build-arg PYTHON_VERSION覆盖例如自定义为 3.12并将pythonX.Y写入conda-meta/pinned防止意外升级。而 Makefile 默认的PYTHON_VERSION?3.13与 Dockerfile 默认值保持一致。2.3 包管理器升级mamba v22024-12-03#2147Breakingdocker-stacks-foundation切换到 mamba v2。从源码可见Micromamba 二进制来自 digest 锁定的官方镜像mambaorg/micromamba:2.8.1sha256:...Dockerfile并在安装时以mamba$(micromamba --version)将 mamba 与 micromamba 版本对齐便于 Dependabot 统一维护。mamba v2 的 CLI 行为变化是升级到 2024-12-03 之后构建的镜像时需要留意的地方。2.4 移除非必要依赖nodejs 与 facets2024-11-08#2172Breakingbase-notebook停止从conda-forge安装nodejs。理由它已不再是镜像中任何功能的直接依赖却使镜像体积增加约 150MB2025-11-06#2347Breakingscipy-notebook移除facets包安装。这类变更提醒使用者镜像体积优化与依赖瘦身是持续的维护方向若自定义镜像依赖这些包需自行在 Dockerfile 中补装。2.5 Spark 栈重构Spark 4.0 preview、Java 21 与 Derbypyspark-notebook与all-spark-notebook经历了三次紧密相关的变更2024-10-22#2159Breaking改用 Spark 4.0.0 预览版。原因有二Spark v3 与 Python 3.12 不兼容sparklyr在本地使用 Spark 时尚未支持 v4因此两个 Spark 镜像的功能验证需注意此限制2026-04-02#2424Breaking升级到 Java 21 与 Derby 10.17.1.02026-07-28#2531Non-breaking自动从 Spark 版本解析pandas版本消除手动维护的版本错位。在 pyspark-notebook/Dockerfile 中可以完整看到这一栈的实现ARG openjdk_version21安装openjdk-21-jre-headlessARG spark_version未设置时安装最新版配合setup_spark.py完成下载与配置Spark 自带的 Derby 10.16.1.1 被固定替换为 10.17.1.0且通过echo ${derby_sha256} */tmp/derby-....jar | sha256sum -c -做下载校验和验证——这正是 2026-07-27 #2522 中下载校验和验证的落地示例。ENV SPARK_OPTS同时预设了 1GB 最小/4GB 最大驱动内存的默认 JVM 参数。2.6 构建工具链升级Docker v29 与docker buildx imagetools create2025-11-29#2368Breaking改用 Docker v29 与docker buildx imagetools create来完成多平台镜像的合并。这要求本地构建环境与 CI 的 Docker 版本同步升级低于 v29 的环境将无法按原流程合并多架构镜像。三、运行时行为与安全加固镜像更健康的演进3.1 镜像引用锁定到 digest2026-05-31#2450Non-breaking将容器镜像引用固定Pin到 digest 哈希。仓库中已有多处体现这一原则docker-stacks-foundation的根镜像ubuntu:24.04sha256:224a...与 Micromamba 镜像mambaorg/micromamba:2.8.1sha256:fb18...均以 digest 引用Dockerfile并在注释中说明由 Dependabot 自动维护版本与 digest 的同步更新。digest 锁定意味着镜像内容的可复现性与供应链完整性得到增强——只要 digest 不变拉取到的就是完全一致的内容这对需要审计与复现的部署场景尤为重要。3.2 发布物签名与 SBOMcosign anchore镜像发布流程的供应链安全加固分三步完成2025-09-16#2317通过anchore/sbom-action发布 SBOM软件物料清单。落地位置在 .github/actions/apply-single-tags/action.yml以spdx.json格式作为构建产物上传2026-08-07#2534为推送的镜像执行 cosign 签名。在 docker-tag-push.yml 与 docker-tag-merge.yml 中通过sigstore/cosign-installer安装 cosign先由tagging.apps.calculate_image_ref计算镜像引用再执行cosign sign --yes --new-bundle-formattrue ${IMAGE_REF}。工作流注释明确指出bundle 格式使用 OCI 1.1 referrers 存储签名验证时需 cosign v3。这两个能力组合后用户可以在拉取镜像后验证签名并审计 SBOM实现内容可验证、成分可追溯的供应链闭环。3.3fix-permissions只对目录设置 setgid2026-08-07#2539Non-breakingfix-permissions脚本改为仅对目录设置 setgid 位。对照 images/docker-stacks-foundation/fix-permissions 源码第一个find仅对组权限不满足grwX的条目执行chgrp与chmod grwX第二个find用-type d限定只有目录才执行chmod gs。其意图是setgid 作用于目录时新建文件与子目录会自动继承${NB_GID}组而将 setgid 设到普通文件上既无意义也可能引发意外行为。脚本头注释也说明需要自定义用户 ID 的部署可通过docker run --group-add users保留权限。3.4 健康检查兼容非 HTTP(S) 服务器2026-07-27#2522Non-breaking健康检查支持非 HTTP(S) 的服务器 URL。在 docker_healthcheck.py 中脚本先从jupyter --runtime-dir定位运行目录并读取*server-*.json取出url若 URL 不以http://或https://开头例如c.ServerApp.sock配置的 UNIX socket 监听则直接打印提示并以退出码 0 报告健康否则请求url api并raise_for_status()。同时该 PR 还带来了容器重启幂等性避免重复启动同一服务实例与下载校验和验证等多项小修复。3.5 Rosetta 垃圾清理与镜像瘦身2026-07-28#2531Non-breaking中的Rework Rosetta junk cleanup在多个镜像中可见例如 docker-stacks-foundation/Dockerfile 预先创建~/.cache并多次执行rm -rf /home/${NB_USER}/.cache/rosetta防止 macOS Rosetta 翻译层在 ARM 镜像中留下无用缓存文件base-notebook/Dockerfile 等镜像也重复这一清理。其对应测试位于 test_rosetta_junk.py。四、日志与启动流程可观测性提升4.1 按级别着色的结构化日志2026-06-01#2452改进start.sh与run-hooks.sh的日志2026-06-02#2459按日志级别为输出着色。两者都落地在 images/docker-stacks-foundation/_docker_stacks_log.sh_log函数统一处理INFO/WARNING/ERROR/FATAL/DEBUG级别当 stderr 为终端且未设置NO_COLOR时输出 ANSI 颜色FATAL 粗体红、ERROR 红、WARNING 黄、DEBUG 青并遵循JUPYTER_DOCKER_STACKS_QUIET环境变量——设置了该变量后 INFO/DEBUG 静默但 FATAL/ERROR/WARNING 始终输出。_log_fatal在记录后还会exit 1。start.sh 全程使用这些日志函数覆盖了用户重命名、UID/GID 修正、home 目录迁移、sudo 授权等每个关键步骤run-hooks.sh 则在执行/usr/local/bin/start-notebook.d与before-notebook.d钩子时逐条记录正在 source 的 .sh、正在运行的可执行文件与忽略的非可执行文件并在钩子失败时记录错误但继续执行通过临时关闭errexit实现。4.2 启动入口的兼容性处理base-notebook/Dockerfile 的CMD [start-notebook.py]与ENTRYPOINT [tini, -g, --, start.sh]定义于 docker-stacks-foundation/Dockerfile共同构成启动链路start.sh作为默认入口若用户仍在 CMD 中显式书写start.sh脚本会通过_START_SH_EXECUTED环境变量识别并给出警告。健康检查则由 Dockerfile 中的HEALTHCHECK --interval3s --timeout1s --start-period3s --retries3配合/etc/jupyter/docker_healthcheck.py执行。五、标签Tagging与清单Manifest体系演进镜像的多版本标签与内容清单是 Jupyter Docker Stacks 的独特基础设施2025 年经历了显著重构2025-02-21#2228/#2231重构tagging/与tests/目录结构形成模块化的 tagging/hierarchy、tagging/manifests、tagging/taggers 分层2025-03-12#2251新增conda与mamba版本标签器2025-03-12#2252将 taggers 与 manifests 改为函数形式2025-04-01#2274在同一处完成标签应用与合并。当前 tagging/hierarchy/images_hierarchy.py 以数据类ImageDescription(parent_image, taggers, manifests)描述每个镜像例如docker-stacks-foundation挂载commit_sha、日期、Ubuntu 版本、Python、mamba、conda 等 7 个标签器pyspark-notebook挂载spark与java标签器并配套spark_info_manifestall-spark-notebook继承自pyspark-notebook并追加 R 标签器。而 tagging/taggers/versions.py 展示了标签器的实现方式——在容器内执行mamba --version、conda --version、pip show tensorflow等命令从输出来构造mamba-x.y.z、conda-x.y.z、spark-x.y.z、java-x.y.z等标签。这套机制由 Makefile 的hook/%目标串联依次执行write_tags_file、write_manifest、apply_tags按平台uname -m应用对应 tagging/apps 下的应用入口。六、测试与 CI 基础设施的持续打磨6.1 测试体系2025-03-20#2254/#2255base-notebook的健康检查测试重构为单一函数并新增 IPv4/IPv6 监听测试对应 test_healthcheck.py 与 test_ips.py2025-03-21#2256-#2258重构TrackedContainer的run_detached/exec_cmd测试中仅在必要时分配 TTY并在 Python 执行execvp前刷新输出tests/utils/tracked_container.py2025-02-18#2219简化并改进test_packages.py2025-02-17#2214先上传构建产物再运行测试便于快速调试坏镜像。6.2 CI 流水线与运行器2025-02-11#2202开始使用 GitHub 托管的ubuntu-22.04-armaarch64 运行器2025-02-18#2209切换到ubuntu-24.04-arm运行器2025-02-18#2218不为 CUDA 镜像创建额外磁盘空间通过.github/actions/free-disk-space按需执行见 docker-tag-push.yml2025-02-18#2222内部代码使用 Python 3.12区别于镜像内的运行时 Python2025-02-17#2212/#2213在 PR 中构建贡献的 recipes由 contributed-recipes.yml 负责2025-04-11#2282CI 中tag-push依赖贡献的 recipes 构建成功2025-03-22#2260/#2261运行 Docker 命令默认分配 TTY并改进相关日志。6.3 标签合并与多平台发布2025-03-23#2262tensorflow-notebook改用 mamba 安装jupyter-server-proxy2025-12-02#2352为 ARM64 启用 CUDA 构建涉及 tensorflow-notebook/cuda 与 pytorch-notebook/cuda12、cuda13 等变体目录2025-12-31#2391pytorch-notebook改为构建 CUDA 13 镜像替代原 CUDA 11。注意 pytorch-notebook/Dockerfile 默认通过pip install --index-url https://download.pytorch.org/whl/cpu安装 CPU 版 PyTorchCUDA 变体则由cuda12/、cuda13/子目录维护。七、平台扩展与易用性改进2025-11-24#2358新增 Dev Container 支持方便在 VS Code 等 IDE 中直接以容器作为开发环境2025-11-24#2357新增使用 Singularity 运行 Jupyter Docker Stacks 的 recipe见 docs/using/recipes.md2026-08-08#2548Makefile 支持 Apple 的 Container 框架。在 Makefile 中CONTAINER_CLI?$(if $(shell command -v docker),docker,container)会优先使用 Docker否则回退到 Apple 的container命令并针对两者在镜像列表、强制标志、超时参数等细节上做了分支适配——这意味着在 Apple Silicon Mac 上无 Docker 也能完成make build/minimal-notebook等任务。此外2025-04-12#2283将libxml2固定版本以避免 ABI 断裂属于典型的依赖钉死案例2025-02-17#2215为 aarch64 的r-notebook与datascience-notebook固定部分包该改动随后在 #2220 中被回退说明这类临时代码会随上游修复而清理2025-04-13#2263让tensorflow-notebook安装最新版 TensorFlow。八、升级路径建议综合以上变更可将升级影响归纳为四类供镜像使用者对照自查构建侧若使用本地docker build定制镜像需确认已将ROOT_CONTAINER/BASE_CONTAINER更新为ROOT_IMAGE/BASE_IMAGE并留意 Python 版本默认 3.13与 Docker v29 的最低版本要求可通过make build/imageMakefile传入REGISTRY、OWNER、ROOT_IMAGE、PYTHON_VERSION等参数验证构建Spark 栈使用者pyspark-notebook/all-spark-notebook需适配 Java 21、Derby 10.17.1.0 与 Spark 4 系列sparklyr的本地模式兼容性需单独验证运行与消费侧拉取 2026-05-31 之后发布的镜像即可获得 digest 锁定、cosign 签名验证需 cosign v3与 SBOM 审计能力如使用非 HTTP(S) 的 Jupyter 服务器配置健康检查行为已兼容平台与编排Dev Container、Singularity、Apple Container 与 ARM64 CUDA 等能力的启用方式可分别参考 docs/using/recipes.md、docs/using/running.md 与 examples/ 目录下的示例。每次重大升级后可通过仓库内置测试快速验证make test/image调用 tests/run_tests.py 运行对应镜像的完整测试套件pytest.ini 定义了测试运行配置帮助在投入生产前发现行为差异。赞分享云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载相关推荐pi-ai 变更日志深度解读从全局 API 到 Models 运行时pi 的 LLM 统一层如何演进pi ai 变更日志深度解读从全局 API 到 Models 运行时pi 的 LLM 统一层如何演进 packages/ai/CHANGELOG.md ht人工智能大模型AI Agent代码智能体AI 应用工具调用eggjs/tegg-runtime 变更日志深度解读从 3.x 到 4.x 的运行时演进与核心机制eggjs/tegg runtime 变更日志深度解读从 3.x 到 4.x 的运行时演进与核心机制 eggjs/tegg runtime 是 tegg后端Web框架schedule 变更日志深度解读从 0.1.0 到 1.2.2 的 API 演进、行为变更与升级实践指南schedule 变更日志深度解读从 0.1.0 到 1.2.2 的 API 演进、行为变更与升级实践指南 本文以开源仓库 schedule Python任务调度后端上一篇游戏UI自动化测试终极方案Poco框架实战指南下一篇终极指南使用OpenCV DNN模块构建高效目标检测系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
