11–20 of 71 posts
I tried both and decided the answer was neither - I'd recommend giving Ansible serious consideration. ( https://github.com/ansible/ansible )
Another one is Babushka, for serious simplicity and speed http://babushka.me
There is a third and fourth solution to the "Encrypted data bags for puppet" problem. The third, my solution, is to never, ever, store AAA in configuration system. EVER! I do store calls to programs and such or even just data files as a program. I admit sometimes the "program" to get certain passwords is something like "backtick cat somefile backtick" but usually I do better. Those AAA programs/repos are handled much more delicately and securely than a "everything goes" config system that everyone can mess with.
The fourth solution is the implied idea that you'd never rotate AAA credentials on a regular basis and never change infrastructure passwords when someone quits, which sounds pretty funny to me. Hey HN, my mysql root password for a month back in 1998 was: (insert something like line noise here)
Another old time puppeteer observation is everyone has a SSL nightmare eventually and even the mighty GOOG can't help you sometimes. Especially on restoral of backups, or replication of live systems, it can get pretty hairy. Also DNS malfunctions can horribly confuse puppet's SSL occasionally. This is something you'll only hear from an old puppeteer not a short experiment like the article.
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…
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 puppet. If DNS is dead you may as well forget debugging puppet until your local DNS is healthy.
Also its possible to do unusual SSL configurations that can make it a bit slow. Vanilla out of the box should be reasonably fast. Starving a virtual image of CPU can make the SSL slow... a virtual 40 MHZ 386 equivalent is not going to do SSL any faster than a physical 40 MHZ 386 used to.
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 package on each node on each run. this might work fine if you're running on beefy physical/virtual hardware, but not for managing hundreds/thousands of tiny LXC containers that need to be scaled on-demand in seconds
• not self-hosted: chef seemed to have real difficulty closing the loop and being the thing that deployed and configured itself. there's guides online for scripting yourself up to a basic chef setup, but what if you want your chef client to bootstrap with some custom rubygems? back to bash scripting - and then how does that script get on each of your nodes? chef isn't intended to build/deploy itself the way it does the rest of your stuff
We've now transitioned everything to heroku buildpacks + a build server, which create self-contained "slugs" and therefore are self-hosting (i.e. the build server can build itself), and allows us to have a single build/deploy process for everything
I tried both and decided the answer was neither - I'd recommend giving Ansible serious consideration. ( https://github.com/ansible/ansible )
Thanks for the Ansible reference, looks interesting.
I've used both (and cfengine) to varying degrees and would have to agree. Simply using a configuration management tool takes an incredible amount of work off your shoulders, you can't go wrong with either.
0 - http://linuxadminshow.com/2012/10/28/episode-4-puppet/
(edit - I said I interviewed the Chef guy, I meant Puppet)
In our experience puppet is easier to setup and start, chef server stack is HUGE compared to just installing a package for puppet master and certs/knife setup is a PITA.
The DSL is pretty similar except for how they track dependencies and general workflow, where chef is `procedural`, puppet internally builds a call graph based on a declarative syntax which can be hard to track down and understand in some situations.
Regarding cookbooks vs manifests, both have tons of modules around, but like with any plugins/modules software the basic stuff in general is cover, but you will need to get your's hand dirty to get things to work your way and not all manifest/cookbooks are good to use at all..
We don't found compilation and install time to be an issue for us, a complete lamp stack install fully customized takes less than 2 minutes per node.
We have a linux background and didn't find ruby hard at all to hack and mess around to solve some of our issues like custom facters and install some rare stuff like nsis :)
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…
If you are managing a small application, Chef may feel heavyweight. However, imho, if you can't manage Service-Oriented Architecture w/out a serious configuration management system, be it Chef or Puppet. There are just too many moving parts.