Comment by phaer | Hacker News Reader

Comment by phaer | Hacker News Reader

I still prefer the Open Source edition of https://puppet.com/ to manage larger, diverse environments - which may include not just servers, but workstations, network appliances and so on. It's well established with lots of quite portable modules. But it can also be a bit on the slower side and comes with a steeper learning curve then some of the others.

https://www.ansible.com/ is surely a good solution for Bootstraping Linux cloud machines and can be quite flexible. I personally feel like its usage of YAML manifests instead of a domain-specific language can make complex playbooks harder to read and to maintain.

If all you do is to deploy containers on a managed Kubernetes or a similar platform, you might get away with some solution to YAML templating (jsonnet et al) and some shell glue.

I am keeping an eye on https://github.com/purpleidea/mgmt which is a newer contender which many interesting features but lacks more complex examples.

Others like saltstack and chef still see some usage as far as I know, but I've got no personal experience with them.

Ansible amazing for configuration management, much better than Puppet. Storing the config in YAML makes it super easy to read and maintain, also much better than Puppets method.

As you mention, puppet has a steep learning curve, whereas Ansible has a very shallow one. It’s easy to get running in a few minutes!

We use both Puppet and Ansible at work, and its constant complaints and delays with Puppet whereas Ansible is little complaints and no delays.

> We use both Puppet and Ansible at work, and its constant complaints and delays with Puppet whereas Ansible is little complaints and no delays.

That's probably because you are not running masterless, which means your puppet master is a bottle neck.

The master is part of the bottleneck, but a lot of the complaints are trying to get it to do what it says. But a big benefit of puppet is the master feature, so if that's taken out, why puppet?

Puppetmaster took off because it conceptually easy to understand to people who were used to managing servers by hand.

I would argue that masterless puppet is a superior pattern for both scaling creating a hierarchical structures.

I used to use Puppet back when they were ruby based. I dropped them once they switched to Java, not interested in pushing Java onto every host when it's not in our stack.

It's still good in Enterprise land where taking the time to work out the declarative style and dependency chains is worth it (and you have the people to put on it and the CAB process to review infrastructure changes). For a small to mid sized company I find it gets in the way of iterating fast. I spent waaaay too much time there either fighting the tooling or having to work out dependency chains. Redhat and I-think-AWS-but-I-might-be-thinking-of-Chef also have tooling in this space.

I'll take Chef or Ansible's imperative approach in the environments I work in any day (Mostly ansible playbooks for baking hosts only, I've never been entirely comfortable with having one Ansible Tower/Chef Server/Puppetmaster/etc be authoritative over everything, too large a failure pattern if security controls fail). But again, I'm working in many younger small environments and not large mature ones.

Most of this is also irrelevant for us as we're all in on Docker/ECS for anything new. Config management plays a limited role there over having your tasks/services checked into the individual repos.

Just for reference, the clients are all still ruby based. It's only the web servers for the puppet masters ( the parsing code is still jRuby ) and puppetdb that are written in clojure that runs on the JVM.

Reply on news.ycombinator.com