General discussion about Chef

[chef] Re: Re: Push jobs vs SSH


Chronological Thread 
  • From: Eric Horne < >
  • To:
  • Subject: [chef] Re: Re: Push jobs vs SSH
  • Date: Sat, 07 Feb 2015 06:06:47 -0800
How do you schedule a chef-client run without logging into the box to schedule it (.. because if you have to log into the box, you may as well just run it yourself at that point).

The thought around using knife ssh was to launch chef-client with it.. not to abandon chef altogether with scripts.

A question remains, though. How do people in the real world use chef push to orchestrate a change among different servers with different roles?

Slightly off topic here.. My thinking right now is to control releases with attributes assigned to either nodes or environments and node tags. This way chef-client can just run and install what is desired for the node and still support the A/B testing we do in production. Hosts foo001-010 get version 2.5 and foo010-019 get 2.6. Push! The only problem there is setting the variables for each node. hmm.. I wonder if I could use a databag and a version matrix.  anyway.. back on topic.

-Eric

" type="cite">
" photoname="Brad Knowles" src="jpgwYiE6ldWw1.jpg" name="postbox-contact.jpg" height="25px" width="25px">
Friday, February 06, 2015 2:54 PM

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.

" photoname="Eric Horne" src="jpgRnV_liKnTK.jpg" name="compose-unknown-contact.jpg" height="25px" width="25px">
Friday, February 06, 2015 7:45 AM
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

" photoname="Hajducko, Steven" src="jpgOy1p2dpeqf.jpg" name="postbox-contact.jpg" height="25px" width="25px">
Friday, February 06, 2015 7:10 AM
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=yHub6E4DNvg

I also believe that push jobs are the way of the future over knife ssh.

-
sh


" photoname="Eric Horne" src="jpgRnV_liKnTK.jpg" name="compose-unknown-contact.jpg" height="25px" width="25px">
Friday, February 06, 2015 5:34 AM
What's the difference between chef push jobs and knife ssh?

I'm researching a use case for chef in which we want highly controlled deployments to orchestrate across several different systems. The traditional "pull" doesn't fit the bill well because it is difficult to get that to coordinate properly across systems.

From what I've read so far, chef push jobs are essentially a daemon running on the remote servers that allow arbitrary (but pre-defined/whitelisted) execution of commands. Aside from perhaps a cleaner white-listing concept (over forced-ssh), how is this different (better) than just using knife ssh?

I'm failing to see the benefits or use cases of chef push jobs over knife ssh. The documentation is lacking in terms of how it is intended to be used. Are push jobs better suited for different situations (and what are those situations?)

Thanks for the help!

-Eric

Archive powered by MHonArc 2.6.16.

§