Thomas Hatch, SaltStack CTO and creator of the Salt open source software project, explains the architecture of Salt and why SaltStack intelligent IT automation was built to be different than legacy systems management tools or contemporary configuration management tools.
“Welcome to another episode of Salt Air. My name is Tom Hatch and I’m the creator of Salt and the CTO of SaltStack. Today we’re going to be talking about Salt architecture, but also we’re going to be talking about what so fundamentally is. The fundamental construct of Salt is something that a lot of people have a hard time understanding. Salt itself was a very large distributed management platform. Let me talk a little bit about the core concepts behind Salt and how much you build outside of the system. Salt is made to manage a system. Now, whether or not this system is a full-blown operating system or whether or not this system is a sensor, a camera, or a container, we don’t really care. All we care about is making sure that we can manage disparate systems. To manage these systems we first build an abstraction on top of them. We have a remote execution system and the remote execution system allows us to manage large numbers of systems in parallel and allows us to do complex orchestration tasks. The next thing we have is what we call the state system. The state system allows us to configure systems and enforce the state in which they are running. So that those systems that we’re working with can be exactly what we need them to be and we can say, yep, this system is configured to maybe say a web server, or a database, or a TV and a cruise ship, or a slot machine. Finally we have an event-driven system. The event-driven system is kind of the antithesis of the remote execution system. The remote execution system allows us to push commands down, but the event system allows us to bring events back up, so that we can see what’s happening on the device. The lifecycle of any device system or server of course is not a completely static thing. We want to be able to see what’s happening on these systems. Now, with that core premise in mind, let me talk a little bit about how we organize the actual software to express this system. When we talk about the management of the specific device, that device in Salt vernacular is always referred to as a minion. We can have many minions that are under management and those minions connect up to a master. Since this is more conceptual I’m not going to talk about how we do high availability with the master or a lot of the nuts and bolts, but focus on those three core concepts. The remote execution system comes from the Salt master and we can send those commands down at breakneck speed. Those commands can be propagated out to tens of and sometimes hundreds of thousands of systems in mere seconds. Once those commands get propagated out to these minions the minions themselves ship with what we call execution modules. These execution modules provide a library of different routines that are available to abstract or manage those specific systems…” – Thomas Hatch
View more of the Salt architecture by viewing the video below.
Note also that the Salt architecture has expanded to include a more plugin-based framework.