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

61–70 of 71 posts

Re: Puppet or Chef?

#61

Post by stevekemp »

cmer wrote: post #27

For those looking for a dead simple alternative to Chef or Puppet, I wrote Shoestrap. It's a pure Bash, no-BS set of scripts. Doesn't have all the bells and whistles of Chef, but it might be enough for your needs. https://github.com/cmer/shoestrap https://github.com/cmer/shoestrap-example

I too wrote my own system - which uses Perl. Mine is called Slaughter and the upcoming 2.x release allows you to fetch policies/instructions from remote servers via one of:

* rsync * http * git clone * hg clone

etc. It is pretty extensible and covers my needs. Beyond that it is a little hard to know.

http://steve.org.uk/Software/slaughter/new.html for the upcoming 2.x release.

Re: Puppet or Chef?

#62

Post by Corrado »

The reason I chose Puppet was that it allows my servers to pull their configuration instead of my pushing it to them. This is important because my servers are all remote and behind firewalls that I don't control. Using Puppet, my servers can make an outbound connection to the Puppet Master without having to mess with firewall ingress rules.

Things like Salt or Fabric require direct access to the target servers and won't work in my situation. I'm not sure about how Chef works as it wasn't available (popular) when I was setting this up several years ago.

Re: Puppet or Chef?

#63

Post by thyrsus »

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.

I document my puppet configurations in Leo (http://webpages.charter.net/edreamleo/front.html) taking full advantage of Leo's ability to represent directed acyclic graphs natively.

There are lots of things I'd like to improve in Leo that involve chucking its current code base (e.g.: back end storage is XML and thus version control hostile; front end is not a web browser; acyclic should get dropped from "rooted, ordered, acyclic graph"), but until that bit of brilliance dawns over the world, I'll continue to use Leo.

Re: Puppet or Chef?

#64

Post by uggedal »

Corrado wrote: post #62

The reason I chose Puppet was that it allows my servers to pull their configuration instead of my pushing it to them. This is important because my servers are all remote and behind firewalls that I don't control. Using Puppet, my servers can make an outbound connection to the Puppet Master without having to mess with firewall ingress rules. Things like Salt or Fabric require direct access to the target servers and wo…

Salt can be used both in a pull or push fashion.

Re: Puppet or Chef?

#65

Post by uggedal »

mgarfias wrote: post #31

I pretty much hate puppet after 4 years of dealing with it. Scaling problems, having to run another bunch of crap to store configs, in an app that was designed to store configs. I'm getting all riled up just remembering the hell. Next time I get to pick, I'll use salt.

I migrated all my machines to salt 6 months ago after using Puppet for a few years. It's been pretty painless but I would check out Ansible also before commmiting to a Salt transition.

Re: Puppet or Chef?

#66

Post by mpdehaan2 »

swalberg wrote: post #46
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?

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…

Ansible is definitely model based (and idempotent, like Puppet or Chef), unlike Fabric.

The resource model was reasonably inspired by Puppets, even if other aspects were not.

I look at Fabric as a deployment tool, fine if you like it, but configuration management requires more things on top.

Re: Puppet or Chef?

#67

Post by gyepi »

Over the years, I've also used cfengine and a host of other systems and have decided that simplicity and the ability to customize a system to fit your needs are key. Turns out it's quite easy to roll your own, given the right tools. I now use:

gsl https://github.com/imatix/gsl and synctool https://github.com/walterdejong/synctool

The former is used to generate configurations for various classes of systems and the latter pushes them out over ssh. Works very well.

Re: Puppet or Chef?

#68

Post by jchonphoenix »

My first reaction to this was "Puppet must either have horrible documentation or be difficult to pick up."

I mainly gleaned this from him correcting himself about puppet all the time and took this to mean he had a harder time picking up puppet.

Re: Puppet or Chef?

#69

Post by retrogradeorbit »

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…

Came here to comments to post about saltstack. Couldn't agree more. So blindingly fast. I think people who comment that puppet isn't slow just don't know how fast salt is. Tens of thousands of clients polled in just seconds is something puppet just can't approach. I also found not having to learn yet _another_ DSL refreshing.

Re: Puppet or Chef?

#70

Post by nigelk »

thyrsus wrote: post #63
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.

I document my puppet configurations in Leo ( http://webpages.charter.net/edreamleo/front.html ) taking full advantage of Leo's ability to represent directed acyclic graphs natively. There are lots of things I'd like to improve in Leo that involve chucking its current code base (e.g.: back end storage is XML and thus version control hostile; front end is not a web browser; acyclic should get dropped from "rooted, orde…

I'd love to see more details about this. You may not return to this comment, but nigel@puppetlabs.com would love to chat about what you're doing here.
Post reply on HN