シェフのサービス再開のメカニズム

Question

シェフの再開メカニズムがどのように裏で働いているかについての説明を探しています。私はオンラインでそれに関するドキュメンテーションを見つけることができず、コードをトレースしようとしています（トリガーは遠く離れているようなアクションです）。

具体的にはnginxを見て、私たちはシェフサーバーを使用していて、chef-soloではないと仮定します（違いがあるかどうかはわかりません）。

私はこの（例えば）を持っているレシピに：

template '/etc/nginx/nginx.conf' do 
    source 'nginx.cfg.erb' 
    owner "root" 
    group "root" 
    mode 00755 
    notifies :reload, "service[nginx]", :delayed 
end 

notifies :reloadビットは、リロードをトリガー意味し、:delayedは、それがchef-client実行の終了時に起こることを意味します。それはどのように舞台裏で機能しますか？実行スレッドの後に問題があります。

どこかchef-clientは、service nginx reloadまたはその行に沿って何かを実行する必要があります。それはどこにどのように定義されていますか？

Answer 1

notifiesは、別のシェフのリソースに何かを行うように通知します。

この例では、リソースservice[nginx]を:reloadに伝えています。 service[nginx]はservice resourceであり、nameはnginxです。

これを行うには、ノードrun_listでservice[nginx]がある時点で宣言されている必要があります。さもなければ、シェフはエラーを投げます。通常、これはユーザーがレシピで手動で行うか、または依存関係（application、またはnginxのクックブックなど）を介して行われます。

シェフがreloadコマンドを実行する正確な方法は、service[nginx]リソースがどのように宣言されたかによって異なりますが、通常、このようなツールを使用することの美しさの1つです（下位レベルの詳細離れて複数のプラットフォームで同じコードを使用することができます）。

serviceドキュメントの構文セクションでは、あなたがこれを見つける：

• サービスはシェフ・クライアントの実行中に、次のプロバイダのいずれかを使用するシェフ、クライアント伝えます：Chef::Provider::Service::Init、Chef::Provider::Service::Init::Debian、Chef::Provider::Service::Upstart、 Chef::Provider::Service::Init::Freebsd,Chef::Provider::Service::Init::Gentoo,Chef::Provider::Service::Init::Redhat,Chef::Provider::Service::Solaris,Chef::Provider::Service::WindowsまたはChef::Provider::Service::Macosxである。シェフクライアントは、Ohaiによって収集されたデータに基づいて、実行の開始時にプラットフォームを検出します。プラットフォームが特定されたら、シェフクライアントは正しいプロバイダを決定します

Answer 2

機能は、chef docoに記載されています。

設定ファイルの内容が変更された場合、これはnginxサービスのリロードをトリガーします。 「遅延」設定は、シェフ実行の最後に再ロードアクションが発生することを意味します。シェフの実行によっていくつかの設定ファイルが変更される可能性があり、変更された各ファイル（「即時」オプション）ではなく、最後に1回のリロードが必要なことが考えられます。