SLS，但是它发出的语法无效，这会导致错误，例如：my-minion-id:
- State 'system' in SLS 'network' is not formed as a list
可能会以某种方式检查Jinja模板的输出，然后再尝试将其解析为
SLS文件。 Jinja渲染器存在一个Python模块salt.renderers.jinja，但是如果我尝试在CLI上执行它，则会收到错误消息：我的模板？似乎很难调试很荒谬。#1 楼
签出slsutil.renderer模块。这应该做您想要的
salt my-minion-id slsutil.renderer /srv/salt/network/init.sls 'jinja'
该模块只是直接为您调用compile_template函数。
编辑：/srv/salt/network/init.sls是奴隶上的路径，如果您不以主人作为奴隶，则可能需要执行以下操作。 >
salt minion-id cp.cache_file salt://network/init.sls
salt minion-id slsutil.renderer /var/cache/salt/minion/files/base/network/init.sls
或指向cache_file发出的任何文件。
如果您使用的是2018.3或更高版本，则只需指定
salt://network/init.sls #2 楼
考虑到我数周前花了很多时间来解决一个紧密相关的问题，我希望早点解决这个问题。解决方案似乎是使用
salt.modules.cp.get_template让Salt minion检索文件，通过模板引擎进行渲染，并将其放置在可读的位置： 这很有意义；
my-minion-id位于/root/network.sls命名空间中，而您可以从CLI访问的模块位于salt.renderers.jinja命名空间中。模板渲染发生在可以使用晶粒等的奴才上，我还没有看到执行奴才代码的模块将任意输出返回到主对象（例如，在CLI上查看）；返回的数据始终具有良好的结构和简洁。 （可能有这样一个模块，但我不知道它是什么。将测试文件拖放到一个奴才上是一个更好的解决方案。）编辑：@gtmanfred的答案要好得多，而且更直接，我已经接受了那个。我将其留在此处仅供参考。这不是最好的解决方案，但它仍然有效。
评论
这个答案似乎对于调试由jinja引起的错误更有用，因为它提供了jinja处理后，编译之前的文本输出。调用slsutil.render尝试编译模板，如果失败（原始问题的动机），则它不会发出可用于确定Jinja产生何种混乱的输出。
–特里·伯顿（Terry Burton）
20年4月7日在15:13
如果您的主人是奴才（这似乎是个好主意，因为salt中的所有内容，甚至是文档都在奴才上运行），则可以执行salt调用cp.get_template salt：//foo.sls / dev / stdout
– emorris
20 Sep 18 '10：44
评论
但是/ srv / salt / network是什么路径？这是主人的道路吗？奴才？
–默滕
18-10-26在12:55
这是一条通往奴才的道路。您可以执行salt minion-id cp.cache_file salt：//network/init.sls的操作，然后对在小虫上缓存后吐出的文件运行slsutil.renderer，或者从2018.3开始，只需指定salt：/ /network/init.sls
–gtmanfred
18-10-27在13:04
除非我有误解，否则我的环境会有所不同，否则slsutil.render会尝试编译模板并输出结果。这样可以看到最终的结果状态，但是对于检查jinja的输出（结果是无效状态）并没有帮助，该结果是无效状态。
–特里·伯顿（Terry Burton）
20年4月7日在15:17
是的，但是您可以仅打印出jinja对象，或将其模板化为yaml并转储它，以便您可以检查jinja对象中的数据。
–gtmanfred
20年4月8日在16:15
slsutil.render会渲染然后编译状态，并且似乎没有一种在编译之前终止管道的方法。因此我看不出它是如何解决的：“原则上，应该有可能以某种方式检查Jinja模板的输出，然后再尝试将输出解析为SLS文件。”如果您不知道，那么我很想看看一个示例（特别是对于Jinja会产生损坏的状态），因为cp.get_template令人讨厌的事情是它需要输出FD，因此当被Salt中的salt调用时无效/ dev / stdout的主机不可用。
–特里·伯顿（Terry Burton）
20年4月12日在13:56