![仅在提交时运行 puppetmaster 和客户端,每天运行一次](https://linux22.com/image/592221/%E4%BB%85%E5%9C%A8%E6%8F%90%E4%BA%A4%E6%97%B6%E8%BF%90%E8%A1%8C%20puppetmaster%20%E5%92%8C%E5%AE%A2%E6%88%B7%E7%AB%AF%EF%BC%8C%E6%AF%8F%E5%A4%A9%E8%BF%90%E8%A1%8C%E4%B8%80%E6%AC%A1.png)
Puppet 正在消耗我机器上的资源,不幸的是我必须在一台机器上同时运行 master 和其他进程。
现在我计划停止 puppet 作为守护进程一直运行,而是考虑运行它:
- 当 Puppet 控制的清单发生变化时。我的清单在 git 中处于修订控制之下。也许通过发布接收钩子。
- 每天运行一次 puppet。如果有人要更改机器上的配置,则应替换此配置。例如,sshd_config 应该是原始的。
有人尝试过这样的策略吗?
有人能帮忙吗?
答案1
答案2
您可以像往常一样将 puppet 添加到 cron 作业中(这允许您选择仅在工作时间运行它,或者每半小时运行一次或多或少),但将其包装在一个简短的脚本中,该脚本检查源代码控制的修订号是否已增加。如果是,它会触发 puppet 客户端,如果没有,则不需要 puppet(以及它所做的所有昂贵的文件哈希处理)。
然而,这意味着如果你在主机上更改了一个文件,Puppet 不会改变它后退直到下一次配置更改。您可以通过更改包装器脚本的逻辑来避免此问题,如果距离上次运行已超过 24 小时,则还运行 puppet 客户端。
“无主”傀儡想法(ewwhite 提到的)消除了傀儡主控作为瓶颈的问题,并用 git 作为瓶颈来代替它,在我看来这是非常可取的。除非你对 git 的更改速度比它将这些更改推送到所有主机的速度快,否则这个瓶颈不会成为问题。如果它真的成为一个问题,你可以以树的形式排列“辐条”。这应该可以扩展到数万台主机。