Hacker News Reader

Comment by account_taken | Hacker News Reader

Isn't puppet overkill for this? Seems like a bunch of ruby to build command line arguments. Bash would have been easier. We have a workstation dotfiles which we clone and execute an install script with plugins for oh-my-zsh.

View on HN

To set up initially, possibly. But this is for maintenance too. Need to install a security patch? Puppet. Need to upgrade versions? Puppet. Want to tweak some setting somewhere? Puppet. Using Puppet makes it stupid easy for us to keep our setups (a) in sync, (b) up to date and secure, and (c) do it without a bunch of hacky scripts that will probably break or not work right in 3 months.

I'm not seeing it how installing a security patch is any different. Security patches usually check to see if they need to be applied before doing anything. Updating a version is as simple as `brew update node`, `brew updated mongodb`, etc. The bash you call hacky is what's being done here with an extra layer of Ruby.

Cool, well have fun next time you need to update a setting buried in a config file or verify the results of something you ran. You can write 200 lines of bash that might work (or might not if the user decides they like csh or zsh) or like 3 lines of Puppet and guarantee it's idempotent.

There's a lot more to this than just setup scripts, but if all you need is setup scripts with the occasional update, then by all means just stick with that. Our needs just happen to be beyond that.

Might seem like overkill, but Chef/Puppet are designed to be idempotent, which is exactly what you want when you're running configuration scripts that are expected to evolve and update, and hence must be run over and over without reformatting the workstation.

Disclosure: I'm a big pivotal_workstation and Chef fan, but excited to see what new angles boxen demonstrates :)

Puppet not only allows you to deploy changes but makes sure they stay. There is something called Puppet Dashboard, that allows you to see all the installed clients, who has a valid config, who is outside that config. This allows you to quickly see machines that need attention. There are some better screenshots here [2].

[1] https://puppetlabs.com/puppet/related-projects/dashboard/

[2] http://bitcube.co.uk/content/puppet-dashboard-six-months

I understand the benefits of puppet, ansible, etc for provisioning on a massive scale.

Drift after installation and incremental updates were more of a problem for us than initial installs.

It's easy to install something originally from state X to state Y with bash, but Puppet makes it easy to continue ongoing because it's a declarative syntax.

Reply on news.ycombinator.com