事务与多设备编排#

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

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

#三者如何选择

#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

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

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