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
-
@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?
-
@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?:
@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?
Open connection. They always talk.
