Configuration Management With Ansible: A Whirlwind Tour

what's going on guys we've been talking about configuration management's and in this video we're going to cover the very very basics of ansible I'm starting with ansible will probably do some puppet videos as well I've used both in production and most recently ansible it's got a couple of advantages especially for the beginner I think first off ansible is just easier to get started with it uses no agents that run on the target machines and there's no client-server thing that you've got to set up it just does everything over SSH so basically every machine you're ever going to administer has SSH installed already this means that most of your prerequisites are done ooh nice we can see an error there we're going to debug that in a second ansible can scale it's not sort of bound or bottlenecked by SSH so you can do a tremendous amount of machines in parallel and it's written in Python so all these things together I think make it a good place to start and keep things very simple and just learn the concepts while still having something that's actually useful that you can work with right away I just wanted to do a very very quick tour of ansible sort of an ansible in 10 minutes kind of thing just to give you an idea of what this looks like in practice so first off get used to seeing errors your basic workflow is going to be writing configuration files so working on the the configuration itself and then testing it by running it against a test machine and seeing a lot of these green things some of these yellow things and a whole bunch of red and your job is to get the red to become green let's just quickly look at a and ansible project so here I've got an instable project open the folder structure it's meant to be convenient for big projects and it is for small projects can feel a little bit overbearing but this is going to make sense in a second just so you can quickly see so this is a fairly small project just to give you an idea of the folder structure basically you've got one directory that holds your variables then a single file your hosts file where you've got all of the different machines that are going to be configured in there you can group them into different named groups makes it easy to say you know do this just to the web servers okay but do this to all the servers on and on your roles where the actual configuration lives and so you can have several roles we just have a common role here because it's very simple we just have a single type of host and we're going to apply only the common configuration to it you can also have like you know a web configuration or a database configuration that does those specific tasks like okay we're going to install Postgres each of these roles in turn has files that are simply copied to the target machine handlers which are things like restarting services they're very very simple you're going to want to abused handlers by making them more complicated than they're designed to be but don't you've got tasks which is this is what we think of as the configuration management I mean this is where you're like okay do this do that do this install these things run this command and then templates which are files that are filled in with variables from your group VARs in practice this is really nice for very small projects this structure feels a little bit overbearing you always have that sort of feeling like Jesus you know I could write this in a single text file and it would still be nice but it's nice that it forces you to do this for small product well you can escape this structure but I think you should use this even for small projects because small projects have a habit of growing into large projects and if you already have this stuff kind of separated out into the structure of okay this is one role oh I'm going to add web stuff now well I'll put my nginx config in and all my files and handlers and tasks and templates for nginx over into the web server role and so on it forces you to keep things really easy to access for other people and really easy to find and I know if you've listened to my other videos about why even do configuration management it's fairly obvious that I'm huge on the documentation front like I'm a big fan and configuration management itself I think should be a type of documentation so you can sit a noose aside man down and say hey did well read about how we configure our web server and then you'll pretty much know what's going on on one of these web servers so this forces you to keep your documentation structure essentially your configuration management structure consistent which means a new person as long as they're familiar with ansible can sit down look at this and know what's going on immediately okay so here we are in the very first file I just pasted an example from the from the official ansible Docs here you can get fancy with this so you can group servers I'm just calling this test hosts right now so I can add some later that I want to configure but basically there's only a single IP in here it doesn't even have a name in DNS you can do if you have a larger file you would this would be your group this would be another group and this would be something that gets run even when a specific group isn't called but again these are commented out this is basically just like bash or Python so this is means it's commented and ignored and this is my single little lonely Aleksey container that we're configuring here so that's the hosts file it's very on the outside and let me close these and make this a little more here's the basics playbook so it's basically just configuration management instructions for some tasks and the PlayBook has this host file and now the site dot yml it's a yeah mol configuration file it's like a super simple syntax it starts with three dashes begins the configuration file you can see here the only role we're interested in configuring here is all the test hosts which is just that one IP we're going to use the root user to log in and do stuff because this is all running over SSH you can see we could sudo to another user or sorry suited to root or use another user on that system but we're not going to do that we're just running a single roll here let's look very quickly at the group virus file so these are all the variables basically that you would configure before running this on a machine or a group of machines and I've just done this for demonstration this is really just for and I'll add this SSH configuration file variables so I've created a variable here that has the port number so you can change this before run you could say I know we're going back to the default the permit route login directive in the SSH key file the pub key authentication or an password authentication I've just pulled out a couple variables I'll show you how those work in a second so those are my variables and now we start the roles now on a larger project you'll have many roles but for a simple project you just have the common role let's take a look at that so a role consists of files which are simply copied from A to B we don't have any of those handlers which are very simple tasks I'll show you in a second the tasks file which is the main configuration area and then your templates which are basically halfway between five their their files that have variables and I'll show you what I mean in a second you see these variables here this uses the Python Jinja two templating engine which means I can do things like this instead of this saying port whatever I've this is just a copy pasted SSH config file instead of having to say 22 in here and then using a corset or something to modify this on the machine I can simply use this as a use the Jinja syntax here the same please go into the group VARs directory and find me the sshd port variable and it says okay great I'm going to go do that and there it is so 4 4 3 and then it basically just inserts 4 4 3 here nice and easy you can get a little fancier with this but we're going to keep it very simple so it's just simple variable substitution here so you can see for the permit route login thing I have another hey Jinja insert a value here if there is one and on and on obviously it needs all these values and if I put a junk value in in the configuration file like this I'm going to have a problem when I try to restart SSH because this is not an acceptable value for password authentication okay but that should basically explain the variables file group VARs all how templates work and that really leaves handlers and tasks now a handler is a good example of a very very very simple task it has a name a task has a name and the task itself in this case it uses the service module to restart a service so it says my name is restart sshd and the thing I do is I look for the service names SSH and I try to run a restart on it if that exists so that's really what you're dealing with tasks so ansible is basically the way you'll be using it is playbooks are simply collections of tasks split into different roles so let's look at the main tasks flow this is really where you're going to do most of the work again simply Yambol file so you've got these three minus signs or hyphens this thing has a name again and you can see uses the apt module this is one of the things I was bitching about before because I like to just have the abstraction called package and have it figure out you know if that's apt or if that's package you know on FreeBSD or if it's yum or if it's something else I don't want to have to deal with that maybe I'll write a module for that who knows so I'm basically just saying update the package cache which really actually just means all I'm doing is apt-get update right we're going to install T box because we love T max we're going to install Z shell and we're going to install all the OpenSSH server now this is kind of a weird way of doing it because this is for installing a single package you can install multiple packages like this so we'll just install I don't know Python dev stuff just for fun and you can see we use this syntax you can really just copy and paste this and use it for whatever to install multiple packages so this will take these three packages this is silly because ansible needs Python installed anyway to run so this if this runs Python is already installed but we don't care about that it's just demonstrating a point here so each of these things is substituted here right using the same Jinja templating so this just becomes apt you know python State present okay that runs then it becomes apt Python dev stay present and then a Python virtual end state present so this is just a way of condensing if you're installing 40 packages this is a much easier syntax to deal with and you can see we've got another module here the user module that's for obviously managing users on your system and you can get pretty fancy with this I'll give you an example in a second but this is the most simple way of doing this we're simply creating a user and we're having the shell be the bin bash would be the default anyway the name it means things like the home directory is automatically created that's the default it means things like the group is automatically created and named the same thing as the user and the UID and group ID are automatically simply taken as the next available one you're not specifying you can you can get fine-grained with this I mean you can say I want a user with UID 2302 and I want the default shell to be here and I don't want you to create a home directory and like in this example which I kept I want this person to be if you didn't have the append yes you this would mean only in the groups admins and developers if you add the append yes it means whatever groups you're already part of in this case Dave and please append to that the groups in admins and developers so just to give an example you can a lot of these modules have extra options you can use and other stuff and it's all in the modules documentation for ansible but that's not the point we're just running through this as quickly as possible okay running individual commands this is another module so this is literally just passing a command to a shell so this starts a shell session somewhere and then passes a command that's run on that shell in this case change shell because we just installed Z shell we are going to and that was the bug before the user name goes at the end here so the command is change shell to the shell user bin Z shell for the user Dave so this simply updates the shell for the Dave user and since we want to show how templating works we're just going to can you tell where I pasted this from I was working on an engine X project and then this came with me so we're going to copy the configuration file over using those variables that I talked about and the syntax for that is the template module pretty straightforward right I'm talking about templates well that's the thing in here with the variables that have been replaced well we give the source file which is this config file here it automatically will look in the templates directory and a destination on the machine that's being configured so this will be on the remote server that we talking to or my LXC machine here and we're saying please just put this file here that's where this goes and the notify thing is something that we use to fire a handler and what that means is in this handlers directory you've got the different handlers where we pass the handler name here so we say notify the handler named restart sshd so if you remember in the handler file this is simply called restart sshd those things have to match up and what that does is it makes a call to service and restart it and what the handlers do is basically you could simply paste that code from the handler in here but then it would run every single time that you do it you don't want that you actually just want to run that once after you change the config file and that's one of these principles that ansible tries to be a Dem patent note if I'm pronouncing that right but whatever that is idempotent it I am potent whatever it tries to be that and kind of goes out of its way to make it easy to have it be possible to run the same configuration script once or 50 times and not break anything and not do anything weird and not restart services a million times so the way the handlers work is you basically make a separate Handler and then notify it only for the cases where you're actually changing something that requires a restart of a service or something like that okay let's try running this bad boy again now that we've hopefully fixed all the bugs that's right okay let's have a go Oh running the playbook so you change the rectory to the the playbook directory that you're in so do the same thing as site ymo and then you run ansible - playbook I hosts your host file or list and the site configuration let's see if this works again at the moment it requires just a couple of things it requires Python installed on the remote machine that's all it really needs and you obviously need SSH running generally it's best to obviously have SSH running with keys that's the best case scenario anyway but if you don't ansible is going to scream and you're going to have to pass an extra argument called it's - - ask - pass so we're not using Kies asked me for the password the ssh login password for the user and for that you'll need an extra package installed on your management machine ssh pass so i recommend you just install python and set up ssh keys so you can log in with a key on the machines that you're going to manage most of the time it's going to be done anyway in any real environment but again there's this other way with ssh pass and ask pass when you run ansible and we're running we're running we're running so you can see it's going through those tasks right now one by one in the way that we named them they're coming up here and it actually just made it all the way through so that was the only bug we had so this is the output it shows you what host it's happening on the green means nothing is changing the yellow means something has changed it always has the action name above so you can see there was already a Dave user on that machine but now that users default shell has been changed to Z shell you can see that sshd should have had its config file changed and had its port change to 443 and then been restarted okay so that's basically how it looks when you run configuration management playbooks with ansible so those are collections of tasks you can I've just run it on one machine but you could run this the same way on a hundred machines the nice thing is if anything ever changes on that machine I can just run this again and I'll see here what changed and then what was changed back but that's a very simple look at something that's really complicated actually and this is probably the fastest way I've found to get into it if this is helpful give it a thumbs up and subscribe there's going to be more about configuration management and we'll also cover some other configuration management tools I've been playing with salt stack a little bit lately but in production I've used instable and puppet see you in the next video

Channel: tutoriaLinux

Views: 56,595

Rating: 4.9157896 out of 5

Keywords: computer, how-to, Linux, tutorial, system administration, sysadmin, command-line, CLI, configuration management, ansible, deployment, devops, Technology, basic ansible tutorial, basic ansible course

Id: fYd_KQpfBs8

Length: 20min 5sec (1205 seconds)

Published: Wed Apr 08 2015