Salting things up in the DevOps' World: things just got real
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 34 | |
| Number of Parts | 169 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/21168 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Insertion lossConfiguration managementArithmetic meanMultiplication signRepresentation (politics)Metric systemInformationVideo gameCASE <Informatik>Functional (mathematics)Mechanism designTerm (mathematics)Virtual machineInteractive televisionMereologyData miningProduct (business)Network topologyImplementationState of matterScaling (geometry)Computer configurationComputer architectureSet (mathematics)MassHypermediaSystem programmingGroup actionProteinInformation securityWeb 2.0Server (computing)IP addressGame controllerFood energyTranslation (relic)Proxy serverNormal operatorPressureRight angleAddress spaceCodeSystem administratorPatch (Unix)WhiteboardSelf-organizationElectronic program guideSubject indexingComputer fileEstimatorEvent horizonElectronic mailing listWeb syndicationHeegaard splittingComputer-assisted translationBitSoftwareCache (computing)Software maintenancePresentation of a groupSpeech synthesisImage resolutionRootkitReading (process)Lecture/Conference
08:03
System programmingEvent horizonModul <Datentyp>State of matterEvent horizonLetterpress printingMereologyDirectory serviceConfiguration managementComputer fileEndliche ModelltheorieMenu (computing)View (database)Statement (computer science)String (computer science)Process (computing)Point (geometry)Interface (computing)InformationBasis <Mathematik>CodecInformation securityStandard deviationSystem programmingSystem administratorModule (mathematics)MathematicsAuditory maskingOrder (biology)Level (video gaming)Multiplication signVirtual machineMassInstance (computer science)CASE <Informatik>Set (mathematics)ResultantType theoryDifferent (Kate Ryan album)Software developerProduct (business)Key (cryptography)INTEGRALDirection (geometry)Game controllerSingle-precision floating-point formatLine (geometry)Image resolutionTowerNetwork topologyConnected spaceArithmetic meanTrailRing (mathematics)NumberMessage passingCodeIP addressBitBus (computing)Web syndicationState of matterUniform boundedness principleData miningElectronic mailing listWritingFile systemLecture/Conference
15:58
State of matterEvent horizonSpecial unitary groupNewton's law of universal gravitationStatisticsAssociative propertyComputer fileConnectivity (graph theory)State of matterChemical equationRange (statistics)Configuration managementInformationGroup actionImplementationExistential quantificationArithmetic meanSystem programmingEvent horizonLevel (video gaming)Independence (probability theory)Price indexWordProcess (computing)Key (cryptography)WeightMultiplication signView (database)BitAuthenticationDependent and independent variablesNamespaceSoftware testingComplex (psychology)LogicSheaf (mathematics)Point (geometry)Disk read-and-write headRevision controlAreaResultantSlide ruleHypermediaSequenceSinc functionSet (mathematics)SoftwareType theoryData storage deviceIntegrated development environmentRepresentational state transferReading (process)DemonLecture/Conference
23:54
Arithmetic meanInformationExecution unitSoftware testingGame controllerInformation and communications technologyINTEGRALWater vaporQuicksortDegree (graph theory)Different (Kate Ryan album)Dot productAuthenticationMathematicsSystem programmingEncryptionIntegrated development environmentPoint cloudCycle (graph theory)Cartesian coordinate systemWordService (economics)Set (mathematics)SpacetimeRepresentational state transferView (database)Power (physics)Information securityContext awarenessOpen sourceState of matterEvent horizonDemo (music)Limit (category theory)Element (mathematics)Point (geometry)Computer hardwareMereologyMultiplication signNatural numberTheoryFlow separationCASE <Informatik>Bus (computing)Goodness of fitGeneric programmingHookingBitMobile appSystem callInstance (computer science)DemonLecture/Conference
31:49
Pairwise comparisonSystem programmingINTEGRALPoint (geometry)Integrated development environmentOrder (biology)WindowSet (mathematics)TelecommunicationCycle (graph theory)SoftwareWebsiteLimit (category theory)Connectivity (graph theory)Computer configurationFunction (mathematics)Core dumpWeb 2.0Term (mathematics)Multiplication signWorkstation <Musikinstrument>Cartesian coordinate systemNeuroinformatikShared memoryServer (computing)DemonBitProper mapComplete metric spaceFile formatWeb applicationComputer animationLecture/Conference
34:38
Dynamical systemTelecommunicationRevision controlData storage deviceState of matterKey (cryptography)CurveInformationSystem programmingMultiplication signVideo game consolePower (physics)Virtual machineRight angleMereologySelf-organizationData managementService (economics)Configuration managementPattern languageIntegrated development environmentDifferent (Kate Ryan album)Error messageSoftware testingNumberDependent and independent variablesPerspective (visual)BuildingCategory of beingGroup actionBootingServer (computing)CausalityMathematicsProduct (business)Event horizonPlug-in (computing)Endliche ModelltheorieImplementationMechanism designPosterior probabilityFlow separationWorkstation <Musikinstrument>Level (video gaming)Rule of inferenceNominal numberResultantGreatest elementSurvival analysisMessage passingAreaAtomic numberPixelArithmetic meanRange (statistics)Point (geometry)Module (mathematics)Library catalogForm (programming)Lecture/Conference
Transcript: English(auto-generated)
00:01
Welcome to Sorting Things Up in the DevOps world. I'm here with Juan Manuel Silva, salty guy. Give him some claps. Right. Thank you all for coming. For those of you who've been here last year, I gave
00:25
a similar talk. This is going to be a little more in-depth, so let's get started. Okay, let's get the boring stuff out of the way. My name is Juan Manuel Santos. I work as a team leader and a support engineer at Red Hat.
00:45
I'm also one of the organizers of SIS Army, which is the Argentinian system administrators community, and Arderla, which is a local co-working slash tech conference event that we do every year in Buenos Aires since 2014.
01:02
I've been using Salt for a couple of years now, mainly with no regrets, or with all regrets, whichever you want to choose. Let me get a disclaimer first, so let's get this out of the way too. I am only a humble user of Salt. I have tinkered a bit with the code, I have submitted an ugly patch, but not much more.
01:27
I only have three days to prepare this, so who doesn't like pressure, right? My thanks go to the EuroPython team for managing to squeeze this talking. So, why Salt? As you may or may not know, Salt is a configuration management
01:45
system. In case you don't know what that is, think Puppet, Chef, Ansible, but only better. And why do I say better? It's because it's written in Python, and it leverages YAML and Jinja. Now I know some people in the room might not like YAML, but you can also use JSON if you want.
02:05
It is relatively easy to understand, and I said relatively because it has some complex things, but what it lacks in simplicity of reading and understanding makes it up in being extremely powerful and giving you a huge amount of control over what you can do with it.
02:23
Some of this we'll be seeing in the next few minutes. One more detail that frequently gets lost in translation. Salt can work without an agent, in the case you don't have root access or you're not allowed to run the agent on your machines, via SSH much like Ansible does.
02:42
So, previously in EuroPython, as I said, last year I gave a talk. This was mainly an introduction, speaking of the basic mechanics and terms and concepts behind Salt. As a quick recap, Salt has a master-minion architecture, where the master is the
03:01
one that gives out the orders, and the minions are ordered to do minion stuff. It does so by defining states and high states. The states are representing the state a system should be in, and the whole collection of states that should be applied to a system is called a high state. Another core concept is that of matching, which means targeting your minions and determining which states apply to which minions.
03:29
Finally, there's the concepts of grains and pillar, grains being information sent from the minions to the master, and pillar being information sent from the master to the minions.
03:43
Sadly, and I have to say this, still no Python 3 support. Salt is still in Python 2. It's getting there, though. There's a big issue, and hopefully we'll get there. As usual, it's not because of Salt. It's because of Salt's dependencies.
04:01
Anyway, moving on. Two more concepts that didn't make it to last year's presentation are those of the mine and the syndic. The mine essentially gets data from the minions, is sent to the master, on a regular interval. Now, even though this is done on a regular interval, this is not useful for metrics because only the most recent data that you collect is maintained.
04:30
Another thing that might confuse you is that all the data is made available to all the minions, so when you query it, you might get the answer of the same data from all the minions at the same time, which can be quite confusing.
04:45
In fact, you might be wondering, isn't this like grains? Isn't this what grains are supposed to do? Get data from the minions, send it to the master? Kind of. The thing is, the mine data is updated more often. The grains are mainly static.
05:02
They're only updated if you purposefully update them, which is not something that you would usually do. Also, if minions need data from other slower minions, the mine acts as a kind of cache. So there's that, too.
05:26
There are two ways of defining which mine functions you want to collect from the minions. In the case of normal operation of Salts, you would do so either on the pillar or on the minions configuration file. In the special case of not using the agent, as I mentioned before, you have three ways. Since you
05:46
don't have the minions configuration file, you can either use the roster, the pillar, and the master configuration file. And so, a quick example of what the salt mine would be, so that you don't get much too confused. I promise you, you'll get confused. Looks like this.
06:03
So let's say we want to first target all the minions in our web servers group. We are going to be applying a mine function to gather the IP addresses of the first network count, every five minutes.
06:20
So this we can later use, for example, in an HAProxy configuration to populate the server list. Now, I know that you might be getting baffled about all the ginger here. Try not to think of it. The important thing to understand here is that should we add a new host to the web server group, within five minutes we can have its IP address up in the HAProxy configuration file.
06:46
This is all thanks to the mine, which we can configure as an interval of updating. Now, before we continue, since we already mentioned that salt has a master minion architecture, there's an inherent topology to it. So let's talk a bit about that.
07:03
The most common one would be one-to-many, meaning one master, many minions. But of course, this is boring, this minot scale. This also kills cats during lunar eclipse. So what are the alternatives? How much can we toy around with this? Could we have more masters? Could we have a multi-master topology?
07:28
I don't know if there's any information security guys in the room, but if you are, you're going to love this question. Could we implement segregation? Meaning, could we segregate part of the infrastructure, split it
07:41
so they don't communicate with each other, but there's still a functioning salt infrastructure? And coincidentally, now I'm wearing the right hat, after all, let's answer those questions with another question. So, what if we try more power?
08:03
So to solve this, there's something called the syndic node. The syndic node is an intermediate node type, which acts as a pass-through. The aim of it is to control a given set of lower level minions, which means that, in the case of the syndic node, we're going to be having two demons, the syndic and the master.
08:23
Optionally, you can run a minion too. So the way it works is something like this. The main master, which now we're going to call the master of masters, you're going to see why, even though it's already a funny name, sends an order to the minions and to the syndic node. The syndic node relays those orders to the local
08:46
master that is running the same machine, and then that master gets the orders and relays them to the lower minions. So now, our syndic node is actually called the master of minions. And, well, this of course works the other way around, when some of the
09:04
lower level minions reply to any orders, they go first to the lower level master, then to the syndic, and then up to the main master. So if we have the master, which now is our master of masters, it can have as many minions as you would like connected to it,
09:24
then we can have a syndic node for example, a syndic master of minions node, which can also have any given number of minions connected to it. But the good thing about this is that we can even nest levels of syndic, one over the other, and have as many minions as we like.
09:43
So the topology here is kind of up to you. So the only places where you're going to have to ensure connectivity is where the lines are. So how do we actually do this? The configuration is quite simple. On the syndic node, we're going to be setting the syndic master directive. This should point to our main master.
10:04
We also have to define an ID here, because syndic node takes the ID from here. Then on the master node, of course, we have to tell it that we're now ordering all the masters. We're now in control of syndic nodes. In the case of the minions, they should have the lower level minions, they should have the IP address of the syndic node in their configuration file.
10:28
Just a few more steps. We run the syndic node, of course, and on the main master, we're going to have to accept the key, because essentially there's a new key that gets generated. So, now you might be getting the idea behind this talk is to make you think of the possibilities.
10:46
You could have different syndics per environment, development, QA, production. You could also have different syndics to comply with some security standards that you might have, that you might want to come up with.
11:01
Just to mention it, we can even do multi-masters with this. We can have syndics and main masters. We will not cover it here, but just know that this is possible. So, that's it for mine and the syndic node. Now we're on to more heavy metal stuff. Our first stop here is going to be the event system. What do you think an event system does?
11:25
Of course, it keeps track of events, but that's not the only thing it does. The important thing is that events can be acted upon. This system is also the base of the rest of the systems that we're going to see in this talk.
11:42
In essence, this is mainly a 0MQ pub interface. The important things to understand here is that every event has a tag which allows for quick filtering and identifying an event, and also has an amount of arbitrary data inside of it, which tells us information about the event.
12:01
So, with just a simple command running the master, we can already start watching for events, you know, start watching what's going on. We can also use this other command to send a random event that we are, you know, just making it up. You can see that this would be the tag, those would be the data of the event. The data is mainly JSON string.
12:24
In Python it would be a dictionary, because in fact you can also send events from Python code, from pure Python code. And if we did things right after sending the event, this should show up if we were watching attentively to the event bus. We can see that there's our tag and there's our data.
12:45
Now, another interesting bit that I didn't get to make the distinction last year. There are two kinds of modules, state modules actually. The first one is the execution modules and the other one is the runner modules. So the execution modules is the main kind of state that you see in salt.
13:06
It means something that is going to be run on the minions, whereas the runner modules are going to be run on the master. These runner modules can be synchronous or asynchronous. They are added via the runner directory configuration in the master file.
13:25
And that's the best part. What do we put inside that directory? Pure Python code. So runner modules are essentially Python code. And an addendum to this, since we just talked about events, any print statements that we put inside our runner modules will be converted to events.
13:49
So if we do this inside a runner module, we will get something like this. The tag is not quite nice, but there's our data.
14:02
So even though you can write runner modules, and you're certainly welcome to do so, it is tempting, but there's actually no need. I mean, there's already a full list of runner modules available in salt in the documentation. So feel free to check those out. Now, wouldn't it be nice to live in a place like that?
14:26
Sadly, we're not talking about those kind of beacons, but kind of. Salt beacons are like those concrete towers with a light bulb on top. They're also a kind of single. Or something like that. I mean, they use the event system to monitor things that are happening outside of salt.
14:47
And when something happens to those things, a notification is sent, which is actually an event. So those are configured via the minions configuration file, because we're actually interested in the minions at this point.
15:02
And any system administrators in the room? Does any of this ring a bell? Something that is, you know, notifications? iNotify, maybe? Okay. Yeah. I mean, iNotify, which is a file system monitoring
15:22
API to track changes on files and directories, kind of looks like this. So, in fact, there is an iNotify beacon, which you use to monitor changes to a certain kind of file, to a certain file, in a given time interval.
15:42
And there you have it. Any time the resolve.conf file changes, we now get an event. There's also other types of beacons, for example, a process. We can be monitoring whether or not a certain process with a process name we specify is running or not.
16:02
If it's not running and it starts to run, we get an event. If it's running and it stops, we get an event. So, kind of nice, right? There are actually several beacon types. Memory, disk, system load, network settings. It works. There are really a lot and they're growing. I'm just going to leave you... You can also write your own, of course. I'm
16:23
just going to leave you the documentation here so you can check it out later. Now, this is where things are going to get a little bit more interesting. Yeah. Like that. It would be nice if actually the reactor was like this. Believe me, it's actually close.
16:41
So, what is the salt reactor? As its name implies, the main job of the salt reactor is to react, but not react in a JavaScript way, thankfully. To react in a salt way, or salty way. In other words, the reactor is the component that is responsible for triggering actions in response to events.
17:03
So now you see why we saw the event pass earlier. Of course, we need the event system first, but what is an action? Since we're in salt, an action is essentially a state that we define. And what is actually going to happen in reality is something goes something like this.
17:22
Something is going to happen. If we think right, there's going to be an event. Maybe because this something was being monitored by a beacon or something else. And the event is going to be picked up by the reactor, and the reactor is going to translate that event into an action, or actually a state.
17:42
Reactors are defined in the master's configuration file. It's a component of the salt master engine. As we said, the reactor will be making disassociations. The associations, if you remember what an event was, you remember that it had a tag.
18:00
A disassociation is made via the tag. So we put a tag in the configuration file, and we define which states are going to cover that action. Syntax here is quite clear. Do note that there's an asterisk there. We can use wildcards, because some events are fired by more than just one minion, and have the minion ID in the tag.
18:22
So for example, this first one here is the event of a minion starting up. So if we want to match all the minions starting up, we just put the wildcard in the right place. So this whole slide is actually the main reason I'm here. It's the one thing I
18:43
spend the most time while working with salt, so I ask you to please pair with me. There are a few k-bats. The state system that we just saw here, those are states living inside the reactor. The state system is actually rather limited, and you can easily skip this while you're reading the documentation and trying out your reactor states.
19:09
Trying to run things that would normally work in the rest of salt, in the rest of the states that you have, might not work here. You will find that things are missing, and for starters, forget about grains and pillar. Grains and
19:23
pillar are not available in the reactor. If you choose to use those, you get unexpected results. Also, reactor states are actually processed sequentially. They're first rendered, and the data is then sent to a worker pool. But since they're first processed sequentially, you're going to want to make your states as simple and as small and as fast as possible.
19:47
So, after long hours of fighting over the reactor and tearing the little hair I have left in my head, this is the short version. Do not handle logic in your reactor states. This might be a bit too confusing, because what's the point then?
20:05
I'm going to explain it in a bit more detail. You should use your reactor states for matching, and then decide which minions to which states, based on an event. And then, just call your normal salt states that you have lying around. Do not try to add
20:26
some logic here. You're going to spend a very long time, and you won't be happy about it. So, I don't know if this is actually true. It's what it looks like from the outside. It
20:42
appears there's a disconnect, because we're talking about two different engines, even if it's under the same daemon. I like to think it's because of Python namespaces, but I could be wrong. But so, too long, didn't read. Do not handle logic there. So, as we said, with the reactor we're associating events to states, so if we have our custom
21:05
event, and we have our custom reactor state file, the idea is to keep it as simple as this. And if you really have to do complex things, and ensure that many, many things are done when a given event is fired, just put those inside the long running and complex state.
21:25
So, once the reactor parses this and sends it to the worker pool, this will be running on the main salt namespace, so to speak. So, what can we use a reactor for? One good example is auto-accepting all the keys of all the minions in our environment.
21:46
It's quite a hassle. Every time you start a minion, you have to go to the master, accept the key, and so on and so forth. So, as you might have guessed, whenever a minion tries to authenticate, an event is fired, and whenever a minion finishes starting up, there's another event.
22:05
So, for the purposes of this example, we are going to assume that all minions whose names start with nice are going to have their keys auto-accepted. So, first of all, in the state that's going to be dealing with authentication, we'll
22:25
first want to remove the keys coming from the minions that have failed to authenticate. The next step is going to be to trigger a minion restart, and now I know this is ugly, this is just for the purposes of examples. Every time I read SSH in the middle of another language, another configuration management
22:44
system, I kind of creep out a bit, but this is just an example. What we want to do is have the minion re-authenticate, generate a new key, so to speak. So, reaching the end of our big state, if we are in pending status,
23:01
of authentication pending status, and the name starts with nice, we accept the key. As for the last state, when the minion finishes starting up, this is actually a good practice that you can implement. Whenever a minion finishes starting up, we apply a high state to that minion.
23:21
This is something nice to ensure that all your minions are consistent, at least when starting up. Note here that we've been hardcoding the nice, and maybe some other things around it, because, as we said before, we don't have the grains, we don't have the pillar, we don't have a safe way to store information, make it available to the reactor.
23:41
So, keep that in mind whenever you use the reactor. Our last component today is going to be the API. Of course, Salt has a REST API. The main idea behind it is to send commands to our running master, and the API supports both encryption and authentication.
24:03
The authentication, which is something that you might not see very usually in Salt, well, Salt has an external authentication system. It allows for authentication against LDAP, against PAM, it also has access control in it. So, it's really outside the scope of this talk, it's a very big thing to talk about, but it is worth mentioning that it actually exists.
24:29
The entire things that are managed by the API are controlled by another demon, the Salt API demon. So, if it's a REST API, we can of course use anything that can make HTTP requests and get information from it, or send information to it.
24:46
In this very short example, we are making a request to a certain URI for minions, and if we pass the correct minion ID, we're going to start getting data about that minion. In this case, for the sake of simplicity, we're not using authentication here.
25:07
Now, there are several API endpoints available, already bundled with the Salt API. They're pretty much self-explanatory, but let me draw your attention to one in particular, the slash hook.
25:22
This is a special endpoint. It's a generic webhook entry point, and the whole reason for existing is that any POST requests that are done here will be generated events on the master side, on the event bus. And the POST data that we send to it is going to become the data of our generated event.
25:44
Another important thing, because this is a special endpoint, it's the only one that Salt allows you to explicitly disable authentication in this particular part. The thing is, if you disable authentication, it does not mean that you can do whatever you like. You're expected to implement some kind of security.
26:05
Why would you be disable authentication? Well, I like to think of apps that can barely perform an HTTP request, that can barely understand a URL, so they can only do a request with a special hard-coded token that you specify, so that's why we have that there.
26:28
Now, how about, from all the rush that we've just been in, how about we put them all together, be nice and friends.
26:40
Now I know you might be better here, you've seen a lot of information, and I think that you might be a little bit confused, but I assure you we can do pretty interesting stuff, although we saw the events, the beacons, the reactor, and the API. Now, more graphical understanding of how all this connects together, we first have the beacons and the API.
27:09
The main interesting point about these two is that they're related to elements outside Salt. The beacons monitor things outside Salt, and the API, it's an API, so anybody
27:21
can make a request to it, so they're both related to elements from the outside. Now, both of these two will be generating events in our event system, in our event bus. Those events can be later picked up by the reactor, given what we define inside the reactor, which then can be translated into Salt states.
27:42
Now, with the greatest possibility of having to manage your entire DevOps slash workflows infrastructure, comes a great power. And there's a deliberate reordering of the phrase here, because if you configure Salt properly, you're going
28:01
to have full control of everything in your infrastructure, in your workflow, everything, and from within Salt. So as such, you're expected to know what you're doing, and you should always rely on a sensible way of doing things. For example, beware of the security risks. You might be tempted to give way too much power to
28:25
Salt, and that's a good thing, but beware of somebody trying to do an ugly thing with it. So, to finish this off, let's take a minute, talk about what all you can do with all of this.
28:41
I'll just be naming you a couple of examples from the top of my head, and leave you to think the rest. That's because that's what Salt is. Salt is kind of like a batteries included approach to give you the space to create your own solutions, much like Python is, which is why I love Salt.
29:02
So just to name an example, let's talk about self-healing. Anybody know what self-healing is, what it consists of? Anybody heard the term? Okay, so in more humane words, self-healing is the ability that we give our applications or systems the ability to repair themselves whenever something bad has happened, whenever they encounter an adverse situation.
29:27
On their own, that's the thing, that's why it's called self-healing. Now all this might just be a REST API call away, because if in your application you can identify that the bad thing that has happened can be corrected by something that can be automated, you can do it with an API call, because Salt can have control of that.
29:50
Or another example, and I think many of you have encountered this, let's say half your team refuses to use Jenkins or the CI tool that you're using. Fear not, because you can leave them be wherever they are using and integrate the rest of
30:05
the push, build, test, deploy, endless CI cycle with Salt. You can manage it with Salt too. Another example, if you were talking about scaling both up or down or sideways, growing, shrinking, you can prepare for it with Salt.
30:23
And you can also trust in Salt to do some provisioning. We haven't covered it here, but Salt also has a Salt Cloud daemon to provision cloud instances. Last but not least, with a good beacon setup, you can make sure that your environments are consistent. If you have things that aren't supposed
30:41
to change and you suspect that somebody tends to do nasty things, with the beacons you can react immediately upon any changes that you deem unwanted. These are mainly all the examples that I could think of with the short time that I was given, as I said before.
31:02
I really do hope that you can leverage what you saw here to come up with your own solutions, because I'm sure that your problems might be worse than what I simply presented to you. As for the docs, and as for last year, all the documentation is in the official SaltStack documentation. I really encourage you to take a read.
31:30
If you have any particular questions, there's also the possibility of bothering the guys at the salt-free node channel in IRC. I do that a lot.
31:40
We're reaching the end, so now we have time for some questions, so feel free to shoot away. Can you compare Salt with Ansible?
32:01
I'm going to be honest with you, I haven't used Ansible. I know that it maybe has a more basic approach. What I've been told from the people that have tried both is that Ansible lacks some components that salt has, like the reactor for example. So it goes around those lines. I was wondering how one could use salt as a deployment tool. Is it feasible to deploy a complete web application with it, or
32:50
is it just well fit to set up the system and then you need to revert to a proper deployment tool to deploy your application? For application deployments, right?
33:01
Yeah, web application, so set up a database, do something, put some basic data in it, deploy your Django application, set up the web server and things like that. Yeah, I mean, maybe that was covered in the previous talk, which is more basic, but no no no, that's a very good question. And yeah, you can do it. You might have to handle a slightly more manual
33:24
approach in order to tailor it for your environment, but you can certainly do it. And if you're thinking of doing some bare metal provisioning, you can also do that, not exactly with salt on its own, but salt has format integration.
33:40
Format is a provisioning software that was mainly written for puppet, but now has salt integration. So you can do the whole cycle from it. Hello, I understood that the communication channel is SSH, is it correct? Salt has a way of working with SSH, but it's not the main way that...
34:05
What I want to ask is how do you handle minions that are running Windows? That's a very good question, actually. It is possible, but I'm sorry, I've never had to do it. I have been a little bit playing around with that and found a way to insert an SSH daemon in Windows that's using SuckWin that has an SSH.
34:28
It seems to be working, I'm just curious if there are other options. Yeah, I mean, as long as you are aware of any limitations that you might have, it should work. The rest of the system is shared and it's the same.
34:44
Thanks for the great talk. I'm using Salt for three months. It's really cool. There is also one stuff we are using, engines, getting some additional events. And currently I'm looking for a way to make pillars dynamic. I want pillars to get information from console or from etcd during deployment.
35:10
To get some key information from key value storage external. Is it possible? I'll have to look that up. I'm not entirely sure, but everything appears to be extensible in Salt, so I don't see why not.
35:28
Yeah, maybe it is. Hi, how do you upgrade Salt without SSH or is there any good approach to do that?
35:41
Upgrading Salt without SSH, you mean the master and the... I don't think I understood where you were going with the question. Oh, you need to have access to the system. You need to have access to install the new version and you also have to restart the agent.
36:09
Actually that's one thing that is still not handled very well in Salt, is restarting minions whenever there is an upgrade. Because you can't do it from inside the master. Because you are going to be losing communication for a bit.
36:22
Yeah, it's kind of a tricky spot still. Regarding the question about dynamic pillar, I think it's possible Salt has a mechanism to get a pillar from external services.
36:41
You can implement Python model to... There is a plugin called glass which uses that to make pillar more usable, in fact. The question is, how do you test your states? We have several breakages in our production due to human error.
37:04
I know, I know. I don't have a production system. I use Salt for personal uses. I don't have the luxury of working with the Salt environment. But I know where you are going with it. It would be nice if you could have a development environment or QA to try things out.
37:25
Because once you made a change to a state and Salt doesn't like it, it will blow up. So, it's kind of tricky. You have to keep looking at the logs and be very careful what you changed. You are bound to have the last change that you made cause a problem if you see a problem.
37:52
How do you handle provisioning new servers and how do you handle your inventory of servers?
38:08
Let's answer the first question. Provisioning is done in two parts. We are talking about bare metal provisioning. You have to use something like Foreman that allows you to boot a system and then apply Salt states to it.
38:20
So, Salt is like Puppet in that way and it's not like Ansible in that way. It doesn't have the ability to provision a system from bare metal from the ground up. When the system is already installed and has a minion running, you can do whatever you want with it. As for the catalog, the inventory, from the perspective of the master, all the master sees are minions.
38:45
So, it is up to you to group them using node groups or grains or whatever you deem to be necessary. You would be basically setting your categories on your own, building node groups, setting grains on certain minions to identify them from the perspective of the master.
39:04
But essentially there is no way of distinction. In fact, when we talked about the syndic node, the master of masters will see all minions connected to it, even those from lower level syndic nodes. So this is in response to the question about testing the Salt states. We do this.
39:30
We will use Vagrant on your local machines with a masterless minion setup and then spin up in a number of VMs and actually test the states at least at some minimal so that we can catch human error like that.
39:43
Because we have the same problem. How we deploy across hundreds of machines simultaneously in one error can really mess up your day. So I have tried with Vagrant. Locally it works pretty well because you can spin up different kinds of VMs. We use FreeBSD or Ubuntu or CentOS and you can simulate a lot of those environments easily.
40:01
Interesting. Thank you. Hi, thanks for the talk. I am seeing a pattern here. I am seeing that most of the questions we are asking about Salt within that Salt can't do can be done perfectly using Ansible.
40:24
Like initial system configuration or maybe someone asked about service management. I know you already said you haven't used Ansible but have you heard about someone using Ansible and Salt together?
40:42
No. Pretty much when somebody chooses a configuration management system they like to stick to it. It has to do with the learning curve and all that stuff so it will be harder. From the very few things that I have seen from Ansible it is quite different from Salt even though both are written in Python, even though both use YAML.
41:02
They are quite different. Every organization wants to choose one technology and stick to it. Well, that's interesting. If Ansible can be used for the bare metal provision part and Salt maybe for the rest or Salt for the reactors.
41:23
You could certainly mix those two. I want to create a machine to install SaltMaster on it and to configure it and then to apply high state.
41:42
Are we talking about the Fabric Python module? Yes, right. The one that comes from Paramiko. It uses SSH to make a basic provisioning to start with your machine to put SaltMaster on it and then use SaltMaster and the full power of Salt.
42:03
You can also do that. We have time for one more question. Or not. Thank you guys. Thank you guys.