我使用SaltStack管理一些虚拟机。我正在寻找一种方法来渲染在top.sls文件中附加了指定.sls的minion的ID /主机名,或者在jinja模板启用的文件中的特定状态。我之所以这样做是因为我可以轻松地在客户端配置中引用服务器,而无需在任何地方硬编码值。例如;
/srv/salt/top.sls:
base:
'desktoppc01':
- generic.dns
'bind9server01':
- generic.dns
- bind9
/srv/salt/generic/dns/init.sls:
/etc/resolv.conf:
file:
- managed
- source: salt://generic/dns/files/resolv.conf
- mode: 644
- template: jinja
最后,
/srv/salt/generic/dns/files/resolv.conf:
domain {{ pillar['domain_name'] }}
search {{ pillar['domain_name'] }}
nameserver {{ list_minions_with_state['bind9'] }}
我具体的是等同于{{ list_minions_with_state['bind9'] }}
(我只是为了演示而做的)。我曾经认为这将是非常普遍需要的东西,但在搜索模块页面之后我还没有找到任何东西。
目前,我让客户从支柱中获取信息,但必须手动配置,并不会花费时间。
我希望我可以通过for
循环扩展这个想法,以便在服务器创建时动态添加服务器。
编辑:
使用具有相同数据和文件的文件层次结构作为top.sls,呈现
base:
{% for server_id in salt['pillar.get']('servers') %}
'{{ server_id }}':
{% for states in salt['pillar.get']('servers:{{ server_id }}') %}
- {{ states }}
{% endfor %}
{% endfor %}
给你
base:
'desktoppc01':
'bind9server01':
我在{{ server_id }}
上尝试了一些变体,但未成功。除非在该函数中使用支柱变量是一种简单的方法,否则我想要提出功能请求并将其称为一天。
答案 0 :(得分:1)
我认为解决这个问题的方法是使用jinja并拥有一个包含dns服务器列表的变量...由一个支柱变量填充
例如,你可以有一个支柱:bind:servers变量 见http://docs.saltstack.com/en/latest/topics/tutorials/states_pt3.html 和http://docs.saltstack.com/en/latest/topics/pillar/index.html#master-config-in-pillar既可以用来设置resolv.conf的名称服务器,也可以用于将 - bind9状态添加到服务器。 所以最后你只有一个地方可以编辑:在柱子中绑定服务器的minion列表
答案 1 :(得分:0)
首先想到的是通过将test = True设置为state.apply或state.highstate来使用测试状态方法。如果要应用的状态为零,则服务器将完全应用您的高状态或特定的sls。
salt '*' state.highstate test=True
使用salt-run的survey.diff可能会有所帮助(尽管diff补丁不如检查配置文件那样适合这种情况):
salt-run survey.diff '*' state.apply my.state test=True
虽然当前不适用于基于示例的问题,但我想到的另一种方法是在州内使用盐粒。当您将状态应用于系统时,状态将附加到“状态”颗粒中。在您的案例中,谷物可以跟踪诸如角色(例如Web,数据库等)之类的事物,而谷物可以跟踪状态,而更多的是应用了什么,而不是角色逻辑。然后,您可以使用它们来定位和/或查询服务器。
按谷物定位(仅显示奴才ID):
salt -G 'states:bind9' test.ping
salt -G 'states:generic.dns' test.ping
salt -G 'states:my_jinja_state' test.ping
查询谷物(为每个奴才显示状态谷物)
salt '*' grains.get states
谷物差异(比较每个小兵的谷物状态):
salt-run survey.diff '*' grains.get states