Salt uses a server-agent communication model, (though it works well as a standalone single-server management utility, and also provides the ability to run agent-less over SSH). The server component is called the Salt master, and the agent is called the Salt minion. The Salt master is responsible for sending commands to Salt minions, and then aggregating and displaying the results of those commands. A single Salt master can manage thousands of systems. Watch this episode of Salt Air to learn about the architecture behind the Salt high-speed communication bus for event-driven automation.

“Welcome to another episode of Salt Air. This week I want to talk about the master minion communication systems. Now, one of the major hallmarks of Salt is that we can have a lot of connected minions and still communicate with them very very quickly. If we come up here and we look at, really the classical approach, we’ve got the master and then many minions connected up to that master. What I want to talk about is what’s going on right here, that connection is made to be fast, it’s also made to be as network efficient as is humanly possible. So what’s going on is that up on the master we have two ports that are exposed one that we call the pub port for the publication and the other end that we call the return port or the wreck port. The minion connects up to the published port this is why when you’re setting up Salt the minion only needs to know where the master is. The master doesn’t need to be informed where the minion is. Also, from a firewall perspective you have a unidirectional connection which needs to be made. Now, the minion connects up to the published port and then the published port is sending down what are called pub messages. These pub messages are made to be extremely small, since the logic and the intelligence about how to do whatever routine is being called, lives on the minion we don’t need to send that actual message over the wire just a reference to it. We use serialization inside of this message to make it as small as possible, so that they can fan out in a very efficient way across large numbers of minions. The minion then receives the publication and it executes it. After it executes it connects back up to the return port with the return information. Now the publish message comes down with what we call a JID or a job ID. That job ID is a timestamp so we know exactly when that job was initiated and the job ID is created up on the master. That is what allows us to make sure that these returns that are coming back, have the job ID associated with it. We get continuity. One of the ways that we get speed is with decoupling these two routines. Since the publication and the return are completely decoupled, that allows us to not have to have any waiting sequences up on the Salt master that also allows us to make sure that since there are no waiting routines we can have significantly lower overhead on the master and it allows us to make sure that we have stronger continuity…” – Thomas Hatch

Watch the video below to learn more about the architecture behind the SaltStack high-speed communication bus for event-driven automation.

Watch or listen to Salt Air on: YouTube | SoundCloud | Spotify | iTunes