Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Puppet or Chef?

philsturgeon.co.uk

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Puppet or Chef?

#51

Post by themgt »

amalag wrote: post #48
themgt wrote: post #15

We started off writing the bulk of our server setup/deployment automation in chef, and have since completely abandoned it The core problems we had with chef were: • worse than ruby: the chef ruby DSL is like some bastardized, crippled ruby - e.g. ruby_block{}, just uggh • way too slow & resource intensive: chef itself uses a lot of memory and CPU, has a slow boot time, and does stuff like execute apt for each desired…

Using Heroku buildback means you have shifted to using Heroku instead of self hosting?

No, we've combined bits & bobs that Heroku has open sourced (check ddollar's repos on github) with our own Ruby/CoffeeScript/Lua/Bash glue on dedicated hosting. There's a single OS image and compiled binaries for software stored in Ceph's S3-compatible distributed storage, and everything else is applications and buildpacks stored in git

The build server takes URLs for an app and a buildpack, runs the buildpack to do any dependency fetching/compilation/etc, bundles up the output into a .tar.gz file that contains everything necessary to boot up on the standard LXC image, and uploads it into the distributed storage. Then when we want to boot 1 or 2 or 10 of that app, we just grab the gzipped "slug" and boot it up on an ephemeral LXC containers (i.e. a single base image + temporary overlay file system)

This system can build a rails web app, a node.js app, other services like mysql/redis/nginx, and even the build server itself

So the bootstrapping is a little tricky, but e.g. the process to run a build may go git -> api -> mysql/redis -> worker -> build server -> ceph/s3, and each of those pieces themselves is built/deployed/managed the same way, which we've found to be a huge win for maintainability

Re: Puppet or Chef?

#52

Post by Hontano »

VLM wrote: post #14
Hontano wrote: post #4

I never got on well with either. Puppet was mind-bogglingly slow (even locally without a master), both Chef and Puppet felt overwrought, and I prefer keeping dependencies to a minimum. Just a pointer for anyone else that doesn't have much love for either: I found myself happy and productive with Salt. Fast, simple, and lets me do what I needed with less Byzantine setup: http://docs.saltstack.org/en/latest/ There's al…

"I prefer keeping dependencies to a minimum." The job of an OS not a human admin. "apt-get install puppet" on the clients and "apt-get install puppetmaster" on the puppetmaster. That's about it. "Puppet was mind-bogglingly slow" Was it a pause exactly equal to one DNS lookup timeout? The SSL inside puppet used to get all wound up about reverse DNS matching the forward or whatever exactly. You need working DNS to pupp…

"The job of an OS not a human admin. "apt-get install puppet" on the clients and "apt-get install puppetmaster" on the puppetmaster. That's about it."

It might be a simple apt-get command, but consider setting up Chef Server. You're suddenly adding the following to your system: Ruby, CouchDB, RabbitMQ, Java, merb-assets, merb-core, merb-helpers, merb-param-protection, merb-slices, thin, solr-jetty. And then maybe libxml-ruby, merb-haml, haml, coderay. (From http://wiki.opscode.com/display/chef/Installing+Chef+Server)

That's a whole heap of stuff and moving parts I wasn't looking for. Compare that to the above mentioned Ansible or cdist on the lightweight end of the spectrum.

Re: Puppet or Chef?

#53

Post by Xylakant »

CoffeeDregs wrote: post #50
swalberg wrote: post #46

Earlier quoted context omitted.

One huge advantage that puppet and chef offer is abstraction from the underlying system. So if you write a configuration that says "Apache should be running, have PHP installed, and have the following 3 virtual hosts installed", then you don't care if you're running on Solaris, Debian, or CentOS. The manifest/recipe takes care of figuring out what the package is called and where the config files go. I'm not familiar…

then you don't care if you're running on Solaris, Debian, or CentOS. That does sound like an advantage, but I generally run the same OS across all machines (for a client), so that's not a huge advantage for me. Fabric seems more like SSH with a for loop. Definitely. And that suffices fairly well for managing 10-20 servers. if someone goes and changes a vhost file by hand, that file will be replaced with a good one an…

> Ah, so Puppet is running on a machine, it will maintain the configuration of the machine even if some well-intentioned user fiddles?

Yes, at least for all ressources under its control. So in theory all changes to ressources managed via puppet should be done via puppet. I guess that's better this way when you're running a large farm of machines, the use-case puppet/chef/etc. were created for.

Re: Puppet or Chef?

#54

Post by cdavid »

I have started using chef to automate build environments on top of vagrant. One thing that made me choose chef is windows support: chef uses winrm on windows, + things like powershell, and that seems to work better than puppet (e.g. I could not for the life of god make a unattended install of visual studio with puppet).

On the - sides, I don't find it particularly well documented (it feels like reading the MSDN, where things are self-referentials), and it is quite slow.

Re: Puppet or Chef?

#55

Post by stock_toaster »

themgt wrote: post #15

We started off writing the bulk of our server setup/deployment automation in chef, and have since completely abandoned it The core problems we had with chef were: • worse than ruby: the chef ruby DSL is like some bastardized, crippled ruby - e.g. ruby_block{}, just uggh • way too slow & resource intensive: chef itself uses a lot of memory and CPU, has a slow boot time, and does stuff like execute apt for each desired…

  >  what if you want your chef client to bootstrap with some custom rubygems?
knife bootstrap[1]?

[1]: http://wiki.opscode.com/display/chef/Knife+Bootstrap

Re: Puppet or Chef?

#56

Post by dikbrouwer »

themgt wrote: post #15

We started off writing the bulk of our server setup/deployment automation in chef, and have since completely abandoned it The core problems we had with chef were: • worse than ruby: the chef ruby DSL is like some bastardized, crippled ruby - e.g. ruby_block{}, just uggh • way too slow & resource intensive: chef itself uses a lot of memory and CPU, has a slow boot time, and does stuff like execute apt for each desired…

While I'm not a Chef fanboy, far from it, some of these comments are just not true.

"and does stuff like execute apt for each desired package on each node on each run". No you just need to set it up correctly so that it keeps the timestamp of the latest apt-get update, and does not refresh it within the next x hours.

"not self-hosted". Somewhat agreed, although you can easily get around this with the excellent https://github.com/tobami/littlechef

Re: Puppet or Chef?

#57

Post by benmccann »

CoffeeDregs wrote: post #41

Why not add: or Fabric or Ansible or something else? I haven't found much that Fabric won't do for me and I haven't found much reason to install Ruby on my system [Python is a system package]. For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?

I use Fabric to run Puppet. Setting up a puppet server is overkill for my small setup, but I found Puppet to be better suited to managing server configuration and more scalable should my number of servers continue to grow.

Re: Puppet or Chef?

#58

Post by CoffeeDregs »

account_taken wrote: post #45
CoffeeDregs wrote: post #41

Why not add: or Fabric or Ansible or something else? I haven't found much that Fabric won't do for me and I haven't found much reason to install Ruby on my system [Python is a system package]. For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?

Fabric + Cuisine is happy joy.

Thanks for the tip!

Re: Puppet or Chef?

#59

Post by atsaloli »

atsaloli wrote: post #43
jacques_chester wrote: post #10

I recently had occasion to look at Cfengine, Chef and Puppet. I chose Puppet. http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign... (scroll down if you don't enjoy my windbaggery). The short version is: Puppet best fits the way I think about how such systems should work. Despite ostensibly belonging to the same genre of system, the three of them have subtle but very important differences.

Could you elaborate about these subtle but very important differences, please?

I found the answer in the above referenced blog post.

(http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...)

Re: Puppet or Chef?

#60

Post by dredmorbius »

VLM wrote: post #14
Hontano wrote: post #4

I never got on well with either. Puppet was mind-bogglingly slow (even locally without a master), both Chef and Puppet felt overwrought, and I prefer keeping dependencies to a minimum. Just a pointer for anyone else that doesn't have much love for either: I found myself happy and productive with Salt. Fast, simple, and lets me do what I needed with less Byzantine setup: http://docs.saltstack.org/en/latest/ There's al…

"I prefer keeping dependencies to a minimum." The job of an OS not a human admin. "apt-get install puppet" on the clients and "apt-get install puppetmaster" on the puppetmaster. That's about it. "Puppet was mind-bogglingly slow" Was it a pause exactly equal to one DNS lookup timeout? The SSL inside puppet used to get all wound up about reverse DNS matching the forward or whatever exactly. You need working DNS to pupp…

What distro are you running that's got current Puppet/Chef releases in its archives?

The story may be better for puppet, but with chef, it's pretty much "off to the racetrack" to get the latest and greatest Ruby, Chef, and other deps installed.

Post reply on HN