I’m currently maintaining a couple of small (<25 nodes) knife-solo and knife-zero setups.
Typically the setups are too small to run a traditional chef-server setup, also the owners don’t want to rely on third party services (data protection, latency) - so hosted chef is not a solution.
Recently I’ve re-evaluated the current state of chef-provisioning and it looks way better than a couple of months ago. However I’m not sure how this is meant to replace the “knife-*” solutions out there: While setting up a couple of machines with attributes/run-list is very nice using the Chef-Provisioning Chef-DSL, my customers usually don’t want to (re-)converge all nodes but run chef-client explicitly on one (or more) nodes.
Example provisioning recipe: https://gist.github.com/rmoriz/f293ca1402591c5469ae
I can run “bundle exec chef-client -z provisioning/test.rb” and the instances will be provisioned, bootstrapped and converged. awesome!
But how do I later use chef-zero to converge e.g. only the nginx node? When I re-run the recipe, all nodes will be converged.
As far as I understand, I could add some attributes or even (ab)use local environment variables to execute only specific resources of the chef-provisinioning cookbook, but I’m sure this is not the right way to do it, right?
A “one node per recipe”-approach seems to be very non-DRY to me and breaks all the nice “10.times do |i| … end” examples to create a bunch of identical nodes.
I’m missing something like knife-zero in the mix, unfortunately it currently use a different port for knife-zero forwarding which currently makes it incompatible.
Any hints? Thanks