事务与多设备编排

rauto 提供三层逐步增强的执行模型：

tx
tx-workflow
orchestrate

它们不是彼此替代，而是从 单目标事务块 逐渐升级到 多目标多阶段编排。

`tx`：单目标事务块

rauto tx 适合在一台设备上执行一个紧凑、可回滚的变更单元。

命令模式

rauto tx \
  --name vlan-change \
  --command "vlan 120" \
  --command "name campus-users" \
  --rollback-command "no vlan 120" \
  --rollback-command "default name" \
  --rollback-on-failure \
  --mode Config \
  --connection core-01

适合：

少量步骤
回滚逻辑明确
不想单独维护工作流 JSON

命令流模式

tx 也可以直接把命令流作为事务步骤来执行：

rauto tx \
  --run-kind command-flow \
  --flow-template cisco_like_copy \
  --flow-vars ./flow-vars.json \
  --rollback-flow-file ./rollback-flow.toml \
  --connection core-01

适合：

事务步骤本身带有交互流程
正向和回滚都不是简单静态命令

当前源码还暴露了这些更细的 tx 控制项：

--rollback-commands-file：每行一条回滚命令
--rollback-commands-json：JSON 数组形式的回滚命令
--rollback-trigger-step-index：资源级回滚触发步骤索引
--resource-rollback-command：显式资源级回滚命令
--json：机器可读结果输出

这对企业场景很重要，因为很多团队会从少量显式回滚命令，逐渐演进到可评审的回滚工件。

`tx-workflow`：结构化事务工作流

当变更已经不再是“一小段步骤”，而是包含多个 block、不同 rollback policy 时，推荐改用 tx-workflow。

rauto tx-workflow ./workflow.json --view
rauto tx-workflow ./workflow.json --dry-run
rauto tx-workflow ./workflow.json --connection core-01

一个典型工作流结构

{
  "name": "campus-core-vlan",
  "fail_fast": true,
  "blocks": [
    {
      "name": "create-vlan",
      "rollback_policy": "per_step"
    },
    {
      "name": "create-svi",
      "rollback_policy": {
        "whole_resource": {
          "rollback": {
            "kind": "command",
            "mode": "Config",
            "command": "default interface vlan 120"
          }
        }
      }
    }
  ]
}

适合：

需要把变更拆成多个命名 block
不同 block 的回滚策略不同
希望把流程以 JSON 形式长期维护

当前 README 还强调：tx-workflow 不只适合长期保留为原始文件。当结构稳定后，也可以进一步演进为可复用执行模板，或通过 Web 侧下发。

`orchestrate`：多设备多阶段编排

如果你的目标从一台设备扩展到一组设备，就应该使用 rauto orchestrate。

rauto orchestrate ./orchestration.json --view
rauto orchestrate ./orchestration.json --dry-run
rauto orchestrate ./orchestration.json --record-level full

一个典型编排结构

{
  "name": "campus-vlan-rollout",
  "fail_fast": true,
  "rollback_on_stage_failure": true,
  "stages": [
    {
      "name": "core",
      "strategy": "serial"
    },
    {
      "name": "access",
      "strategy": "serial"
    }
  ]
}

编排支持这些关键概念：

stage：阶段
job：阶段内的执行单元
targets / target_groups：执行目标
strategy：串行或并发
max_parallel：并发上限
action：执行动作，如 tx_block 或 tx_workflow

当前 README 还补充了：

rollback_completed_stages_on_failure：后续 stage 失败时，对之前已完成 stage 的成功目标做补偿回滚
支持带 vars 的内联 targets
支持 inventory_file 和内联 inventory 结构来做分组目标选择
tx_block 与 tx_workflow 都支持多种 action 来源模式

编排中的 action 来源模式

对 tx_block job，当前 README 记录了两种主要来源：

命令模式（template / commands + vars）
事务块模板模式（tx_block_template_name / tx_block_template_content + tx_block_template_vars）

对 tx_workflow job，当前 README 记录了四种互斥来源：

workflow_file
内联 workflow
workflow_template_name
workflow_template_content 配合 workflow_vars

这是面向企业级交付的重要能力，因为它让编排既能消费本地文件，也能消费受治理的可复用模板。

三者如何选择

场景	推荐能力
单目标，少量步骤，需回滚	`tx`
单目标，分 block，流程更复杂	`tx-workflow`
多设备、多阶段、需要并发控制	`orchestrate`

Dry Run 与 View 的价值

这三层能力都建议优先在以下模式下验证：

--view：查看结构化计划
--dry-run：只输出计划，不实际执行
--json：输出原始 JSON 或结构化结果，便于集成

对于生产变更，这是非常值得坚持的习惯。

与 Inventory / 已保存连接的关系

orchestrate 在多设备执行时，通常会结合：

已保存连接
group
inventory defaults / group defaults
运行时变量

仓库示例展示了两种典型风格：

小型计划直接写 targets
大型 staged delivery 通过 target_groups + inventory_file 管理目标

这也是为什么 rauto 后期更适合作为“执行底座”，而不是简单的命令发包器。

建议重点学习的示例家族

仓库中的以下示例值得作为“文档工件”来理解，而不只是测试样例：

core-vlan-workflow.json
fabric-change-workflow.json
campus-vlan-orchestration.json
campus-inventory.json
fabric-advanced-orchestration.json
fabric-advanced-inventory.json
linux-image-rollout-orchestration.json
linux-image-export-and-transfer-workflow.json
linux-image-export-and-transfer-with-password-scp-workflow.json
linux-image-load-and-restart-workflow.json

如果你想按目录方式查看这些示例，请继续阅读示例库。

如果你需要了解这些底层数据如何保存和合并，请继续阅读运行时数据与配置。