使用 Docker 单独部署 Conductor UIconductor:ui 镜像构建、运行与 nginx 代理配置全解析【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor导读Conductor 的 Web 控制台UI默认随conductor:server镜像一并打包提供但在某些场景下——例如已有独立部署的 Conductor Server、希望前后端分别扩容或需要将 UI 挂在自定义域名之后——单独运行一个 UI 容器是更清晰的架构选择。本文以 docker/ui/README.md 为骨架完整讲解conductor:ui镜像的构建命令、两种典型运行方式连接 localhost 服务端 / 连接外部服务端、WF_SERVER环境变量的作用并结合 docker/ui/Dockerfile、docker/ui/nginx.conf.template 以及ui-next前端工程的源码深入剖析该镜像的构建流程、nginx 反向代理与 SPA 静态资源服务原理帮你快速落地一套可独立运行的 Conductor 控制台。一、镜像定位conductor:ui 与 conductor:server 的关系在动手构建之前先明确conductor:ui在整个 Docker 镜像体系中的位置conductor:serverdocker/server/Dockerfile是服务端 UI 一体化镜像它在构建阶段同时编译 Java 服务端 JAR 与ui-next前端产物最终镜像内用 nginx 托管 UI 静态文件并把/api、/actuator反向代理到本机 8080 端口。这也是docker-compose系列文件默认使用的方式例如 docker-compose.yaml 中直接将服务端口映射为8000:8080API与8127:5000UI。conductor:uidocker/ui/Dockerfile是独立的 UI 镜像仅包含前端静态资源与 nginx。Dockerfile 头部注释明确说明the conductor:server image already bundles this same UI — this image is only for running the UI separately.server 镜像已内置同一套 UI本镜像仅用于单独运行 UI。因此如果你的目标是我只需要一个可访问的 Web 控制台且服务端已经就绪单独构建并运行conductor:ui即可无需重新构建庞大的 server 镜像。二、构建 conductor:ui 镜像2.1 标准构建命令在仓库根目录执行docker build -f docker/ui/Dockerfile -t conductor:ui .要点必须从仓库根目录执行构建上下文为当前目录Dockerfile 中通过COPY ui-next /conductor/ui-next引用整个ui-next/前端工程-f docker/ui/Dockerfile显式指定 Dockerfile 路径-t conductor:ui为镜像命名后续docker run与docker compose均使用该名称引用。2.2 两阶段构建流程剖析从 docker/ui/Dockerfile 可以看出该镜像采用标准的多阶段构建阶段一builder编译前端FROM node:lts AS builder COPY ui-next /conductor/ui-next WORKDIR /conductor/ui-next RUN corepack enable \ pnpm install --frozen-lockfile \ NODE_OPTIONS--max-old-space-size4096 pnpm build使用 Node LTS 基础镜像通过corepack enable启用 Corepack并按 ui-next/package.json 中packageManager字段锁定的 pnpm 版本当前为pnpm10.34.1执行安装--frozen-lockfile强制按pnpm-lock.yaml精确安装依赖保证构建可复现NODE_OPTIONS--max-old-space-size4096将 Node 堆内存上限提升到 4GB避免大型前端构建vite build时 OOM产物输出到/conductor/ui-next/dist。阶段二serve打包静态资源并接管 HTTP 服务FROM nginx:stable-alpine ENV WF_SERVERhttp://conductor-server:8080 COPY --frombuilder /conductor/ui-next/dist /usr/share/nginx/html COPY docker/ui/nginx.conf.template /etc/nginx/templates/default.conf.template EXPOSE 5000基于nginx:stable-alpine轻量镜像通过ENV预置WF_SERVER默认值http://conductor-server:8080容器内服务端主机名与端口将前端构建产物拷贝到 nginx 的 Web 根目录/usr/share/nginx/html将 nginx 配置模板拷贝到/etc/nginx/templates/目录官方 nginx 镜像会在容器启动时用envsubst将模板渲染到/etc/nginx/conf.d/EXPOSE 5000声明容器监听 5000 端口。需要特别留意的是该阶段没有自定义ENTRYPOINT/CMD完全沿用官方nginx:stable-alpine镜像的启动行为这正是模板会被自动渲染这一机制能够生效的前提。三、运行 conductor:ui 容器3.1 模式一连接 localhost 上的 Conductor Server适用于 UI 与 Server 部署在同一台机器、Server 监听 8080 端口的场景docker run -p 5000:5000 -d -t conductor:ui-p 5000:5000将容器 5000 端口映射到宿主机 5000 端口-d后台运行-t分配伪终端与 README 原始命令保持一致此时WF_SERVER使用镜像内置默认值nginx 将/api、/actuator代理到conductor-server:8080。若本机部署的 Server 容器恰好命名为conductor-server且与 UI 容器处于同一 Docker 网络则开箱即用。3.2 模式二连接外部 Conductor Server当 Server 运行在其他主机、其他容器或不同网络时通过环境变量覆盖服务端地址docker run -p 5000:5000 -d -t -e WF_SERVERhttp://conductor-server:8080 conductor:ui将http://conductor-server:8080替换为你的实际服务端地址即可例如http://192.168.1.100:8080或https://conductor.example.com。由于模板是启动时渲染的只需修改环境变量并重建容器即可切换后端无需重新构建镜像。3.3 验证部署启动后可通过以下方式确认curl -I http://localhost:5000 # 应返回 200 与 text/html curl -I http://localhost:5000/api # 应被 nginx 代理转发到服务端若服务端未就绪/api会返回 502/504此时只需确认服务端地址可达、端口正确即可。四、nginx 配置深入静态服务 API 反代 安全头conductor:ui之所以能同时胜任前端静态资源服务器和API 网关两个角色全部逻辑都在 docker/ui/nginx.conf.template 中。逐段解读如下4.1 SPA 静态资源服务与安全响应头server { listen 5000; server_name conductor; server_tokens off; location / { add_header Referrer-Policy strict-origin; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; root /usr/share/nginx/html; try_files $uri /index.html; }server_tokens off隐藏 nginx 版本号减少信息泄露面三个安全头分别约束来源引用策略Referrer-Policy: strict-origin、禁止被 iframe 嵌入X-Frame-Options: SAMEORIGIN、禁用 MIME 类型嗅探X-Content-Type-Options: nosnifftry_files $uri /index.html是标准的 SPA 回退规则请求路径若命中真实文件则直接返回否则一律回退到index.html由前端路由react-router接管——这保证刷新/workflow/xxx之类的深链接不会 404。4.2 /api 与 /actuator 反向代理location /api { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; proxy_pass ${WF_SERVER}/api; proxy_ssl_session_reuse off; proxy_set_header Host $http_host; proxy_cache_bypass $http_upgrade; proxy_redirect off; } location /actuator { ... 同上 ... }${WF_SERVER}是模板变量容器启动时由envsubst替换为WF_SERVER环境变量的值与proxy_pass ${WF_SERVER}/api这种带 URI的写法搭配时nginx 会将原始请求 URI 中匹配/api前缀之后的部分拼接到上游地址之后因此前端请求/api/workflow会被转发为${WF_SERVER}/api/workflow透传X-Real-IP、X-Forwarded-For便于服务端记录真实客户端 IPHost: $http_host保证服务端看到的 Host 与浏览器一致/actuator用于透传 Spring Boot Actuator 健康/指标端点如http://localhost:8080/health方便 UI 展示服务端健康状态proxy_redirect off避免上游 3xx 响应中的 Location 被改写。4.3 模板渲染机制envsubst这段配置之所以是.template后缀而非.conf是因为官方 nginx 镜像内置的入口脚本会遍历/etc/nginx/templates/*.template以环境变量为输入执行envsubst将渲染结果写入/etc/nginx/conf.d/同名文件。因此想要指向外部服务端只需-e WF_SERVER...无需修改任何文件如果需要自定义更多 nginx 行为如 gzip、客户端上传大小、额外 location可以基于该模板自行扩展后再构建镜像。五、前端与后端的连接方式全景理解了镜像后再看ui-next前端工程本身对服务端地址的三层处理能帮助你判断该改哪里层级机制位置生效时机构建期VITE_WF_SERVER环境变量ui-next/README.md、ui-next/.envpnpm build时注入运行时public/context.js中的window.conductor/window.authConfigui-next/public/context.js.example页面加载时读取无需重新构建容器期WF_SERVER环境变量 → nginx 模板渲染docker/ui/nginx.conf.template容器启动时对于容器化部署conductor:ui前端静态资源中的 API 地址通常写为相对路径/api实际的跨主机跳转完全由 nginx 反代完成因此你只需要关心WF_SERVER这一个变量即可。这也是该镜像把 nginx 作为统一入口的设计意图浏览器永远只与 UI 容器对话UI 容器再与 Server 通信天然规避了浏览器跨域问题。六、与 docker-compose 的配合使用如果你不希望手动管理docker run可以仿照 docker-compose.yaml 的写法将独立 UI 编排进现有服务栈services: conductor-ui: image: conductor:ui container_name: conductor-ui ports: - 5000:5000 environment: WF_SERVER: http://conductor-server:8080 networks: - internal前提是conductor-server容器与conductor-ui容器处于同一 Docker 网络compose 中可直接用服务名作为主机名。参照 docker-compose-port-override.yaml 的做法也可随时用-p 8080:5000之类的端口覆盖语法改变宿主机暴露端口。七、常见问题与排障容器启动了但页面打不开检查docker ps确认端口映射并用docker logs container查看 nginx 启动日志是否有模板渲染报错。页面能打开但列表/执行请求失败基本可以定位到WF_SERVER指向的服务端不可达。在 UI 容器内执行wget -qO- http://server:8080/health验证连通性注意使用容器网络内的地址而非 localhost。刷新深层链接 404确认使用的是本镜像自带的try_files $uri /index.html配置不要自行覆盖为纯静态root服务。构建时pnpm install网络超时前端依赖较大网络不稳时可参考 docker/README.md 中关于YARN_OPTS与--network-timeout的说明适当调大包管理器的网络超时时间后重试。想改 UI 端口修改EXPOSE与 nginxlisten的同时运行时的-p映射也要保持一致若WF_SERVER使用 https请确保模板中的proxy_pass相应使用https://前缀该镜像默认配置为 http。八、小结conductor:ui是一个轻量、独立、可通过环境变量切换后端的前端交付镜像两阶段 Dockerfile 保证构建可复现、产物精简nginx:stable-alpine打底模板化的 nginx 配置借助官方镜像的envsubst机制让WF_SERVER成为唯一的运行时开关SPA 回退与/api、/actuator反代使浏览器请求永远只落在 UI 容器上。掌握构建、运行与配置三件事你就能在任何已有 Conductor Server 的环境中快速拉起一套独立控制台相关实现细节均可回到 docker/ui/Dockerfile、docker/ui/nginx.conf.template 与 ui-next/README.md 中继续深挖。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Docker 单独部署 Conductor UI：conductor:ui 镜像构建、运行与 nginx 代理配置全解析
使用 Docker 单独部署 Conductor UIconductor:ui 镜像构建、运行与 nginx 代理配置全解析【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor导读Conductor 的 Web 控制台UI默认随conductor:server镜像一并打包提供但在某些场景下——例如已有独立部署的 Conductor Server、希望前后端分别扩容或需要将 UI 挂在自定义域名之后——单独运行一个 UI 容器是更清晰的架构选择。本文以 docker/ui/README.md 为骨架完整讲解conductor:ui镜像的构建命令、两种典型运行方式连接 localhost 服务端 / 连接外部服务端、WF_SERVER环境变量的作用并结合 docker/ui/Dockerfile、docker/ui/nginx.conf.template 以及ui-next前端工程的源码深入剖析该镜像的构建流程、nginx 反向代理与 SPA 静态资源服务原理帮你快速落地一套可独立运行的 Conductor 控制台。一、镜像定位conductor:ui 与 conductor:server 的关系在动手构建之前先明确conductor:ui在整个 Docker 镜像体系中的位置conductor:serverdocker/server/Dockerfile是服务端 UI 一体化镜像它在构建阶段同时编译 Java 服务端 JAR 与ui-next前端产物最终镜像内用 nginx 托管 UI 静态文件并把/api、/actuator反向代理到本机 8080 端口。这也是docker-compose系列文件默认使用的方式例如 docker-compose.yaml 中直接将服务端口映射为8000:8080API与8127:5000UI。conductor:uidocker/ui/Dockerfile是独立的 UI 镜像仅包含前端静态资源与 nginx。Dockerfile 头部注释明确说明the conductor:server image already bundles this same UI — this image is only for running the UI separately.server 镜像已内置同一套 UI本镜像仅用于单独运行 UI。因此如果你的目标是我只需要一个可访问的 Web 控制台且服务端已经就绪单独构建并运行conductor:ui即可无需重新构建庞大的 server 镜像。二、构建 conductor:ui 镜像2.1 标准构建命令在仓库根目录执行docker build -f docker/ui/Dockerfile -t conductor:ui .要点必须从仓库根目录执行构建上下文为当前目录Dockerfile 中通过COPY ui-next /conductor/ui-next引用整个ui-next/前端工程-f docker/ui/Dockerfile显式指定 Dockerfile 路径-t conductor:ui为镜像命名后续docker run与docker compose均使用该名称引用。2.2 两阶段构建流程剖析从 docker/ui/Dockerfile 可以看出该镜像采用标准的多阶段构建阶段一builder编译前端FROM node:lts AS builder COPY ui-next /conductor/ui-next WORKDIR /conductor/ui-next RUN corepack enable \ pnpm install --frozen-lockfile \ NODE_OPTIONS--max-old-space-size4096 pnpm build使用 Node LTS 基础镜像通过corepack enable启用 Corepack并按 ui-next/package.json 中packageManager字段锁定的 pnpm 版本当前为pnpm10.34.1执行安装--frozen-lockfile强制按pnpm-lock.yaml精确安装依赖保证构建可复现NODE_OPTIONS--max-old-space-size4096将 Node 堆内存上限提升到 4GB避免大型前端构建vite build时 OOM产物输出到/conductor/ui-next/dist。阶段二serve打包静态资源并接管 HTTP 服务FROM nginx:stable-alpine ENV WF_SERVERhttp://conductor-server:8080 COPY --frombuilder /conductor/ui-next/dist /usr/share/nginx/html COPY docker/ui/nginx.conf.template /etc/nginx/templates/default.conf.template EXPOSE 5000基于nginx:stable-alpine轻量镜像通过ENV预置WF_SERVER默认值http://conductor-server:8080容器内服务端主机名与端口将前端构建产物拷贝到 nginx 的 Web 根目录/usr/share/nginx/html将 nginx 配置模板拷贝到/etc/nginx/templates/目录官方 nginx 镜像会在容器启动时用envsubst将模板渲染到/etc/nginx/conf.d/EXPOSE 5000声明容器监听 5000 端口。需要特别留意的是该阶段没有自定义ENTRYPOINT/CMD完全沿用官方nginx:stable-alpine镜像的启动行为这正是模板会被自动渲染这一机制能够生效的前提。三、运行 conductor:ui 容器3.1 模式一连接 localhost 上的 Conductor Server适用于 UI 与 Server 部署在同一台机器、Server 监听 8080 端口的场景docker run -p 5000:5000 -d -t conductor:ui-p 5000:5000将容器 5000 端口映射到宿主机 5000 端口-d后台运行-t分配伪终端与 README 原始命令保持一致此时WF_SERVER使用镜像内置默认值nginx 将/api、/actuator代理到conductor-server:8080。若本机部署的 Server 容器恰好命名为conductor-server且与 UI 容器处于同一 Docker 网络则开箱即用。3.2 模式二连接外部 Conductor Server当 Server 运行在其他主机、其他容器或不同网络时通过环境变量覆盖服务端地址docker run -p 5000:5000 -d -t -e WF_SERVERhttp://conductor-server:8080 conductor:ui将http://conductor-server:8080替换为你的实际服务端地址即可例如http://192.168.1.100:8080或https://conductor.example.com。由于模板是启动时渲染的只需修改环境变量并重建容器即可切换后端无需重新构建镜像。3.3 验证部署启动后可通过以下方式确认curl -I http://localhost:5000 # 应返回 200 与 text/html curl -I http://localhost:5000/api # 应被 nginx 代理转发到服务端若服务端未就绪/api会返回 502/504此时只需确认服务端地址可达、端口正确即可。四、nginx 配置深入静态服务 API 反代 安全头conductor:ui之所以能同时胜任前端静态资源服务器和API 网关两个角色全部逻辑都在 docker/ui/nginx.conf.template 中。逐段解读如下4.1 SPA 静态资源服务与安全响应头server { listen 5000; server_name conductor; server_tokens off; location / { add_header Referrer-Policy strict-origin; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; root /usr/share/nginx/html; try_files $uri /index.html; }server_tokens off隐藏 nginx 版本号减少信息泄露面三个安全头分别约束来源引用策略Referrer-Policy: strict-origin、禁止被 iframe 嵌入X-Frame-Options: SAMEORIGIN、禁用 MIME 类型嗅探X-Content-Type-Options: nosnifftry_files $uri /index.html是标准的 SPA 回退规则请求路径若命中真实文件则直接返回否则一律回退到index.html由前端路由react-router接管——这保证刷新/workflow/xxx之类的深链接不会 404。4.2 /api 与 /actuator 反向代理location /api { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-NginX-Proxy true; proxy_pass ${WF_SERVER}/api; proxy_ssl_session_reuse off; proxy_set_header Host $http_host; proxy_cache_bypass $http_upgrade; proxy_redirect off; } location /actuator { ... 同上 ... }${WF_SERVER}是模板变量容器启动时由envsubst替换为WF_SERVER环境变量的值与proxy_pass ${WF_SERVER}/api这种带 URI的写法搭配时nginx 会将原始请求 URI 中匹配/api前缀之后的部分拼接到上游地址之后因此前端请求/api/workflow会被转发为${WF_SERVER}/api/workflow透传X-Real-IP、X-Forwarded-For便于服务端记录真实客户端 IPHost: $http_host保证服务端看到的 Host 与浏览器一致/actuator用于透传 Spring Boot Actuator 健康/指标端点如http://localhost:8080/health方便 UI 展示服务端健康状态proxy_redirect off避免上游 3xx 响应中的 Location 被改写。4.3 模板渲染机制envsubst这段配置之所以是.template后缀而非.conf是因为官方 nginx 镜像内置的入口脚本会遍历/etc/nginx/templates/*.template以环境变量为输入执行envsubst将渲染结果写入/etc/nginx/conf.d/同名文件。因此想要指向外部服务端只需-e WF_SERVER...无需修改任何文件如果需要自定义更多 nginx 行为如 gzip、客户端上传大小、额外 location可以基于该模板自行扩展后再构建镜像。五、前端与后端的连接方式全景理解了镜像后再看ui-next前端工程本身对服务端地址的三层处理能帮助你判断该改哪里层级机制位置生效时机构建期VITE_WF_SERVER环境变量ui-next/README.md、ui-next/.envpnpm build时注入运行时public/context.js中的window.conductor/window.authConfigui-next/public/context.js.example页面加载时读取无需重新构建容器期WF_SERVER环境变量 → nginx 模板渲染docker/ui/nginx.conf.template容器启动时对于容器化部署conductor:ui前端静态资源中的 API 地址通常写为相对路径/api实际的跨主机跳转完全由 nginx 反代完成因此你只需要关心WF_SERVER这一个变量即可。这也是该镜像把 nginx 作为统一入口的设计意图浏览器永远只与 UI 容器对话UI 容器再与 Server 通信天然规避了浏览器跨域问题。六、与 docker-compose 的配合使用如果你不希望手动管理docker run可以仿照 docker-compose.yaml 的写法将独立 UI 编排进现有服务栈services: conductor-ui: image: conductor:ui container_name: conductor-ui ports: - 5000:5000 environment: WF_SERVER: http://conductor-server:8080 networks: - internal前提是conductor-server容器与conductor-ui容器处于同一 Docker 网络compose 中可直接用服务名作为主机名。参照 docker-compose-port-override.yaml 的做法也可随时用-p 8080:5000之类的端口覆盖语法改变宿主机暴露端口。七、常见问题与排障容器启动了但页面打不开检查docker ps确认端口映射并用docker logs container查看 nginx 启动日志是否有模板渲染报错。页面能打开但列表/执行请求失败基本可以定位到WF_SERVER指向的服务端不可达。在 UI 容器内执行wget -qO- http://server:8080/health验证连通性注意使用容器网络内的地址而非 localhost。刷新深层链接 404确认使用的是本镜像自带的try_files $uri /index.html配置不要自行覆盖为纯静态root服务。构建时pnpm install网络超时前端依赖较大网络不稳时可参考 docker/README.md 中关于YARN_OPTS与--network-timeout的说明适当调大包管理器的网络超时时间后重试。想改 UI 端口修改EXPOSE与 nginxlisten的同时运行时的-p映射也要保持一致若WF_SERVER使用 https请确保模板中的proxy_pass相应使用https://前缀该镜像默认配置为 http。八、小结conductor:ui是一个轻量、独立、可通过环境变量切换后端的前端交付镜像两阶段 Dockerfile 保证构建可复现、产物精简nginx:stable-alpine打底模板化的 nginx 配置借助官方镜像的envsubst机制让WF_SERVER成为唯一的运行时开关SPA 回退与/api、/actuator反代使浏览器请求永远只落在 UI 容器上。掌握构建、运行与配置三件事你就能在任何已有 Conductor Server 的环境中快速拉起一套独立控制台相关实现细节均可回到 docker/ui/Dockerfile、docker/ui/nginx.conf.template 与 ui-next/README.md 中继续深挖。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考