Hi -
I’ve got several functioning chef-provisioned and deployed
systems/applications, and am only now getting round to worrying about
automatic updates/deployment. (Up to now have been running knife ssh “sudo
chef client” as needed).
The most obvious thing (and lightweight) that I can do is to add to one of
my recipes a cron resource to sudo chef-client every 30 minutes. However I
notice that there’s a chef-client cookbook with recipe for running it as
service.
Is there a strong reason for running chef-client as a service rather than a
cron? The chef-client cookbook’s README encourages me to delete the
validation before installing chef-client. Why would I want to do that?
There’s also a client_service recipe within the chef cookbook as well.
Options, options. Any pointers?
thanks
Tim
–
Tim Diggins
http://red56.co.uk
On Fri, Apr 8, 2011 at 11:42 PM, Tim Diggins tim@red56.co.uk wrote:
Is there a strong reason for running chef-client as a service rather than a
cron? The chef-client cookbook's README encourages me to delete the
validation before installing chef-client. Why would I want to do that?
There's also a client_service recipe within the chef cookbook as well.
Options, options. Any pointers?
We've just added a feature in 0.10 [1] so if you were running
chef-client as a daemon, you could run "knife ssh SEARCH sudo killall
-USR1 chef-client" to trigger a client run. If the client is already
in a run, it runs again when finished. If you were running in cron, it
is up to you to manage locking so multiple chef-clients do not run at
once.
The validation key allows the registration of additional clients. By
deleting it, you gain a little additional protection from a malicious
user. The client recipe used to be managed in the chef cookbook, but
because we only ship cookbooks to systems when required now, the
client code was forked into its own cookbook.
Bryan
[1] http://tickets.opscode.com/browse/CHEF-1761
On Sat, Apr 9, 2011 at 12:00 AM, Bryan McLellan btm@loftninjas.org wrote:
On Fri, Apr 8, 2011 at 11:42 PM, Tim Diggins tim@red56.co.uk wrote:
Is there a strong reason for running chef-client as a service rather than a
cron?
in a run, it runs again when finished. If you were running in cron, it
is up to you to manage locking so multiple chef-clients do not run at
once.
Note the client daemon implements splay in addition to an interval
between chef runs to reduce the thundering herd effect on the server.
If you go the cron route, you'll want to mimic this behavior as well.
I'd say just use the daemon unless it somehow consumes a non-trivial
amount of system resources while sleeping, and even then, just log
that as a bug.
I dunno if anyone's had to do this with Chef but in the Puppet world
the folks I know that stopped using the daemon did so only because
they needed to switch to centrally orchestrated runs (via
mCollective).
KC