在云端 Mac 上自动化 Bonjour 服务发现回归测试

CI/CD 实践 ·约 7 分钟阅读

在云端 Mac 上自动化 Bonjour 服务发现回归测试

远隔办公时，应用能通过明确的主机名和端口连接，并不代表 Bonjour 服务发现也正常。打印、投屏、调试代理或局域网协作工具常依赖 mDNS；一旦服务类型、TXT 记录或网络接口发生变化，界面只会表现为“附近设备消失”。这类问题适合在云端 Mac 上做协议级回归：先注册一个临时服务，再验证浏览、解析和退出清理，而不是等待真实设备偶发失败。

先明确测试边界

Bonjour 通常通过 UDP 5353 在链路本地发送 mDNS 组播。它不会因为 TCP 端口可达，就自然穿过路由器、普通 SSH 隧道或远程桌面连接。因此，云端测试应拆成两层：

  1. 在同一台 macOS 节点验证注册、浏览、SRV 解析和 TXT 记录。
  2. 在目标局域网内另做真实设备互通测试，验证交换机、无线网络和组播策略。

第一层适合放进每次提交的 CI，能发现服务类型拼错、端口错误、元数据缺失和进程未退出。第二层属于网络验收，不能用第一层结果替代。

Bonjour 测试通过，只能证明服务发现契约在当前测试边界内成立，不能证明组播已经跨越远端网络边界。

服务类型建议为产品分配专用值，例如 _myapp-test._tcp。不要借用 _http._tcp，否则测试节点上的其他服务会混入结果。实例名也不能固定，应包含本次任务的唯一标识。

用 dns-sd 建立最小闭环

macOS 自带 dns-sd，无需额外安装依赖。下面的脚本启动临时 HTTP 服务，先开启浏览器，再注册 Bonjour 实例，最后解析实例并检查 TXT 内容。它适合作为仓库中的 ci/test-bonjour.sh。

#!/bin/bash
set -euo pipefail

RUN_ID="${CI_RUN_ID:-$(date +%s)}"
INSTANCE="vmcache-${RUN_ID}"
TYPE="_myapp-test._tcp"
PORT="${BONJOUR_TEST_PORT:-8088}"
WORK_DIR="$(mktemp -d)"
BROWSE_LOG="$WORK_DIR/browse.log"
RESOLVE_LOG="$WORK_DIR/resolve.log"

HTTP_PID=""
BROWSE_PID=""
REGISTER_PID=""
RESOLVE_PID=""

cleanup() {
  for pid in "$RESOLVE_PID" "$REGISTER_PID" "$BROWSE_PID" "$HTTP_PID"; do
    if [[ -n "$pid" ]]; then
      kill "$pid" 2>/dev/null || true
      wait "$pid" 2>/dev/null || true
    fi
  done
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT INT TERM

python3 -m http.server "$PORT" --bind 0.0.0.0 \
  >"$WORK_DIR/http.log" 2>&1 &
HTTP_PID=$!

dns-sd -B "$TYPE" local. >"$BROWSE_LOG" 2>&1 &
BROWSE_PID=$!

dns-sd -R "$INSTANCE" "$TYPE" local. "$PORT" \
  "path=/" "run=$RUN_ID" >"$WORK_DIR/register.log" 2>&1 &
REGISTER_PID=$!

sleep 4
grep -F "$INSTANCE" "$BROWSE_LOG"

dns-sd -L "$INSTANCE" "$TYPE" local. >"$RESOLVE_LOG" 2>&1 &
RESOLVE_PID=$!
sleep 3
kill "$RESOLVE_PID" 2>/dev/null || true
wait "$RESOLVE_PID" 2>/dev/null || true
RESOLVE_PID=""

grep -E "path=/|run=$RUN_ID" "$RESOLVE_LOG"
grep -E "$PORT" "$RESOLVE_LOG"
curl --fail --silent --show-error "http://127.0.0.1:$PORT/" >/dev/null

浏览必须先于注册启动，否则短任务可能错过新增事件。这里没有把 dns-sd 放在前台，因为浏览和解析命令会持续等待；CI 必须主动设置观察时间并结束进程。

把断言对准服务契约

仅检查实例名出现还不够。稳定的回归测试至少要验证四项：服务类型、实例名、端口和 TXT 记录。TXT 记录应保存发现阶段真正需要的低敏感元数据，例如协议版本、能力标记和健康检查路径，不应放令牌、密码或内部凭据。

建议把协议版本写成 api=2，把能力写成 features=sync,preview。测试端逐项断言，而不是比较整行输出。dns-sd 的输出包含时间和接口信息，整行快照容易随系统版本变化。

若应用会拒绝旧协议，可以再注册一个 api=1 的实例，验证客户端确实忽略它。这样测试覆盖的是选择逻辑，而不只是“看见一个名字”。解析成功后，还应对实际端口发起一次最小请求，避免出现“广播写 8088，服务却监听 8089”的假通过。

处理并发、残留与暴露面

同一节点并行执行多个任务时，实例名和端口都必须隔离。实例名加入任务编号只能解决发现结果混淆，不能解决两个 HTTP 服务抢占同一端口。CI 调度器应预先分配端口，或在启动前用 lsof -nP -iTCP:$PORT -sTCP:LISTEN 检查占用。

所有后台进程都要进入 trap。如果断言失败后注册进程仍存活，下一次测试可能发现旧实例，形成难以复现的假阳性。清理顺序应先停解析和注册，再停浏览器与测试服务。

示例为了完成端到端检查监听全部接口。独享云端 Mac 仍应遵循最小暴露原则：测试端口只在受控网络和短时间内开启，不需要网络请求时可以省略 HTTP 服务，只验证注册与解析。运行前后可分别执行 lsof，确认端口没有遗留监听者。

从失败输出定位问题

“浏览不到”先检查服务类型是否完全一致，包括前导下划线和 _tcp 后缀；再检查注册进程是否提前退出。能浏览但不能解析，重点查看实例名转义、域名参数和本机名称解析。能解析却连不上端口，则检查监听地址、端口占用、防火墙策略和服务启动顺序。

CI 应保存 browse.log、resolve.log 与注册进程输出，但上传前要做脱敏。失败时同时记录 scutil --get LocalHostName、networksetup -listallhardwareports 和相关端口的 lsof 结果，通常足以区分命名问题、接口问题与监听问题。

在 VMCache 的独享物理节点上运行这类测试时，也不要假设远程连接路径会转发 mDNS。把协议级回归固定在节点内部，把真实设备发现放在目标局域网验收，两套结果分别记录，才能让失败边界清晰且可重复。

常见问题

Bonjour 服务能否通过 SSH 隧道自动被本地电脑发现？

不能直接依赖这一点。Bonjour 通常使用链路本地的 mDNS 组播，普通 SSH 端口转发不会转发 UDP 5353 组播；远程访问应使用明确地址、专用网关或经过设计的发现代理。

CI 中怎样避免多个 Bonjour 测试互相冲突？

为每次任务生成唯一实例名，固定专用服务类型，并用 trap 回收 dns-sd 和测试服务进程。并发任务还应分配不同端口，不能只靠实例名隔离。

独享物理节点

为构建、测试与 MLX 推理选择云端 Mac

按实际任务选择 M4、内存、存储、节点与租期。每份租用对应独享物理机，非虚拟机。

选择租用方案