DeerFlow lark-cli init 镜像（Pattern A）：用 init 容器 + emptyDir 为 Kubernetes 沙箱预置 lark-cli 运行时

DeerFlow lark-cli init 镜像Pattern A用 init 容器 emptyDir 为 Kubernetes 沙箱预置 lark-cli 运行时【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flowDeerFlow 是一个开源的长程 SuperAgent harness其飞书/Lark 集成依赖沙箱内可用的lark-cli运行时。本文以 docker/lark-cli-init/README.md 为核心完整讲解 “Pattern A” 方案在镜像构建期下载并校验官方larksuite/cliLinux 二进制在运行期通过 init 容器把运行时复制到共享emptyDir从而让 Gateway 免去“安装时从 GitHub 下载二进制 hostPath/PVC 挂载”的环节。读完本文你能掌握该镜像的构建与版本发布方式、如何把 init 容器接入 provisioner以及沙箱 PATH 契约/mnt/integrations/lark-cli/runtime/bin/lark-cli为何保持不变。1. Pattern A 要解决什么问题传统的做法legacy 路径是Gateway 在安装阶段从 GitHub 下载 Linux 二进制然后通过 hostPath/PVC 把运行时目录挂进沙箱 Pod。这种方式有两个弱点——每次安装都依赖外网下载并且运行时目录强依赖宿主机路径或 PVC 的可用性。Pattern A 的思路是把下载前移到镜像构建期把挂载前移到 init 容器构建时有网络下载官方larksuite/cli的 Linux 发布版二进制并做 SHA-256 校验把运行时布局暂存到镜像内的/opt/lark-cli/opt/lark-cli/bin/lark-cli # 架构分发启动器按 uname -m 选择 /opt/lark-cli/linux-amd64/lark-cli /opt/lark-cli/linux-arm64/lark-cli /opt/lark-cli/.deerflow-lark-cli-runtime.json # {version: vX.Y.Z}运行时无网络依赖init 容器执行cp -a /opt/lark-cli/. - ${LARK_CLI_RUNTIME_DEST}默认/mnt/integrations/lark-cli/runtime然后以退出码0结束。这个布局与 Gateway 侧的写入函数_write_lark_cli_sandbox_launcher的产物字节级一致并且满足_validate_lark_cli_sandbox_runtime的校验因此无论运行时是由 Gateway 下载写入还是由 init 容器复制而来沙箱内的 PATH 契约/mnt/integrations/lark-cli/runtime/bin/lark-cli都不变。2. 镜像构建源码级剖析构建入口是 docker/lark-cli-init/Dockerfile采用多阶段构建builder 阶段基于debian:bookworm-slim安装ca-certificates和curl执行 build-runtime.sh 完成二进制下载与暂存。支持APT_MIRROR构建参数替换 Debian 源地址便于网络受限环境。最终阶段只从 builder 复制/opt/lark-cli目录和入口脚本 entrypoint.sh镜像极小、不含网络工具。2.1 构建期脚本 build-runtime.sh 做了什么build-runtime.sh 是保证二进制可信的关键其流程为接收LARK_CLI_VERSION必填可带或不带前导v脚本会归一化为vX.Y.Z形式的 tag从larksuite/cli的 GitHub releases 下载checksums.txt以及lark-cli-version-linux-{amd64,arm64}.tar.gz两个资产逐个校验 SHA-256从checksums.txt中查找对应资产的期望哈希与本地sha256sum结果比对不一致即报错退出——这是“SHA-256-verifies”这一说法的实现落点从压缩包中只提取lark-cli可执行文件install -m 0755到dest/linux-arch/lark-cli生成架构分发启动器dest/bin/lark-cli#!/bin/sh set -eu case $(uname -m) in x86_64|amd64) archamd64 ;; aarch64|arm64) archarm64 ;; *) echo Unsupported sandbox architecture: $(uname -m) 2; exit 126 ;; esac script_dir$(CDPATH cd -- $(dirname -- $0) pwd) exec $script_dir/../linux-$arch/lark-cli $该启动器按uname -m在x86_64/amd64 → amd64、aarch64/arm64 → arm64之间分发未知架构以退出码126失败。脚本注释明确要求它与 Gateway 中LARK_CLI_SANDBOX_LAUNCHER_SCRIPT定义于 backend/packages/harness/deerflow/integrations/lark_cli.py保持字节级一致并且 backend/tests/test_lark_cli_integration.py 中的单元测试会断言两者永不漂移drift。最后写出清单文件.deerflow-lark-cli-runtime.json内容形如{version: v1.0.65}供 Gateway 的运行时校验识别版本。2.2 运行期入口 entrypoint.shentrypoint.sh 逻辑非常短小且防御式若/opt/lark-cli/bin/lark-cli不存在或不可执行打印错误并exit 1init 容器失败会阻塞整个 Pod 启动快速失败优于静默缺二进制mkdir -p目标目录后cp -a ${SRC}/. ${DEST}/注意/.会把点文件清单.deerflow-lark-cli-runtime.json一并复制打印ls -R输出便于通过kubectl logs排查。目标目录由环境变量LARK_CLI_RUNTIME_DEST指定Dockerfile 中默认值为/mnt/integrations/lark-cli/runtime。3. 构建与发布镜像按 README 的说明本地构建命令为docker build -t deer-flow/lark-cli-init:v1.0.65 \ --build-arg LARK_CLI_VERSIONv1.0.65 \ docker/lark-cli-init两个值得注意的版本策略镜像 tag 编码 lark-cli 版本如v1.0.65这样 lark-cli 升级可以独立于上游all-in-one-sandbox沙箱镜像单独 bumpCI 发布多架构镜像.github/workflows/lark-cli-images.yaml该 workflow 文件确实存在于仓库.github/workflows/lark-cli-images.yaml会以linux/amd64,linux/arm64双架构发布到ghcr.io/owner/deer-flow-lark-cli-init:lark-cli-version。触发方式为手动传入lark_cli_version输入或推送lark-cli-v*形式的 tag。该发布流程与 DeerFlow 自身的v*release 解耦因为镜像追踪的是上游larksuite/cli的版本——RELEASING.md 也确认该镜像有自己的verify-versions版本门禁且版本号取 lark-cli 发布版而非 DeerFlow 发布版。4. 接入 provisioneropt-in 且默认关闭init 容器路径是显式 opt-in不配置就是旧行为零风险。接入方式在 provisioner 服务上设置LARK_CLI_INIT_IMAGE指向已发布的 tag例如deer-flow/lark-cli-init:v1.0.65。留空默认⇒ 走 legacy 的 hostPath / Gateway 下载路径行为完全不变。配置后 provisioner 的行为变化源码位于 docker/provisioner/app.py环境变量读取LARK_CLI_INIT_IMAGE os.environ.get(LARK_CLI_INIT_IMAGE, )同时定义运行时容器路径常量LARK_CLI_RUNTIME_CONTAINER_PATH /mnt/integrations/lark-cli/runtime与卷名lark-cli-runtime使能判断_lark_cli_runtime_enabled()返回bool(LARK_CLI_INIT_IMAGE) and provision_lark_cli_runtime——即“镜像已配置”且“创建请求带provision_lark_cli_runtime: true”两个条件同时成立才生效Gateway 在托管 Lark 技能包安装后会自动发送该标志见 docker/provisioner/README.md满足条件时provisioner 会添加一个lark-cli-runtimeemptyDir卷、一个名为lark-cli-init的 init 容器image_pull_policyIfNotPresent注入LARK_CLI_RUNTIME_DEST环境变量并挂载该卷、使用安全加固的 security context以及沙箱主容器上的只读运行时挂载此时会忽略任何指向/mnt/integrations/lark-cli/runtime的 hostPath/PVC extra mountinit 容器路径取代它而 per-user 的config/data凭据挂载不受影响照旧挂入沙箱若同时配置了 Pattern B 的 broker 镜像broker 优先_build_lark_cli_init_containers中 broker 分支先于 runtime 分支返回。就绪信号上报provisioner 通过GET /api/capabilities报告{lark_cli_init_image: true|false}源码中该端点返回lark_cli_init_image与lark_cli_broker_image两个布尔值Gateway 把它作为 Lark 集成的沙箱运行时就绪信号暴露在GET /api/integrations/lark/status上。从源码结构看Gateway 的 lark_cli.py 按优先级判定broker 已配置 ⇒broker模式否则 init 镜像已配置 ⇒init-container模式都未配置则sandbox_runtime_readyfalse并给出 “The provisioner has no lark-cli runtime image configured (LARK_CLI_INIT_IMAGE / LARK_CLI_BROKER_IMAGE)” 的提示。这样设置页 UI 能如实显示聊天时lark-cli是否真的存在于沙箱内避免“状态绿色、聊天时报 command not found”的假就绪README.md 主文档对此有同样的描述。在 docker/docker-compose.yaml 与 docker/docker-compose-dev.yaml 中provisioner 服务已预留- LARK_CLI_INIT_IMAGE${LARK_CLI_INIT_IMAGE:-}环境变量默认空与 docker/provisioner/README.md 的环境变量表一致LARK_CLI_INIT_IMAGE默认空feature off。5. 测试与验证该特性的行为契约由测试固化在 backend/tests/test_provisioner_pvc_volumes.pytest_no_init_container_when_image_unsetLARK_CLI_INIT_IMAGE为空时即使请求带provision_lark_cli_runtimeTruePod 中也不出现 init 容器test_no_init_container_when_flag_disabled镜像已配置但请求不带标志时同样不注入test_init_container_and_emptydir_when_enabled两者齐备时Pod 得到 init 容器 emptyDirtest_runtime_extra_mount_dropped_when_init_container_enabledinit 容器启用时指向运行时路径的 extra hostPath 挂载被丢弃“双镜像双标志”用例断言 broker 胜出shim init sidecar印证第 4 节的优先级。6. 小结何时使用 Pattern A适用场景Kubernetes 沙箱部署、希望消除安装期外网下载依赖、节点不便于维护 hostPath/PVC 运行时目录的飞书/Lark 集成环境启用步骤构建并发布镜像tag 编码 lark-cli 版本→ provisioner 设置LARK_CLI_INIT_IMAGE→ 通过/api/capabilities与/api/integrations/lark/status验证sandbox_runtime_ready不配置时完全回落到 legacy hostPath / Gateway 下载路径无行为变化——这是该设计明确的 opt-in 承诺后续演进若目标是让appSecret/OAuth 令牌文件完全不进入沙箱文件系统仓库提供了 Pattern Bdocker/lark-cli-broker其 broker 模式在两者同时配置时取代 Pattern A。【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考