Introduction to Ansible Playbooks (and demonstration)

[Music] [Music] in this video we're going to get an introduction to ansible playbooks but we're first going to start with the discussion on variables so to go into a little bit more detail variables and ansible are used to account for differences between servers by using variables I'm going to have the ability to keep a nice layer of abstraction in my play books and I can define my variables as I need to and various host bars or group bars files and variables could be anything for things like facts or for file paths or for packaged versions so when we talk about variables I would be remiss if I did not bring up variable precedents and basically what variable precedence is it's the order in which the same variables are going to override each other it's a hugely important concept in danceable and azov ansible - oh in fact there are 16 levels of variable precedents and you can see from this slide right here is that extra VARs are always going to take precedence because they're number one and then role defaults are going to get overwritten by all of these other bar types so I've highlighted a couple of the variables in the variable precedent slide here to show you that where we defined those variables in inventory a few slides ago is basically where these fall on the variable precedence chain so we had to find host specific bars and group bars for all the hosts inside the inventory file specifically and so you can see that everything except inventory bars and roll defaults are going to override these so that's my variable precedence is super important because you need to think about where you should define your variables in relation to what your playbook is actually doing so if you have variables that you're defining inside of your play header of your playbook those need to be somewhere inside the variable precedence chain that ansible can access at runtime if they're not then it's going to fail so it's very important and where the best place to define your variables is okay so just to recap so far we have talked again about acting against inventory with modules but those modules are going to be contained in things called tasks and tasks are simple and declarative because we're basically just telling the module to do something specifically so you take a look at this slide here I've got a few examples we did an ad-hoc demonstration where I said that I wanted to install Apache and that I wanted to be present on the machine so YUM a package should be installed that's pretty straightforward the other ones it's the same kind of story with the template module we're rendering a configuration file from a template file with file we're making sure a directory should exist or we can create a symlink these are the types of arguments that we're going to be passing to our modules and those are going to be inside tasks so example tasks in a play got a few examples on this slide in our first example we have named our task add caster and it is best practice to name your tasks and to name them something appropriate to what you're actually doing in the task itself so my task name add caster that's exactly what I'm doing I'm using the file module I'm passing it some arguments in this case I am telling it that I want the cache directory path to be opt cache and I'm setting the state to directory which means that I'm actually going to create the directory opt cache the second and third examples are fairly straightforward basically just like we did with the ad-hoc command demonstration we are using the yum module to install a package except in this case I'm installing nginx and I'm making sure that it's at latest and then I'm going to use the service module to ensure that nginx is both enabled and actually I'm going to restart it in this case I've set the state to restarted so normal tasks we've seen a couple examples of those those are going to run sequentially but there's a special type of task called a handler task that actually only runs on notification so handlers they can be notified multiple times during a play and they're only triggered when a task causes a change in state so typically you're going to see a change in state if you push out a configuration file for the first time and that's normally where you're going to define handlers these are only going to run once at the end of the play regardless of how many times they've been triggered so if I include a notify keyword to restart Apache it's and I do that for each task in my playbook it's still only going to trigger one time so an example handler in a play would look like the following basically taking that exact same example from before and turned it into a handler so I've installed nginx with the module except I included a notify keyword at the end to restart nginx so if that task returns changed so remember when we did the demonstration we saw that it returned changed when something actually happened if it returns change that's going to trigger the handler and that's going to restart nginx at the end of the play so ad cache directory is going to happen then install nginx then maybe you have other tasks that are going to happen and then at the end that's when the handler is going to trigger so now that we've looked at some example tasks and some handler tasks we should talk now about what those tasks are going to be contained inside of which are please and then consequently playbooks so please are ordered sets of tasks and those are going to execute against a host selection from our inventory file and a playbook is a file that contains one or more plays so you can have one play or you can have more than one play really up to you so let's go into a little bit more detail I have a playbook example here that is basically one a and I'm going to kind of walk through what each of the pieces represent so to start off we have our name field and again just like with task names these are best practices you should always name your place you should always name your tasks and they should represent what's actually happening inside of your play so in this case my play name is called install and start Apache which is exactly what I'm going to be doing and I also have highlighted the task names as well so both of these all of these are human readable comments and again best practices is that you should include them so the next thing that we're doing is we have our host declaration inside of the play I'm targeting the web group so my web servers group in this case and then I have a VAR section in my play so I'm setting two variables here HTTP port I'm setting to 80 I'm setting my max client setting to 200 and if you think about variable precedence so we're defining the VARs right inside of the play book so just like the variable precedence chains we variables can be handled in several different ways so this is directly in the play book but we also showed an example of variables defined inside of inventory you can define them as an extra bar where you pass it at runtime you can do it as an output from a previous play or you can do it via ansible tower then we have our connecting user information so in this case I'm setting my remote user to root in the ad-hoc command demonstrations that I did previously I was connecting as the vagrant user so is definitely absolutely not required that you connect as the root user but in this case this is just the example that I'm using here and like I showed before with my install Apache ad-hoc command demonstration we can actually connected the user and escalate to route and we have multiple privilege escalation methods including sudo su power broker and other privilege escalation mechanisms well so now we're into our task section which we talked a little bit about before so these examples are a little bit different than the ones we showed but basically our modules are going to be in key value pairs we have our yum module which is going to be installing apache we're setting the package name to httpd we're setting the state to latest which means I'm getting the latest version of Apache that I can get from from the repository where it's coming from and you'll notice that I'm using the package alias instead of name here so those are interchangeable you can use either name equals httpd or package equals httpd and then our second task were writing the Apache config file so for that we're going to use the template module where we have a HTTP dj2 so the J 2 extension standing would stand for Jinja 2 and that's located on our control machines in the serve directory and then we're going to put that the destination directory is going to be equal to SC HTTP be calm so it's going to push out the file to the remote machine and then our last task we're going to start Apache now that we've pushed out the configuration file and we're going to start it with the service module name equals httpd state equals started so that includes our overview on the introduction to playbooks but what I wouldn't want to do now is I actually want to transition over to my text editor of choice to actually write a basic playbook so I have a psyche animal file here which is basically my name you can name your playbook files whatever you want to but I always call it site animals because indicating that it's you know the overall mean site playbook and so I'm going to start I've got my three dashes here to start my playbook file those are optional but I like to have them it's comforting you don't have to put them in if you don't want to but just wanted to put that out there so the first thing I'm going to do is name my play and I'm going to install and start apache so now I have my host declaration line here and I'm going to target my web servers group I go over to my host file you can see that I've got my web servers group over here and makes sense that I would target the web service group with I'm going to install Apache and then I'm going to put in my connecting user and then I'm going to escalate to the root user once I connect to the machine so this is that purple adjust galician that I did in the ad-hoc command except now I'm doing it inside of the playbook so now my playing header is complete I can move on to my task section and again name your task so actually before I install Apache I do want to actually install the apple repository and I will also do that with a young module so name equals apple release state equals present so now I make sure that I've got that that repo ready to go and enabled and then my next task I'm actually going to install a couple Python packages for su onyx so we're kind of we're kind of mixing up some things here but I want to make sure that I have all of this because when we transition into a role we're going to need each of these individual components so this is kind of a good practice for that so I'm going to set my name to a variable name equals item and I'm going to set the state to present and basically the item is just a standard loop because I'm going to include a with items here and then I'm going to say which packages I actually want to install so I'm going to get Lib su Linux Python and Lib SC managed Python and then we should be good so that task will install each of these items in one task so it saves me the trouble of actually having to write about two separate times the reason why I didn't include Apple in that is because I'm going to keep that separated out for later use okay so now we're on to our third task so now I'm actually going to test to see if SELinux is running now that I have installed it and I'm going to use the command module to just issue a get enforce on the machine and I'm going to register the output of that and call that SC status and basically what the register is doing is it's just registering the return of this task into it a new variable and I'm naming that variable se status and then now I'm also going to set changed when to false because the command module is always going to return changed even though nothing may have actually happened so I want to change that to false so that it'll actually just return okay okay so now I can move on to my next task which should be the Apache pieces so my name actually wasn't very appropriate for this particular playbook because I'm actually installing way more than a but c'est la vie so install Apache use the module again so just like I did with the ad-hoc demonstration and then now I'm going to start it with the service module stay equal started enabled equals yes okay so this is all fairly straightforward I have the tasks to install the apple repository I'm getting some SELinux Python packages I'm testing to see if Fe Linux is running and then I'm installing and starting Apache so I'm going to save this file and then now I can actually go ahead and run it so you switch over to my terminal window here clear that out and then if I list the contents and cat my site yeah mol you can now see that I have the pieces of the task that I just put in there so that's good and so now I'm going to run the PlayBook and to run a playbook it's actually ansible - playbook instead of just ansible which is what you would use for ad hoc still going to pass the whole file though and now I just pass the PlayBook name so real quick before I run this what's going to happen is it's going to execute those tasks that I specified in order from top to bottom so it's going to first start by gathering facts which happens implicitly and then I'm going to go and order the tasks that I wrote out so first installing Apple then the Python bindings for selinux and so on and so forth I'll go ahead and run this so there's the setup I'm going to install Apple there's the change return install Python bindings for selinux which should show an output for two packages because I did the standard loop with with items now I tested to see if selinux is running which returned okay because I did changed when to false now I'm installing Apache which again is taking a while because I already rolled this back previously and then the start Apache also returned changed so you can see here I've got my play recap of okay six change four and just like with an ad-hoc command that idempotency principle will will persist through to here if I run this again it should return okay for all six items which it does so that concludes our presentation on introduction to playbook join us in our next video where we're going to talk about how to transition this basic playbook into a roll

Channel: Red Hat

Views: 94,519

Keywords: Red, Hat, Ansible, Red Hat, Playbook, Configuration Management, Automation

Id: ZAdJ7CdN7DY

Length: 18min 2sec (1082 seconds)

Published: Wed Mar 15 2017