-1

We have a set of Chef servers whose node data we integrate with data outside of Chef. Currently we use a batch sync process to read nodes out of Chef and then push the data into the data integration system. We run this every hour, and so far it works fine.

My question is whether Chef supports a more real-time mechanism for getting at this data. Ideally I'd like to get the change--such as a new node appearing or being removed--more or less immediately after it occurs, decreasing the lag and also eliminating the big batches. Does Chef server publish notifications? (I don't see anything about this here.) Or would one handle this client side (chef-client)? Are there other approaches I'm not considering?

EDIT: I'm talking specifically about node data. I do

GET /nodes

to get the node->URI hash, and then

GET /nodes/:name

to get the individual node data. It's a huge amount of data coming back though, so it would be great to take advantage of some kind of push mechanism if it exists. I'm doing this because I want to integrate this data with other service data (e.g., service dependency data, farm data, load balancer rotation states, etc.) that lives outside of Chef.

  • It's a bit unclear what your "data" is about (still I think that the one who voted -1 should have left some comment..). On the one hand, you can use a [chef report handler](http://docs.chef.io/handlers.html) that is executed at the end of the Chef run to do arbitrary things. For "real-time config mgmt", chef is not the ideal solution, maybe look at etcd, zookeeper, consul - or be a bit more specific on your use-case. – StephenKing Dec 15 '14 at 07:27
  • Thanks for the feedback. I added some more information to explain. –  Dec 15 '14 at 07:49
  • So you want a simple notification after each chef run, or the list of changed attributes (plus their new value?)? – StephenKing Dec 15 '14 at 19:53
  • Even a simple notification would be fine, such as "this node was created" or "this node was updated". I can just query for the new node. Prefer server-side notification, but I don't think it exists. (At least not without something like Chef Guard.) Happy to hear about any reasonable option though, including client-side. –  Dec 15 '14 at 20:00
  • I'd even settle for "something happened to this node". :-) –  Dec 15 '14 at 20:07
  • Then implement a custom report handler that runs after the chef run and sends just a notification to the other system (we're doing this [here for monitoring chef runs](https://github.com/StephenKing/chef-zabbix-custom-checks/blob/master/templates/default/chef-client/chef-client-handler.rb)). You could also only send a signal, if >0 resources were changed. Maybe, you can even figure out, what attributes were changed. – StephenKing Dec 17 '14 at 08:08
  • Thanks Stephen. Consider posting it as an answer so I can upvote. –  Dec 17 '14 at 18:06

2 Answers2

0

I don't think Chef has any such mechanism built-in. However, you should look at Chef-Guard. Chef-guard acts almost like a proxy between your nodes/workstation and the chef-server. it implements the entire chef rest api, so you can hit it as if it were your chef server. However, it maintains a github repo with all of your changes - in real time. It then forwards those changes over to the chef-server. You could do one of two things, depending on how ambitious you feel.

  1. You could fork chef-guard and replace the github integration with your own custom actions. (basically creating your own chef-server proxy with custom triggers built in)
  2. You could just use chef-guard out of the box, and then put triggers on the github repo (which supports custom triggers out of the box).

I realize both answers are a bit more effort than you'd hoped for, but they'll get you where you want to go.

Tejay Cardon
  • 379
  • 1
  • 4
0

You can use a report handler that runs at the end of the chef-client run and notifies your other system.

The run_status object contains some interesting information about the run, like run_status.updated_resources, which could make the notification dependent on if some resource was changed. If you are interested in the node's attributes, run_status.node contains the new attributes that you could POST via an HTTP request.

StephenKing
  • 952
  • 1
  • 8
  • 18