Configuration Management with Salt Stack: Zero to Hero

so if you want to follow along you can we're gonna make some cool stuff in salt you can run it if you want the instructions on how to do that you can go here and at least download salt which you know let's see if we can break the network real quick how's that sound cool lovely uh how's everybody doing good perfect about two hours ago the air conditioner unit in my room started making this lovely just didn't stop so that was lovely but anywho hopefully everybody saw that recently I'm Wes I am a Mac operations engineer at square and today my talk is configuration management with salt and we're gonna try and do a quick zero to hero if that is okay with you who here has ever heard of salt or salt stack knows what it is cool that's awesome is anybody is anybody actually using it Greg nice yeah sweet two out of 75 not too bad yeah maybe after this you will know so first things first what is configuration management if it's to sum it up it's the process of maintaining the configuration of a system in an automated fashion it handles the control of things like files users services which in the max case would be launched Damons and profiles defined configurations are normally stored in some variation of version control and normally those are in some type of code as you would do in version control and it's responsible for making the necessary changes to a machine to put it in the desired state so I'm sure everyone's wondering great we have a nother configuration management tool talk is this like the 17th one we have so sorry so we decided to use this one and I'll go over a little bit why we picked this one versus the other ones that are out there so why we pick salt first and foremost we gave a few of the popular ones out there a try and we notice that the barrier to entry was a little bit difficult it either required a specific dsl or you know you had to code everything was was code so we have a bunch of like younger folks that like to contribute to our team and this was an easy way to get them going quickly so there is no coding required if you don't want to everything is just yeah Mille which is some people say it can be quite difficult with white spaces or whatnot and another thing we liked is pretty much every single thing in salt is easily extendable so if you find an issue or a problem with like one little module you can easily duplicate that module and fix it and boom you're good to go and writing custom models and stuff and salt super easy and the number one thing for us was it was Python and you can easily get to the Python objective-c bridge which allows you to do some fun stuff with a native API s-- on Mac OS and the biggest thing is that it is not written in Ruby because really does anybody actually like Ruby okay that's what I thought and then so the fun thing about a lot of the other configuration management tools that are written in Ruby if you want to do objective-c stuff you have to shell out to Python then go back to objective-c so that's really efficient or we could just do it natively okay so what's the plan what are we going to talk about so first we're gonna install salt and configure it from master list we could do a master setup but you know we'll keep it all local make it nice and easy then we're gonna go over some different vocabulary and modules a different module types so when I talk about certain things in salt you're not like what the heck is that and then we're gonna go on we're gonna write some simple states and we're gonna show you how to target them to specific machines and then we'll get a little more advanced we'll write some advanced States and then we're gonna have a lot of fun and we're actually gonna write some custom modules or I'll show you ones that like I've written that are super easy well and then we'll show you how to run those custom modules and then we'll cover high states which is well we'll get there well let's go so if you wanted to you can download and install salt either through the repo or if you have Auto packaged there's an auto packaged recipe for it because who doesn't love auto packaged recipes okay and then I made a little git repo for different steps and running different things with so you don't have to like copy them out and type them down they're just all there on your machine and then set it up you just CD into the change the directory into the salt PSU repo and then copy the minion config after you've already installed it into at sea salt minion so that's where salts native minion configures and then you can make the SRV repo and then that's well we'll take all the source files and that's the place where will serve the files to salts and all our different states and modules will be in there and that's where salt will look for them once you done with that you can stop the launch daemon and restart it cool so salt terminology let's learn some new things the first one this is a salt master which is normally the server piece that would be responsible for serving the different files and instructions to minions and sending execution commands if you want but in this case we're master list so that doesn't necessarily matter but the minion is what is the your computer in this scenario so normally you would have a master and then minions which would be like other servers if you were doing this in a you know like a a server environment but with clients in portable laptops will do master list so no matter where you are you don't have to always be connected to a master to do things States states are and this is like gonna sound almost too easy but states are what you use to determine the state of a machine easy okay cool yeah yeah yeah so yeah there's like 50 different states that you can have so the state of the machine being a configuration a list of instructions on what salt should do to that particular machine then so salt is mainly built of a bunch of different modules and a bunch of different so each like group of modules performs a different task and in a little bit we'll cover like some of the unique modules that we'll go over and what they actually do and then lastly we have salt call which is going to be the command that you run to invoked different salt States and different execution commands so let's go over those some of those salt modules I was talking about so we'll cover four of these modules in a little bit more detail and we'll start with grains so salt grains are used to derive information from the underlying file systems that it's being run on these are very similar to puppets facts or chefs oh hi I they're called grains because they give salt little grains of information about each machine that makes sense right you can you can see what grains are on your machine and available by just running a pseudo salt call - - grains that'll give you a list of all the key value pairs of the grains and if you want to view just the keys like what available grains are actually on your machine and you don't care about seeing what the actual values of them are you can just do so-called salt called grains LS and if you want to yeah you could you could go ahead and just run those you can try it if you want okay execution modules can anybody guess what execution modules do yeah sure when you install the package it should put them in your path if not it's opt salt bin oh yeah that'll yeah good good call lovely okay yes execution modules so if they execute actions on the machine again the naming terminology is pretty simple so it's easy to understand salt comes with about fourteen different unique Mac OS specific modules which is pretty neat so they have done a lot of work with Mac OS already I and a few of them that are available one is Mac service which controls launch Damons there's also the Mac defaults module that as you can guess is a wrapper for like the defaults command and there's also the Mac package util module which allows you to install packages and inspect those packages if you want and there are dozens of other cross-platform modules that also work on Mac OS so let's take a look at using some of those execution modules so for instance if you want to list all the available launch daemon services you can just do salt call service dot list and then if you let's say you wanted to get the software update catalog URL from the machine you could just run salt call software update dot get catalog let's take a brief look at like the syntax that's here so a software update is going to be the name of the module and then after that after the period is the name of the function that's in that module that you want to call and if there are any parameters to that you just pass them later which in this case would just be if you want to set that URL to a sweet URL so state modules I I wonder what these could possibly be used for so state modules are responsible for the configuration management portion portion they take the instructions that you've given salt and they're responsible for making sure that it's in the correct state that you want so packages are installed services or running files are there all that kind of stuff state modules are the item potent portion of this which is basically a fancy DevOps word for not running everything all of the time if you don't need to so it checks to see if something is in a particular manner or in a particular way and then if it's the way it should be run sit again you're smiling Alistair [Laughter] so I actually this morning I had a really good idea at least I thought it was to do a DevOps bingo so everybody would have gotten a nice little bingo card and then if I set a particular DevOps e or configuration management the fancy word then you know you get to check off the bingo and then somebody wants a prize at the end fortunately not enough time to make that and print out so many copies or so but anywho so back to the state modules state modules are actually all multi-platform a majority of them so a single state module is actually responsible for the same type of configuration on multiple platforms because they all pretty much have the same idea and the same concept they just work different ways on different platforms the last one we'll cover is renderer modules so the only thing that salt really cares about to define the state of a machine is it's just a Python dictionary so renderers take any type of data that you have or like a data set that you want and then it just converts it into a Python dictionary so if you want you can write States for salt in llamó with Jinja you could write it in pure Python if you wanted you could write it in JSON or even each JSON say let me know what each JSON is I did not know that until like going over render modules nobody it is actually it's like a yam Oh JSON hybrid it basically allows you to put comments in JSON and it's a little bit more human readable I found it fascinating and it's actually kind of cool but yeah so if you wanted to define information insult and it's JSON you could so you're not bound to one specific way of doing anything okay so let's actually write a state since we've talked about it about 75 times now so we're gonna go over the yeah mole version of assaults state syntax which is how most of the examples are in the documentation if you couldn't tell this probably isn't going to run anything this is just the template of how its organized so we're gonna change this into a state that will manage a file with certain contents in that file so the first one here is ID the ID is a unique identifier to in a human readable way describe what you're gonna do in the state or what it's doing in this case we're just going to make a file so since salt states are just a bunch of Python modules we need to be specific about which ones we want to use seems pretty reasonable so we want to manage a file let's use the file module so after that we should specify which function inside the file module we want to use and in this case we want to manage a file so we'll use the managed function inside of it so next we're going to was we need to tell salts where we want the file otherwise it's it has no idea where wants to put it or what you want to do with it in this particular state that's going to be covered under the name parameter and this will be the location of the file that you want to manage as an absolute path so in this scenario we'll just make a file in temp salt PSU and a file to manage because I couldn't think of anything clever to put there fluffy unicorn bunnies maybe I don't yeah so functions often have multiple arguments to control different ways of doing or like controlling that particular function so by default salt will not make a directory for you if you don't want it to this parameter is false by default and I doubt anybody actually has temp salt PSU on their machine so you need to tell salt that if there is a directory missing create that directory as well so we can resolve the entire path and then for funsies we'll go ahead and put some stuff in the file because you know what's the point of just a blank file sometimes so one of the other parameters that available is the contents parameter and we'll go over showing a list of like providing a list to our parameter so for the contents in the file on the first line so each item in the list is a line of the file so the first one will do we made a file with the string on the first line yeah that was pretty easy right on the second line yeah super super easy so I bet you're wondering cool we just made that sweet file probably nobody is a courier we've made that awesome state file how do we run it how do we do that so it's pretty simple if you've done the instructions so far you can just run salt call state dot apply which is saying give me the state execution module and I want to run the apply function that's in there which then runs other states so this particular one is in the state's files file dot example or a file - example and if you run that you should see output similar to this so by default salt doesn't really give you any output during the run it tries to keep it quiet and then at the end it will give you a summary of what's happened so in this particular run the output will give you on the top line the ID which is that unique identifier in this case it was make a file and then it'll tell you the function that was used we used the file managed function and then the name or in this case the path where the file was that'll be in the name and as you can see it was true it worked and then each state has a comment so you know what actually happened and in this case that file was updated and/or created you can see some started in duration times then also the changes that took place so which in this case we made a new file and our total summary so as you can imagine when you have more and more states these numbers grow so in this particular scenario we ran one successful state and there were one set of changes and it took all of 22 milliseconds to run I would do it live but live demos are not my forte so for funsies I changed the second line of the file from that was pretty hard there from that was pretty easy - that was pretty hard I ran salt again and it's telling me that the diff that it did after it successfully ran was it changed that second line back to what it should be which was that was pretty easy I mean what's pretty easy does anybody actually doing it live no yes no maybe so not working oh I would like to play along but I'm missing the portion where does the master let's set up yeah so I be if you copy the minion file over and then you restart the daemon it should be in master list already if not you can just add - - local and that will for sure specify to run locally so as I'm sure you know if you manage more than like two machines each machine is probably a little bit unique and you need to apply different things to different machines so how salt does that is you can specify in what's known as the top file and this gives it a bit of some instructions on which machines to apply them to so let's take a look at a super super simple top file so in this top file it's going to use the base environment which is here at the top you can specify multiple environments however many you want you could do base dev production you know wherever you want this particular in this base environment we're going to specify that all machines get the next particular set of configurations so any machine that has this top file run on it will get every single state that we specify below which in this case would be monkey OS query encrypt so this is a little bit more of a advanced top file so as you can see we have just our base environment and this particular set will only run on a Mac OS device and how it's doing this is it's basing it off of a grain so as we talked about earlier grains are they provide different information about the machine in one of those grains is the OS type and in this case it's Mac OS so it'll then run in our if we had a full set up of directories and different states in this particular case it would run the state's Mac file or state so if a particular minion was configured for a dev environment then and the OS release version is 10.12 which is also being matched off the grain then that machine could get all the states that are in the 1012 directory then for we had a production environment setup you can do some conditional logic so if the OS is a Mac and the host name is Baz of some sort then these states will be applied so but let's say we had the same top file but no environments so salt doesn't just stop at the the first one so say we had a Mac that was on ten twelve it would run both of these but if that Mac that was on ten twelve had a host name that has bass in the name then it would get all the above states okay make sense anybody have any questions about that particular top file no cool yeah sure up here wait for the mic if you don't mind Thanks are you providing the name for those states themselves or those built in the salts no those are all provided so in the like the SRV directory that we made earlier it'll look inside of that for for these there would be a directory called states and then subsequent directories underneath them I'm gonna actually go a little bit deeper into this a little bit later but I just wanted to touch it a high level right now cool all right so let's look at some more advanced states because just writing a single file with like a couple lines inside of it it's probably not what you're going to be doing to a lot of machines possibly but we'll look at some more advanced tactics here so for advanced States the first thing we look at is specifying multiple states under the same ID then we're gonna take a look at requisites so what records requisites are or they are a way in salt to connect different states and perform certain actions when certain things are true then we're gonna look at doing some templating in Jinja if you've ever used Jinja and this will be pretty easy if not it's still pretty simple and then we're also going to take a look at different renderers and in this case we'll take a look at how you would make a state that's using the Python renderer anybody want to take a guess or what this state does No yeah sure so this particular state we're going to say that it's actually monitoring the application usage launch daemon that comes with monkey so we want to make sure that a file exists on the system and in this case we also want to make sure that a service is also running which should be a launch daemon so for the top piece we want to make sure that the file at library launch taemin's comm Google Code monkey app usage monitor is there and the source of that where you see salt colon forward slash forward slash is actually saying make sure that the file that we have in our repo which in this case would come out to wherever we have it and when I was doing this locally it was in my downloads folder for everything else so it'll take that file and make sure that it is at library launch Damons make sure that the permissions are root and wheel and with the executable of 64 4 or the mod permissions this piece of the state will make sure that the service is running so salt will use the same name for multiple platforms so some configuration management tools might have this labeled is like launch Damons or launch de or launch CTO I salt tries to bundle it all underneath one name so you can run it on multiple platforms and you don't have to specify multiple things so in this case launch Damons or services and we want to ensure that that launch daemon is running and we're going to check that calm cool code monkey dot app usage monitor is running running and you're probably wondering okay how does it know that name or how do you know - how to which name to specify so if you look at the actual launch name and P list you can use the label key if you want you can also specify the full path to where it is or just the file name so now let's take a look at this fun little guy called watch this is a requisite so the service module in salt if you specify a watch requisite it will and if any of the requisites are true it'll restart the service and to specify that you specify the module that it needs to watch which in this case is the file module and then you need to specify the name of the other state you want to manage which is matched here you can also specify the unique ID if you want to instead of the name which we could then put just monkey app usage launch daemon so if any of those other states get modified in any fashion salt will automatically unload and reload app usage Monitor launch daemon so let's take a peek at another requisite this one's called on changes mm-hmm so in this state we're going to make sure that a line is appended at the end of a file and the file that we want to make sure that we have a line at the end of is at CASL kampala install and we want that particular string of text at the bottom of the file so this is actually a state for OS query and this will make sure that the Apple install logs get also sent to syslog so OS query can gather them up a big shout-out to the Airbnb security team for finding this and putting this up so this is a state to manage that so we have this this other state declaration in this IDE called command dot run so command dot run by default will not actually run anything unless there's an action to cause it to run but if that action that would cause it to run is true it would run this command which is disabling the syslog and turning it back on but the only way it would do that is if again the particular state file which in this case whoops too far is the at CASL coppola install file so if that's modified then it'll run this command so now let's take a peek at using jinjun States is anybody actually used Jinja it's more of like a web development templating framework Shea Craig's probably like it's great more Jinja so that's the default template that salt uses so in this state let's make a file using ginger so Jinja can specify grains if you want to so in the top file we had like different OS versions but say you don't want to like make 75,000 directories you can make a single state and then in that specify different objects if you want to based on different conditionals instead of making the same state 75 times you can make it once and put a little templating inside so for this particular one if the OS release version has 13 in it so at 10:13 machine it'll make this file but if it's on a 1012 machine it'll make this file and if it's not on 10 12 or 10 13 then it'll make the file that we don't know what we're on we could actually make a file with the actual OS version then we have but you know this is what we decided to go with so this is a local example of that requisite of on changes so if in this particular time you need to specify the ID because you don't actually know which name is going to be there so when you specify the ID if anything any of the files that are modified it'll run that command so say we wanted to do that you can run it this way states files file Jinja with state dot apply and this particular one was ran run on a 1013 machine so as you can see the file Mac OS underscore 13 file was created but after that it saw that the file was created so salt was like oh you told me to run this particular command after something was modified in which this case we just ran the command echo we made a file so we should run this command and here's the output from that command being run so it captures the process ID that was spun up to run this command the return code was zero there was no standard error output and the standardout output was we made a file so we should run this command che Craig told me I should do this with Cal se which it's actually kind of funny but that was more slides to be made so I decided not to and the normal output and the summary so let's say you are one of the people that 100% everything must be in code then if that's the case the Python render is probably for you you could write a state file with something like this it's good a little bit of a closer look to specify which renderer salt should use in this particular case just a shebang pie and then all that's needed or the only thing salt will check for in this particular Python State renderer is a function called run so like I mentioned earlier the only thing salt really needs is just a Python dictionary so let's make a dictionary here that we can add different state configs to and let's say we want to make all of these files foo bar Baz bat-ball banana salt would loop through this list and then it wouldn't make a state file based on the name of the file and it would add inside that file the name of the file so we made a file foo or we made a file bar that with this string on the first line and then just return that dictionary and salts pretty happy so unfortunately the folks that wrote salt weren't capable of thinking of everything that you could possibly want to do so sometimes you will need to write your own Python modules or functions we're going to show you how to write just a simple execution module in this case and how to call it or test it in this case so this is a super simple [Music] execution module as you can see at the top we're just importing a few different Python libraries and setting up the logger Logging's good so in case anything breaks getting logs is always good so how salt decides which modules it should use is all done with the virtual function and then the virtual name so if you have a execution module called Batman and Robin and you really wanted to confuse people you could tell salt that the actual name that people need to use for that particular module is called foo so before salt performs any actions it goes through when it compiles all of the available execution modules and what's available so in this particular case I if this module was run on a Windows machine salt would return false that module dot foo is only available on Mac OS if you tried to run it but since we're on a Darwin machine it'll return foo so salt now knows this module is named foo and we have one function in here called bar that takes the parameter bass and what this will do is it will run another salt execution module called command run which what we saw earlier in some states and then it'll pass the parameter bars to that other module I mean this is a little bit redundant because you could probably just call the command outrun but as a super simple overview and then we could go ahead and just run that locally so you could do salt call food up bar with the parameter echo we ran a command and your output would be you ran a command super easy if you know a little bit of Python so let's take a quick look at also running a state module so this would be used to make sure that a certain custom object that you want is in a particular state and then this repo it's in salt PSU underscore States is where you would put any of the extra state modules you want so while I was preparing for this talk and and writing it up I was looking at all the different Mac modules and I stumbled across the software update module so this is an execution module so if you tell salt to do this it'll just run it every time execution modules are not item potent they'll normally just run every single time that's the idea behind it is when you run an execution module you want to execute that no matter what but I was just like hmm I don't think there's an actual state module for this that would be item potent so we don't run something every single time salt runs it's not very efficient so I looked at the different spots for different modules like there is no multi-platform software update module so I was just like okay that's right run will quit right one real quick and here it is so let's take a peek at the import oh no wait you guys can't see that that hey Siri enhance oh hey thank you that's the first time you've ever worked so again we're importing and setting up the logger specifying the virtual name again like the previous execution module this is literally only on Mac OS and I wanted to write a state function that's called set catalog and what I wanted that to do was make sure that the software update URL catalog is always set to one particular thing and it has a simple parameter which is named all states have a name parameter and in this case it'll be the URL of the software update catalog you wish to set or if you pass it default it'll set it back to the default catalog for what are there whatever that particular machine is so when we saw all that output from previous states they all had like a name a result what changes were made and a comment for what was run in that particular case so we can easily set all that return values up here in just this simple dictionary so before we set the catalog we should check to see what the actual catalog is so in this case we're telling salt to run the actual execution module software update get catalog and we're gonna store that as the old catalog value then we're going to check to see if the old catalog value name matches the name we want it to be if it does then we're good it's in the state we want it to be we don't need to run anything else so we'll set the comment to the software up catalog is already set correctly and then we'll return the information but let's say it's not we need to change it to what we want and in this case we're going to use the software update dot set catalog function and pass it the name which would then run that execution module and with that particular execution module it'll check itself to see if it actually ran correctly some don't but for this one so if it didn't run correctly then set cat would be false and then we know that the result of this state run is false and we can set the comment that we failed to set the software update catalog but if it's true then we can say we set it correctly and then you know how it did the diff at the end for the changes so we would say well the old catalog was set to this and now the new catalog is set to whatever the new one was so if you were at macca duck pricing gave a really good talk on python docstrings so this is how salt documentation works so in every single function and at the state you can you know write a big doc string that tells you how to use your custom state and these are examples of some of the yeah moles on how to set it I also made this state run or make sure that the schedule for Apple software update is always on and that's how you would set up a state to use either of those so just software update dot set catalog we want to make sure it's the default catalog and then we want to turn on them updates so software update schedule with the name on so anybody have any questions around writing custom state modules or execution modules nope okey dokey I'm assuming everybody knows what's going on right yes yeah it's fun once you get into it I promise now I sound like one of my friends trying to explain a board game it takes like seven hours to play it's gonna be fun I promise so salt has what's known as a high state and a high state is whenever salt looks at that top file and it goes through the entire salt repo that you have and decides which all states it should run so when we run a high state with this particular repo setup it will first look in this top dot SLS which what we looked at earlier which in this case we want to on just Mac OS machines mash off the grain we want to run everything that's in the states directory so let's take a look at the state's directory it'll look inside the state's directory for and an it file which then you can specify other states in so you don't have to end the top file list out 85 different states you can just slow you slowly work your way down the directory inside the init file there's an include so we want to say in this directory we want to include all the file states and all the software update states so if we go back and look at that directory it'll then look inside the files directory and the software updates directory for their individual and NIT files which we'll just take a look at the files in it file and as you can see we want to run the directory the file example the file Jinja and the file pi states and it'll actually do it in that particular order so if you want to specify an order of operations you can do them in the unit files and then if you ever want to run a high state just salt call state dot high state so by default the salt minyan won't actually constantly be looking for the configuration and where you have a high state or where you have a top file you need to tell the minion how often you want to run a high state and how you do that is you can write a schedule state and how whatever you're using to install salt on that particular machine you can have it run this state which will then set up the rest of the high State for you which with this will run it every 60 minutes and you can only be running you can tell it you're only allowed to run one high state at a time you can have schedules available but not active so with the enabled key we want to make sure yes that the high state is running and then we're going to use the returner so what a returner is is a different module so there's multiple types of returner this specific one we want to say take all that output and return it as a JSON file and put it in the default directory for that returner so we can look at it later if we wanted to and then run it on a splay of 600 seconds so not every particular hour but with display of a couple minutes in between so at square we actually run a masterless setup so we don't have a salt master so you're probably thinking how do you continuously get all the files that you want with the particular changes on the machine if the minion isn't talking to a master to get the files and do all that fun stuff wait for it so salt actually has a archive state where you can specify where you want the particular you want where you want to pull the particular archive from and it's tracked it so in this case we have a tarball sitting on rounded corners in the salt directory there with our tar ball and then we also gather a hash of that particular tar ball and salt will check the hash after it's done downloading against the tar ball that it's pulled down make sure that matches if it does then it'll extract it to the particular directory which in this case is SRV salt and then all the other parameters are so for instance if it'll cache the last known hash if the last known hash matches the current hash it's done it won't even bother downloading the file because it knows what it wants and then say something else is in that particular directory the Key says forcibly extract this archive to that particular directory no matter what's happening so use that with caution keep source says cache the old tar ball around keep it around so you can compare it later and then clean makes sure to look through every single file to make sure that it's the way it should be and then we're also setting some directory permissions there so with this in the high States alt will pull down a new tar ball and extract it and then on the next run it'll pick up the changes and apply them and that's pretty much it anybody have any questions about this particular bit Yes No maybe so oh come on not one so before we go eh oh sorry I totally miss you you may have covered this but um what are you used for reporting like to know that things had actually run from a sort of centralized viewpoint so a great question I thought I thought about throwing this in here but then I was like a little bit concerned about time I so we have a a launch daemon that looks for the modification of where this raw JSON file gets laid down which would be back here so the default for that is at sea salt log or no sorry of our log salt and then it's I think it's minion or either returner so every single time it'll put a new JSON line in that file and we configured we rewrote the salle reporter if you use monkey and you're familiar was familiar with Sal so whenever the Sal report script runs it gathers all the salt IDs and actually puts them in Sal so when you look at a particular machine in Sal you can see every single application that monkeys installed on it and then every single state ID and if there's any problems it'll like it looks for all the logs and any errors and it'll mix them in with the monkey log specified as salt logs it's actually pretty neat so hopefully tonight I'll see what Shay Craig is doing but what I actually want to do is you can write custom returners I want to write a custom Sal returner so you don't have to do the extra bit so every single time salt runs a high state it just immediately takes the information and just sends it directly to South all built in and that could work on multiple platforms - so looking at you buddy yeah yeah any other questions how boring was this anyway learn anything maybe cool that's that's good um so anyway before we go otherwise you know what's the point of doing all this so a good buddy of mine I don't know if you saw grams talk yesterday at the end he mentioned about how recently he got testicular cancer and how he was lucky enough to beat it and so I figured we'd team up and I try to raise some money for the Movember foundation so if you enjoyed any of this or any of the code that I write out there or any of the projects instead of buying us a beer donate if you could great and I guess that's all the Q&A because nobody else had any questions so oh sure yeah does the master ever reach out to the clients or are the clients just reaching back to the master always so and this is actually like one of the really powerful things about salt is if you are using a master it has a constant when it's on the internet what a protocol it's called 0 mq which is pretty fast reliable and that's how it maintains a constant connection so on the master you could run like one of those execution modules and say run this on every single machine that I have right now it's super powerful pretty dangerous I didn't even want to like give myself the opportunity to do something like that but I like that's one of the things salts really known for is its ability to do something like that is like modify 10,000 servers at any given one point with just one line in the terminal on your salt master so that's why we went with master list so nobody can accidentally do something like that um so yeah go ahead and ask the question again if you could thanks the effect I'm a network would it be staggered at all so the communication would be very lightweight because it's just you know it's not like you're sending a hundred megabyte package to each machine you could in that case it would probably get pretty crazy but if you're just running a single execution command but salt does all the magic I am nowhere near understanding of how all that magic works I'd recommend if you're actually like super curious I'd recommend the the salt slack channel like on the salt team and ask in general they're always super responsive and super friendly and I'm sure one of the actual main core engineers would love to tell you about how that works anybody else Allister oh no no comments where can we get one of your attractive t-shirts did you bring enough for the class it's always you you already got one dude okay I I don't just get them for free to like hand them out but maybe next year I'll see you if I can bring some cool square t-shirts so yeah sorry Allister maybe I don't this was probably too big for you anyway so I don't give you shirt off my back now I love you bro anybody else who thank you so much [Applause]

Channel: MacAdmins Conference

Views: 11,425

Rating: 4.7217393 out of 5

Keywords: Apple, mac, macOS, macadmins

Id: EiQty-dVfqY

Length: 68min 37sec (4117 seconds)

Published: Fri Jul 27 2018