4 ms·

I think Puppet hits the sweet spot in this area. It's default is a series of idempotent "here's how this should be configured" statements, but it can be used as

I think Puppet hits the sweet spot in this area. It's default is a series of idempotent "here's how this should be configured" statements, but it can be used as a full programming language in its more advanced capacity, and it's reasonably extensible (in Puppet-lang and Ruby) to support specific custom applications. I also think that the facts/manifest/apply separation is conducive to nicely testable infra code, and useful dry-run output. I'm always surprised that Puppet isn't still more popular. My theory is that it's passed over because of its age/cruftiness/bad vibes in some cases, and that a couple of technical flaws mess it up for some key userbases: For folks who just want a quick-to-start management tool for a small set of config, Puppet's ugly and clunky client/server model and the hyper-YAML-ification of its best practices (which is pursued to a fault by the community, and not helped by the Hiera pitch that the Puppet stack can also be sort of an asset tracking/catalog system) make small-scale usage and prototyping hard. Puppet doesn't have to be used that way (it can be used just like pyinfra/Ansible with a local-apply or via Bolt, hitting a nice sweet spot between ad-hoc/non-idempotent commands and nice declarative/idempotent Puppet code), but I think the puppetmaster/hiera-all-the-things legacy in the community does Puppet and potential new users a disservice. From the other side, I think a lot of more cloud-oriented users looking for a "better Terraform for server state" end up annoyed by the quality of modules on the Puppet forge and Puppet's lack of a statefile equivalent (meaning that it doesn't support deletes or infrastructure state snapshots in the same way TF does).

turtlebits 3y ago
Adding config management agents to run on your infra is IMO unnecessary operational burden. (ie puppet, chef, saltstack, etc.) In the day and age of everything running on Docker, the closer you are to a bare OS image, the better. Config management that uses SSH is generally good enough.
- eurekin 3y ago
  Can concur, used puppet a bit at the dayjob and agent issues were common at some point. Also, for bigger inventories on a single vm runtimes shot up quickly in the hour realm
  - zbentley 3y ago
    Yeah, dealing with agent issues sucked; I'm glad I haven't worked on one of those setups in awhile. And if the agent bootstrapped some part of the shell-in-and-remotely-troubleshoot tooling, good luck debugging it, and if the agent bootstrapped the telemetry system, good luck telling the difference between "host with agent failure" and "host that disappeared"... anyway. Fun times. For hour+ runtimes I really do think that's pretty much always user error. I know that's a clichéd and grouchy comment, but (as, I'll admit, a Puppet fan with some personal defensiveness for a favored tool) I do think it's true in this case.
- zbentley 3y ago
  I agree; that's the "client-server legacy" that I mentioned in GP. It's unfortunately not widely known that Puppet can be run just like you describe, over SSH (or, for e.g. running in a Docker container, can be invoked as a one-shot "puppet apply" against a local configuration file like pyinfra's "local" transport): https://www.puppet.com/docs/bolt/latest/bolt.html https://www.puppet.com/docs/bolt/latest/bolt.html. Doing that requires no background daemons, puppetmasters, cert-signing hell, inventory management PuppetDB/Foreman stacks, or any of that stuff: you run a command which SSHes to a remote/local machine and applies changes based on instructions written in Puppet-lang or one-off scripts. The remote end is entirely self-hosting; it doesn't rely on anything being running on the remote host (Bolt will install the "puppet-agent" package to bootstrap itself, but in this context that package is inert and is used equivalently to a library when you run tasks). I'm with you that the agent-based approach is far from the best way to go these days. I'm just bummed that we're throwing the baby out with the bathwater: I wish Puppet-the-language and Puppet-the-server-management-tool weren't so often dismissed along with the Puppet-as-inventory-system or Puppet-as-daemonized-continuous-compliance-engine.
- esoterae 3y ago
  Ssh and its child processes are just another agent. Agents of a model that must be up at time-of-convergence as seen from the coordinator node; a remarkably inflexible arrangement that can only be addressed with additional development not otherwise necessary. Ruby is far, far preferable to shell for ease of idempotence and implicit convergence.
- bigstrat2003 3y ago
  Hard disagree. Having an agent running on things is IMO far superior for preventing config drift (agents checking in versus one big centralized cron job pushing state to everything). And to be honest, the fact that it doesn't play as well with Docker is a flaw with the idea of putting everything in Docker, not having a config agent. Some things work well in containers, but it's silly to try to shoehorn everything into them the way many people do.
aprdm 3y ago
I believe it's due to Ruby being its language of choice. Ruby is mostly a dead language in the Ops space, unlike Python. Having inherited a big mess on Puppet of some people who used the flexibility of Ruby to automate 5 datacenters, but then left the company was also an interesting experience..
bityard 3y ago
I was an early adopter of Puppet back when it was fairly new. It was a breath of fresh air when the state of the art was cfengine! Despite its many great ideas, I never particularly liked the agent or need for a master server. And I've always managed to avoid learning Ruby so I couldn't easily hack on it myself. The company I'm with now uses it extensively so I'm having to re-learn it and so far my impression is that it went from "cool new open source thing" to "your average enterprise-grade bloatware thing".
nijave 3y ago
Usually when I use these types of tools I'm building immutable infrastructure where a golden image gets built and an existing app data volume gets attached to a new OS image (same workflow as Docker containers but more access to kernel/hardware) Puppet doesn't work well for that. I've seen it come up in auditing scenarios since the agent can effectively report if the instance is still in the correct config state.
slyall 3y ago
Another reason for puppet being less popular is lots of places ended up with very complicated configuration that did everything on the server but was hard to work with. Ansible you could deploy a small playbook that did just one thing. A lot easier to get started with and keep under control. As others have mentioned puppet was also a lot less useful when server images can per-configured and often short lived. It was more designed to take a bare OS install and turn into a long-lived server.

turtlebits 3y ago

Adding config management agents to run on your infra is IMO unnecessary operational burden. (ie puppet, chef, saltstack, etc.) In the day and age of everything running on Docker, the closer you are to a bare OS image, the better. Config management that uses SSH is generally good enough.

eurekin 3y ago
Can concur, used puppet a bit at the dayjob and agent issues were common at some point. Also, for bigger inventories on a single vm runtimes shot up quickly in the hour realm
- zbentley 3y ago
  Yeah, dealing with agent issues sucked; I'm glad I haven't worked on one of those setups in awhile. And if the agent bootstrapped some part of the shell-in-and-remotely-troubleshoot tooling, good luck debugging it, and if the agent bootstrapped the telemetry system, good luck telling the difference between "host with agent failure" and "host that disappeared"... anyway. Fun times. For hour+ runtimes I really do think that's pretty much always user error. I know that's a clichéd and grouchy comment, but (as, I'll admit, a Puppet fan with some personal defensiveness for a favored tool) I do think it's true in this case.
zbentley 3y ago
I agree; that's the "client-server legacy" that I mentioned in GP. It's unfortunately not widely known that Puppet can be run just like you describe, over SSH (or, for e.g. running in a Docker container, can be invoked as a one-shot "puppet apply" against a local configuration file like pyinfra's "local" transport): https://www.puppet.com/docs/bolt/latest/bolt.html https://www.puppet.com/docs/bolt/latest/bolt.html. Doing that requires no background daemons, puppetmasters, cert-signing hell, inventory management PuppetDB/Foreman stacks, or any of that stuff: you run a command which SSHes to a remote/local machine and applies changes based on instructions written in Puppet-lang or one-off scripts. The remote end is entirely self-hosting; it doesn't rely on anything being running on the remote host (Bolt will install the "puppet-agent" package to bootstrap itself, but in this context that package is inert and is used equivalently to a library when you run tasks). I'm with you that the agent-based approach is far from the best way to go these days. I'm just bummed that we're throwing the baby out with the bathwater: I wish Puppet-the-language and Puppet-the-server-management-tool weren't so often dismissed along with the Puppet-as-inventory-system or Puppet-as-daemonized-continuous-compliance-engine.
esoterae 3y ago
Ssh and its child processes are just another agent. Agents of a model that must be up at time-of-convergence as seen from the coordinator node; a remarkably inflexible arrangement that can only be addressed with additional development not otherwise necessary. Ruby is far, far preferable to shell for ease of idempotence and implicit convergence.
bigstrat2003 3y ago
Hard disagree. Having an agent running on things is IMO far superior for preventing config drift (agents checking in versus one big centralized cron job pushing state to everything). And to be honest, the fact that it doesn't play as well with Docker is a flaw with the idea of putting everything in Docker, not having a config agent. Some things work well in containers, but it's silly to try to shoehorn everything into them the way many people do.

aprdm 3y ago

I believe it's due to Ruby being its language of choice. Ruby is mostly a dead language in the Ops space, unlike Python. Having inherited a big mess on Puppet of some people who used the flexibility of Ruby to automate 5 datacenters, but then left the company was also an interesting experience..

bityard 3y ago

I was an early adopter of Puppet back when it was fairly new. It was a breath of fresh air when the state of the art was cfengine! Despite its many great ideas, I never particularly liked the agent or need for a master server. And I've always managed to avoid learning Ruby so I couldn't easily hack on it myself. The company I'm with now uses it extensively so I'm having to re-learn it and so far my impression is that it went from "cool new open source thing" to "your average enterprise-grade bloatware thing".

nijave 3y ago

Usually when I use these types of tools I'm building immutable infrastructure where a golden image gets built and an existing app data volume gets attached to a new OS image (same workflow as Docker containers but more access to kernel/hardware) Puppet doesn't work well for that. I've seen it come up in auditing scenarios since the agent can effectively report if the instance is still in the correct config state.

slyall 3y ago

Another reason for puppet being less popular is lots of places ended up with very complicated configuration that did everything on the server but was hard to work with. Ansible you could deploy a small playbook that did just one thing. A lot easier to get started with and keep under control. As others have mentioned puppet was also a lot less useful when server images can per-configured and often short lived. It was more designed to take a bare OS install and turn into a long-lived server.