20.13. 额外变量
当您传递问卷调查变量时,它们作为自动化控制器中的额外变量(extra_vars)传递。但是,将额外变量传递给作业模板(就像对问卷调查的操作一样)可能会覆盖从清单和项目传递的其他变量。
默认情况下,extra_vars 标记为 !unsafe,除非您在作业模板的 Extra Variables 部分中指定它们。这些是信任的,因为它们只能由具有足够特权的用户添加或编辑作业模板。例如,嵌套变量在作为提示符输入时不会扩展,因为 Jinja 方括号被视为字符串。有关不安全变量的更多信息,请参阅 Unsafe 或 raw string。
只有在以下条件之一被满足时,传递给作业启动 API 的 extra_vars 才有效:
- 它们与启用的问卷调查中的变量对应。
-
ask_variables_on_launch设置为 True。
Example
为 debug = true 定义了清单的变量。此变量 debug = true 可能会在作业模板问卷调查中被覆盖。
要确保您传递的变量不会被覆盖,请在问卷调查中重新定义变量来确保包括它们。可以在清单、组和主机级别上定义额外的变量。
如果您要指定 ALLOW_JINJA_IN_EXTRA_VARS 参数,请参阅 自动化控制器管理指南中的控制器 提示和 Tricks 部分,以便在控制器 UI 的 Jobs Settings 屏幕中进行配置。
作业模板额外变量字典与问卷调查变量合并。
以下是 YAML 和 JSON 格式的 extra_vars 的一些简化示例:
- YAML 格式的配置:
launch_to_orbit: true satellites: - sputnik - explorer - satcom
launch_to_orbit: true
satellites:
- sputnik
- explorer
- satcom
- JSON 格式的配置:
{
"launch_to_orbit": true,
"satellites": ["sputnik", "explorer", "satcom"]
}
{
"launch_to_orbit": true,
"satellites": ["sputnik", "explorer", "satcom"]
}
下表记录了自动化控制器中变量优先级的行为(层次结构)与 Ansible 中的变量优先级比较。
| Ansible | 自动化控制器 |
|---|---|
| 角色默认值 | 角色默认值 |
| 动态清单变量 | 动态清单变量 |
| 清单变量 | 自动化控制器清单变量 |
|
清单 | 自动化控制器组变量 |
|
清单 | 自动化控制器主机变量 |
|
Playbook |
Playbook |
|
playbook |
playbook |
| 主机事实 | 主机事实 |
| 注册的变量 | 注册的变量 |
| 设置事实 | 设置事实 |
| Play 变量 | Play 变量 |
|
play | (不支持) |
|
play |
play |
| role 和 include 变量 | role 和 include 变量 |
| 块变量 | 块变量 |
| 任务变量 | 任务变量 |
| 额外变量 | 作业模板额外变量 |
| 作业模板调查(defaults) | |
| 任务启动额外变量 |
20.13.1. 重新启动作业模板 复制链接链接已复制到粘贴板!
通过设置 launch_type 以重新启动作业来表示重新启动作业,而不是手动 重新启动作业。重新启动行为与启动行为不同,其不会继承 extra_vars。
作业重新启动不会通过继承逻辑。它使用为重新启动的作业计算的相同 extra_vars。
Example
您启动了一个没有 extra_vars 的作业模板,这导致创建名为 j1 的作业。然后,您编辑作业模板并添加 extra_vars (如添加 "{ "hello": "world" }")。
重新启动 j1 会导致创建 j2,但由于没有继承逻辑,并且 j1 没有 extra_vars,j2 没有任何 extra_vars。
如果您使用您在创建 j1 后添加的 extra_vars 启动作业模板,则创建重新启动作业(j3)包含 extra_vars。重新启动 j3 会导致创建 j4,这还包括 extra_vars。