chef-solo - 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 的 Recipe 。您可能希望为操作系统保留 X 数量的 RAM，其余的则用于 memcached。

在 VM 中运行时可以更改可用 RAM，甚至无需重新启动它。这可能是将 chef-solo 作为守护进程运行并频繁运行 chef-solo 的一个很好的理由，就像您习惯将 chef-client 与 chef-server 一起使用一样。

关于您的其他问题:

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

A:Chef 不响应更改。相反，它会频繁运行并确保当前状态与所需状态同步——这可以基于 Chef-server list 、API 调用、OHAI 属性等。每次运行 Chef 时所需状态都是从头开始构造的，在生成所有资源的编译阶段。了解一下 here

---

问:如果您更新它依赖于它何时运行的说明书和节点文件，它会如何表现？

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