Service 是否可以使用puppet通知其他主机上的服务？

我有一个傀儡模块，用于主机1进行一些文件交换

是否可以将主机1上的更改通知主机2上的另一个傀儡代理（即使用notify）

如果可能的话，最好的做法是什么

类文件交换主机1{
文件{'/var/apache2/htdocs'：
确保=>目录，
来源=>”puppet:///modules/${module_name}/var/apache2/htdocs“，
所有者=>'root'，
组=>“根”，
recurse=>true，
清除=>true，
force=>正确，
notify=>Service['restart-Service-on-host-2']，
}
}

Puppet无法直接从一台主机的清单中通知另一台主机上的服务

也就是说，你能用这个吗？我们将导出的资源与Icinga一起使用，因此一个主机为自己生成Icinga配置，然后将其导出到Icinga服务器，该服务器将重新启动守护进程

例如，在客户端主机上：

@@file { "/etc/icinga2/conf.d/puppet/${::fqdn}.conf":
  ensure  => file,
  [...]
  tag     => "icinga_client_conf",
}

在主主机上：

File <<| tag == "icinga_client_conf" |>> {
  notify  => Service['icinga2'],
}

文件{
notify=>Service['icinga2']，
}

---

在您的情况下，似乎没有导出资源，但这是否为您提供了构建所需功能的工具？

许多人都提出了这个问题，并且在不同的时间都在谈论实现一个功能以使其成为可能。但这是不可能的，也不可能很快实现

出口资源被认为是解决类似问题的早期解决方案，尽管一些人（例如）认为这不是一个好的解决方案，我不认为现在经常使用出口资源

我认为，现在推荐的方法是保持简单，并使用类似于在节点A上然后在节点B上依次运行命令的方法

---

如果不是Puppet Bolt，您也可以使用McCollective的后继者，甚至是负责人。

您可以使用Orchestrator和任务/计划来执行此操作，但该方法也必须位于目录之外。导出资源可以允许在收集该资源的节点上对其进行管理。这确实可以触发收集节点上其他资源的信号，但我不认为这适用于OP的情况，因为要克服的关键问题是，要管理的文件和应该通知的服务位于不同的节点上。你是说OP会导出某种只用于触发通知的虚拟资源吗？没错，John。一个虚拟资源就可以做到这一点。我在一定程度上希望原始海报实际上有一些隐藏的配置，这些配置正在使用一些非木偶方法“导出”，并且所有这些都会到位……多亏了你们两位，我想我知道了如何使用它。我将尝试使用文件夹的md5校验和创建一个资源。这将是我的出口资源。我将在第二台主机上收集该校验和，并将其与旧主机进行比较。如果它改变了，我将重新加载服务。@DschungelRatte听起来像个计划。我要指出的是，您不需要比较校验和-Puppet将发现文件内容的差异并启动服务通知，而无需您做任何事情。