playbook-rs

YAML 驱动的容器工作流程编排

特性

• 设计用于与 nvidia-docker2 一起工作，并实现非常复杂的 GPU 工作流程
• 语言无关的符号命名空间（注意 whitelist 和 #[playbook(something)]）
• 静态/动态伪装（setuid 和可选地创建和引用主机用户）以确保正确的权限
• 通过白名单一小部分超级用户功能来加强内部安全性
  • SETUID, SETGID, CHOWN
• 通过设置 gui: ture 使用 X11 图形
• 每个步骤都可以在不同的容器（或主机）中运行，以支持同一工作流程中的不兼容依赖项
• 支持指定 IPC 和网络命名空间
• 简单的动作调用约定： awesome_func(ctx)
• 启动工作流程的最小命令行参数： playbook some.yml
• 彩色日志以提高可读性

依赖项

• (可选) Docker CE

简而言之

1. 添加一个函数 def something(ctx)。当前执行上下文在 ctx 中作为字典。键也可以作为属性访问，以节省很多方括号和引号。并确保将此函数声明为 playbook 中的符号。

## hello_world.py ##

#[playbook(something)]
def something(ctx):
    print(ctx.message)

2. 将源文件路径添加到 whitelist。

## main.yml ##
whitelist:
- src: hello_world.py

3. 在 steps 中添加您的 YAML 文件的条目，其中 action 是步骤函数名称

## main.yml ##
whitelist:
- src: hello_world.py
steps:
- name: Some description here
  action: something
  message: Hello World!

4. 运行它！

$ playbook main.yml

查看 Wiki 了解更多细节和示例。

常见问题解答

这与 ______ 的区别是什么？

Docker-compose

该系统具有模拟（也称为容器用户配置）和其他安全增强功能，使其成为研究和开发使用更好的抽象级别。尝试使用-vv来亲自看看我们在docker命令/ API调用中使用了多少选项来更仔细、更正确地运行事情。将这些视为需要自动化的重复性工作，因此创建了该项目！所有这些都可以完全使用docker或docker-compose（这正是它的工作方式）来完成，但可能每个要容器化的项目中都需要更多的模板和脚本。

此外，我们还旨在协助全球系统资源协调，尤其是在共享系统中。从长远来看，我们希望支持Kubernetes、SLURM、HTCondor或任何其他我们感兴趣使用的系统。

Kubernetes

Kubernetes关注工作负载，而该系统关注工作流程。

为什么选择Rust？

首先，任何脚本语言都不可行，因为使用如此动态且容错性强的语言构建具有高可靠性和可持续性要求的系统要困难得多。我们希望系统在出现任何一点过时代码或数据结构时都能崩溃，甚至最好连编译都通不过，这样我们就能在尽可能早的时候发现问题，而不是在容器构建并交付给用户之后。

其次，据我所知，目前最好的AOT编译且无任何承诺的语言是C++、Rust和Go。

最后，我们希望有一个好的包管理器，所以Rust在这里是唯一的选择。