我正在使用servicenow.servicenow.now插件处理可解析的动态清单。其主要思想是告诉ansible使用winrmkerberos连接类型来连接我从中提取的所有主机。因此，我使用compose选项来完成此操作，但是，字符串似乎没有按预期进行解析。文档中说应该是jinja2表达。在我的情况下，我只想设置一个数字和字母混合的字符串。出于某种原因，它只适用于数字？
这是插件配置：
# Simple Inventory Plugin example
plugin: servicenow.servicenow.now
instance: myamazingcompany
username: username
password: 'amazingpassword'
filter_results: 'install_status=5'
fields: [name,support_group]
table: computers
use_extra_vars: yes
keyed_groups:
- key: sn_support_group | lower
prefix: ''
separator: ''
compose:
ansible_user: "my_windows_user"
ansible_password: "4567"
connection: "winrm"
ansible_winrm_transport: "kerberos"
ansible_winrm_server_cert_validation: "ignore"
这是我从servicenow 得到的结果
[...]
"windows_server_1": {
"ansible_password": "4567",
"sn_name": "windows_server_1",
"sn_support_group": "windows_support"
},
"windows_server_2": {
"ansible_password": "4567",
"sn_name": "windows_server_2",
"sn_support_group": "windows_support"
},
[...]
为什么我只将ansible_password变量设置为我的主机？我试过使用简单的引号，根本没有引号，但它不起作用。我很困惑，因为插件文档没有解释任何东西。
感谢您的帮助
是的，这会出现很多，他们只是在compose:步骤中默默地吞下jinja2错误，这会让你的体验变得更糟
因此，首先，你的问题的答案，然后是一个建议，如何在未来的中绕过这种愚蠢的行为
答案是因为这些组成的值中的每一个都隐含地封装在CCD_ 2中；jinja2表达式"；这就是为什么在他们的文档中有效的原因：
compose:
sn_tags: sn_sys_tags.replace(" ", "").split(',')
ansible_host: sn_ip_address
可以看到，这两个都是pythonjinja2，并且在生成的json中肯定不是键；因此，这里实际发生的是：
compose:
sn_tags: '{{ sn_sys_tags.replace(" ", "").split(",") }}'
ansible_host: '{{ sn_ip_address }}'
但我想，将胡子包含在.yaml文件中会让用户认为他们可以在任何地方使用胡子，这肯定是不真实的
因此，在您的环境中，您必须将这些键放入表达式中，将产生这些文字，如下所示：
compose:
ansible_user: '"my_windows_user"'
ansible_password: '"4567"'
connection: '"winrm"'
ansible_winrm_transport: '"kerberos"'
ansible_winrm_server_cert_validation: '"ignore"'
由于如果作用域中没有这样的符号，则{{ winrm }}是jinja2错误，但{{ "winrm" }}是字符串winrm；外层的'"是从yaml 中逃离那些"
你的password: "1234"之所以有效，是因为{{ 1234 }}会自行解决，而{{ foobar }}不会，尽管从学术角度讲，ansible_password:当时是int，而不是str，但我想它还不足以让爆炸显现出来：-(
现在，我试图回答您提出的问题，但将来，您真正想要的是group_vars，因为您提供的每一个密钥都不会因库存响应而变化，因此它们属于group_vars/${whatever}.yaml文件，即使文件名最终为all.yaml，因为它同样适用于库存中的每一台主机