首页 文章

独立盐奴的沉默失败

提问于
浏览 次
2

我正在启动一个使用Salt Stack来协调配置的项目 . 但它现在不起作用 - 日志文件（在minion上，在/ var / log / salt / minion）没有显示任何错误，但是minion没有做我要求的 .

基本上，我正在构建一个带有几个顶级文件和至少两个minion配置的SaltStack . 特别是，我正在调试一个minion我正在调用bootstrap（因为它应该在minion上引导一个salt master）：

master: localhost
file_client: local
file_roots:
  base:
    - /srv/salt/base
    - /srv/salt/states
  master:
    - /srv/salt/master
    - /srv/salt/master/states

据我所知，Salt正在加载顶级文件，并将它们解析为有效对象，但Salt没有运行任何命令来响应对象 . 实际上，minion日志文件说：

2014-03-01 23:00:09,644 [salt.utils.jinja ][DEBUG   ] Jinja search path: '['/srv/salt/base', '/srv/salt/state
2014-03-01 23:00:09,651 [salt.template    ][DEBUG   ] Rendered data from file: /srv/salt/base/top.sls:
base:
  '*':
    - edit.vim
    - essential
    - users.root

2014-03-01 23:00:09,656 [salt.loaded.int.render.yaml][DEBUG   ] Results of YAML rendering:
OrderedDict([('base', OrderedDict([('*', ['edit.vim', 'essential', 'users.root'])]))])

这一切看起来还不错，除了它立即跳转到：

2014-03-01 23:00:09,661 [salt.utils.jinja ][DEBUG   ] Jinja search path: '['/srv/salt/master', '/srv/salt/mas
2014-03-01 23:00:09,662 [salt.template    ][DEBUG   ] Rendered data from file: /srv/salt/master/top.sls:
master:
  '10.47.94.0/24':
     - match: ipcidr
     - master
     - srv.dns.unbound

2014-03-01 23:00:09,665 [salt.loaded.int.render.yaml][DEBUG   ] Results of YAML rendering:
OrderedDict([('master', OrderedDict([('10.47.94.0/24', [OrderedDict([('match', 'ipcidr')]), 'master', 'srv.dns.unbound'])]))])

在日志文件的其余部分中，永远不会再提及base . 与base相关的命令/状态没有运行 . 我确实看到了edit.vim，srv.dns.unbound等的日志条目 . 但是它们都遵循相同的模式：解析并且什么也不做 .

我究竟做错了什么？我得到的模糊印象是它与我的minion配置中有多个file_roots有关，但在我知道架构应该是什么之前，我宁愿不进行体系结构更改 . （我曾经尝试过使用Salt一次，遇到“这个”无声错误，重新开始，现在再次遇到它）

salt-stack

2 回答

  • 1
    master: localhost
file_client: local

    'master：localhost'和'file_client：local'选项是互斥的 .

    如果你有'file_client：local'，那么当地的盐奴将根本不会寻找主人 .

    如果想在同一台机器上运行salt-master和salt-minion，那么你可以在minion配置中使用'master：localhost'并注释掉'file_client' . 在这种情况下，你还要将你的奴才和主人配置分开 .

    至于你关于top.sls文件渲染的问题 . 这是根据设计 . Salt将查找并呈现每个文件环境的根目录中的每个top.sls . 因此，因为你有两个环境，它总是会渲染两个top.sls文件，然后为每个minion评估它们，以确定sls文件在每个minion上执行 .

    需要更多信息来解决为什么基础环境中的状态未被执行的原因 . 尝试运行以下命令并提供输出：

    salt-call state.show_highstate -l debug
    回复于
  • 1

    当我开始阅读saltstack文档时，这通常是混乱 .

    • 始终坚持主人 - 奴才设置，避免任何尝试，甚至“认为无主” . Going Masterless不会为你节省大量的CPU和内存资源，但会对盐栈学习/构建过程造成更多的困惑 .

    • 总是绘制一个逻辑图而不是“直接考虑到盐堆” .

    • 在提问时总是记下正确/明确的文件路径和名称，即 . 对于配置文件，状态等，不要采取快捷方式 .

    我想做类似的事情，即在数据中心D中使用我的内部网盐主要名称AA规定盐主X，然后从盐主设备X启动minion提供 . 控制数据中心D内的所有minion .

    所以这样做是合乎逻辑的

    Salt master AA < - >（Datacenter D Server XYZ [Salt master X，Salt minion X to AA]，
    服务器S_1 [Salt minion S_1，salt-master X]，
    服务器S_2 [Salt minion S_2，salt-master X]，
    服务器S_3 [Salt minion S_3，salt-master X]
    ）

    因此盐主AA将控制服务器XYZ作为一个小兵 . 然后我可以将下一级控制代码从主AA发送到服务器XYZ，也许运行自动化脚本来卸载AA中的salt minion连接器 .

    回复于

相关问题