Continuous deployment & Orchestration with Chef

Question

I'm looking into ways of deploying my application (web / DB / application tier) across multiple hosts while utilizing Chef. What I've come up with is using Chef recipes to represent each step of the deployment as an individual node state. For example if there is a step that handles the stopping of X daemons & monitoring, it could be written as a chef recipe that simply expects the specific X daemons to be stopped. In the same way, the deployment step that moves an artifact from a shared location to the web root could also be referenced as a chef recipe that represents that specific state of the node (having the artifact copied from point A to point B).

The whole deployment process will consist of various steps that basically do these three things:

1. Modify the run list of the nodes depending on the current deployment step.
2. Have chef-client run on each node
3. Log any failures and allow for a repeat of the chef run on the failed nodes or the skipping of the step so the deployment can continue.

Questions:

• Is using Chef in such a way (constantly modifying the run list of my nodes in order to alter the node state) a bad practice? And if so why?
• What are the best ways to orchestrate all this? I can use any kind of CI tools there, but I'm having trouble figuring out how to capture the output of chef-client and be able to repeat or ignore the chef-client runs on specific nodes.

Answer 1

This is really not the kind of thing Chef is best for. Chef excels at convergent configuration, less so with the procedural bits. Use Chef for handling the parts where you do a convergent change like deploying new code or rewriting config files, use a procedural tool for the other bits.

As for tools to coordinate this, RunDeck is one choice if you want something more service-y. If you want a command-line tool look at Fabric or maybe Capistrano. Personally I use a mix, RunDeck plus Fabric to get the best of both. Some other less complete options include Chef Push Jobs, Mcollective, and Saltstack.

Answer 2

Puppet and Chef are not orchestration tools and they do a very bad job from this perspective. They were not designed to be orchestration and even though some parties with specific interests are pushing the boundaries of the definition of orchestration to get Chef to be considered for orchestration, they are ignoring critical facts/needs. Unfortunately, I am not aware of a single serious solution for orchestration of large environments - most of the tools are quite specific to some needs and some are really not production ready yet. I had to invent my own workarounds to get this done but there was nothing elegant in doing so.