Nomad Web UI 开发模式运行指南本地调试与代理生产集群【免费下载链接】nomadNomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.项目地址: https://gitcode.com/gh_mirrors/no/nomad导读本文基于 Nomad 官方仓库中的ui/DEVELOPMENT_MODE.md文档完整讲解如何以开发模式运行 Nomad Web UI 并将 API 请求代理到一个真实的 Nomad 集群。Nomad 二进制内置的 UI 在生产构建中会压缩与混淆 JavaScript 和 CSS导致调试错误时堆栈信息晦涩难用开发模式则保留原始文件提供可读的堆栈追踪。读完本文你将掌握三条完整操作链路克隆并搭建 UI 开发环境、用 Ember CLI 在本地起服务、通过--proxy与USE_MIRAGE配置把开发版 UI 对接上生产集群并了解其背后的 Mirage 模拟后端与 HTTP/WebSocket 代理实现。官方文档特别强调开发模式仅在调试问题debugging issues时才有必要使用。除非你在排查 UI 问题否则请直接使用 Nomad 二进制内置的 Web UI。为什么需要开发模式生产构建与开发构建的差异Nomad Web UI 是一套基于 Ember.js 构建的单页应用与 Nomad 主体代码位于同一个仓库中。当通过make release或make dev-ui构建产物时生产环境的 JavaScript 和 CSS 会经历拼接concatenate与压缩minify。压缩后的代码会把变量名替换为短名、折叠空格、删除换行浏览器控制台里报出的错误往往形如TypeError: Cannot read properties of undefined (reading x)却看不到具体的调用上下文排查极其痛苦。开发模式则不同前端文件保持原始未压缩状态报错时堆栈追踪stack traces完整可用配合 LiveReload 可以实现改动即时生效。从服务端看Nomad 的 HTTP API 网关在 command/agent/http.go 中注册 UI 路由当构建启用了uibuild taguiEnabled true且配置允许时/ui/路径会被挂载到内嵌的静态文件服务上http.StripPrefix(/ui/, ...)文件系统来自assetFS()否则会返回一段stubHTMLNomad UI is disabled。这说明内嵌 UI 是静态编译产物而开发模式的目标正是绕开这套静态产物、直接运行源码。调试 UI 问题在开发模式下分三步完成克隆 Nomad 仓库获取 UI 源码搭建开发环境或使用 Vagrant本地起 Web UI 服务同时把 API 请求代理到生产 Nomad 集群。第一步克隆 Nomad 仓库Web UI 与 Nomad 本体在同一个仓库内位于仓库根目录下的ui/目录因此只需克隆 Nomad 仓库即可同时获得两者git clone https://gitcode.com/gh_mirrors/no/nomad cd nomad克隆后UI 源码的目录结构大致如下可对照仓库实际内容ui/app/Ember 应用的业务代码路由、组件、控制器、模板ui/mirage/Mirage 模拟后端数据工厂、场景、序列化器ui/server/Ember CLI 开发服务器的自定义中间件与代理ui/config/environment.js开发环境配置Mirage 开关、默认场景等ui/package.jsonnpm/pnpm 脚本与依赖清单ui/DEVELOPMENT_MODE.md、ui/README.md开发模式说明与完整使用文档。第二步搭建开发环境官方在 ui/README.md 中列出了运行 UI 所需的软件前置条件与安装步骤。前置条件Node.js 当前 LTS 版本nodejs.org 中engines字段声明了node: 20.*Ember CLIember-cli本项目使用~6.12.0corepack通常随 Node 一同安装若没有可用 Homebrew 等工具单独安装。安装依赖从 Nomad 项目根目录执行以下命令安装 UI 依赖使用 pnpm 作为包管理器corepack enable corepack prepare pnpmlatest --activate pnpm i安装完成后pnpm会生成pnpm-lock.yaml仓库根目录与ui/下均有锁定文件。依赖安装成功即可进入下一步。第三步本地启动 UI 并代理到生产集群这是整个流程的核心环节。在ui/目录下执行单条命令即可启动开发服务器。默认启动Mirage 模拟数据本地环境Localember serveVagrant 虚拟机环境ember serve --watch polling --port 4201说明--watch polling让虚拟机内的 Ember CLI 通过轮询方式感知宿主机上的文件变更--port 4201是因为 Vagrantfile 默认不转发 4200 端口本地开发更推荐直接在本机跑而 4201 已被转发。关键开关USE_MIRAGE 与 Mirage 场景默认情况下开发模式后端使用的是 Ember CLI Mirage 的模拟数据fixtures而不是真实集群。Mirage 会在浏览器侧拦截 HTTP 请求并返回假数据。这一行为由 ui/config/environment.js 中的USE_MIRAGE环境变量控制let USE_MIRAGE true; if (process.env.USE_MIRAGE) { USE_MIRAGE process.env.USE_MIRAGE true; }值为true默认启用 MirageUI 展示自动生成的假数据值为false关闭 MirageUI 会把 API 请求发往真实后端。环境文件同时配置了 Mirage 默认场景mirageScenario: smallCluster以及mirageWithNamespaces、mirageWithTokens、mirageWithRegions等开关。Mirage 的具体场景定义在 ui/mirage/scenarios/default.js 中包括smallCluster、mediumCluster、largeCluster、massiveCluster、allJobTypes、allNodeTypes、everyFeature、emptyCluster等一系列命名场景可用 URL 查询参数?mirage-scenarioemptyCluster切换。模拟数据基于**稳定种子seed**生成默认种子为1?faker-seed2或任意非 0 数字使用固定种子生成稳定可复现的数据?faker-seed0关闭种子每次加载生成不同数据。使用代理连接真实 Nomad 集群要对接自己的 Nomad 集群使用 Ember CLI 的--proxy选项本地环境ember serve --proxy https://demo.example.comVagrant 环境ember serve --watch polling --port 4201 --proxy https://demo.example.com把https://demo.example.com替换为你实际的 Nomad 集群地址即可。启动后开发服务器会接管所有以/v1开头的请求并将其转发到目标集群。代理的底层实现在 ui/server/proxies/api.js开发服务器中间件读取options.proxy使用http-proxy创建代理对象并注册/v1前缀的转发规则const proxyPath /v1; let proxyAddress options.proxy; let proxy require(http-proxy).createProxyServer({ target: proxyAddress, ws: true, // 支持 WebSocket changeOrigin: true, }); app.use(proxyPath, function (req, res) { req.url proxyPath req.url; // 补回被剥离的 /v1 前缀 proxy.web(req, res, { target: proxyAddress }); });值得注意的细节ws: true表示代理同时支持WebSocket 升级这与 Nomad UI 的事件流event stream与状态监视watcher功能直接相关Nomad 的 API 通过 WebSocket 向 UI 推送变更事件在server.on(upgrade, ...)回调中会把Origin请求头改写为代理目标地址从而让 Nomad 服务端接受代理过来的 WebSocket 连接ui/server/index.js 还挂载了morgan(dev)中间件在终端打印所有代理请求日志方便观察 UI 到底向集群发起了哪些 API 调用、状态码如何——这是排查问题时的第一手信息。访问开发版 UI服务启动后从宿主机浏览器访问本地环境http://localhost:4200/uiVagrant 环境http://localhost:4201注意ui/config/environment.js中配置了rootURL: /ui/因此本地开发地址需要带/ui路径而通过 Vagrant 转发时根路径即指向应用。更省事的封装脚本pnpm start / pnpm start:proxy除了直接执行ember serveui/package.json 还提供了两个封装脚本脚本实际命令说明pnpm startember server默认开发模式使用 Mirage 假数据地址为 http://localhost:4200/uipnpm start:proxyUSE_MIRAGEfalse ember server --port 4646 --proxy http://127.0.0.1:4646关闭 Mirage、把 API 代理到本机 4646 端口上的 Nomad并以 http://localhost:4646/ui 提供服务start:proxy是最常用的本地 UI 本机 Nomad组合只要本机 4646 端口有一个可访问的 Nomad 进程无论官方发布版还是 dev 分支构建server 模式或 dev 模式均可UI 即可正常工作。若 Nomad 不在本机可用显式方式覆盖代理目标USE_MIRAGEfalse ember serve --proxy http://newlocation:1111务必同时确认USE_MIRAGE已设为false否则 UI 会把请求交给 Mirage 的假数据而不是 Nomad 进程。在 Vagrant 中运行的注意事项官方 ui/README.md 指出Vagrantfile 已安装全部 UI 开发所需工具主要用于在开发 Nomad 时从源码构建 UI。但由于 Ember CLI 依赖的 Broccoli 构建系统对文件系统的要求文件事件监听官方强烈不建议在 Vagrant 内做 UI 代码的日常改动开发。若确实要在 Vagrant 中跑 UIember serve需要两个额外参数--watch polling让 VM 感知宿主机上的文件变更--port 42014200 未做端口转发本地开发仍以宿主机直跑为推荐。完整命令ember serve --watch polling --port 4201仓库根目录的 Vagrantfile 中可以看到相关端口转发配置除了 Nomad API 的 4646、Consul 的 8500 之外还转发了guest: 4201, host: 4201以及 49153这正是 Vagrant 模式使用 4201 端口的原因。如果改用其他端口需要自行在 Vagrantfile 中追加转发规则并执行vagrant reload。常见问题排查TroubleshootingUI 在运行但所有 API 请求都不工作这是最常见的坑多半是请求被 Mirage 拦截、或代理目标不对。按以下顺序检查使用pnpm start:proxy等价于USE_MIRAGEfalse ember server --port 4646 --proxy http://127.0.0.1:4646把 UI 代理到本机127.0.0.1:4646的 Nomad并以 http://localhost:4646/ui 访问Nomad 运行在别处时显式指定代理USE_MIRAGEfalse ember serve --proxy http://newlocation:1111确认USE_MIRAGEfalse已生效——这是UI 是否真的在访问 Nomad 进程的总开关。Nomad 跑在 Vagrant 里宿主机却访问不到 APINomad 默认绑定127.0.0.1:4646loopback 地址Vagrant 宿主机自然无法直连。解决办法bin/nomad -bind 0.0.0.0同时确认端口转发已配置4646 已默认转发若 Nomad 用了非默认端口需要在 Vagrantfile 中补充转发并vagrant reload。开发模式配套工具链速览调试之外ui/下的开发工具链还包含测试与构建能力方便在修改 UI 后验证改动运行测试ember test单次、无头浏览器ember test --server监听变更、完整浏览器用--filter 测试名过滤如ember test --filter allocation detail。测试环境数据默认随机种子URL 追加faker-seed1非 0可获得稳定数据Lintpnpm lint检查pnpm lint:fix自动修复覆盖 JS/ESLint、HBS 模板、SCSS 与 TypeScript 类型检查构建日常构建走make release或make dev-ui需要检查构建产物时可执行ember build开发或ember build --environment production生产产物输出到ui/dist发布约定UI 发布与 Nomad 发布保持同步集成在make release工具链中分支命名约定为f-ui-功能与b-ui-修复该前缀会让 CI 跳过 Nomad 后端测试。总结整个开发模式的核心心智模型只有一句话开发服务器替你跑源码版 UIMirage 或--proxy决定数据从哪来。默认 Mirage 提供稳定的假数据用于纯前端开发USE_MIRAGEfalse加--proxy 集群地址则把 UI 无缝接到真实集群——两者之间只需环境变量与一个命令行参数即可切换。结合 ui/server/proxies/api.js 的/v1转发与 WebSocket 升级实现你可以清楚地看到 UI 与 Nomad API 的每一次交互再配合 ui/mirage/scenarios/default.js 的场景化假数据无论是复现线上问题还是开发新页面开发模式都能提供比内嵌压缩产物友好得多的调试体验。调试完成后请记得回到 Nomad 二进制内置的 Web UI/ui/路径——那才是日常使用应走的方式。【免费下载链接】nomadNomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.项目地址: https://gitcode.com/gh_mirrors/no/nomad创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考