4 ms·

> 4. Why fork puppet instead of contributing to ansible or salt? Puppet and Ansible (not sure about Salt) works very differently. Puppet is pull based, as in e

> 4. Why fork puppet instead of contributing to ansible or salt? Puppet and Ansible (not sure about Salt) works very differently. Puppet is pull based, as in each client pulls their configuration from a central server at regular intervals, where as Ansible pushes a configuration when asked. Puppet is also more of a "Ensure that my client is in this state" while Ansible can be see as "Run these steps on the client", that's not a 100% accurate and people have also made Ansible work in a pull configuration, but I feel that makes picking one over the other a little simpler. In any case, Puppet is easier to scale to thousands of servers. Ansible is easier to develop for and easier to upgrade or run multiple versions simultaneously. It two different approaches to the same/similar problem, but they are fare from interchangeable.

mdaniel 2y ago
I am glad you at least mentioned ansible-pull[1] since it's just common to use push based setups, but not the only way. I don't know exactly how puppet thinks of these things but ansible-pull is also still agentless (meaning one does not need to register the managed machine a priori). I also especially like "--only-if-changed" <https://docs.ansible.com/ansible/11/cli/ansible-pull.html#cmdoption-ansible-pull-o https://docs.ansible.com/ansible/11/cli/ansible-pull.html#cm...> which can keep keeps the journalctl noise down if that option is appropriate to your setup 1: https://docs.ansible.com/ansible/11/cli/ansible-pull.html https://docs.ansible.com/ansible/11/cli/ansible-pull.html
0cf8612b2e1e 2y ago
> Puppet is easier to scale to thousands of servers I would have expected the opposite. Pushing changes as required seems easier when the head node is the only one with smarts deciding on what happens next. Unless Ansible has some hard cap on how many servers it can direct in parallel?
- everforward 2y ago
  The head node has to do all the processing of what changes to make, for each server it runs against. Pull based systems have the destination server do that, making them scale horizontally natively. Presuming there's no need for orchestration between nodes (which pull-based configs make very hard/impossible), pull-based systems parallelize perfectly where push-based systems cannot parallelize. SSH is also very slow as far as these things go. At some point the head node just gets saturated on doing SSH encryption or the NIC.
- citrin_ru 2y ago
  Puppet servers can be scaled horizontally - create N puppet servers and then allow a client (an agent) to select a random server (either using a load balancer or just a DNS RR). But even a single server on modern hardware with appropriate tuning should be able to serve thousands nodes.

mdaniel 2y ago

I am glad you at least mentioned ansible-pull[1] since it's just common to use push based setups, but not the only way. I don't know exactly how puppet thinks of these things but ansible-pull is also still agentless (meaning one does not need to register the managed machine a priori). I also especially like "--only-if-changed" <https://docs.ansible.com/ansible/11/cli/ansible-pull.html#cmdoption-ansible-pull-o https://docs.ansible.com/ansible/11/cli/ansible-pull.html#cm...> which can keep keeps the journalctl noise down if that option is appropriate to your setup 1: https://docs.ansible.com/ansible/11/cli/ansible-pull.html https://docs.ansible.com/ansible/11/cli/ansible-pull.html

0cf8612b2e1e 2y ago

> Puppet is easier to scale to thousands of servers I would have expected the opposite. Pushing changes as required seems easier when the head node is the only one with smarts deciding on what happens next. Unless Ansible has some hard cap on how many servers it can direct in parallel?

everforward 2y ago
The head node has to do all the processing of what changes to make, for each server it runs against. Pull based systems have the destination server do that, making them scale horizontally natively. Presuming there's no need for orchestration between nodes (which pull-based configs make very hard/impossible), pull-based systems parallelize perfectly where push-based systems cannot parallelize. SSH is also very slow as far as these things go. At some point the head node just gets saturated on doing SSH encryption or the NIC.
citrin_ru 2y ago
Puppet servers can be scaled horizontally - create N puppet servers and then allow a client (an agent) to select a random server (either using a load balancer or just a DNS RR). But even a single server on modern hardware with appropriate tuning should be able to serve thousands nodes.