厨师在运行结束时删除目录答案

【问题标题】：chef delete a directory at the end of a run厨师在运行结束时删除目录
【发布时间】：2016-08-26 11:27:22
【问题描述】：

所以我想让厨师在整个运行完成后清除一个目录。我认为这样做的方法是通过通知，但我运气不佳。我有下面的代码，我认为它会删除缓存目录（/var/chef/cache），但它似乎永远不会运行。

日志表明目录资源被跳过，因为在编译阶段该操作没有任何意义（这是有道理的），但该操作永远不会在最后通过通知运行。我错过了什么？

directory "delete the dir #{Chef::Config["file_cache_path"]}" do
    recursive true
    path "#{Chef::Config["file_cache_path"]}"
    action :nothing
end

s3_file "download tarball" do
    <details>
    notifies :delete, "directory[#{prefix} delete the dir #{Chef::Config["file_cache_path"]}]", :delayed
end

【问题讨论】：

标签： chef-infra

【解决方案1】：

主厨食谱按照run_list 中指定的顺序执行。如果您想最后执行某些操作，请将该配方放在 run_list 的末尾。使用通知是不可取的，因为：

不直观
不保证

不直观

假设您是团队中的另一位开发人员，正在查看此代码。为什么s3_file会删除文件缓存路径？没有评论等。此外，在更大、更复杂的应用程序中，您可能会收到多个资源的通知。以我的经验，人类在视觉化这种间接程度方面非常糟糕，而且经常会导致不必要的痛苦。

不保证

Chef 中有两种通知 - delayed 和 immediate。如果调用资源报告它已被最后一个操作更新，则保证立即触发通知。但是，在其他所有内容执行完毕后延迟通知。如果 Chef Client Run (CCR) 未能成功完成，则不会触发这些通知。因此，使用延迟通知将某些内容推送到 CCR 的“末尾”并不能保证执行。

正如 HolgerJust 在 cmets 部分中指出的那样，Chef 11 将尝试运行延迟通知，但这仍然不能保证 Chef Client 的操作。

此外（以及此处关于 Promise 的真正要点）是，Chef 仅在资源报告它已被最后一个操作更新时才会触发通知。考虑：

user 'sethvargo' do
  # ...
  notifies :restart, 'service[tomcat]'
end

# ...

service 'tomcat' do
  action :nothing
end

第一次执行此运行时，它将创建名为“sethvargo”的用户，该用户会将:restart 操作发送到 tomcat 服务。但是，在后续运行中，用户“sethvargo”已经存在，因此不会触发通知。

在您的特定示例中，如果s3_file 报告其上次操作未更新（也就是未更改系统状态），则通知不会触发。这似乎并不可怕，直到我告诉您 updated_by_last_action 是 cookbook 开发人员 必须代理的属性。此外，这是许多社区食谱过去没有设置的属性。 s3_file 资源很可能没有正确记录其状态，因此不会触发通知。

最后一点：

删除Chef::Config[:file_cache_path] 可能是个坏主意。如果您需要删除特定文件，只需删除该文件即可。或者告诉 Chef 不要在您的资源上使用 backup false 备份文件。

【讨论】：

Chef 11 仍会尝试在运行结束时执行计划的延迟通知，即使发生异常也是如此。因此，延迟通知实际被安排应该总是运行。您后面的观点仍然适用，因此 +1。
@HolgerJust 它尝试这样做，但系统不保证（即它不是客户的承诺）。但你的观点仍然有效。我将通过澄清更新答案。
好吧，它会捕获任何异常并仍然运行通知的资源。这应该得到保证。 attempt 的限制是调度的资源更改当然可能在执行期间由于任何原因而失败。也就是说，据我了解，应该始终执行每个预定的通知。如果我对此功能的概念不正确，您是否有指向解释该行为的一些深入文档的链接？
如果延迟通知失败，进一步延迟通知也会失败。因此异常处理发生在 CCR 周围，而不是 per 延迟通知。这有意义吗？
@sethvargo 关于备份错误的问题。快速谷歌搜索仅显示备份是 cookbook_file 资源的一部分。我是否遗漏了什么，或者这是我唯一可以停止备份的地方？

【解决方案2】：

对于 vagrant chef_solo 供应商，如果执行“vagrant up”、“vagrant provision”、“librarian-chef update”，重新启动 vagrant 供应阶段的预期方法是确保厨师/缓存拥有最新的食谱”、“无业游民”？

我看到厨师/缓存在“流浪供应”请求之间持续存在，即使食谱的内容和元数据由于图书管理员更新而发生变化。

解决方法是进入机器并删除遗留的厨师目录。这很尴尬。

【讨论】：