- From: "John E. Vincent (lusis)" <
>
- To:
- Subject: [chef] Re: Ad-hoc tasks and ad-hoc sources
- Date: Thu, 1 Mar 2012 23:23:08 -0600
- Authentication-results: mr.google.com; spf=pass (google.com: domain of
designates 10.216.132.32 as permitted sender)
; dkim=pass
On Thu, Mar 1, 2012 at 10:50 PM, Three Tee
<
>
wrote:
>
Are there any best practices that have emerged around executing ad-hoc tasks
>
via Chef? A use case that seems to come up often for me is performing code
>
deployments using the application cookbook without executing any other
>
configuration tasks that would usually be executed by the run_list. I
>
understand that with Chef one typically considers a deployment to be
>
inclusive of the prerequisite package installations, etc., but humor me for
>
a bit. :)
>
>
Anyway, a couple of ways that I thought the above might be handled are to
>
either set the run_list on the fly prior to the chef-client run, or to
>
execute chef-client on the target nodes with the -j option, passing it an ad
>
hoc run_list in the JSON. The former would require the previous run_list to
>
be saved, then restored after the chef-client run (assuming it is
>
successful). The latter appears to set the run_list on the Chef server after
>
the chef-client run. Both options seem to make it difficult to use the
>
nodes' run_list settings on the Chef server as a source of truth for a
>
node's function, so I'm not really happy with either one.
>
>
I'd love to hear how you all have handled the above problem. Or maybe I'm
>
just looking at this the wrong way? In any case, thanks in advance for any
>
advice.
This may come out the wrong way but....you're looking at it the wrong
way. Two things:
1) The Chef application cookbook is opinionated.
2) Client runs are idempotent
Pretty much it boils down to this. If you don't trust your client run
then you shouldn't be using the application cookbook. If you trust
your client run, the only penalty from using the application cookbook
is dealing with its opinions and the fact that will take a little
longer than had you just run the application cookbook.
If the problem is time it takes to deploy then stop using the
application cookbook. If the problem is that you "might lose changes",
then you've got a more fundamental problem.
The main reason I don't/have never used the chef-client run is that I
didn't like its opinions. That doesn't mean there isn't something to
learn from it. At the previous gig, we did all deploys via jenkins.
Worked fine for us.
However if you're insistent on trying to run JUST the application
cookbook, you can either use chef-solo or you can jump through the
hoops you mentioned. However if you use chef-solo, you've now got to
build data bags that have all the information that you might need from
searches.
Archive powered by MHonArc 2.6.16.