expjobserver

这是一个跨多个测试机器的实验作业服务器和客户端。在某种程度上，它就像一个简单的集群管理器。

高级概念是，你有一个服务器（expjobserver），它在你的机器（例如始终在线的桌面机）上运行，可能在一个屏幕会话中。你有一些实验，你希望从某个驱动程序应用程序或脚本中运行。你还有一群机器，可能类型不同，你希望在这些机器上运行作业。 expjobserver 将这些作业调度到这些机器上，并将结果复制回主机机器（运行服务器的机器）。通过无状态的 CLI 客户端与服务器交互。

此外，expjobserver 还支持以下功能

• 一个出色的 CLI 客户端，具有生成 shell 完成脚本的 capability。
• 机器类别：相似机器被添加到同一类别，作业被调度在类别中的任何机器上运行。
• 机器设置：expjobserver 可以运行一系列设置机器，并在完成时自动将机器添加到其类别中。
• 作业矩阵：使用不同参数组合运行作业。
• 只要实验驱动程序向 stdout 输出格式为 RESULTS: <OUTPUT FILENAME> 的行，就会自动将结果复制回主机。
• 良好的服务器日志记录。
• 通过使用 protobuf 保存服务器历史记录并与客户端通信，尝试对失败、崩溃和服务器/客户端版本不匹配具有一定的容错能力。

先决条件

• rust1.37+

安装

cargo install expjobserver

这将安装客户端（j）和服务器（expjobserver）。

构建

这些命令都会构建客户端和服务器

# Debug
cargo build

# Release
cargo build --release

实际上，这并不重要，因为我已经禁用了优化并为发布构建添加了调试信息。原因是性能在这里并不重要（服务器本身也不是性能优化的），而可调试性非常有帮助。

用法

运行服务器

expjobserver \
  /path/to/experiment/driver \
  /path/to/logs/ \
  /path/to/log4rs/config.yaml

第一次运行时，您需要传递 --allow_snap_fail 标志，这将允许覆盖服务器历史记录。默认情况下，如果加载历史记录失败，则会失败并退出。这是为了提供一点安全性，以防您在奇怪的配置下重新启动，不会清除服务器的历史记录，这可能会很烦人。

您可能想在一个 screen 或 tmux 会话中运行服务器。这样，您可以断开连接并在后台运行。您始终可以通过再次连接或通过命令查看 /path/to/logs 来检查日志，其中服务器将记录调试日志。

服务器使用 log4rs 库进行日志记录。它是高度可配置的。这是我自己使用的合理配置 example.log.yml。要使用它，使用命令中的第二个参数将服务器指向它。

运行客户端

j --help

有许多子命令。它们在 CLI 使用消息中有很好的文档。

示例

这主要是为了快速浏览您能做什么（针对客户端）。这不是全面的。阅读使用消息（--help）以获取有关您能做什么的所有信息的更多信息。有很多酷炫的功能！

将机器添加到池中

首先，让我们列出池中的机器。

$ j machine ls

目前，没有。让我们添加一些。如果我们已经设置了机器，我们可以使用 j machine add，但我们也可以让机器运行设置脚本，并在之后自动添加到池中。

$ j machine setup --class foo -m my.machine.foo.com:22 -- "setup-the-thing {MACHINE} --flag --blah" "another-setup-command"
Server response: Jiresp(
    JobIdResp {
        jid: 0,
    },
)

在这里，{MACHINE} 将自动替换为 my.machine.foo.com:22。您也可以使用其他变量（请参阅 j var 命令）。这可以在几种方式上有所帮助

• {MACHINE} 允许您为多台机器使用相同的命令（您可以通过传递 -m 多次）。
• 您可以使用其他变量来最小化最终出现在您的 bash 历史记录中的机密数量（例如，如果您需要 GitHub 访问令牌或类似的东西）。

在此阶段，机器 my.machine.foo.com:22 将按照给定顺序开始运行列出的命令。假设它们都成功，该机器将被添加到池中的 foo 类别，并准备好运行任何请求 foo 类别机器的工作。

列出和排队作业

上述服务器响应中的 jid: 0 是设置任务的作业 ID。我们可以看到当前正在运行的任务，包括设置任务。

$ j job ls
 Job   Status  Class  Command                                  Machine                Output
   0  Running  foo    setup-the-thing {MACHINE} --flag --blah  my.machine.foo.com:22

目前，迄今为止唯一运行的是我们上面启动的设置任务。

我们可以为 foo 类别机器排队一些其他作业，以便在准备好时运行。

$ j job add foo "bar --the --foo baz" /path/to/results/dir -x 3
Server response: Jiresp(
    JobIdResp {
        jid: 1,
    },
)
Server response: Jiresp(
    JobIdResp {
        jid: 2,
    },
)
Server response: Jiresp(
    JobIdResp {
        jid: 3,
    },
)

这里我们将 3 个相同的任务排队，以便在第一个可用的 foo 机器上运行。作业按排队顺序运行。

$ j job ls
 Job   Status  Class  Command                                  Machine                Output
   0     Done  foo    setup-the-thing {MACHINE} --flag --blah  my.machine.foo.com:22
   1  Running  foo    bar --the --foo baz                      my.machine.foo.com:22
   2  Waiting  foo    bar --the --foo baz
   3  Waiting  foo    bar --the --foo baz

我们可以查看作业的 stdout（使用 tail）

j job log -t 1

其中 1 是上面表格中运行任务的作业ID。您还可以查看已完成任务的日志或获取日志文件的路径。

$ j job log -l 0                # look at the log of 0 with `less`
...

$ j job log 0                   # path to the log file
/some/path/0-setup-the-thing_my.machine.foo.com:22_--flag_--blah

作业矩阵

有时您想运行一系列略有变化的相似命令（例如，为了查看改变一个参数的效果）。

您可以使用 j job matrix 来实现。

j job matrix add foo "my-experiment-cmd --param0 {I} --param1 {J} --param2 {K}" \
    /path/to/copy/results/ I=1,2,3,4 J=linear,quadratic,exotic K=banana,rockingchair,airplane

该命令将排队 4x3x3 = 36 个作业，您可以通过 j job ls 或 j job matrix stat 来查看。

此外，您还可以使用 j job matrix csv 将矩阵和任何结果路径导出为 CSV 格式。

更多

查看各个命令和子命令的 --help 帮助信息，以了解更多功能。