大厨独唱 - 如何工作,有什么意义？

我理解chef-client --daemonize的目的,因为它是Chef Server可以连接并与之交互的服务.

但是,chef-solo是一个命令,只是简单地使当前系统符合规范,然后完成.

那么主厨 - 独唱 - 重要的是什么呢？具体是什么呢？例如,当系统与规范不符时,它会自动检测吗？它是通过轮询或利用文件系统事件来实现的吗？如果您更新它已经运行的菜谱和节点文件,它的行为如何？

您可能也会问为什么chef-solo支持--splay和--interval论证.

不要忘记,厨师服务器不是唯一的数据来源.配置值可以依赖于许多其他来源(API,OHAI,DNS ......).最经典的一个是OHAI - 想想一个配置memcached的食谱.您可能希望为操作系统保留X量的RAM,其余的则用于memcached.

在VM内部运行时可以更改可用RAM,即使不重新启动它也是如此.这可能是一个很好的理由将厨师独奏作为一个守护进程与常见的厨师运行,就像你习惯使用厨师 - 客户与厨师 - 服务器.

至于你的其他问题:

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

答:厨师不回应变化.相反,它经常运行并确保当前状态与所需状态同步 - 这可以基于主厨服务器库存,API调用,OHAI属性等.每次运行Chef时,从头开始构建所需状态,在编译阶段生成所有资源时.在这里阅读它

问:如果您更新它已经运行的菜谱和节点文件,它的行为如何？

答:通常在运行chef-solo时,使用该--json标志来指定具有节点属性和运行列表的JSON文件.在--daemonize使用chef-solo的模式下运行时,节点属性仅在第一次运行时读取.对于其余的运行,就好像你在没有--json标志的情况下运行它一样.我无法找到一种让它工作的方法,就像你再次运行它一样--json,但是,你可以使用该--override-runlist选项至少使运行列表坚持下去.请注意,您在JSON中指定的属性不会超过第一次运行.这可能是一个错误.