What is DevOps?
-
We hear about DevOps almost everywhere, but it is a poorly understood concept outside of DevOps circles and, in fact, often within them as well. I've written about understanding DevOps in the paper On DevOps and Snowflakes and have spoken at conferences about DevOps and have been involved in DevOps in some capacity since 1994.
A lot of mystery and confusion surround this concept. The name comes from the smashing together of "DEVeloper and OPerationS" which is another way of trying to say "System Administrations (Ops) with Developer Skills." This is the source of the name, but the name is silly and doesn't convey what people mean when they talk about DevOps today.
What is driving DevOps today, and what we will talk about here, are the concepts of Software Defined Systems, SDS; and Software Defined Infrastructure, SDI.
The "old way" of handing systems administration is to log into machines individually and set them up by hand. Each machine is a "special snowflake." SDI (we will use the broader term and assume that SDS is contained within it) takes a different approach: that we define our infrastructure in code (really configuration files) which define the intended "state" of the resulting system.
That sounds cool, but if you've never used SDI it really just sounds like buzz words. Let's explore some standard SDI concepts. Keep in mind that SDI grew up as a useful concept in conjunction with cloud computing and without SDI, cloud computing has little value. SDI works without cloud computing, but cloud computing only nominally works without SDI.
- No logins. A common SDI concept, especially in strict circles, is the idea that users will "never" log into a server again. In fact, it is becoming common to not even have access to do so. All actions that would normally be done while logged in can be handled via the state machine.
- Extreme tooling. Log collection, extensive monitoring, state engine agents and other tools create the ecosystem that allows for effective central management without needing to access individual systems direction.
- DevOps Toolsets. Common toolsets like Ansible, Chef, Puppet and Salt are expected to be used. These are the state engines (and often more) that use remote access of their own or locally installed agents to handle the state of machines.
- Data only backups. This is a topic I will explore separately. But SDI backups are a completely different beast and are often tiny and compact compared to traditional backup strategies.
- Autoscaling. SDI systems have a strong leaning towards being able to scale natively. This is not always true, but is very common and often expected.
- All system management done in code. Basically system admins spend their time "defining state" by describing the resulting systems in code and configuration files.
- Immutable. Systems don't change but are defined and kept held to that state.
- Repeatable. System state can be applied over and over again in a predictable way.
- No more updates. Why update running systems when a new replacement system can be built and replace the old one in situ? Small patches are often still done, but larger updates are normally handled through automated lift and shift.
- Change control. The natural of SDI being able to define servers in a text file, combined with development practices makes change control trivial and highly effective. Tools like Git, Mercurial and Subversion give us the ability to define servers over time and roll a server back to any state, at any time for testing, fixes, or whatever or simply to track changes.
SDI requires us to change how we think about system management. And while we talk about servers, there is no reason that SDI concepts do not apply to desktops as well. In fact, Group Policy is a low key, old style SDI tool to some degree; simply one that has not kept pace with the modern world.
-
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
-
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -K -
And while we talk about servers, there is no reason that SDI concepts do not apply to desktops as well.
All of my workstations are managed with Puppet/Ansible. Very limited local user accounts for emergencies and passwords and everything are controlled through Puppet. We kickstart them and then sign the Puppet cert and we're done.
-
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
-
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
-
Chef, Salt, and Puppet all use agents installed on the client end. Ansible is unique from the rest because you don't install anything on the clients. The only thing you need is the Ansible "server". Playbooks and ad hoc commands are run from that machine using SSH or PowerShell.
-
So it looks like Salt can be run without an agent over SSH or completely by agent.
You can also do master less Puppet environment where the agents compile the manifests themselves instead of a Puppet Master doing it.
Is this what you're thinking of?
-
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
When I tested it, both their site (and the way it worked in testing) was serverless
I think they all do a lot of things. Chef does server and serverless, too.
-
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
Servers are typically pull, not push.
-
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
Servers are typically pull, not push.
No. Agents are pull. The server holds the configs and the agent checks in and pulls the config. Ansible is push and specifically states that on their website.
-
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
When I tested it, both their site (and the way it worked in testing) was serverless
I think they all do a lot of things. Chef does server and serverless, too.
I use it every day and I guarantee you push from a machine you installed Ansible on. That could be anything, like a laptop or on my case a VM just for Ansible, but you definitely push from a single machine.
-
Like I said before. Ansible does have pull, however documentation is sparse and you have to install Ansible (the same full Ansible install you do with the push architecture) on every machine. I've never interacted with anyone using it in that fashion. I also did a mini ~2 hour training from Red Hat on Ansible and they did push exclusively.
-
Even in Ansible's pull implementation, it's exactly the same as how the push system works. It looks at the playbook and instead of SSH'ing into other machines to run the playbook, it literally SSH's into 127.0.0.1. So it's still a push architecture, just on the local host.
-
@stacksofplates said in What is DevOps?:
Like I said before. Ansible does have pull, however documentation is sparse and you have to install Ansible (the same full Ansible install you do with the push architecture) on every machine. I've never interacted with anyone using it in that fashion. I also did a mini ~2 hour training from Red Hat on Ansible and they did push exclusively.
It was the feature that caused it to get introduced around here.
-
@stacksofplates said in What is DevOps?:
Even in Ansible's pull implementation, it's exactly the same as how the push system works. It looks at the playbook and instead of SSH'ing into other machines to run the playbook, it literally SSH's into 127.0.0.1. So it's still a push architecture, just on the local host.
Lol good point.
-
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
Servers are typically pull, not push.
No. Agents are pull. The server holds the configs and the agent checks in and pulls the config. Ansible is push and specifically states that on their website.
Not necessarily. Salt is an agent but push. The agent doesn't pull. At least not by default.
-
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
Servers are typically pull, not push.
No. Agents are pull. The server holds the configs and the agent checks in and pulls the config. Ansible is push and specifically states that on their website.
Not necessarily. Salt is an agent but push. The agent doesn't pull. At least not by default.
It's the exception then. Chef and Puppet both pull. I really like the pull system for CM. I use Ansible for orchestration.
-
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
Servers are typically pull, not push.
No. Agents are pull. The server holds the configs and the agent checks in and pulls the config. Ansible is push and specifically states that on their website.
Not necessarily. Salt is an agent but push. The agent doesn't pull. At least not by default.
It's the exception then. Chef and Puppet both pull. I really like the pull system for CM. I use Ansible for orchestration.
Yup. The push is their huge selling point. No other major player does it. And no open ports either. Doesn't need SSH which is huge.
-
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
@stacksofplates said in What is DevOps?:
@scottalanmiller said in What is DevOps?:
Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.
A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.
Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.
Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.
Now you just run
ansible host -m shell -a "whatever you need to do" -b -KOne of their big selling points is that you can do pure push, all agent, no server
It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.
Servers are typically pull, not push.
No. Agents are pull. The server holds the configs and the agent checks in and pulls the config. Ansible is push and specifically states that on their website.
Not necessarily. Salt is an agent but push. The agent doesn't pull. At least not by default.
It's the exception then. Chef and Puppet both pull. I really like the pull system for CM. I use Ansible for orchestration.
Yup. The push is their huge selling point. No other major player does it. And no open ports either. Doesn't need SSH which is huge.
How does the agent know to interact? Just heartbeat every few seconds?
