[chef] Re: Re: Re: Knife fundamentals (what did I miss?)

["John E. Vincent (lusis)" < >]

On Fri, Sep 16, 2011 at 9:01 PM, Maven User 
<
 >
 wrote:
> So there's no way to trigger a deployment from the webui?
> I'm asking because what we want to do is have say, jenkins, upload a package
> (I'm guessing I only need to define the cookbook once) then from the webui,
> tell chef which chef-clients it needs to deploy it to.
> For instance, one push to chef then allow users to select which environment
> that artifact should be deployed to (dev integration, then qa, then staging,
> then production).
> I _guess_ I could write a jenkins job that could sshexec the client call on
> the given node, but quite a few of the "nodes" are windows boxes.  Seems
> like a waste that the master server knows the agents and the agents know the
> master - too bad that same communication mechanism can't be used to trigger
> deployments as well.

I think there's a bit of confusion here. Remember that the Chef server
is designed to be as lightweight as possible. It's nothing more than
an API endpoint.

Node interaction (for lack of a better word) is done via knife (knife
ssh, bootstrapping). Additionally pretty much every single task for
managing your chef environment is also done via knife (it just makes
API calls to the chef-server).

As for "triggering deployments", yes, the normal path for continual
convergance is daemon mode on the client or a cron job. Combined with
a custom handler, you can keep up to tabs on the results of the runs.

If, for some reason, daemon mode or cron/task scheduler doesn't work
for you, you can use jenkins as you said. We actually have knife and
associated tools installed for our jenkins user with a custom set of
credentials. That allows our jenkins jobs to look up the current nodes
of role "foo" to install the "foo" app to for deploys (using a custom
knife script*). There's no reason you can't use "knife ssh" as a shell
step in your jenkins jobs.

If you wanted to get really fancy, you could call the server API
directly or even write a small listener that runs on the nodes and
accepts trusted "pings". Those pings trigger runs chef-client for you.
That can be triggered with the jenkins notification plugin. I wrote a
p.o.c. of that to test with Noah here:

https://gist.github.com/7cb3b37fa013fcb4ef6e

Chef isn't designed to be all encompassing. Think about the fact that
the chef-server has been rewritten in Python and other languages. It's
just an endpoint. Chef was designed to push as much work as possible
out to the edge. Contrast this with puppet which does that on the
server side. I'm not making value judgements on either approach. Just
explaining the differences.

There are 20 ways from Sunday to trigger convergence. Doing it FROM
the chef-server software package just doesn't happen to be one of
them.

* https://gist.github.com/e5c78ba10da7020a83ab