A Puppet User Trying Chef

I have a decent amount of experience at this point with puppet both from experience using it to manage the infrastructure running Fedora as well as setting it up at a pretty large scale at HubSpot.  But in a new gig, I decided it was worth rounding myself out a bit and giving chef a try.  Not out of any deep seated dislike of puppet but there are a few pieces that I’ve continued to run up against which are a little grating and so I figured it was worth broadening my horizons.  The nice thing is that both are fairly successful open source communities and realistically, as long as you’re using a system, you probably can’t go that wrong or switch in the future.

Side-note: I’ve also been playing with Michael Dehaan’s new project, ansible which is also interesting. But I don’t think it’s mature enough to use for a production environment yet and I also was mostly interested in it as a better remote execution layer as opposed to another full fledged config management tool. But yeah. It’s there.  It’s interesting. I’ll probably write more about it later.

With a little bit of chef time under my belt, I have to say that I’m not struck by drastic differences.  The terminologies are different, the DSL used on the config side is a bit different but they act pretty similarly and you can get either of them to do what you want.  That said, there are a few things (good and bad) that I’ve noticed about chef and figured I’d share for others who are looking at deciding for themselves.  Note that a few of the things in the dislikes section may well just be me missing something and being a n00b… suggestions welcome!

Things I’ve Liked 

  • Hosted Chef is a very very nice option to have.  Props to the Opscode team for building an infrastructure to run the server side for youand especially for making the barrier to entry nearly zero by letting you manage up to five hosts for free.  Given some of my headaches around running a puppetmaster previously, I’m glad not to be having to pull together everything to run a chef server
  • Knife is actually pretty cool.  I was skeptical before using it but it does a pretty nice job of encapsulating a lot of common tasks for you
  • Knife gets really cool with the addition of the ec2 plugin.  Launch servers, register them with hosted chef and have them ready to go.  I’ve built all of the surrounding bits and as the environment I’m dealing with grows, I think I’ll grow out of being able to use knife ec2 effectively, but it’s great for an easy starting point
  • Chef solo seems to work okay and have a few niceties over a master-less puppet setup but I didn’t spend much time with masterless puppet, so it’s probably just that I didn’t find the related nice pieces

Things I’ve Disliked / Been Annoyed By

  • The package support in the Fedora/CentOS/RHEL universe is pretty poor.  I realize that all the cool kids use Ubuntu these days but tons of server infrastructures are not.  Todd does a great job with the puppet (+ ecosystem) packages for Fedora and EPEL. Would love to see someone do similar for all of the Chef stuff
  • A lot of the cookbooks that are out there and published are Ubuntu specific. Even the ones which strive to work across distros often end up coercing the Fedora universe to look more like Debian.  Which isn’t necessarily a path I want to go down
    • Probably just a side effect of this but a lot of cookbooks using things which aren’t the standard init system (eg, depending on runit)
  • knife-ec2 makes you think you can get away with using it but I keep tripping across things it doesn’t support and making me consider abandoning it
  • Trying out cookbooks from others drives me crazy.  I’m pretty sure I’m missing the good workflow here but polluting my checkout by adding vendor branches and auto-committing things.  There’s gotta be something I’m missing here
So am I now a rabid chef fan?  Nope.  But it’s a nice system with some definite advantages for certain use cases.  I suspect I’ll find more of them as I use it more.

6 thoughts on “A Puppet User Trying Chef”

  1. Please check out http://saltstack.org as well if you’re trying things out. Salt also does remote execution, but it uses zeromq, which scales better for very large environments than ssh.

    Salt is remote execution + config management so it might be interesting to take for a spin.

    1. While it it is likely faster for very large infrastructures, it also does it’s own very unique crypto, which is something everyone is going to have to audit and decide if they are comfortable with for a listening root-level daemon. ZeroMQ offers no security built-in. So far lots of folks are gravitating towards not having a listening root-level daemon in Ansible, but sure, if you have 30,000 servers, it’s not going to manage them all at once. However, most people don’t have 30,000 servers, so the need doesn’t arise. Technically Ansible’s connection layer is still pluggable, so that doesn’t rule out using a proper message bus later. Patch would be reasonably trivial.

  2. For the Red Hat/CentOS packages, check out the beta of the new omnibus installers. A single RPM, with an fully encapsulated ruby, and all the dependencies – http://www.opscode.com/chef/install/.

    The vendor-branch workflow is there to make it reasonably easy to be tracking published releases of a cookbook, along with your individual customizations, across multiple releases. (You can commit on top of a cookbook from the community, and have your changes tracked across updates from the upstream.) There are alternate approaches (librarian being probably the most common one,) but that’s why that pattern exists.

    Thanks for the write-up, and let us know if we can help.

    1. Will take a look at the omnibus package. I’m using the aegisco ones at the moment which are working. But playing outside of the ecosystem is that many more steps for people to jump through to use. And fwiw, providing a repo instead of a shell script that I have to trust running through curl would be small work for huge usability gains.

      I understand what the vendor-branch workflow is trying to accomplish and see the value. But it just feels klunky. There’s got to be people who actually have stumbled across a nice workflow but it’s not written up in a cohesive fashion (or I haven’t found it). Some of it may actually be “well it’s obvious to a ruby/rails person” but not being one, it doesn’t pop out at me.

  3. Hey Jeremy, on the maturity thing, I don’t care what you use, but just to clarify that production use comment on Ansible…

    Lots of folks ARE using Ansible in production already. The playbook language will protect folks from any changes to the underlying API while the Python API stabilizes, though changes so far have been very minor. (And it’s not like the Ruby API under other tools hasn’t changed). There’s also very few moving parts and about 1/60 the amount of code of the other tools, so there’s less to go wrong. Coupled with a pretty freaking high github adoption rate for a 2 month old project, peer review is also pretty solid. I’d say if anyone is concerned with rate of change, just fork it, and update when you feel comfortable. If you don’t feel like updating, there’s no need to update, i.e. there are no daemons or remote code to patch or anything like that… because there are no daemons or remote code.

Comments are closed.