So why not
schedule a chef-client run with a specified recipe to be executed?
IMO,
the problem with tools like Ansible is that they don’t force you to
re-think your approach to solving problems, as you try to scale up. You
still think of it as shell scripts and ssh to run those scripts.
From
the perspective of managing scalable systems, you really do want to
define what you want the overall system to look like, and then you need
to let the system maintain itself. Don’t ssh out to a bunch of machines
to run a shell script to edit files in place, because you’re already
starting from an unknown state that just takes you one step further down
the line of being further and further un-maintainable.
Instead,
take files that are properly version controlled and push them out and
replace whatever might be present that doesn’t match what’s in your
known good copy of the file from your version control system. And if
you do actually need to make changes to what configuration gets put on a
given server, then make sure that you properly version control the file
and the code that makes that happen.
Chef doesn’t completely
and totally force you to work this way, but this is the easiest way to
do things in Chef, and that’s a part of what makes it more scalable.
I’m
getting involved in a Puppet job for a customer, and while there are
some things that I am finding I like about being able to easily apply a
puppet manifest locally to a vagrant VM, I am now starting to have some
questions. Like, I have no idea whatsoever how to take what I’ve done
with local manual operations that amount to “puppet module install
xyzzy” and “puppet module install dependency” followed by “puppet apply
xyzzy/manifests/init.pp” and take that to the next level of being able
to automatically apply that process to nodes as they are created.
Thanks Steven (and Hi!) I
saw the video, but there isn't a comparison to ssh that I remember
(maybe I should watch it again). I was sold on pushy being the next
awesomeness, but now that I'm playing with it... it just looks like
another ssh client (yes I know it's not using ssh at all) with some
additional easy-to-use controls and reporting.
The video appears aimed at showing that the technology works as opposed
to presenting use cases in which it is superior to other solutions. When
is pushy better than knife ssh or an ssh call integrated into a recipe?
My expectations for pushy were a little more lofty, I guess. I was
hoping for more integrated orchestration, the ability to run a single
recipe on a system as opposed to just running chef-client to get
everything (so I guess something more like ansible, but integrated into
Chef). Something like: "push out THIS change" as opposed to "sync all
changes now".
So.. all that said -- this isn't intended to be a critque of push; I
honestly think I'm missing something somewhere along the line.
(on a side note, doesn't Chef already use rabbitmq?)
-Eric
One of the big benefits is
speed.
Knife ssh uses a parallel ssh method. Chef push jobs use
a message bus ( zeromq I believe ).
Here's a video that
demonstrates the push job feature:
https://m.youtube.com/watch?v=yHub6E4DNvgI
also believe that push jobs are the way of the future over knife ssh.
-
sh