*
ok: [test] => {
“msg”: [
“11111”,
“user_foo”,
“22”,
“root”
]
}…
“`
为什么结果不如期望？
解决方案
请注意以下操作可能存在版本差异，建议在操作前做好备份。
这个情况是因为Ansible会根据变量的优先级进行处理，导致你的预期结果与实际结果不符。
首先，需要理解Ansible中变量的优先级。当你在不同的地方定义了相同的变量时，Ansible会根据变量优先级规则来进行处理。
值得注意的是，通过额外变量传递的变量具有最高优先级，你不能在其他地方或运行期间（如使用set_fact）更改它们。
现在我们来分解一下发生了什么，以下以backup_ansible_port为例，其他变量也是类似的。你可以在理解了这个例子后自行推断其他变量。
当你在debug任务中显示"{{ backup_ansible_port }}"时：
- 第一个Jinja2模板处理发现它应该扩展为Play中定义的
ansible_port变量。 ansible_port在清单中被定义为直接的值”11111″，作为主机变量（参见上述优先级文档中的#8）。但是，它还作为Play变量中tmp_port的扩展来定义（参见上述优先级文档中的#12）。优先级高的胜出，因此第二个Jinja2模板处理发现应该扩展为tmp_port。tmp_port在额外变量中有值”22″，这将是最终返回的值。
所以，最终的输出与你的预期不符，是因为变量的优先级规则导致了这种结果。
如果你希望获得预期的输出，可以考虑调整变量的定义和使用，以使其符合你的预期结果。
正文完