通知包含的LWRP配方中定义的服务 [英] Notify service defined in included LWRP recipe

问题描述

是否有一种方法来通知服务重新启动（由包含的LWRP定义）？

Is there a way to notify a service to restart which is defined by an included LWRP?

我写了一个名为 sidekiq的LWRP来设置服务，

I wrote an LWRP called "sidekiq" which sets up a service, like this, and appears to be working fine on its own.

service "#{new_resource.name}_sidekiq" do
  provider Chef::Provider::Service::Upstart
  action [ :enable ]
  subscribes :restart, "template[/etc/init/#{new_resource.name}_sidekiq.conf]", :immediately
end

问题是我正在使用它另一个用于部署的配方，并需要它来通知LWRP中定义的服务。我目前有这样的东西

The problem is I am using it another recipe which I use for deployments, and need it to notify the service defined in the LWRP. I currently have something this

include_recipe "sidekiq"
deploy_revision my_dir do
  notifies :restart, "service[myapp_sidekiq]"
end

问题出在编译时，厨师看着这个食谱并给出错误

The problem is at compile time, chef looks at this recipe and gives an error

错误：资源deploy_revision [my_dir]配置为通过重启操作通知资源服务[myapp_sidekiq]，但service [myapp_sidekiq ]在资源集合中找不到。

ERROR: resource deploy_revision[my_dir] is configured to notify resource service[myapp_sidekiq] with action restart, but service[myapp_sidekiq] cannot be found in the resource collection.

我可以通过在部署配方中定义一个空服务来消除错误，例如服务'myapp_sidekiq'，在首次配置计算机时一切正常。但是，如果我运行部署并且sidekiq LWRP中没有任何变化，则myapp_sidekiq服务将永远不会重新定义，因此无法重新启动。

I can get rid of the error by defining an empty service in my deployment recipe, like service 'myapp_sidekiq', and everything will work fine when first provisioning the machine. However if I run a deployment and nothing changes in the sidekiq LWRP, the myapp_sidekiq service is never redefined and thus cannot be restarted.

推荐答案

要通知要完成操作的资源，必须先在当前的主厨运行，并且正如Tensibai指出的那样，在自己的 run_context

To notify a resource to complete an action, that resource must be defined previously in the current Chef run, and as Tensibai notes not defined inline in it's own run_context

简单的方法是在您的非默认提供程序的部署脚本中创建占位符，其作用为：没什么，但您可以稍后再通知。

The simple way is to create a place holder in your deploy script of your non default provider that has an action of :nothing, but you can notify it later.

service "myapp_sidekiq deploy notifier" do
  provider      Chef::Provider::Service::Upstart
  service_name  "myapp_sidekiq"
  action        :nothing
end

您还可以修改 client.rb 中资源的总体默认提供程序，如果您一直在使用Chef配置为其他内容的平台上使用Upstart，例如 systemd

You can also modify the overall default provider for a resource in client.rb if you are using Upstart all the time on a platform that Chef has configured as something else, like systemd

Chef::Platform.set :platform => :yours, :resource => :service, :provider => Chef::Provider::Service::Upstart

有 Chef 12中的更改，这将使Chef可以在运行时评估要使用哪个服务提供商，而不是静态配置。这基本上是由于systemd出现并在曾经非常稳定和易发生的系统上发生了一些变化。

There are changes coming in Chef 12 that will let Chef evaluate which service provider to use at run time instead of static configuration. This is basically due to systemd coming along and shaking up something on systems that was once very stable and predicatable.

请注意用于资源的名称。如果您通过相同的服务名称定义了多个服务资源，由于它们厨师将它们视为克隆，您可能正在运行某些意外的操作。如果您使用多个服务定义，请尝试为特定目的为它们命名一些独特的名称。然后在属性中，使用 service_name

Be careful of the name you use for resources. If you have multiple service resources defined via the same service name you can run into issues due to they way Chef treats them as clones and you may be running something you didn't expect. If you are using multiple service definitions try naming them something unique for the specific purpose. Then in the attributes, specify the service with service_name

如果您有重复定义的特别复杂的资源，并且您认为只应为其指定所有通用参数，则可以创建自己的轻量级资源和提供程序封装了所有通用设置，因此您可以在配方中更轻松地定义资源：

If you had a particularly complex resource that you are defining repeatedly and you think you should only be specifying all the generic parameters for it once, you could create your own Light Weight Resource and Provider encapsulating all the generic setup so you can define the resource more easily in recipes:

service_myapp_sidekiq "deploy notifier" do
  action      :nothing
end

service_myapp_sidekiq "config subscriber" do
  action      :nothing
  subscribes  :restart, 'blah'
end

就像您必须为要支持的每个基础操作创建LWRP 操作一样，并且如您所见，这并没有使您的用例容易得多。

That is a lot of work as you have to create an LWRP action for every underlying action you want to support and as you can see, doesn't make your use case much easier.

您也可以使用库，它定义了资源的基础，并允许您添加所需的任何自定义项（例如名称）。

You could also do the same sort of thing with a function in a library that defines the basics of the resource and allows you to add any of the customisations you want (like name).

def create_myapp_service name, action, options = {}
  s = Chef::Resource::Service.new "myapp service #{name}"
  s. service_name   "myapp_sidekiq"
  s.provider        Chef::Provider::Service::Upstart
  s.action          action
end

create_myapp_service "deploy", :nothing

同样，这些仅可能用于更复杂的资源设置以及您反复需要定义

Again, these are probably only needed for much more complex resource setups and cases where you repeatedly need to define the same complex resource with small variations.

TLDR ：定义占位符服务部署：没事。

TLDR: Define a place holder service which does :nothing for the deploy.

这篇关于通知包含的LWRP配方中定义的服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！