4 ms·

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

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 2y 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 2y 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 2y 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 2y 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 2y 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.

eurekin 2y 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 2y 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 2y 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 2y 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 2y 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.