Nomad 深读：一个二进制编排全部负载，许可与企业版各埋一个坑

一、它到底是什么：一个二进制，三类负载

README 的第一句话就把范围划完了，原文是：

Nomad is a simple and flexible workload orchestrator to deploy and manage
containers (docker, podman), non-containerized applications (executable,
Java), and virtual machines (qemu) across on-prem and clouds at scale.

翻成人话：能跑容器，也能直接跑可执行文件和 Java 程序，还能拉起虚拟机。支持 Linux、Windows 和 macOS。同时存在一个商业版本，README 里就一句：

A commercial version of Nomad, Nomad Enterprise, is also available.

三类负载对应三组驱动，边界很清楚：

README 自列的五个特性里，最该认真读的是第二条。原文说它单二进制、完全自包含，把资源管理与调度合在一个系统里，不需要任何外部服务做存储或协调，并且用领导者选举加状态复制来保证高可用。这句话的实际含义是：部署清单上没有别人，没有数据库、没有消息队列、没有额外的控制面组件。

其余几条分别是：设备插件与 GPU，靠设备插件自动识别并调度 GPU、FPGA、TPU，对在本地跑模型或推理服务的机器是刚需；联邦，README 的原话是开箱即用，可以跨多个区域和多个云部署；以及规模，官方自述在生产环境里跑到过万级节点。最后这条是项目方自己的说法，没有第三方验证，当作方向看就好。

这里有一处把两份文档对着读才会发现的口径错位。联邦这个词在两处指的不是一件事：README 说集群之间的联邦开箱即用，而企业功能页里单列了一条跨区域部署，指的是把一个作业部署到多个已联邦的区域，并控制发布顺序和失败行为。前者在开源版，后者在企业版。做多区域选型时，按后者预留预算。

版本线要交代清楚：2.0.0 发布于 2026-04-21，本轮抓到的最新正式版是 2.0.6（2026-09-09），发版节奏基本是每月一个补丁。从 2.0.0 起版本号从常见的三段式改成 IBM 的版本模型：四月开一个新的支持周期，十月加功能但不另开周期，月度为修缺陷。这个改动本身是个信号——项目的产品节奏已经并入 IBM 的自管理软件体系。

二、怎么用：从安装到跑起第一个作业

README 里没有安装命令，快速上手只有两行，而且把测试与生产分得很开。原文是：

#### Testing
Refer to the Getting Started tutorials for instructions on setting up a local
Nomad cluster for non-production use.

#### Production
Refer to Production reference architecture for recommended practices and a
reference architecture for production deployments.

安装照官方安装页来，macOS 是两条命令：

brew tap hashicorp/tap
brew install hashicorp/tap/nomad

Ubuntu 与 Debian 上走官方软件源，三条命令：

wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o \
  /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release \
  || lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install nomad

官方入门教程给了一个完整可跑的小应用，四个作业文件分别演示服务型、参数化批处理和定时批处理三种形态。最基础的那个是一个 Redis 服务，完整作业文件长这样，可以直接照着改：

job "pytechco-redis" {
  type = "service"

  group "ptc-redis" {
    count = 1
    network {
      port "redis" {
        to = 6379
      }
    }

    service {
      name     = "redis-svc"
      port     = "redis"
      provider = "nomad"
    }

    task "redis-task" {
      driver = "docker"

      config {
        image = "redis:7.0.7-alpine"
        ports = ["redis"]
      }
    }
  }
}

提交与派发就三条命令，注意第三条是参数化批处理的用法，作业里用 meta_required 声明了必须传入的参数：

nomad job run pytechco-redis.nomad.hcl
nomad job run pytechco-setup.nomad.hcl
nomad job dispatch -meta budget="200" pytechco-setup

这套例子里有两点值得单独看。第一是服务发现与配置注入是内建的：作业里的 template 块用 nomadService 函数取到 Redis 的地址和端口，渲染成环境变量文件后直接注入任务，不需要另外部署一套服务注册中心，也不用写胶水脚本。第二是批处理的几种形态齐了：服务型常驻、参数化按次派发、定时型按 cron 触发，另有系统与系统批处理两类，共用同一套调度器。

装完之后的第一个坑不在 Nomad 身上，在 Docker 驱动的权限。官方文档原文写得很直白：Nomad 需要 Docker 装在宿主上并与 agent 并存；如果不用 root 跑，必须把 nomad 用户加进 docker 组：

sudo usermod -G docker -a nomad

紧接着的一句更要紧，很多人是在性能不符合预期时才回头看到它：Nomad 会为每个任务管理一个 cpuset cgroup，要写进 Docker 拥有的 cgroup 就需要 root 权限。不是 root 跑的时候，声明了 CPU 核数的任务，它的 CPU 隔离与 NUMA 感知调度都不会正常工作，而且同一台宿主上其他驱动的任务也会被牵连。

三、优点和缺点，摊开说

先说值得用的地方：

• 单二进制、零外部依赖：部署清单里没有数据库和消息队列，资源管理与调度在一个进程里，这是它和 Kubernetes 最本质的成本差。
• 能编排非容器负载：exec 与 java 驱动让老程序不用先容器化就能纳管，迁移路径比想象中短。
• 内建设备插件与 GPU 调度，对本地跑模型、跑推理的机器是刚需。
• 服务发现与模板渲染内建：template 块加 nomadService 函数，省掉一层外部模板渲染的胶水。
• 几类作业共用一套调度器：服务、批处理、参数化、定时，不用为不同形态换工具。
• 许可虽然换了，但留了后路：每个版本在发布四年后自动转为 MPL-2.0，这在源码可得的商业许可里算是比较克制的一种。

再说必须提前知道的缺点——这部分才是本期重点：

Licensor:             International Business Machines Corporation (IBM)
Licensed Work:        Nomad Version 1.7.0 or later.
Additional Use Grant: You may make production use of the Licensed Work,
                      provided Your use does not include offering the
                      Licensed Work to third parties on a hosted or
                      embedded basis in order to compete with IBM Corp's
                      paid version(s) of the Licensed Work.
Change Date:          Four years from the date the Licensed Work is published.
Change License:       MPL 2.0

还有一点需要说清楚，避免误伤：Nomad 本身没有被标记废弃，作者也没有禁止转载宣传，2.0.6 就在本轮抓取前一周发布，仓库是活跃的。上面这些风险点里，真正需要你当场决策的只有两条——许可的竞品条款，和企业版的不可逆。其余的属于升级与运维成本，排期可以解决。

四、最终能达到什么效果

落地之后，日常是这样：一台机器上装好二进制，把 Docker 与要跑的东西装齐，集群就起来了，没有数据库、没有额外的控制面。写一个作业文件描述要跑什么，一条命令提交，调度、重试、失败检测、服务注册全部由它接管；容器、老程序、虚拟机用的是同一套作业语法和同一套调度器。定时批处理直接写 cron 表达式，参数化批处理按次派发，需要的时候用内建模板把上游服务的地址注入到下游的环境变量里，不必为此再部署一个服务注册中心。

规模化之后会遇到的第一个门槛是治理：配额、审计日志、跨区域部署这三样落在企业版。在此之前，它换来的是一套几乎不需要运维投入的编排面。

动手前先做三件事：

• 先确认你是 root 跑还是 nomad 用户跑。不做 root，声明 CPU 核数的任务，CPU 隔离与 NUMA 感知调度都不会生效，这一点官方文档写在最前面，但通常要到压测对不上数才被发现。
• 升级前一定先读升级指南里对应版本的前置条件。从 1.9 之前一路升上来，要同时处理作业文件格式、Vault 与 Consul 的认证方式、以及客户端最低版本三件事，顺序错了集群起不来。
• 别顺手装企业版试功能。装了就降不回来，开源服务端加进企业集群会 panic，想退只能另起一个集群再迁。

下期预告：上一期文末预告的 Agent 沙箱横向对比继续欠着——本轮日报与周报再次被写过的面孔占满，干净的新面孔是从语言周报里捞出来的，所以先把它写掉。下期做自建编排路线的横向对比：Nomad、轻量 Kubernetes、以及定时任务加脚本这三条路，在资源开销、许可条款和支持周期上分别怎么选。

#GitHub趋势#工作负载编排#自建服务#开源许可

数据来源：GitHub 官方页面与 REST API · 抓取时间：2026-09-16 18:44。文中安装命令、作业文件与驱动要求均取自仓库 README 所链接的官方文档原文（安装页、入门教程、Docker 驱动页）；许可条款取自仓库 LICENSE 全文；企业功能清单、降级警告与支持周期取自官方企业功能页；升级破坏性变更取自官方升级指南；命令行为与沉积需求来自仓库公开问题单（#545 / #1635 / #8892）。本轮未在本机安装运行该项目，所有结论均为文档、发版说明与问题单层面的核实结果。项目地址：https://github.com/hashicorp/nomad