Chef infra 围绕厨师长的系统单位资源开展工作

允许您通过采用字符串或哈希的内容属性指定服务文件。这两种想法都让人觉得是一个令人讨厌的坏主意；他们的例子是：

systemd_unit 'sysstat-collect.timer' do
  content <<-EOU.gsub(/^\s+/, '')
  [Unit]
  Description=Run system activity accounting tool every 10 minutes

  [Timer]
  OnCalendar=*:00/10

  [Install]
  WantedBy=sysstat.service
  EOU

  action [:create, :enable]
end

这感觉很不对。。。混合我的厨师食谱，什么应该只是一个配置文件或模板文件。我尝试过各种方法，尝试使用cookbook_文件将文件写入我的目标，然后将其读回以传递给内容，但这也让我感到不满意，到目前为止还没有奏效

编辑以提出希望更好的问题：

---

是否有某种机制可以使用chef systemd资源，这样我就不会将配置文件作为字符串嵌入配方文件本身？

您可以使用类似于template/etc/systemd/system/{unit_name}do的东西。。。结束并通知守护进程重新加载。

当我第一次开始使用systemd_单元时，我的想法大致相同，但现在我对它的看法有所不同。我不保留JSON、YAML或TOML配置文件作为模板，因为它们可以从属性哈希生成。这确保了它们在语法上是正确的，并且更改属性比更改cookbook文件更灵活。单位是INI格式的文件，所以我以同样的方式处理它们

但有时，您只需要读取文本文件并将其传递给资源。我确信这种方法可以改进，但它确实有效

unit_temp_path = "#{Chef::Config[:file_cache_path]}/foo.service"

cookbook_file unit_temp_path do
  action :create
end

systemd_unit 'foo.service' do
  # delay reading until convergence phase
  content lazy { ::File.read(unit_temp_path) }
  action :create
end

---

我不确定OP面临的两个问题中的哪一个：

未将原始字符串放入systemd_单元 systemd_单元在设置不是.service的单元时行为不正常 我在使用Chef13上的systemd_unit资源用于非计时器和非服务单元时遇到问题。具体来说，它似乎讨厌.network和.netdev，这迫使我使用链接到某个东西的模板_文件，该文件将在以下情况下调用systemctl daemon reload：/

至于不将原始字符串放入systemd_单元，下面的示例可能会有所帮助

systemd_unit 'portage-sync.timer' do
  verify true
  content(
    Unit: {
      Description: 'Timer to synchronize portage tree',
    },
    Timer: {
      OnCalendar: '*-*-* 12:00:00 UTC',
      Persistent: true,
      RemainAfterElapse: true,
      Unit: 'portage-sync.service',
    },
    Install: {
      WantedBy: 'multi-user.target',
    },
  )
end

---

我是否正确地理解了您的方法只是绕过使用chef systemd_单元资源，而只是放下文件并执行重新加载守护进程的命令？是的。该资源并没有考虑到烹饪书的内容，因为Facebook更愿意在可能的情况下不使用它们。更容易查看单个代码文件。