[wernerb]

> No masters. For Ansible this meant using ansible-playbook locally, and for Salt this meant using salt-call locally. Using a master for configuration management adds an unnecessary point of failure and sacrifices performance.

There are two models for delivering state to your infrastructure nodes. Pulling and Pushing configuration. Ansible Pushes code from the controller to your nodes, while salt, puppet and chef all pull state from a master somewhere.

Like twic says, Ansible does not have a master. The original author says no masters means faster performance. What he means is that pulling configuration from a remote checkout equals faster performance, which is true because it can be loadbalanced etc.

A chef/puppet master can have features such as search and service discovery that should be a large red flag for SPOF problems.

[twic]

But Ansible doesn't have masters! It has a machine where you run Ansible. But that can be any machine, as long as it has Ansible installed, the Ansible code checked out, and an authorised SSH key. If your usual machine goes down, just check out the code and run from a different machine. The idea that you need to use local playbooks to use Ansible masterlessly just seems mistaken to me.

Moreover, any scheme which involves running local configuration (whether in Ansible, Chef, or Puppet) involves either pushing configuration updates to machines, or having the machines poll for configuration updates, in which case it's no different to running remote configuration or having a master, respectively.

I don't get the point about open ports. Are you running machines without SSH? If you are, well done. But if, like most people, you're not, then you already have all the port you need open.

[wernerb]

I haven't mentioned an Ansible Master? I referred to the user running ansible as the controller.

Running local configuration and checking out local state can indeed be very different from having a master. Like I said, master features often include features such as search and service discovery. Checking out state from version control does not have those features therefore the user implements those features on his own with stateless cookbooks/pillars/modules/whatever. The remote checkout is not a SPOF and a master is.

You are right in regard to the open ports, it is uncommon, though I have seen it with workstations. I edited the post!