Haystack Docker 镜像构建与部署指南从docker buildx bake多平台构建到生产发布【免费下载链接】haystackOpen-source AI orchestration framework for building context-engineered, production-ready LLM applications. Design modular pipelines and agent workflows with explicit control over retrieval, routing, memory, and generation. Built for scalable agents, RAG, multimodal applications, semantic search, and conversational systems.项目地址: https://gitcode.com/GitHub_Trending/ha/haystack导读本文聚焦 deepset Haystack 开源仓库中 docker/README.md 所定义的核心内容deepset/haystack官方 Docker 镜像的形态、基于 BuildKit 与 Bake 的镜像构建流程以及多平台amd64/arm64构建的常见问题与解决方案。读完本文你将掌握如何拉取并验证 Haystack 基础镜像、如何基于base镜像自定义应用镜像以及如何复现官方 CI 的镜像构建、发布与版本校验全流程。一、镜像形态概览只有一个base镜像从 docker/README.md 可以看出Haystack 2.x 及后续版本对镜像策略做了大幅简化——整个仓库只维护一个镜像haystack:base-version包含一个可直接运行 Python 的完整环境并且已经预装好 Haystack 本体。该镜像被设计为基础镜像预期由用户通过FROM指令继续派生。这一点在官方文档 docs-website/docs/development/deployment/docker.mdx 中有明确印证目前 Haystack 唯一的镜像 flavor 就是base它所包含的内容等价于在本地执行pip install haystack-ai后得到的 Python 环境。拉取指定版本镜像官方文档给出了按版本标签拉取镜像的方式例如拉取包含 Haystack 3.0.0 的镜像docker pull deepset/haystack:base-v3.0.0用镜像快速验证版本base镜像虽然定位为待派生的基础但也可以直接用来在本地快速运行 Haystack 脚本无需手动搭建 Python 环境。例如打印镜像内预装的 Haystack 版本docker run -it --rm deepset/haystack:base-v3.0.0 python -cfrom haystack.version import __version__; print(__version__)这一验证思路与官方 CI 的做法完全一致详见下文第六节通过from haystack.version import __version__读取包版本再与仓库VERSION.txt中的期望值比对。从源码看haystack/version.py 中的__version__实际来自已安装发行版的元数据importlib.metadata读取haystack-ai包版本因此该命令打印的是镜像内真实安装的版本而非硬编码常量。二、基于base镜像自定义应用镜像由于base镜像只包含 Haystack 核心依赖真实应用通常还需要额外的集成包。官方文档给出的典型做法是编写一个派生 Dockerfile在官方基础镜像之上追加安装集成依赖再挂载自己的应用代码。例如一个使用 Chroma 作为 Document Store 的索引管线需要额外安装chroma-haystack包。假设当前目录下有main.py脚本Dockerfile 可以这样写FROM deepset/haystack:base-v3.0.0 RUN pip install chroma-haystack COPY ./main.py /usr/src/myapp/main.py ENTRYPOINT [python, /usr/src/myapp/main.py]随后构建自定义镜像docker build . -t my-haystack-image建议把派生镜像的FROM固定到具体版本标签如base-v3.0.0而不是使用不带版本号的模糊标签这样能保证构建的可复现性——这与仓库构建镜像时通过固定 digest 锁定基础镜像见第五节的理念一致。三、镜像开发用 BuildKit 与 Bake 编排构建docker/README.md 明确指出镜像使用 BuildKit 构建并借助bake进行编排。bake是 Docker Buildx 内置的高级构建编排工具它读取 HCLHashiCorp Configuration Language格式的构建定义文件一次性声明多个构建目标target、变量、平台和标签规则。构建单个镜像在仓库根目录执行docker buildx bake base该命令会解析 docker/docker-bake.hcl 中名为base的 target使用 docker/Dockerfile.base 构建镜像。覆盖变量构建自定义镜像docker-bake.hcl中的所有variable都可在命令行通过环境变量覆盖。例如若想基于 Haystack 仓库的某个分支或 tag 构建镜像可以这样运行HAYSTACK_VERSIONmybranch_or_tag BASE_IMAGE_TAG_SUFFIXlatest docker buildx bake base --no-cache这条命令做了两件事HAYSTACK_VERSIONmybranch_or_tag告诉构建过程从该分支/tag 浅克隆 Haystack 源码并安装对应 Dockerfile.base 中的git clone --depth1 --branch${haystack_version}BASE_IMAGE_TAG_SUFFIXlatest把派生镜像的基础环境对齐到latest同时--no-cache确保不使用旧的构建缓存。四、深入 Bake 配置变量与 target 全解析docker/docker-bake.hcl 是镜像构建的单一事实来源。它声明的变量及默认值如下变量默认值作用HAYSTACK_VERSIONmain指定要安装的 Haystack 源码分支/tag对应git clone --branch的参数GITHUB_REF预留的 CI 引用信息变量发布流程中由工作流驱动IMAGE_NAMEdeepset/haystack推送到 Docker Hub 的仓库名IMAGE_TAG_SUFFIXlocal生成base-suffix标签的后缀部分本地默认localBASE_IMAGE_TAG_SUFFIXlocal用于对齐基础环境标签后缀的变量IS_STABLEfalse是否为稳定版本为true时额外追加stable标签basetarget 的关键定义包括dockerfileDockerfile.basetags生成deepset/haystack:base-${IMAGE_TAG_SUFFIX}且当IS_STABLEtrue时追加deepset/haystack:stable。文件中的注释说明2.Y.Z 形式的正式发布版本例如2.99.0会同时打上base-2.99.0与stable两个标签args向 Dockerfile 传递build_image、base_image两者默认固定为python:3.12-slimsha256:...的 digest 引用以及haystack_versionplatforms[linux/amd64, linux/arm64]即官方镜像默认同时构建 x86_64 与 ARM64 两个架构。需要注意docker-bake.hcl会覆盖 Dockerfile 内声明的默认 digest 参数Dockerfile 注释明确说明这是为了在docker build直接构建或供应链扫描工具解析时基础镜像仍可按哈希解析。构建时如需同步更新基础镜像 digest应同时维护 docker/Dockerfile.base 中的两处ARG默认值。五、多平台构建支持多架构与常见错误docker/README.md 强调Haystack 镜像支持多架构linux/amd64 与 linux/arm64但能否在本地全部构建取决于操作系统与 Docker 环境。常见错误在未启用对应驱动的 Docker 环境中直接多平台构建很可能遇到如下报错multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. “docker buildx create --use”)该错误的根源是默认的docker驱动不支持多平台特性提示信息本身就给出了解决方向docker buildx create --use创建并使用 buildx 构建器。本地限缩到单架构构建另一种务实做法是覆盖platform选项把本地构建限制到与当前机器相同的架构。例如在 Apple M1ARM64上只构建 ARM 版本docker buildx bake base --set *.platformlinux/arm64--set *.platform...语法会批量覆盖 bake 定义中所有 target 的platform字段从而绕过多平台驱动要求。对应地在 x86_64 机器上可写为--set *.platformlinux/amd64。官方 CI 如何实现多平台官方在 CI 中并没有依赖本机驱动而是通过 GitHub Actions 的docker/setup-qemu-action与docker/setup-buildx-action搭建跨架构构建环境见 .github/workflows/docker_release.yml。从该工作流可以推断多平台镜像的完整产物需要 QEMU 模拟 Buildx 构建器协同本地开发时可优先采用单架构限缩策略。六、Dockerfile 构建原理多阶段与版本锁定docker/Dockerfile.base 采用两阶段构建结构清晰阶段一build-image安装 HaystackFROM ${build_image} AS build-image ARG DEBIAN_FRONTENDnoninteractive ARG haystack_version RUN apt-get update \ apt-get install -y --no-install-recommends git基础镜像为python:3.12-slim并通过 digest 固定sha256:...保证可复现性与供应链可审计性安装git为后续克隆 Haystack 源码做准备从ghcr.io/astral-sh/uv复制uv/uvx到镜像用于加速依赖安装。随后完成源码获取与安装RUN git clone --depth1 --branch${haystack_version} https://github.com/deepset-ai/haystack.git /opt/haystack WORKDIR /opt/haystack RUN python3 -m venv /opt/venv ENV PATH/opt/venv/bin:$PATH RUN uv pip install --no-cache-dir -U setuptools \ uv pip install --no-cache-dir .这里有几个值得注意的实现细节浅克隆--depth1只拉取指定分支/tag 的最新提交显著减小构建上下文venv 而非 uv 创建虚拟环境Dockerfile 注释明确说明这是为了确保虚拟环境可被 pip 正常访问避免 uv 引入的兼容性破坏同时 uv 仍用于加速安装升级 setuptools出于 CVE-2022-40897 的修复Dockerfile 中给出了 NVD 编号从本地源码安装执行uv pip install .安装的是刚克隆的源码树因此HAYSTACK_VERSION直接决定镜像内的 Haystack 版本。阶段二final精简运行时FROM ${base_image} AS final COPY --frombuild-image /opt/venv /opt/venv ENV PATH/opt/venv/bin:$PATH最终镜像只保留基础 Python 镜像 已安装的虚拟环境不携带构建期残留的 git 与源码这正是官方文档所说等同于pip install haystack-ai的干净 Python 环境。七、自动化发布与镜像验证CI 视角.github/workflows/docker_release.yml 展示了官方如何把 docker/README.md 中的构建命令落地为持续交付流程触发条件workflow_dispatch手动触发、main分支的docker/**、haystack/**、pyproject.toml、VERSION.txt等路径变更以及v[0-9].[0-9].[0-9]*形式的版本 tag 推送构建环境先设置 QEMU 与 Docker Buildx对应多平台构建需求再登录 Docker Hub稳定版本检测当 tag 形如vX.Y.Z不带预发布后缀时设置IS_STABLEtrue并写入环境变量构建与推送通过docker/bake-action执行basetarget并注入IMAGE_TAG_SUFFIX与HAYSTACK_VERSION均来自 meta 输出的版本号镜像验证分别以linux/amd64与linux/arm64平台运行容器执行python -cfrom haystack.version import __version__; print(__version__)将输出与VERSION.txt解析后的期望版本比对不一致则输出 error验证完成后删除镜像避免撑满 runner 磁盘。这里有一个值得注意的细节工作流对VERSION.txt的解析会先去掉-及之后的预发布后缀再比较说明镜像 tag 与仓库内版本文件可能存在去掉 rc 后缀的对应关系当前仓库 VERSION.txt 为3.2.0-rc0属于开发中的预发布版本。八、镜像内软件的许可说明docker/README.md 最后还给出了镜像许可的使用提示核心要点有三镜像内 Haystack 软件的许可信息见仓库 LICENSE与其他 Docker 镜像类似base镜像内还可能包含来自基础发行版的其他软件如 Bash、系统工具等以及 Haystack 直接或间接依赖的第三方包这些软件各自适用其原始许可使用镜像属于使用预构建产物最终用户有责任确认镜像内所有软件的使用方式符合其各自许可条款。对于企业级落地建议结合仓库的 licenserc.toml 与 CI 中的 license 合规检查.github/workflows/license_compliance.yml自行评估依赖许可。九、从镜像构建到应用部署的衔接需要区分两个层面本文介绍的docker/README.md解决的是**镜像怎么构建出来而 docs-website/docs/development/deployment/docker.mdx 解决的是镜像怎么用起来**——包括拉取官方镜像、基于base派生自定义镜像以及用 Docker Compose 编排 Haystack 服务与外部组件如 Qdrant。如果你需要完整落地一个 RAG 应用可以遵循该部署文档的流程先用docker buildx bake base理解镜像的构建方式再以官方base镜像为起点派生包含自己管线与集成依赖的镜像。十、快速参考命令清单目的命令构建 base 镜像默认 main 分支docker buildx bake base用指定分支/tag 构建HAYSTACK_VERSIONmybranch_or_tag BASE_IMAGE_TAG_SUFFIXlatest docker buildx bake base --no-cache仅构建 ARM64Apple M1 等docker buildx bake base --set *.platformlinux/arm64仅构建 amd64docker buildx bake base --set *.platformlinux/amd64拉取指定版本镜像docker pull deepset/haystack:base-v3.0.0验证镜像内版本docker run -it --rm deepset/haystack:base-v3.0.0 python -cfrom haystack.version import __version__; print(__version__)基于 base 派生并构建应用镜像docker build . -t my-haystack-image适用前提说明上述构建命令需要 Docker 环境启用 Buildxdocker buildx create --useHAYSTACK_VERSION指定的分支/tag 需能被git clone --branch解析且默认从 GitHub 官方仓库克隆本地多平台构建受 Docker 驱动限制时请按第五节方法限缩平台。【免费下载链接】haystackOpen-source AI orchestration framework for building context-engineered, production-ready LLM applications. Design modular pipelines and agent workflows with explicit control over retrieval, routing, memory, and generation. Built for scalable agents, RAG, multimodal applications, semantic search, and conversational systems.项目地址: https://gitcode.com/GitHub_Trending/ha/haystack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Haystack Docker 镜像构建与部署指南：从 `docker buildx bake` 多平台构建到生产发布
Haystack Docker 镜像构建与部署指南从docker buildx bake多平台构建到生产发布【免费下载链接】haystackOpen-source AI orchestration framework for building context-engineered, production-ready LLM applications. Design modular pipelines and agent workflows with explicit control over retrieval, routing, memory, and generation. Built for scalable agents, RAG, multimodal applications, semantic search, and conversational systems.项目地址: https://gitcode.com/GitHub_Trending/ha/haystack导读本文聚焦 deepset Haystack 开源仓库中 docker/README.md 所定义的核心内容deepset/haystack官方 Docker 镜像的形态、基于 BuildKit 与 Bake 的镜像构建流程以及多平台amd64/arm64构建的常见问题与解决方案。读完本文你将掌握如何拉取并验证 Haystack 基础镜像、如何基于base镜像自定义应用镜像以及如何复现官方 CI 的镜像构建、发布与版本校验全流程。一、镜像形态概览只有一个base镜像从 docker/README.md 可以看出Haystack 2.x 及后续版本对镜像策略做了大幅简化——整个仓库只维护一个镜像haystack:base-version包含一个可直接运行 Python 的完整环境并且已经预装好 Haystack 本体。该镜像被设计为基础镜像预期由用户通过FROM指令继续派生。这一点在官方文档 docs-website/docs/development/deployment/docker.mdx 中有明确印证目前 Haystack 唯一的镜像 flavor 就是base它所包含的内容等价于在本地执行pip install haystack-ai后得到的 Python 环境。拉取指定版本镜像官方文档给出了按版本标签拉取镜像的方式例如拉取包含 Haystack 3.0.0 的镜像docker pull deepset/haystack:base-v3.0.0用镜像快速验证版本base镜像虽然定位为待派生的基础但也可以直接用来在本地快速运行 Haystack 脚本无需手动搭建 Python 环境。例如打印镜像内预装的 Haystack 版本docker run -it --rm deepset/haystack:base-v3.0.0 python -cfrom haystack.version import __version__; print(__version__)这一验证思路与官方 CI 的做法完全一致详见下文第六节通过from haystack.version import __version__读取包版本再与仓库VERSION.txt中的期望值比对。从源码看haystack/version.py 中的__version__实际来自已安装发行版的元数据importlib.metadata读取haystack-ai包版本因此该命令打印的是镜像内真实安装的版本而非硬编码常量。二、基于base镜像自定义应用镜像由于base镜像只包含 Haystack 核心依赖真实应用通常还需要额外的集成包。官方文档给出的典型做法是编写一个派生 Dockerfile在官方基础镜像之上追加安装集成依赖再挂载自己的应用代码。例如一个使用 Chroma 作为 Document Store 的索引管线需要额外安装chroma-haystack包。假设当前目录下有main.py脚本Dockerfile 可以这样写FROM deepset/haystack:base-v3.0.0 RUN pip install chroma-haystack COPY ./main.py /usr/src/myapp/main.py ENTRYPOINT [python, /usr/src/myapp/main.py]随后构建自定义镜像docker build . -t my-haystack-image建议把派生镜像的FROM固定到具体版本标签如base-v3.0.0而不是使用不带版本号的模糊标签这样能保证构建的可复现性——这与仓库构建镜像时通过固定 digest 锁定基础镜像见第五节的理念一致。三、镜像开发用 BuildKit 与 Bake 编排构建docker/README.md 明确指出镜像使用 BuildKit 构建并借助bake进行编排。bake是 Docker Buildx 内置的高级构建编排工具它读取 HCLHashiCorp Configuration Language格式的构建定义文件一次性声明多个构建目标target、变量、平台和标签规则。构建单个镜像在仓库根目录执行docker buildx bake base该命令会解析 docker/docker-bake.hcl 中名为base的 target使用 docker/Dockerfile.base 构建镜像。覆盖变量构建自定义镜像docker-bake.hcl中的所有variable都可在命令行通过环境变量覆盖。例如若想基于 Haystack 仓库的某个分支或 tag 构建镜像可以这样运行HAYSTACK_VERSIONmybranch_or_tag BASE_IMAGE_TAG_SUFFIXlatest docker buildx bake base --no-cache这条命令做了两件事HAYSTACK_VERSIONmybranch_or_tag告诉构建过程从该分支/tag 浅克隆 Haystack 源码并安装对应 Dockerfile.base 中的git clone --depth1 --branch${haystack_version}BASE_IMAGE_TAG_SUFFIXlatest把派生镜像的基础环境对齐到latest同时--no-cache确保不使用旧的构建缓存。四、深入 Bake 配置变量与 target 全解析docker/docker-bake.hcl 是镜像构建的单一事实来源。它声明的变量及默认值如下变量默认值作用HAYSTACK_VERSIONmain指定要安装的 Haystack 源码分支/tag对应git clone --branch的参数GITHUB_REF预留的 CI 引用信息变量发布流程中由工作流驱动IMAGE_NAMEdeepset/haystack推送到 Docker Hub 的仓库名IMAGE_TAG_SUFFIXlocal生成base-suffix标签的后缀部分本地默认localBASE_IMAGE_TAG_SUFFIXlocal用于对齐基础环境标签后缀的变量IS_STABLEfalse是否为稳定版本为true时额外追加stable标签basetarget 的关键定义包括dockerfileDockerfile.basetags生成deepset/haystack:base-${IMAGE_TAG_SUFFIX}且当IS_STABLEtrue时追加deepset/haystack:stable。文件中的注释说明2.Y.Z 形式的正式发布版本例如2.99.0会同时打上base-2.99.0与stable两个标签args向 Dockerfile 传递build_image、base_image两者默认固定为python:3.12-slimsha256:...的 digest 引用以及haystack_versionplatforms[linux/amd64, linux/arm64]即官方镜像默认同时构建 x86_64 与 ARM64 两个架构。需要注意docker-bake.hcl会覆盖 Dockerfile 内声明的默认 digest 参数Dockerfile 注释明确说明这是为了在docker build直接构建或供应链扫描工具解析时基础镜像仍可按哈希解析。构建时如需同步更新基础镜像 digest应同时维护 docker/Dockerfile.base 中的两处ARG默认值。五、多平台构建支持多架构与常见错误docker/README.md 强调Haystack 镜像支持多架构linux/amd64 与 linux/arm64但能否在本地全部构建取决于操作系统与 Docker 环境。常见错误在未启用对应驱动的 Docker 环境中直接多平台构建很可能遇到如下报错multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. “docker buildx create --use”)该错误的根源是默认的docker驱动不支持多平台特性提示信息本身就给出了解决方向docker buildx create --use创建并使用 buildx 构建器。本地限缩到单架构构建另一种务实做法是覆盖platform选项把本地构建限制到与当前机器相同的架构。例如在 Apple M1ARM64上只构建 ARM 版本docker buildx bake base --set *.platformlinux/arm64--set *.platform...语法会批量覆盖 bake 定义中所有 target 的platform字段从而绕过多平台驱动要求。对应地在 x86_64 机器上可写为--set *.platformlinux/amd64。官方 CI 如何实现多平台官方在 CI 中并没有依赖本机驱动而是通过 GitHub Actions 的docker/setup-qemu-action与docker/setup-buildx-action搭建跨架构构建环境见 .github/workflows/docker_release.yml。从该工作流可以推断多平台镜像的完整产物需要 QEMU 模拟 Buildx 构建器协同本地开发时可优先采用单架构限缩策略。六、Dockerfile 构建原理多阶段与版本锁定docker/Dockerfile.base 采用两阶段构建结构清晰阶段一build-image安装 HaystackFROM ${build_image} AS build-image ARG DEBIAN_FRONTENDnoninteractive ARG haystack_version RUN apt-get update \ apt-get install -y --no-install-recommends git基础镜像为python:3.12-slim并通过 digest 固定sha256:...保证可复现性与供应链可审计性安装git为后续克隆 Haystack 源码做准备从ghcr.io/astral-sh/uv复制uv/uvx到镜像用于加速依赖安装。随后完成源码获取与安装RUN git clone --depth1 --branch${haystack_version} https://github.com/deepset-ai/haystack.git /opt/haystack WORKDIR /opt/haystack RUN python3 -m venv /opt/venv ENV PATH/opt/venv/bin:$PATH RUN uv pip install --no-cache-dir -U setuptools \ uv pip install --no-cache-dir .这里有几个值得注意的实现细节浅克隆--depth1只拉取指定分支/tag 的最新提交显著减小构建上下文venv 而非 uv 创建虚拟环境Dockerfile 注释明确说明这是为了确保虚拟环境可被 pip 正常访问避免 uv 引入的兼容性破坏同时 uv 仍用于加速安装升级 setuptools出于 CVE-2022-40897 的修复Dockerfile 中给出了 NVD 编号从本地源码安装执行uv pip install .安装的是刚克隆的源码树因此HAYSTACK_VERSION直接决定镜像内的 Haystack 版本。阶段二final精简运行时FROM ${base_image} AS final COPY --frombuild-image /opt/venv /opt/venv ENV PATH/opt/venv/bin:$PATH最终镜像只保留基础 Python 镜像 已安装的虚拟环境不携带构建期残留的 git 与源码这正是官方文档所说等同于pip install haystack-ai的干净 Python 环境。七、自动化发布与镜像验证CI 视角.github/workflows/docker_release.yml 展示了官方如何把 docker/README.md 中的构建命令落地为持续交付流程触发条件workflow_dispatch手动触发、main分支的docker/**、haystack/**、pyproject.toml、VERSION.txt等路径变更以及v[0-9].[0-9].[0-9]*形式的版本 tag 推送构建环境先设置 QEMU 与 Docker Buildx对应多平台构建需求再登录 Docker Hub稳定版本检测当 tag 形如vX.Y.Z不带预发布后缀时设置IS_STABLEtrue并写入环境变量构建与推送通过docker/bake-action执行basetarget并注入IMAGE_TAG_SUFFIX与HAYSTACK_VERSION均来自 meta 输出的版本号镜像验证分别以linux/amd64与linux/arm64平台运行容器执行python -cfrom haystack.version import __version__; print(__version__)将输出与VERSION.txt解析后的期望版本比对不一致则输出 error验证完成后删除镜像避免撑满 runner 磁盘。这里有一个值得注意的细节工作流对VERSION.txt的解析会先去掉-及之后的预发布后缀再比较说明镜像 tag 与仓库内版本文件可能存在去掉 rc 后缀的对应关系当前仓库 VERSION.txt 为3.2.0-rc0属于开发中的预发布版本。八、镜像内软件的许可说明docker/README.md 最后还给出了镜像许可的使用提示核心要点有三镜像内 Haystack 软件的许可信息见仓库 LICENSE与其他 Docker 镜像类似base镜像内还可能包含来自基础发行版的其他软件如 Bash、系统工具等以及 Haystack 直接或间接依赖的第三方包这些软件各自适用其原始许可使用镜像属于使用预构建产物最终用户有责任确认镜像内所有软件的使用方式符合其各自许可条款。对于企业级落地建议结合仓库的 licenserc.toml 与 CI 中的 license 合规检查.github/workflows/license_compliance.yml自行评估依赖许可。九、从镜像构建到应用部署的衔接需要区分两个层面本文介绍的docker/README.md解决的是**镜像怎么构建出来而 docs-website/docs/development/deployment/docker.mdx 解决的是镜像怎么用起来**——包括拉取官方镜像、基于base派生自定义镜像以及用 Docker Compose 编排 Haystack 服务与外部组件如 Qdrant。如果你需要完整落地一个 RAG 应用可以遵循该部署文档的流程先用docker buildx bake base理解镜像的构建方式再以官方base镜像为起点派生包含自己管线与集成依赖的镜像。十、快速参考命令清单目的命令构建 base 镜像默认 main 分支docker buildx bake base用指定分支/tag 构建HAYSTACK_VERSIONmybranch_or_tag BASE_IMAGE_TAG_SUFFIXlatest docker buildx bake base --no-cache仅构建 ARM64Apple M1 等docker buildx bake base --set *.platformlinux/arm64仅构建 amd64docker buildx bake base --set *.platformlinux/amd64拉取指定版本镜像docker pull deepset/haystack:base-v3.0.0验证镜像内版本docker run -it --rm deepset/haystack:base-v3.0.0 python -cfrom haystack.version import __version__; print(__version__)基于 base 派生并构建应用镜像docker build . -t my-haystack-image适用前提说明上述构建命令需要 Docker 环境启用 Buildxdocker buildx create --useHAYSTACK_VERSION指定的分支/tag 需能被git clone --branch解析且默认从 GitHub 官方仓库克隆本地多平台构建受 Docker 驱动限制时请按第五节方法限缩平台。【免费下载链接】haystackOpen-source AI orchestration framework for building context-engineered, production-ready LLM applications. Design modular pipelines and agent workflows with explicit control over retrieval, routing, memory, and generation. Built for scalable agents, RAG, multimodal applications, semantic search, and conversational systems.项目地址: https://gitcode.com/GitHub_Trending/ha/haystack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考