A Visual Introduction to Chef • Hacker News Board

Re: A Visual Introduction to Chef

#11

Post by Woost » Sat, Sep 10, 2011, 12:32 AM UTC

jsdalton wrote: post #2

What's the current sentiment on Chef vs. Puppet these days?

I recently (past couple of months) had to look at chef vs puppet. I went with Chef, since it seemed easier to setup, and I liked the methodology behind it better. That said, there are a few issues around its choice of dependencies (solr, how I hate you).

Basically, I liked how chef treated the terminals as "dumb" and the configuration could be stored in source control. All of my nodes/"cookbooks"/recipes/users/data bags are stored in version control, with a few simple shell scripts to batch load the data. Also, chef nodes ping back to the server, which could cause problems (if you had tens of thousands of nodes hitting frequently), but also solves issues like "what if a server is offline when an important update should be pushed"

I believe that puppet has far more tools for seeing what's going on with your servers, when they last updated, that kind of thing. Also, the recipes/cookbooks you can get from the chef repository can be a little hit and miss (I had to heavily modify a few to make them work in my environment)

Re: A Visual Introduction to Chef

#12

Post by omarqureshi » Sat, Sep 10, 2011, 12:33 AM UTC

gchpaco wrote: post #7

jsdalton wrote: post #2

What's the current sentiment on Chef vs. Puppet these days?

Chef is a nice idea written by people who don't understand Unix. (evidence? check out popen in their source, try to figure out why subprocesses occasionally get SIGPIPE, and then grep to see where it's used and count the file handle leaks. I've had to reimplement that six or seven times and theirs was the one with the most subtle errors. Yes, I'll submit a patch when I have time, which at the current rate the day job…

For puppet, so long as the service that you have has a stop and start setting (i've not come across one that doesn't) and you've told the service to subscribe to a file for changes - then it should automatically do a stop+start at the very least.

Re: A Visual Introduction to Chef

#13

Post by arckiearc » Sat, Sep 10, 2011, 1:19 AM UTC

jsdalton wrote: post #2

What's the current sentiment on Chef vs. Puppet these days?

Once you get rolling with Chef or Puppet, updating your servers feels great - no need to manually fiddle with shell scripts, or wonder "have I installed that package on all my machines?"

Getting to that point can take quite a bit of effort though. In my most recent attempt to install a Chef server on a fresh Ubuntu box, I quit the installation halfway through as I realised I wanted to change some of the values I'd entered into the setup script. After re-running the script I encountered errors, and all my attempts at scrubbing the aborted installation failed. It was easier to just start with a fresh image. I had these sorts of experiences all the time when using Chef and Puppet, they were really frustrating to setup.

I felt more comfortable writing my scripts in Chef because it didn't limit my ability to use Ruby, and the more relaxed approach to handling dependencies suited me. Puppet was easier to setup, had better documentation, and behaved more reliably for me. Neither seems like a clear winner, but I haven't spent a lot of time with them in about a year now, so things may have changed!

Re: A Visual Introduction to Chef

#14

Post by mattdeboard » Sat, Sep 10, 2011, 2:59 AM UTC

vegardx wrote: post #9

Superb! I've recently started with Chef and the learning curve is very high, especially if you're like me and haven't touched Ruby before.

Ditto, but I switched to learning Puppet tonight and I find it much easier to pick up.

Re: A Visual Introduction to Chef

#15

Post by patrickgzill » Sat, Sep 10, 2011, 3:06 AM UTC

What is the difference between capistrano, Chef, and Puppet?

Re: A Visual Introduction to Chef

#16

Post by abscondment » Sat, Sep 10, 2011, 3:57 AM UTC

patrickgzill wrote: post #15

What is the difference between capistrano, Chef, and Puppet?

High level:

Capistrano is a tool for deploying your applications. You use it to push out new versions of your own codebase.

Chef and Puppet are tools for provisioning/configuring servers. You use it to install the right third-party libraries, programs, config files, etc.

Re: A Visual Introduction to Chef

#17

Post by mkent » Sat, Sep 10, 2011, 5:16 AM UTC

mattdeboard wrote: post #14

vegardx wrote: post #9

Superb! I've recently started with Chef and the learning curve is very high, especially if you're like me and haven't touched Ruby before.

Ditto, but I switched to learning Puppet tonight and I find it much easier to pick up.

Puppet is definitely easier to start with but any ruby you pickup in learning Chef is useful in more general sense, while time spent on the puppet dsl is only good for using puppet.

Re: A Visual Introduction to Chef

#18

Post by mkent » Sat, Sep 10, 2011, 5:27 AM UTC

Woost wrote: post #11

jsdalton wrote: post #2

What's the current sentiment on Chef vs. Puppet these days?

I recently (past couple of months) had to look at chef vs puppet. I went with Chef, since it seemed easier to setup, and I liked the methodology behind it better. That said, there are a few issues around its choice of dependencies (solr, how I hate you). Basically, I liked how chef treated the terminals as "dumb" and the configuration could be stored in source control. All of my nodes/"cookbooks"/recipes/users/data b…

Puppet also supports a 'dry run' mode to give you an idea of what changes would have been applied during a run - something Chef is lacking and definitely makes installing Chef on an already functioning machine a very scary proposition.

The built in reporting in Chef isn't very useful and the web ui is pretty light, but there's at least hooks and examples on how to extend it to meet your requirements.

Most of the Chef development so far appears to have been focused on core features and most recently a simplified installer - hopefully reporting will become a focus as the product matures.

Re: A Visual Introduction to Chef

#19

Post by patrickgzill » Sat, Sep 10, 2011, 7:39 PM UTC

abscondment wrote: post #16

patrickgzill wrote: post #15

What is the difference between capistrano, Chef, and Puppet?

High level: Capistrano is a tool for deploying your applications . You use it to push out new versions of your own codebase. Chef and Puppet are tools for provisioning/configuring servers . You use it to install the right third-party libraries, programs, config files, etc.

I will have to look at it more. I have found "using capistrano for system administration" articles however.

Re: A Visual Introduction to Chef

#20

Post by bradleyland » Sat, Sep 10, 2011, 10:15 PM UTC

patrickgzill wrote: post #19

abscondment wrote: post #16

Earlier quoted context omitted.

High level: Capistrano is a tool for deploying your applications . You use it to push out new versions of your own codebase. Chef and Puppet are tools for provisioning/configuring servers . You use it to install the right third-party libraries, programs, config files, etc.

I will have to look at it more. I have found "using capistrano for system administration" articles however.

This is because the tasks involved with deploying applications and system administration have some significant overlaps. Capistrano is, essentially, a tool layer atop Net::SSH that can execute actions on a server, based on definitions written inside the framework provided by Capistrano. Capistrano was originally written for application deployment, but it wouldn't be "wrong" to use it for system administration. Sprinkle (a software provisioning tool) [1] is built on top of Capistrano.

1 - https://github.com/crafterm/sprinkle