为什么光有 Nomad 还不够
本文写给已在裸金属 Mac 上跑 Nomad client、要把 batch 构建与 promote 串进统一编排的团队。单页固定地址:2026-clustervps-mac-mini-m4-nomad-affinity-build-lock.html。制品扇出参数、timeout 与 rsync 矩阵仍请以姊妹篇《2026 跨区并联集群 rsync 决策矩阵》为准;控制面 DNS 与内网回源切片见《拆分 DNS 与制品库矩阵》。全文索引:技术博客首页。
- 错配亲和:重 CPU 的归档任务被派到「黄金扇出」机,抢占 rsync 读盘带宽。
- 双轨锁:Nomad
max_parallel与 shell 层 flock 语义不一致,出现伪并行写入。 - 水位失明:1TB 套餐在 85% 利用率仍全速 dispatch,APFS 快照与缓存把最后一截空间吃掉。
决策矩阵:亲和 × 构建锁 × 磁盘档位
| 运维目标 | Nomad 侧重 | 构建锁与制品 | 磁盘套餐提示 |
|---|---|---|---|
| 区域固定黄金机 | constraint 绑定 meta.build_zone;batch count 与扇出机 1:1。 |
仅 promote 持 flock;编译目录按分支隔离。 | 1TB 可跑单区域;跨区中继建议 2TB 留缓存余量。 |
| 同区多机并联 | distinct_hosts + 反亲和 CPU hog。 |
每机独立 workspace,聚合目录只经单一 rsync 写入者晋升。 | 并行节点多选 2TB,扩容水位按集群最大值告警。 |
| 突发批处理洪峰 | 临时提高 priority 或独立 queue;禁止与 promote 同 meta。 |
锁文件放本地 SSD;禁止网络文件系统持锁。 | 洪峰前预跑清理 job;80% 起限流 dispatch。 |
关键词串联:Nomad 负责把 batch 放到对的 Mac Mini M4;并联扩展吞吐但放大 IO 争用;构建锁把「谁有权改 promote 树」收敛为单写入者;扩容水位决定何时从 1TB 抬到 2TB 或减并发。
可执行 job 约束示例(HCL 片段说明)
下面示例可直接 nomad job run 调试;生产请替换镜像路径、元标签与脚本。阅读顺序:先看块结构,再对照文字说明。
job "mac-m4-batch-promote" {
type = "batch"
group "promote" {
count = 1
constraint {
attribute = "${meta.build_zone}"
operator = "="
value = "apac-golden"
}
constraint {
operator = "distinct_hosts"
value = "true"
}
task "gate" {
driver = "exec"
config {
command = "/bin/bash"
args = ["-c", "flock -n /var/tmp/ci-promote.lock -c /local/bin/promote.sh"]
}
resources {
cpu = 2000
memory = 4096
}
}
}
}
顶层 job + type = "batch":声明短生命周期任务,结束即释放分配,适合与 promote / 校验脚本绑定。group:把共享网络与重启策略捆在一起;count = 1 与 promote 单写入者语义一致,若要多副本并行编译应拆到另一 job。第一个 constraint:要求客户端 meta 中的 build_zone 等于 apac-golden,把任务钉在亚太黄金扇出机(agent 配置里需写入同名 meta)。第二个 constraint:distinct_hosts 防止调度器把多个副本叠在同一台 Mac 上抢磁盘。task + driver = "exec":直接调用本地 bash,避免容器层在 macOS 上额外心智负担。args 中的 flock:与姊妹篇脚本锁一致,调度器只保证「曾尝试放置」;真正互斥仍由 OS 层文件锁完成。resources:为 promote 预留 CPU/内存上限,便于与编译型 batch 分池。
与 rsync 制品同步的衔接顺序
推荐流水线:Nomad batch 完成编译 → 本地 promote(flock)写入祝福目录 → 由黄金机按 profile 执行 rsync 扇出(参数表见上文姊妹篇)。不要在 promote 尚未闭环时启动下游 --delete 同步,否则工作节点会短暂看到半棵树。若需跨区域限速,可把 rsync 包成第二个 Nomad batch,constraint 指向「中继」meta,与 promote job 错开 meta.build_zone。
1TB / 2TB 扩容水位决策表
| 卷利用率(APFS) | 1TB 套餐动作 | 2TB 套餐动作 | Nomad 侧联动 |
|---|---|---|---|
| < 70% | 正常 dispatch;周常清理 DerivedData。 | 可维持较高 batch 并行。 | 维持现有 count 与亲和。 |
| 70% – 80% | 黄色预警:压缩归档、推迟大镜像层缓存。 | 观察 IO 延迟;必要时单任务限 CPU。 | 对非 promote 任务降 priority。 |
| 80% – 90% | 优先评估升 2TB 或外迁冷制品。 | 暂停新的 rsync 全量扇出 job。 | nomad job stop 非关键 batch,保留 promote 通道。 |
| > 90% | 硬停:禁止新写入,先释放快照与缓存,再恢复调度。 | 全局熔断 dispatch,人工确认磁盘曲线。 | |
同一集群内以「最满节点」驱动告警,避免只看平均值;并联节点越多,越要防止单点磁盘拖垮整条 promote 链。
常见问题
能用 Nomad 的并发代替 flock 吗?不建议。调度器层面的 max_parallel 防的是「同时运行」,不防人工脚本或崩溃重启后的重入;OS 锁仍是 promote 最后一道闸。
meta 标签如何与机柜/可用区对齐?在 agent 配置写入 meta.build_zone、meta.az,与 DNS 拆分矩阵中的视图同名,减少值班时的心智映射成本。
批处理任务需要 long-running 吗?编译可拆多段 batch;长时服务请用 service job,以免 batch 完成策略误杀守护型同步进程。
为 Nomad 集群补齐同构 Mac mini M4 节点
按需增加裸金属节点承载 batch 与扇出,无需登录即可查看方案与价格;把亲和标签写进 agent 后,用统一水位策略守护磁盘与制品链。