 SALT is a configuration management tool. It falls in the same kind of umbrella as Chef and Puppet. It's a little bit different because it's also a remote execution framework which can work in place of multiplexing SSH things and stuff like that. And I'll just say how I came to this because I didn't come to this from the kind of DevOps-y, I got all the machines, I got to make them go aside. I came at this because, okay, I'm just going to let this do its stuff. And I came at this because I've got a Mac. I've been a Mac user since 2005. A Mac want-to-be user since 2001 when they cost $4,500 and were 600 MHz or whatever they were. And I love it. You'll have to pry it from my cold, dead hands, but it's really annoying to develop on. Really annoying. If you're using the package manager, invariably you'll come across something that doesn't quite work. The make files don't work very often for OS X. It just kind of slowly was driving me insane. So I came to use Vagrant, which is this awesome thing that lets you start up virtual machines really easily on your computer made by this guy, Mitchell Hashimoto. And it's really awesome. You just have a really tiny little file that makes a virtual machine. Zero. So this is a Vagrant file. This is the simplest Vagrant file that exists. It just says get this Ubuntu image and that's our virtual machine. So that's where we're going to start from. And as I was saying, I came into this from being annoyed with the Mac. And Vagrant has great support for Chef and Puppet. And I tried those out and we weren't friends. Chef annoys me because you have to write Ruby code. And you don't necessarily know that everything's idempotent that the person who's writing all these modules isn't going to remove stuff, delete, star or anything like that. So I didn't like that aspect of Chef. And I tried Puppet for a bit and I just didn't suit me at all. So I started exploring for less mainstream ones. I'm also one of those kinds of people that's for less mainstream tools. So I came across Salt and that's what I decided to use. So I'm just going to move on to... This is, now I've added very simple Vagrant Salt provisioning. I'm going to show you how to use this with Vagrant initially because I can build up a fairly decent example this way. So you can see it's the same config except now we're telling it to provision with Salt. That's not so interesting. This is now, this is Vagrant. But the way Salt works is it runs this daemon called the Salt Minion on the machine that it is managing. And that machine, sorry, this Salt Minion is responsible for installing all the packages that you say you want installed and so on and so forth. So the setup is that you have the syntax is all YAML. It's in here. And so there's a top file called top.sls which looks like so for now. Let me put that at the top. Okay, so the base is just the name of an environment. This could be if you have multiple environments in your network, staging, production, etc. You can have multiple different environments. The asterisk is which machines to match. So here this is to match every machine. I'm only going to have one machine. It's my Vagrant virtual machine so I'm not going to bother with that. And then just for the basic example I'm saying include the edit state. State is the term that Salt uses where Chef uses recipes and Puppet uses modules, I think, or manifests. I can't remember. So if we go into the edit directory, this is sort of Python-esque. This is all a Python tool so they've got this init convention in subdirectories. And now we'll see what the first state looks like and it's just that. This is YAML. The state says that the VIM package should be installed. Of course I'm going to want VIM on the machine because if I need to edit anything I'm going to want to use VIM. So that's the very basics of it. Package installed. So you have the name of the package and then the state is that the package should be installed. You're saying this is what should be. And then when Salt runs it makes that be the case. So moving on to the next step. I'm slowly building up here. Two. So now I've added some Python packages because we do Python here. So back in the top file, now I'm saying that every machine should have the edit stuff and also this Python stuff. And in, let's do it like this. So this is now getting a bit more complicated but it's the same basic structure. The Python packages is an identifier and then it's saying that packages should be installed and these are the packages that should be installed. Python, Python dev, Python pip and virtual end because these are the basics you're going to need for pretty much any reasonable development in Python. And so that's, so this is now getting to be a bit more of a complicated example of how these states work. I should say if anything's not clear at any point I'm very interruptible. So please go ahead. Let's see. So the next thing is now I'm going to go into a little bit more, much more of a complicated example, which is going to demonstrate more advanced features of Salt. So in Puppet you're probably used to being able to order your modules if you use Puppet where some things require others to happen first. And Salt has just exactly the same kind of thing. So now I've got this. I'm adding a couple more things. So what I'm doing here is I'm building like a super awesome Hello World app that's going to run using Circus. It's going to be super scalable and everything. It's really cool. And so we've got the edit and Python, which are the basics. And now let's go take a look at this. It's the Hello World state ls. Okay. So yeah. So anyone who's used to using PIP knows what requirements.txt is. And the requirements here are it's a flask application. So the requirements are we need flask and flask things. And this thing shall set that the Circus people recommend use. And the application is this super awesome Hello World. It's copy, paste, direct from flask.pycu.org. I'm not very original here, but this is what I want to build. And I want this to be really scalable and really awesome. So that's why I brought in Circus. And I'm going to open up this in Vim because it's a bit longer. Yeah. What's wrong? Oh yeah. You're right. Okay. It doesn't matter because it's not going to be run by me actually. Yeah. That's a copy, paste failure. Yeah. So I'm not original and not good at copy, paste. Sorry about that. But this is going to be run by Circus and friends. And so the it's never going to be run as main. So that's no problem. So I'll go back to this, the init.sls. So here now we're getting a bit more complicated. And salt is from Python people. Python people like virtual end. There's a way to manage virtual ends with salt. So I'm putting it in slash var. And there, virtual end managed. Don't use site packages, bad news. Use the requirements from this location. Salt colon slash slash means get it from the salt master location for all of the state information. And it requires referring back to that Python packages list, Python, Python pip, Python virtual end and Python dev. So it's saying you cannot set this virtual end up until that stuff's been installed. Fairly straightforward. And here's another state that's pretty useful is saying salt manage this file for me. I want this. Don't deploy your apps like this. This is wrong. Don't deploy them with your config management. But I'm deploying my awesome hello world app using salt just because it keeps things a little bit more together. So I'm saying manage this file for me and get it from here. So that's the little app.py I showed you with the if indentation problem. So now we've seen the hello world app. But like I said, oh, sure. This is building up a dependency graph on the states that's separate from the dependencies that pip or the packages would have. So you can, I've got an example in the next thing about to show the circus config where you can set up requires which are this must happen first and you can set up watches where if something changes restart a service or some such thing. So in the circus config. So here we've got, I've installed circus with pip as well. So keeping the requirements separate and it's in its own virtual end as well. And I've got two extra files here. There's circus conf, which is an upstart file. My machine is an Ubuntu machine. And circus any, which is the circus config. So I'll just show you what those look like. But they're not so interesting. So this is just an upstart file to say how to do this, how upstart should handle this service. And circus.ini is the circus configuration. So this is mostly just lifted straight from the circus website. I'll just say if nobody knows this virtual end thing is brand new. It was like released at lunchtime. I just happened to be in the right place to see that they added support for virtual ends and circus, which is really cool. 0.7. So this is all a very virtual envy kind of thing that's going on. So now this is the circus I and I, but I'm not going into it because this isn't a talk about circus. It's a talk about salt. So this is what we're going to be talking about more. So this is now introducing another state, which is the service should be running. So the circus service should be running. And it requires that the upstart file has been put in place. The circus virtual end has been put in place. And that that hello world app is in place because that's what it's going to be running. And the watch is what I just alluded to. It's like require, but additionally, if it ever changes, then service will the service state will restart the service. So if you've changed this circus I and I file at some point and then do a salt, what's called, I've forgotten some terminology here, salt high state, which is the way you tell the machine to get the new state. Then if that file has changed, it will restart the service. Super handy. Down here, there's just another, it's another virtual end, much like the one for the hello world app, but this is just to keep circus and its requirements, which are from intruding on the rest of our system. And then here we've got the circus I and I file. This is also something we've seen before. Just get the file from this location and put it in slash, et cetera, slash circus dot I and I. And finally, it's file, managing a file, but a little bit more complicated. So the circus conf because it's the upstart file needs to be owned by root and keep the modes good because we don't want people to screw around with our systems by modifying it. So this is just showing a few more parameters that you can have on, for example, the file managed. And a lot of these states have additional parameters that you can add on to do more advanced management. For example, in particular, the packages can all be version limited, lower bound, upper bound, pinned, et cetera. And because circus needs to compile pies at MQ, it needs a build essential, which gives it GCC and G++ and all of that. So yeah, yeah, sure. How does it know what user login to your vagrant box? Okay, sure. So should I repeat the second question too? The first question is how does it know how to login to the vagrant box and what keys to use and how to install everything? And the second question was could I repeat the first question for the recording? So to answer the first question, I will take a quick break. So if we look at the vagrant file, here I'm using this thing called, this is vagrant specific. This is a plug-in from the salt people that acts like the chef provisioner or the puppet provisioner. This actually will bootstrap salt. It will install salt if necessary and set up all of that stuff. And then above, this is how the state files get to where they're supposed to be. Does that answer well enough? Okay. So this is vagrant magic that that happens. And now I wanted to be doing vagrant up all throughout this, but actually downloading packages, like it takes a minute here, 30 seconds there that this talk would have gone on way too long. So I'm going to do a here's one I prepared earlier, which is a vagrant up on the final state with the circus stuff all installed. Actually, it's already running, but I can SSH into it. And we can just look around the file system a little bit just to see where some of these things are. So here are these virtual ends that the virtual end state set up for us. And the circus I and I file is put there and so on and so forth. And the icing on the cake, of course, is when we check to see if the Hello World app is actually running. And so I'm going to do that from my local machine. I've got the port forwarded. So if I curl local host 8000, Hello World. So that all of that stuff is coming together. And now we've got the Hello World is running. It's all being super scaled with circus. And it's got the upstart script. And anytime I change the I and I, it's going to get reloaded and all of that. And I can take all of this state stuff and transfer it directly to actual running server and run it there. Sadly, I'm out of time. I actually have about seven EC2 boxes that I was going to demonstrate the remote execution with. So I don't get to do anything with that. But if there are any questions, feel free to ask me. Yes. So when you have not just like vagrant, you mean you actually have it in a more real setup. So you have one is called the salt master. I see. You have the salt master, which is like the puppet master or the chef something. And that's the one that stores all of those files. And the way it is set up is that the minions, they're called minions, salt master, salt minion, they have the host name of the master and they connect over ZMQ to the master and listen. And then whenever the master tells them something, they go and do that. And whenever there's that MQ connection drops, they reconnect. So it's, it's a, it's, it's not a pull like puppet or chef. It's a push. Just the connection is to the master, but anytime you change something, it goes immediately. You don't have to go into your, into your minions or, or whatever you call them in the other ones and tell them, check in now. It goes straight through. You need to install what is called salt minion. They have an amazing bootstrap script, which will install it on Ubuntu and Fedora and, you know, all these different things by itself. It needs ZMQ. It needs JINJA because these, all of these state files can be templated with JINJA. I cannot remember what all of the requirements are, but those are the two that come to mind. And the other nice thing just on that note is you don't need any open ports into the minions for this because it's an outgoing connection. You get immediate synchronization, but you don't need open ports on any of the minions, which is nice. Is that a question?