chef-solo --daemonize是如何工作的，重点是什么？

Question

我理解chef-client --daemonize的用途，因为它是Chef Server可以连接和交互的服务。

但是chef-solo是一个命令，它只是简单地将当前系统与规范结合起来，然后就完成了。

那么chef-solo --daemonize的意义是什么，它具体做了什么？例如，当系统与规格不符时，它会自动检测吗？它是通过轮询还是利用文件系统事件来实现的？当它已经在运行时，如果您更新它所依赖的食谱和节点文件，它会有什么行为？

Answer 1

您可能还会问为什么chef-solo支持--splay和--interval参数。

不要忘记chef-server不是唯一的数据源。配置值可以依赖于一堆其他来源(API、OHAI、DNS……)。最经典的是OHAI --想想一本配置memcached的食谱。您可能希望为操作系统保留X大小的RAM，其余的将分配给memcached。

在VM内部运行时，即使不重新启动，也可以更改可用RAM。这可能是将chef-solo作为具有频繁chef- run的守护进程运行的一个好理由，就像您在将chef-client与chef-server一起使用时所习惯的那样。

至于你的其他问题：

问:当系统与规格不符时，它会自动检测吗？它是通过轮询还是利用文件系统事件来实现的？

答: Chef不会对变化做出反应。相反，它会频繁运行，并确保当前状态与所需状态同步-这可以基于chef-server清单、API调用、OHAI属性等。每次运行Chef时，都会在编译阶段生成所有资源时从头开始构建所需状态。阅读关于它的here

问:当它已经在运行时，如果你更新它所依赖的食谱和节点文件，它会有什么行为？

答:通常在运行chef-solo时，会使用--json标志来指定一个带有节点属性和运行列表的JSON文件。使用chef-solo在--daemonize模式下运行时，节点属性在第一次运行时是只读的。对于其余的运行，就好像您在没有--json标志的情况下运行它。我想不出一种方法来让它工作起来，就好像你是在用--json重新运行它一样，但是，你可以使用--override-runlist选项，至少让runlist保持稳定。请注意，您在JSON中指定的属性不会通过第一次运行。这可能是一个bug。