可复用执行模板

可复用执行模板是 rauto 已经超出“命令发包器”范畴的重要标志之一。

它允许把结构化执行 JSON 保存到 SQLite 中，并在执行前按运行时变量渲染。

什么属于执行模板

当前执行模板主要包括：

tx block templates
tx workflow templates
orchestration templates

根据 README，当前 API 家族包括：

/api/tx-block-templates
/api/tx-workflow-templates
/api/orchestration-templates

为什么执行模板重要

它适用于你希望从这些模式升级时：

一次性 JSON 文件
操作员本地各自保存的 rollout 文件
团队之间重复复制粘贴相似变更逻辑

升级成：

集中存储的执行蓝图
可参数化的 rollout 模式
可跨团队、跨时间窗口复用的标准变更逻辑

支持的执行输入模式

Tx block 执行

POST /api/tx/block 支持：

tx_block_template_name
tx_block_template_content
tx_block_template_vars

Tx workflow 执行

POST /api/tx/workflow 支持：

workflow_template_name
workflow_template_content
workflow_vars

Orchestration 执行

POST /api/orchestrate 支持：

plan_template_name
plan_template_content
plan_vars

这意味着同一套 rollout 逻辑可以通过三种方式提供：

直接传内联 JSON
引用已保存模板
传模板内容并附带变量

渲染上下文

README 里已经明确说明了比当前高层文档更丰富的渲染上下文。

模板渲染时可以引用：

vars
- 请求级运行时变量
connection
- 单目标解析后的连接数据，例如 host、username、password、port、device profile
connection.saved
- 当目标来自 saved connection 时附带的元数据
defaults
- 全局默认连接参数，主要用于 orchestration 渲染
now
- 当前时间，例如 rfc3339 与 timestamp_ms

此外还支持顶层简写解析：

先查 request vars
再回退到当前目标连接参数

直接引用连接对象

README 还明确指出模板字符串可以直接引用连接对象。

例如：

{{ edge94.host }}
{{ edge94.password }}
{{ edge94.vars.site }}

这在工作流或编排需要拼接 peer 目标信息时非常有用。

字符串渲染示例

任何字符串字段都可以使用 Minijinja 语法。

{
  "command": "scp /tmp/{{ image_file }} {{ edge94.username }}@{{ edge94.host }}:/tmp/{{ image_file }}"
}

这说明模板渲染不只作用于顶层元数据，执行 payload 内的操作字符串本身也可以动态生成。

Web UI 中如何使用

根据当前 README，Operations -> Orchestrated Delivery 已经为以下场景提供专门的运行时变量输入：

Tx Workflow：workflow_vars
Orchestration：plan_vars

这让不直接编辑原始 JSON 的运维人员，也可以复用模板驱动的 rollout。

与 JSON 文件示例的关系

你不需要只选择其中一种模式。

推荐成熟路径：

从仓库示例 JSON 文件开始
按自己环境调整
把稳定流程沉淀成已保存执行模板
在执行时通过 Web 或 API 注入运行时变量

什么时候使用执行模板

直接使用 JSON 文件更适合：

rollout 仍在快速迭代
主要在本地调试
还没有形成标准作业流程

使用可复用执行模板更适合：

结构已经稳定
会多次重复执行
多个操作员要共用同一逻辑
需要评审和治理
希望 Web 用户也能复用标准蓝图

企业级建议

把模板视为治理资产

执行模板往往代表已经审批过的标准作业流程。

建议为每个模板补充：

用途
必填 vars
适用目标
回滚语义
归属团队
最近验证时间

结构与运行时数据分离

理想的执行模板应做到：

结构留在模板里
环境相关数据通过运行时变量注入

这样更便于复用，也更不容易产生变更漂移。

尽量使用 saved connection 而不是内联凭据

既然渲染上下文已经支持 resolved connection 对象，在企业级场景里更推荐使用 saved connection，而不是在 JSON 里重复写原始凭据。