Knife fundamentals (what did I miss?)

Chef Infra (archive)
1

Hi again all -

While I’m working through my knife/chef-client woes on windows, I’ve been
able to set up a few ubuntu vms (one server, one client).

Following the standard documentation, I have the communicating and can see
them both via the webui.

A few questions:

1 - How do you tell chef to apply/deploy the software? I updated the role
for the chef-client but I never saw it get applied. I had to restart the
chef-client service.
2 - If I have my own software, how does this get transferred up to the chef
server?

There’s a lot of implied things on the wiki for setting up both the client
and the server (and I think I fudged a few things to make it work for
myself).

Can I verify some feedback/changes here then update the docs?

2

On Sep 16, 2011, at 2:49 PM, Maven User wrote:

1 - How do you tell chef to apply/deploy the software? I updated the role for the chef-client but I never saw it get applied. I had to restart the chef-client service.

You re-run chef-client. If you've got it running every thirty minutes under cron, then it should auto-update within the next 30 minutes, one you upload the new cookbook or whatever. If you don't have some automated process that is firing off a new chef-client every thirty minutes (or whatever), then you'll need to manually re-run chef-client on that box.

2 - If I have my own software, how does this get transferred up to the chef server?

You need to build your own cookbook for that and upload it to the chef server. Assuming the new roles, etc... that you define for your own software are properly applied to the correct nodes, the next time they run chef-client, they should pick up the changes and do whatever you told them to do in the cookbook.

--
Brad Knowles bknowles@ihiji.com
Junior Apprentice Prep Cook Trainee

3

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.

On Fri, Sep 16, 2011 at 3:58 PM, Brad Knowles bknowles@ihiji.com wrote:

On Sep 16, 2011, at 2:49 PM, Maven User wrote:

1 - How do you tell chef to apply/deploy the software? I updated the
role for the chef-client but I never saw it get applied. I had to restart
the chef-client service.

You re-run chef-client. If you've got it running every thirty minutes
under cron, then it should auto-update within the next 30 minutes, one you
upload the new cookbook or whatever. If you don't have some automated
process that is firing off a new chef-client every thirty minutes (or
whatever), then you'll need to manually re-run chef-client on that box.

2 - If I have my own software, how does this get transferred up to the
chef server?

You need to build your own cookbook for that and upload it to the chef
server. Assuming the new roles, etc... that you define for your own
software are properly applied to the correct nodes, the next time they run
chef-client, they should pick up the changes and do whatever you told them
to do in the cookbook.

--
Brad Knowles bknowles@ihiji.com
Junior Apprentice Prep Cook Trainee

4

On Fri, Sep 16, 2011 at 9:01 PM, Maven User maven.2.user@gmail.com 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:

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.