ZenML Local Docker Orchestrator 实战指南用 Docker 在本地隔离环境运行流水线【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlLocal Docker Orchestrator 是 ZenML 内置built-in的编排器orchestratorflavor它复用本机已安装的 Docker 引擎将流水线中的每一个 step 分别放进独立的 Docker 容器中依次执行。本文从注册、配置到源码级原理完整讲解这一本地容器化编排方案的适用场景、上手命令、LocalDockerOrchestratorSettings全部可用配置以及它在 ZenML 源码中的真实执行链路帮助你用它复现云端容器行为、低成本排查容器化问题并理解容器化编排器在 ZenML 中的通用机制。何时使用 Local Docker Orchestrator在 ZenML 的编排器生态中Orchestrators 索引页 列出了两类内置编排器默认栈中的local直接在本地进程运行和本文的主角local_docker。两者的核心差别在于隔离粒度——local编排器在本地进程内串行执行 step而 Local Docker Orchestrator 为每个 step 启动一个独立的 Docker 容器从而复现远程容器化编排器如 Kubernetes、Kubeflow、Vertex的执行环境。官方文档给出的典型适用场景有两条需要隔离环境时你希望流水线的每个 step 在彼此隔离的容器环境中运行避免依赖相互污染需要低成本调试容器问题时你怀疑流水线在远程容器化环境中会出问题但又不想等待和付费使用远程基础设施。Local Docker Orchestrator 能让你在本机以与远程环境几乎一致的容器化方式运行流水线从而快速定位依赖、路径、环境变量等容器相关问题。从源码看这一本地优先调试的定位体现得非常明确编排器类LocalDockerOrchestrator的 docstring 直接写明不允许多个 step 并发执行也不支持按调度运行见 local_docker_orchestrator.py。它并非面向生产级并发调度而是聚焦在容器里跑起来、跑对。部署前提只需 Docker使用 Local Docker Orchestrator 不需要安装任何额外集成integration唯一的硬性前置条件是本机安装并运行 Docker。ZenML 通过 docker-pyDocker Python SDK与 Docker daemon 通信。仓库中的容器引擎实现 docker_engine.py 提供了check_availability()方法它依次检查系统中是否存在docker可执行文件shutil.which(docker)能否成功ping通 Docker daemon。如果 Docker daemon 无法连接该方法会给出三类最常见原因的排查提示daemon 未运行~/.docker/config.json配置不正确可通过DOCKER_CONFIG环境变量指定配置目录以及使用了非默认 Docker context可通过DOCKER_HOST环境变量指向docker context ls中带*的 endpoint。实际运行编排器时LocalDockerOrchestrator通过docker_engine属性见 local_docker_orchestrator.py调用get_container_engine(ContainerEngineType.DOCKER)获取引擎实例再通过docker_client属性暴露的DockerClient.from_env()客户端见 docker_engine.py执行容器操作。因此Docker daemon 可用是运行的前提。注册与启用两行命令接入活跃 StackLocal Docker Orchestrator 的注册方式与 ZenML 其他编排器完全一致先注册编排器组件再把它纳入 stack。官方文档给出的命令如下# 注册编排器组件flavor 固定为 local_docker zenml orchestrator register ORCHESTRATOR_NAME --flavorlocal_docker # 注册包含新编排器的 stack并设为活跃 stack zenml stack register STACK_NAME -o ORCHESTRATOR_NAME ... --set其中ORCHESTRATOR_NAME、STACK_NAME分别是你自定义的组件名和栈名...处需要补充 stack 中的其他组件artifact store、orchestrator 之外的其余组件按你的栈设计填写--set表示注册后立即切换为活跃 stack。注册完成后运行流水线的方式与使用任何编排器相同——直接执行运行流水线的 Python 脚本即可python file_that_runs_a_zenml_pipeline.py编排器的 flavor 注册信息可以在源码中直接确认LocalDockerOrchestratorFlavor的name属性返回local_dockerconfig_class指向LocalDockerOrchestratorConfigimplementation_class指向LocalDockerOrchestrator见 local_docker_orchestrator.py。对应的单元测试 test_local_docker_orchestrator.py 也验证了 flavor 的type为StackComponentType.ORCHESTRATOR、name为local_docker与文档及 CLI 用法互相印证。需要留意的是该编排器的validator属性要求活跃 stack 中必须包含**镜像构建器IMAGE_BUILDER**组件见 local_docker_orchestrator.py。这是因为容器化编排器需要先把流水线代码构建成 Docker 镜像再由镜像启动容器缺少镜像构建器时栈校验会失败。运行机制每个 Step 一个容器的串行执行理解了怎么用之后再看怎么跑。LocalDockerOrchestrator.submit_pipeline()见 local_docker_orchestrator.py完整描述了它的执行链路可以概括为以下几个关键环节1. 调度与镜像获取。如果流水线 snapshot 携带了schedule调度配置编排器会打印警告并忽略调度、立即执行——这正是不支持调度的具体表现。随后通过StepEntrypointConfiguration.get_entrypoint_command()获取容器入口命令并为每个 step 通过get_image()从构建记录中解析出对应的 Docker 镜像。2. 本地存储挂载。为了让容器内的 step 能访问 ZenML 本地栈产生的构件artifacts编排器会调用stack.check_local_paths()校验本地路径并把GlobalConfiguration().local_stores_path以可读写rw卷的方式挂载进容器见 local_docker_orchestrator.py。这是 Local Docker Orchestrator 能本地跑通的关键细节。3. 逐步串行提交。编排器遍历 snapshot 中的每个 step为每个 step 单独调用 docker-py 的containers.run(...)启动一个容器并传入entrypoint与get_entrypoint_arguments(step_name..., snapshot_id...)构造的命令行参数。每个 step 的环境变量中会注入ZENML_DOCKER_ORCHESTRATOR_RUN_ID本次运行生成的 UUID与ZENML_LOCAL_STORES_PATH见 local_docker_orchestrator.py用于标识同一次流水线运行。4. 日志实时回流。容器以streamTrue模式运行stdout/stderr日志被逐行解码并写入 ZenML 日志因此你在本地终端能看到 step 容器内的实时输出。5. 失败处理与执行模式。容器以非零状态退出时 docker-py 会抛出ContainerError。编排器记录失败 step并根据execution_mode决定行为FAIL_FASTfail_fast模式下立即抛出异常中断STOP_ON_FAILUREstop_on_failure与CONTINUE_ON_FAILUREcontinue_on_failure模式下则记录错误继续调度后续 step后者不跳过失败 step 的上游依赖前者会跳过依赖失败的 step。整个流水线结束时若存在失败 step会抛出包含失败 step 名称列表的RuntimeError。这三种执行模式正是该类声明的supported_execution_modes见 local_docker_orchestrator.py。6. 动态流水线dynamic pipeline支持。类中还实现了submit_dynamic_pipeline()见 local_docker_orchestrator.py对于动态流水线使用DynamicPipelineEntrypointConfiguration作为入口以detachTrue后台方式启动编排容器若设置synchronousTrue默认则通过SubmissionResult.wait_for_completion等待容器日志流结束否则立即返回。这解释了LocalDockerOrchestratorSettings中synchronous参数的实际用途。此外作为ContainerizedOrchestrator的子类它继承了容器化编排器的通用能力当编排器为本地组件且 ZenML 直接连接 SQL store 时构建的镜像中会自动追加安装zenml[local]version依赖见 containerized_orchestrator.py确保容器内有完整的本地存储访问依赖镜像构建按 step 的docker_settings与流水线级docker_settings的差异去重生成见 containerized_orchestrator.py。进阶配置LocalDockerOrchestratorSettings 详解对于 Local Docker Orchestrator 的额外配置官方文档指出在定义或运行流水线时传入LocalDockerOrchestratorSettings即可。该设置类的完整定义位于 local_docker_orchestrator.py共两个字段字段类型默认值说明synchronousboolTrue是否同步运行流水线。True时提交后等待容器完成并回流日志False时异步返回。动态流水线场景下生效见submit_dynamic_pipeline。run_argsDict[str, Any]{}透传给 docker-pycontainers.run(...)的参数字典可控制 CPU、内存、GPU、端口、环境变量、卷、网络等几乎所有容器运行时行为。其中run_args是最灵活的入口其可用的键与 docker-pyContainers.run方法的参数一一对应包括但不限于cpu_count、mem_limit、gpus、ports、network、restart_policy、working_dir等。需要特别说明的是源码在真正调用containers.run之前会从run_args中抽出几个有特殊语义的键单独处理见 local_docker_orchestrator.pyimage用于覆盖默认构建出的镜像user默认情况下在非 Windows 平台使用os.getuid()作为容器内用户保证文件权限与宿主机一致Windows 下为None你可以显式覆盖environment与 ZenML 注入的 step 环境变量合并volumes与 ZenML 自动挂载的 local stores 卷合并extra_hosts与自动追加的host.docker.internal → host-gateway条目合并该条目保证容器内能访问宿主机服务。因此如果你在run_args里手动设置这些键需要注意它们会与 ZenML 的默认行为合并或覆盖user、image两个键则采用以你的设置为准的覆盖语义settings.run_args.pop(...)。配置示例限制容器 CPU 数量官方文档给出了一个直接可运行的示例通过run_args指定容器可用的 CPU 核数注意cpu_count仅对 Windows 平台生效from zenml import step, pipeline from zenml.orchestrators.local_docker.local_docker_orchestrator import ( LocalDockerOrchestratorSettings, ) step def return_one() - int: return 1 settings { orchestrator: LocalDockerOrchestratorSettings( run_args{cpu_count: 3} ) } pipeline(settingssettings) def simple_pipeline(): return_one()settings字典以orchestrator为键将设置作用到编排器组件上在流水线装饰器上通过settings参数传入后整个流水线的每个 step 容器都会按该配置启动。同理你可以在定义或运行时用同样的方式传入mem_limit、gpus等 docker-py 参数。资源限制与执行模式的注意点结合源码可以确认该编排器有两个值得注意的边界行为step 级资源请求会被忽略。在submit_pipeline中如果某个 step 声明了资源requires_resources_in_orchestration_environment为真编排器会打印警告并忽略该资源配置见 local_docker_orchestrator.py。如需为 step 分配 GPU 等硬件官方文档建议改用 step operator 组件。并发与调度能力缺失。所有 step 按依赖顺序在一个循环中逐个启动容器step 之间不存在并发schedule配置会被忽略并给出警告。GPU 与 CUDA 支持如果你计划让 step 在 GPU 上运行以获得完整的加速能力官方文档明确指出需要遵循 ZenML 分布式训练相关指南中关于自定义镜像与运行时配置的说明对镜像和run_args做额外定制——典型做法包括在镜像中安装带 CUDA 的依赖、通过run_args传入 GPU 相关的 docker-py 参数如gpus/device_requests等。只有正确配置 CUDA 运行时GPU 才能发挥全部加速能力。具体配置项与步骤取决于你的镜像构建方案建议结合 组件指南之镜像构建器 相关文档一并阅读。小结从调试利器到容器化原理的入口Local Docker Orchestrator 是 ZenML 中零集成成本、纯本地、容器化的编排方案只需 Docker 即可把流水线 step 逐个放进隔离容器运行非常适合在本地复现和排查容器化环境问题。透过它的源码local_docker_orchestrator.py、docker_engine.py、containerized_orchestrator.py你还能看到 ZenML 容器化编排的通用骨架——镜像构建、入口点注入、本地存储卷挂载、环境变量传递、执行模式控制——这些机制在 Kubernetes、Kubeflow 等远程编排器中以同样的抽象层次复用。对于想从本地进程运行平滑过渡到容器化/云端运行的团队来说它是一个成本极低、收益直接的起点。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ZenML Local Docker Orchestrator 实战指南：用 Docker 在本地隔离环境运行流水线
ZenML Local Docker Orchestrator 实战指南用 Docker 在本地隔离环境运行流水线【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenmlLocal Docker Orchestrator 是 ZenML 内置built-in的编排器orchestratorflavor它复用本机已安装的 Docker 引擎将流水线中的每一个 step 分别放进独立的 Docker 容器中依次执行。本文从注册、配置到源码级原理完整讲解这一本地容器化编排方案的适用场景、上手命令、LocalDockerOrchestratorSettings全部可用配置以及它在 ZenML 源码中的真实执行链路帮助你用它复现云端容器行为、低成本排查容器化问题并理解容器化编排器在 ZenML 中的通用机制。何时使用 Local Docker Orchestrator在 ZenML 的编排器生态中Orchestrators 索引页 列出了两类内置编排器默认栈中的local直接在本地进程运行和本文的主角local_docker。两者的核心差别在于隔离粒度——local编排器在本地进程内串行执行 step而 Local Docker Orchestrator 为每个 step 启动一个独立的 Docker 容器从而复现远程容器化编排器如 Kubernetes、Kubeflow、Vertex的执行环境。官方文档给出的典型适用场景有两条需要隔离环境时你希望流水线的每个 step 在彼此隔离的容器环境中运行避免依赖相互污染需要低成本调试容器问题时你怀疑流水线在远程容器化环境中会出问题但又不想等待和付费使用远程基础设施。Local Docker Orchestrator 能让你在本机以与远程环境几乎一致的容器化方式运行流水线从而快速定位依赖、路径、环境变量等容器相关问题。从源码看这一本地优先调试的定位体现得非常明确编排器类LocalDockerOrchestrator的 docstring 直接写明不允许多个 step 并发执行也不支持按调度运行见 local_docker_orchestrator.py。它并非面向生产级并发调度而是聚焦在容器里跑起来、跑对。部署前提只需 Docker使用 Local Docker Orchestrator 不需要安装任何额外集成integration唯一的硬性前置条件是本机安装并运行 Docker。ZenML 通过 docker-pyDocker Python SDK与 Docker daemon 通信。仓库中的容器引擎实现 docker_engine.py 提供了check_availability()方法它依次检查系统中是否存在docker可执行文件shutil.which(docker)能否成功ping通 Docker daemon。如果 Docker daemon 无法连接该方法会给出三类最常见原因的排查提示daemon 未运行~/.docker/config.json配置不正确可通过DOCKER_CONFIG环境变量指定配置目录以及使用了非默认 Docker context可通过DOCKER_HOST环境变量指向docker context ls中带*的 endpoint。实际运行编排器时LocalDockerOrchestrator通过docker_engine属性见 local_docker_orchestrator.py调用get_container_engine(ContainerEngineType.DOCKER)获取引擎实例再通过docker_client属性暴露的DockerClient.from_env()客户端见 docker_engine.py执行容器操作。因此Docker daemon 可用是运行的前提。注册与启用两行命令接入活跃 StackLocal Docker Orchestrator 的注册方式与 ZenML 其他编排器完全一致先注册编排器组件再把它纳入 stack。官方文档给出的命令如下# 注册编排器组件flavor 固定为 local_docker zenml orchestrator register ORCHESTRATOR_NAME --flavorlocal_docker # 注册包含新编排器的 stack并设为活跃 stack zenml stack register STACK_NAME -o ORCHESTRATOR_NAME ... --set其中ORCHESTRATOR_NAME、STACK_NAME分别是你自定义的组件名和栈名...处需要补充 stack 中的其他组件artifact store、orchestrator 之外的其余组件按你的栈设计填写--set表示注册后立即切换为活跃 stack。注册完成后运行流水线的方式与使用任何编排器相同——直接执行运行流水线的 Python 脚本即可python file_that_runs_a_zenml_pipeline.py编排器的 flavor 注册信息可以在源码中直接确认LocalDockerOrchestratorFlavor的name属性返回local_dockerconfig_class指向LocalDockerOrchestratorConfigimplementation_class指向LocalDockerOrchestrator见 local_docker_orchestrator.py。对应的单元测试 test_local_docker_orchestrator.py 也验证了 flavor 的type为StackComponentType.ORCHESTRATOR、name为local_docker与文档及 CLI 用法互相印证。需要留意的是该编排器的validator属性要求活跃 stack 中必须包含**镜像构建器IMAGE_BUILDER**组件见 local_docker_orchestrator.py。这是因为容器化编排器需要先把流水线代码构建成 Docker 镜像再由镜像启动容器缺少镜像构建器时栈校验会失败。运行机制每个 Step 一个容器的串行执行理解了怎么用之后再看怎么跑。LocalDockerOrchestrator.submit_pipeline()见 local_docker_orchestrator.py完整描述了它的执行链路可以概括为以下几个关键环节1. 调度与镜像获取。如果流水线 snapshot 携带了schedule调度配置编排器会打印警告并忽略调度、立即执行——这正是不支持调度的具体表现。随后通过StepEntrypointConfiguration.get_entrypoint_command()获取容器入口命令并为每个 step 通过get_image()从构建记录中解析出对应的 Docker 镜像。2. 本地存储挂载。为了让容器内的 step 能访问 ZenML 本地栈产生的构件artifacts编排器会调用stack.check_local_paths()校验本地路径并把GlobalConfiguration().local_stores_path以可读写rw卷的方式挂载进容器见 local_docker_orchestrator.py。这是 Local Docker Orchestrator 能本地跑通的关键细节。3. 逐步串行提交。编排器遍历 snapshot 中的每个 step为每个 step 单独调用 docker-py 的containers.run(...)启动一个容器并传入entrypoint与get_entrypoint_arguments(step_name..., snapshot_id...)构造的命令行参数。每个 step 的环境变量中会注入ZENML_DOCKER_ORCHESTRATOR_RUN_ID本次运行生成的 UUID与ZENML_LOCAL_STORES_PATH见 local_docker_orchestrator.py用于标识同一次流水线运行。4. 日志实时回流。容器以streamTrue模式运行stdout/stderr日志被逐行解码并写入 ZenML 日志因此你在本地终端能看到 step 容器内的实时输出。5. 失败处理与执行模式。容器以非零状态退出时 docker-py 会抛出ContainerError。编排器记录失败 step并根据execution_mode决定行为FAIL_FASTfail_fast模式下立即抛出异常中断STOP_ON_FAILUREstop_on_failure与CONTINUE_ON_FAILUREcontinue_on_failure模式下则记录错误继续调度后续 step后者不跳过失败 step 的上游依赖前者会跳过依赖失败的 step。整个流水线结束时若存在失败 step会抛出包含失败 step 名称列表的RuntimeError。这三种执行模式正是该类声明的supported_execution_modes见 local_docker_orchestrator.py。6. 动态流水线dynamic pipeline支持。类中还实现了submit_dynamic_pipeline()见 local_docker_orchestrator.py对于动态流水线使用DynamicPipelineEntrypointConfiguration作为入口以detachTrue后台方式启动编排容器若设置synchronousTrue默认则通过SubmissionResult.wait_for_completion等待容器日志流结束否则立即返回。这解释了LocalDockerOrchestratorSettings中synchronous参数的实际用途。此外作为ContainerizedOrchestrator的子类它继承了容器化编排器的通用能力当编排器为本地组件且 ZenML 直接连接 SQL store 时构建的镜像中会自动追加安装zenml[local]version依赖见 containerized_orchestrator.py确保容器内有完整的本地存储访问依赖镜像构建按 step 的docker_settings与流水线级docker_settings的差异去重生成见 containerized_orchestrator.py。进阶配置LocalDockerOrchestratorSettings 详解对于 Local Docker Orchestrator 的额外配置官方文档指出在定义或运行流水线时传入LocalDockerOrchestratorSettings即可。该设置类的完整定义位于 local_docker_orchestrator.py共两个字段字段类型默认值说明synchronousboolTrue是否同步运行流水线。True时提交后等待容器完成并回流日志False时异步返回。动态流水线场景下生效见submit_dynamic_pipeline。run_argsDict[str, Any]{}透传给 docker-pycontainers.run(...)的参数字典可控制 CPU、内存、GPU、端口、环境变量、卷、网络等几乎所有容器运行时行为。其中run_args是最灵活的入口其可用的键与 docker-pyContainers.run方法的参数一一对应包括但不限于cpu_count、mem_limit、gpus、ports、network、restart_policy、working_dir等。需要特别说明的是源码在真正调用containers.run之前会从run_args中抽出几个有特殊语义的键单独处理见 local_docker_orchestrator.pyimage用于覆盖默认构建出的镜像user默认情况下在非 Windows 平台使用os.getuid()作为容器内用户保证文件权限与宿主机一致Windows 下为None你可以显式覆盖environment与 ZenML 注入的 step 环境变量合并volumes与 ZenML 自动挂载的 local stores 卷合并extra_hosts与自动追加的host.docker.internal → host-gateway条目合并该条目保证容器内能访问宿主机服务。因此如果你在run_args里手动设置这些键需要注意它们会与 ZenML 的默认行为合并或覆盖user、image两个键则采用以你的设置为准的覆盖语义settings.run_args.pop(...)。配置示例限制容器 CPU 数量官方文档给出了一个直接可运行的示例通过run_args指定容器可用的 CPU 核数注意cpu_count仅对 Windows 平台生效from zenml import step, pipeline from zenml.orchestrators.local_docker.local_docker_orchestrator import ( LocalDockerOrchestratorSettings, ) step def return_one() - int: return 1 settings { orchestrator: LocalDockerOrchestratorSettings( run_args{cpu_count: 3} ) } pipeline(settingssettings) def simple_pipeline(): return_one()settings字典以orchestrator为键将设置作用到编排器组件上在流水线装饰器上通过settings参数传入后整个流水线的每个 step 容器都会按该配置启动。同理你可以在定义或运行时用同样的方式传入mem_limit、gpus等 docker-py 参数。资源限制与执行模式的注意点结合源码可以确认该编排器有两个值得注意的边界行为step 级资源请求会被忽略。在submit_pipeline中如果某个 step 声明了资源requires_resources_in_orchestration_environment为真编排器会打印警告并忽略该资源配置见 local_docker_orchestrator.py。如需为 step 分配 GPU 等硬件官方文档建议改用 step operator 组件。并发与调度能力缺失。所有 step 按依赖顺序在一个循环中逐个启动容器step 之间不存在并发schedule配置会被忽略并给出警告。GPU 与 CUDA 支持如果你计划让 step 在 GPU 上运行以获得完整的加速能力官方文档明确指出需要遵循 ZenML 分布式训练相关指南中关于自定义镜像与运行时配置的说明对镜像和run_args做额外定制——典型做法包括在镜像中安装带 CUDA 的依赖、通过run_args传入 GPU 相关的 docker-py 参数如gpus/device_requests等。只有正确配置 CUDA 运行时GPU 才能发挥全部加速能力。具体配置项与步骤取决于你的镜像构建方案建议结合 组件指南之镜像构建器 相关文档一并阅读。小结从调试利器到容器化原理的入口Local Docker Orchestrator 是 ZenML 中零集成成本、纯本地、容器化的编排方案只需 Docker 即可把流水线 step 逐个放进隔离容器运行非常适合在本地复现和排查容器化环境问题。透过它的源码local_docker_orchestrator.py、docker_engine.py、containerized_orchestrator.py你还能看到 ZenML 容器化编排的通用骨架——镜像构建、入口点注入、本地存储卷挂载、环境变量传递、执行模式控制——这些机制在 Kubernetes、Kubeflow 等远程编排器中以同样的抽象层次复用。对于想从本地进程运行平滑过渡到容器化/云端运行的团队来说它是一个成本极低、收益直接的起点。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考