云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载本文基于 docs/using/custom-images.md 整理并扩充讲解如何为 Jupyter Docker StacksJDS构建一套自定义镜像何时使用 cookiecutter 社区 Stack、如何使用ROOT_IMAGE/PYTHON_VERSION/REGISTRY/OWNER/BASE_IMAGE等构建参数改变底层 Ubuntu 与 Python 版本以及如何用 Docker Bake 在本地按正确的依赖顺序完成整条镜像链的构建。读完后你可以独立完成换 Python 版本/换基础镜像级别的定制构建并理解仓库中各参数在 Dockerfile 里的真实落点。三种定制路径及适用场景构建自定义 JDS 镜像时仓库文档给出了三条递进的路径选择的关键在于定制的深度轻量定制改 Ubuntu 版本、改 Python 版本、微调构建过程利用仓库暴露的 Docker 构建参数build args本地构建即本文的主体内容深度定制 自动化构建管线基于官方镜像派生自己的 Stack并接入 CI 自动构建与发布。仓库提供了 cookiecutter 模板项目jupyter/cookiecutter-docker-stacks详见 docs/contributing/stacks.md它会帮你完成 GitHub 项目初始化、GitHub Actions 配置、容器镜像仓库如 Docker Hub托管以及如何把自己的 Stack 登记进社区 Stack 列表大规模修改直接 Fork 本仓库随意修改若改动易于回合并有利于其他用户可以向上游提 PR。需要注意一个前提约束JDS 同一时间只构建一套one set of镜像。如果你需要更老版本镜像的构建产物应参考 docs/index.rst 中 Using old images 一节的说明而不是依赖本仓库的当前构建。定制点五个关键 Docker 构建参数JDS 的镜像 Dockerfile 在开头就通过ARGFROM $BASE_IMAGE暴露了定制入口。以 images/base-notebook/Dockerfile 为例ARG REGISTRYquay.io ARG OWNERjupyter ARG BASE_IMAGE$REGISTRY/$OWNER/docker-stacks-foundation FROM $BASE_IMAGE所有镜像的 Dockerfile 都遵循这一模式如 images/minimal-notebook/Dockerfile 以base-notebook为默认基础镜像因此构建参数可以逐层向下传递。仓库提供的定制点归纳如下参数类型作用范围说明ROOT_IMAGEDocker 构建参数仅docker-stacks-foundation决定 foundation 镜像的根镜像默认default_root_image即 Dockerfile 内以 digest 固定版本的ubuntu:24.04构建阶段PYTHON_VERSIONDocker 构建参数仅docker-stacks-foundation安装到 foundation 镜像中的 Python 版本默认3.13设为default则安装最新可用版本REGISTRY、OWNERDocker 构建参数所有上层镜像与其他BASE_IMAGE配合指定每个镜像的父镜像来自哪个 registry 与命名空间REGISTRY、OWNERCIenv变量后续步骤构建-测试-推送、标签合并等 GitHub Actions 工作流如build-test-upload、contributed-recipes、tag-push-merge保证镜像在构建、测试、打标签、推送各环节被正确引用两点重要边界来自 docs/using/custom-images.md 的原文说明这些定制点在运行时runtime无法修改——它们是构建期参数必须作用于完整的重建流程自定义参数可能因不兼容导致构建失败如果目标是用例级别的深度定制例如换掉整套构建过程可能需要走完全自定义 Stack 的路线。源码层面的参数落点从源码结构看这两个 foundation 专属参数在 images/docker-stacks-foundation/Dockerfile 中有清晰的落点第 5 行ARG ROOT_IMAGEdefault_root_image第 10 行FROM ubuntu:24.04sha256:224a1869...声明了一个以 digest 固定的构建阶段default_root_image第 17 行FROM $ROOT_IMAGE再据此选择最终根镜像——即不传参时始终使用 digest 锁定的 Ubuntu 24.04 (noble)换版本时直接传ROOT_IMAGEubuntu:22.04之类即可第 105 行ARG PYTHON_VERSION3.13。后续的安装逻辑约 L123-L143用 micromamba 安装python${PYTHON_VERSION}、conda、jupyter_core并在安装后把 Python 锁定到major.minor.*的 pinned 文件避免后续mamba update意外漂移主版本。而REGISTRY/OWNER/BASE_IMAGE的组合方式决定了整条镜像链的上游。仓库根目录的 Makefile 同样围绕这三个变量组织REGISTRY?quay.io OWNER?jupyter IMG$(REGISTRY)/$(OWNER)/$(notdir $)Makefile 中的build/%目标Makefile展示了官方推荐的本地构建入口# Note: ROOT_IMAGE and PYTHON_VERSION arguments are only applicable # to the docker-stacks-foundation image build/%: DOCKER_BUILD_ARGS? build/%: ROOT_IMAGE?default_root_image build/%: PYTHON_VERSION?3.13 build/%: ## build the latest image for a stack using the systems architecture $(CONTAINER_CLI) build $(DOCKER_BUILD_ARGS) \ --tag $(IMG) \ ./images/$(notdir $) \ --build-arg REGISTRY$(REGISTRY) \ --build-arg OWNER$(OWNER) \ --build-arg ROOT_IMAGE$(ROOT_IMAGE) \ --build-arg PYTHON_VERSION$(PYTHON_VERSION)也就是说如果只是想在本地把某一套镜像换 Python 版本构建出来直接make build/docker-stacks-foundation PYTHON_VERSION3.12以及逐层构建上层镜像就是最小改动方式ROOT_IMAGE的注释也明确提示它只对 foundation 生效默认沿用 Dockerfile 内 digest 固定的构建阶段。镜像层级与 BASE_IMAGE 依赖链理解BASE_IMAGE参数的关键是 JDS 的镜像层级结构。仓库中官方镜像按构建依赖顺序定义为见 Makefile 的ALL_IMAGESdocker-stacks-foundation → base-notebook → minimal-notebook → scipy-notebook r-notebook | julia-notebook | tensorflow-notebook | pytorch-notebook → datascience-notebook → pyspark-notebook → all-spark-notebook每个上层镜像的 Dockerfile 都以ARG BASE_IMAGE$REGISTRY/$OWNER/下一层镜像名开头这意味着当你本地把foundation、base-notebook、minimal-notebook依次以本地 tag 重新构建后再把BASE_IMAGE参数指向本地 tag就可以让上层镜像基于你的自定义下层镜像构建。Docker Bake 的contexts机制下一节正是为这种多目标按依赖顺序构建设计的。用 Docker Bake 本地构建自定义镜像链对于换 Python 版本这类轻量定制官方推荐的完整方案是 Docker Bake。文档中的标准示例是基于minimal-notebook构建一个使用Python 3.12的自定义镜像。第一步准备自定义镜像的 Dockerfile假设你的项目里有一个 Dockerfile注意其中BASE_IMAGE参数化ARG BASE_IMAGEminimal-notebook FROM $BASE_IMAGE ...第二步放入 docker-bake.hcl仓库中随文档提供了完整的示例文件 docs/using/recipe_code/docker-bake.custom-python.hcl把它放进你的项目目录通常命名为docker-bake.hclgroup default { targets [custom-notebook] } target foundation { context https://github.com/jupyter/docker-stacks.git#main:images/docker-stacks-foundation args { PYTHON_VERSION 3.12 } tags [docker-stacks-foundation] } target base-notebook { context https://github.com/jupyter/docker-stacks.git#main:images/base-notebook contexts { docker-stacks-foundation target:foundation } args { BASE_IMAGE docker-stacks-foundation } tags [base-notebook] } target minimal-notebook { context https://github.com/jupyter/docker-stacks.git#main:images/minimal-notebook contexts { base-notebook target:base-notebook } args { BASE_IMAGE base-notebook } tags [minimal-notebook] } target custom-notebook { context . contexts { minimal-notebook target:minimal-notebook } args { BASE_IMAGE minimal-notebook } tags [custom-jupyter] }这个文件的组织方式与上一节讲的参数落点一一对应值得逐段对照每个target的context直接以URL#ref:子目录形式指向 JDS 仓库对应镜像的构建上下文images/docker-stacks-foundation、images/base-notebook、images/minimal-notebook无需克隆整个仓库Docker BuildKit 会按需拉取对应 ref 的目录内容foundationtarget 中args只覆盖了PYTHON_VERSION 3.12未覆盖ROOT_IMAGE因此仍使用 foundation Dockerfile 中 digest 固定的 Ubuntu 24.04 构建阶段见 images/docker-stacks-foundation/Dockerfile如果你要同时换 Ubuntu加上ROOT_IMAGE ubuntu:22.04即可中间层 target 的contexts如docker-stacks-foundation target:foundation把上游 target 的构建产物作为 BuildKit 的构建上下文注入下层配合BASE_IMAGE参数使得base-notebook实际FROM的是你刚构建的本地docker-stacks-foundation而不是 quay.io 上的官方版本custom-notebook的context .即你的项目目录最终产出 tag 为custom-jupyter的镜像。第三步执行构建与运行在docker-bake.hcl所在目录执行docker buildx bakeDocker Bake 会根据contexts声明自动推导出正确的构建顺序foundation → base-notebook → minimal-notebook → custom-notebook逐层构建。构建完成后该镜像的使用方式与项目中任何其他 JDS 镜像完全一致例如docker run -it --rm -p 8888:8888 custom-jupyter或者在 Docker Compose 文件中以image: custom-jupyter引用。由于整条链都是本地标签替换任何一层后重新docker buildx bake即可增量验证你的改动。构建失败时的预期管理再次强调原文档的注意事项自定义参数可能因不兼容导致构建报错例如较老的 Python 版本无法满足某些依赖的最低版本约束。出现此类错误时说明你的用例已经超出轻量定制的范畴应考虑基于 cookiecutter 建立完全自定义的 Stack。社区 Stack把定制流程自动化如果你的定制不是一次性的而是希望长期维护并分享给他人文档指出的正确姿势是创建一个社区维护的 Stackcommunity-maintained stack仓库提供了 cookiecutter 模板一条命令即可生成包含 Dockerfile、GitHub Actions 工作流PR 触发构建与测试、镜像仓库推送配置的完整项目骨架。完整流程cookiecutter 参数、Docker Hub 仓库与 Access Token 配置、GitHub Secrets、如何把镜像登记到文档的 Community Stacks 列表请阅读 docs/contributing/stacks.md。该方案与核心 Stack 自身的构建/发布方式保持一致因此也天然继承了 JDS 的测试与版本管理实践。Fork 仓库大规模修改的最后手段当以上路径都不满足需求时可以直接 Fork 本仓库并任意修改。仓库文档给出的协作建议如果你的定制易于回合并可能帮助其他用户欢迎向上游提 PR尽量保持 diff 尽可能小并持续 merge/rebase 上游主分支的最新版本到你的项目中以降低后续跟进上游变更的成本。小结按定制深度选型需求推荐方案入口换 Python 版本 / 换 Ubuntu 基础镜像一次性或内部使用Docker 构建参数 Docker Bake本文主体docs/using/recipe_code/docker-bake.custom-python.hcl、Makefile长期维护 自动 CI 构建发布 对外分享cookiecutter 社区 Stackdocs/contributing/stacks.md深度改造构建过程本身Fork 仓库 保持小 diff 上游 PRdocs/using/custom-images.md适用前提与限制上述构建参数均为构建期参数运行时不可改自定义PYTHON_VERSION/ROOT_IMAGE可能触发依赖不兼容导致的构建失败JDS 任一时刻只维护一套镜像查找历史版本镜像需另行查阅 docs/index.rst。赞分享云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载相关推荐Jupyter Docker Stacks项目构建自定义镜像指南Jupyter Docker Stacks项目构建自定义镜像指南 前言 在数据科学和机器学习领域Jupyter Notebook已成为不可或缺的工具。Jup云原生开发工具数据科学如何快速构建Apache Airflow自定义Docker镜像完整实战指南如何快速构建Apache Airflow自定义Docker镜像完整实战指南 Apache Airflow作为业界领先的工作流编排平台其Docker镜像构建是后端任务调度工作流自动化数据编排批处理数据工程流程编排Docker-Android自定义构建参数API_LEVEL、IMG_TYPE、ARCHITECTURE终极配置指南Docker Android自定义构建参数API_LEVEL、IMG_TYPE、ARCHITECTURE终极配置指南 Docker Android是一个轻量级虚拟化测试开发工具上一篇Honey Select 2 HF Patch完全优化指南从安装到精通的全方位解决方案下一篇智能家居自动化控制与地图管理dreame-vacuum 3大核心功能解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考