Ansible 101 - Episode 5 - Playbook handlers, environment vars, and variables

good morning everybody I hope you're doing well this is the ansible 101 livestream episode 5 we're going to talk about playbooks handlers variables and ansible vault and we'll see where we get there's a good deal of content to cover today so I'm not going to spend too much time introducing and saying hello but it as with all these live streams it'd be great if you put in the live stream chat if you can where you're from and and we can see where where people are coming from and visiting from during these live streams something that's a little more fun than me pre recording these and putting them out there because we can kind of interact with each other and learn from each other as well there's there's always plenty of good comments after the fact and also some good things during the chat that that can help increase our knowledge of ansible together but hello to everybody hi to everybody who's already already said hello and chat I saw Oliver yesterday at the the Drupal livestream too so thanks for coming to that having some fun upgrading my personal website Jeff Garlin comm and for people who weren't on the stream last week I have an ansible content site called anti Bowl Jeff Garlin comm that lists all of the instable all the ansible collections roles play books operators etc that I work on so if you want to see a central list of all that that'd be great good to see you guys I see Ireland Brazil Las Vegas Kansas City Sierra Leone the Netherlands today I was gonna wear my one of my Netherlands soccer jerseys but instead I decided to wear my st. Louis Blues shirt in honor of the NHL season that may never complete but the good thing is for me being a st. Louis and we are technically still the Stanley Cup champions the when we might be the only tough the only team and then NHL that wanted one year and more champions for two so you know I'm not gonna complain too much about that it's India Finland London London more from the Netherlands Nepal Switzerland Virginia Germany it's great to see a global audience and I that I am able to help help you learn some new skills in these these episodes I'm gonna switch over to my screen share so that we can take a look at what what we'll work on today first of all I wanted to thank again device 42 who has sponsored giving away my books ansible for DevOps and ansible for kubernetes free for another month if you don't have a copy please go to lean pub comm and search for ansible for DevOps grab your free copy now because it will only be available for another week or so until the end of April Thank You device-to-device 42 and I told them I'd give them a plug in this live stream for sponsoring that extra month and the ansible is a great tool for driving IT automation but to make the automation work you need to make sure you have an accurate real-time picture of your IT infrastructure and that's where device 42 helps they provide comprehensive discovery of your entire IT estate from mainframes to kubernetes and just like ansible it's agentless you can try it for free download a trial at device 42 comm and see how it can take your ansible automation to the next level so I also wanted to thank all the people who are sponsoring me on github and patreon I've been able to expand some of my open-source work and I don't know if if you follow along so with some of my projects I've had a little more time lately to do PR reviews and try to comment on issues that type of thing and the more sponsorship money I get the more I'm able to do that and focus on that just because it doesn't generate any revenue like it doesn't that work is all done for free and so any work that I do on it I'm basically donating that time and it's time that I I can spend outside of my family life doing doing open-source work the more the more that I can get sponsorship money the more I can justify doing that more outside of my normal work and my normal family time so if you aren't already sponsoring me and have the means to do so that'd be awesome if you could consider doing that on github or patronizing me on patreon I guess it's called and last last week we we had an up so going over our first ansible playbook and there were some questions about let me switch my windows over here there were some questions about different things one person had a question about play books and roles is it better to have all their play books in one ansible play book as roles or make different play books for each role that kind of thing we can also talk about tags which you might get to today that's an organizational question that I will probably get to in the next episode when you start talking about ansible roles I haven't talked about roles yet and you don't need to know what they are yet if you don't know what they are yet because we'll get to the next episode but there's in ansible there's a lot of different ways to organize your code and in some cases it doesn't really matter what you do there are some times when it's better to do it one way or the other but it really depends on what type of project you're managing and what type of person or team you have that's going to maintain this stuff another person mentioned because I think I said in the in the episode last week that double quotes and single quotes don't usually matter that much in play books there are some times when you're using the line in file module which you might use here and there I think I even have an example we'll go over today using it that regular expression characters can behave differently depending on the type of quotes or using so be careful of that and if you have errors with it always check your quotes I mean that's in bash scripts and ansible play books in PHP and Python every everything that you write when you have double quotes and single quotes sometimes you can screw things up and then another person was mentioning that they they often have problems especially when you're getting started with ansible when you're writing the amyl you might not be familiar with spaces and and how to make sure that you don't have the that you have the right amount of white space before a line that you're doing tabs correctly and so a lot of times they have syntax errors when they go to run their play books and this was actually a comment on my blog post about yellow best practices but it comes back to something that we talked about on this on these ansible 101 streams and I mentioned that there's a few different things you can do I'm not go into them right now but there's a few things you can do tool into your code and link to your Gamal using a program called the mo lint and you can also use ansible in to give you more ansible specific linting and that will help you to immediately see what where there's potential problems in your code that's not going to say that the ansible is all correct but the Gamal itself you can make sure that it's correct by integrating those things with your code editor and we'll talk a little bit about that in two episodes the nakos next episode I'm hoping we get to ansible roles and then the episode after that well talking about we'll talk about testing ansible lint yema lint and molecule and we'll get as far as we can there but that also assumes that I have a little bit of time in the next couple weeks to finish rewriting if I forget what chapter it is eight nine or ten or something in the book on testing with the instable but well we'll get there even if I don't finish rewriting the chapter we'll get there in the ansible 101 series so those were some of the questions from last week please feel free to continue asking questions in live chat or sometimes I miss them just because there's a lot of scroll back but if I do miss it please leave a comment in in the video below and if you like this content go ahead and click the like button and I wanted to mention that in in the next week or two I'm gonna be adding some content on YouTube I'm gonna start exploring kubernetes clusters with raspberry PI's this if you have never seen it before is my raspberry pi DRAM Bowl if you go to pied ramble comm you can see more about it how to build it the the ansible playbook that's used to build it all that kind of stuff but this is the culmination of like six or seven years of exploring raspberry Pi based clusters and they have a new thing coming a new prototype coming in the next few days that I'm going to be exploring on the YouTube channel so if you're interested in that or other Raspberry Pi base things I I have a lot of content like that from time to time that I post on YouTube so right below me there's a subscribe button click that button and you'll get that content as well but I will be continuing the ants of a one on one series for sure but there will also be some new stuff coming coming for a spray pie soon so let is let's get into chapter 5 and again I'm working from version 1.2 1 in this book but I think the latest version is 1.2 - and by the time you're watching this video if you're not watching it live it might be version 1.2 5 or 2 6 or some other version of the book so somebody mentions k3s on the pie i actually am not using k3s yet right now I'm still running kubernetes k8s directly on the pies but it is something that I'm exploring and Marcus is mentioning him already on my new MacBook yea you might notice that this week the stream quality is a bit improved not only that my computer is actually running and not dying that is due directly to the donation from device 42 I was able to get a new laptop to do these streams in much higher quality so again thank you to them and thank you to all the sponsors who are making it making me able to do more of this stuff so we're gonna get into chapter 5 now I have for today I have two servers running I created an inventory file I have both of these servers are running in Amazon ec2 and I just created them in the AC to the UI on on the Amazon Amazon's console so I have a cent to s server and I can figure it it up here and I have an abundance of and I can figure it up here and so I can target them using the group name of sent to us or our bun - and you may you might be familiar with this playbook that we this was one of the first things that we created a few weeks ago just a quick ansible playbook that installs Apache on the server and it makes sure that Apache is running and so I'm gonna run that playbook on the sent to us server host sent to us and we'll see if it works ansible playbook - i inventory and then the play books name is Apache animal I think I used to call it Apache but I believe it's Apache now and I just realized that I have state absent so that's that's why this is failing because if you install the package then it won't be able to start the package it's gonna put present for that and it'll try running that again so this playbook installs Apache the service name that the package name is HTTP D and the service name is HTTP B so it makes sure that that's started and we talked a little bit about handlers before and their purpose and how to use them and all that stuff so I'm going to add a handler here for restarting Apache because sometimes when you're making a playbook you'll need to do something and then make sure that the service is restarted and that's typically what handlers are used for but there's other things you can use them for too which we'll talk about so I'm going to call this one restart Apache and I'll put service name HTTP state restarted and now I have a handler but if I run the PlayBook it's not going to call this handler because nothing is telling ansible to use this handler but the one good thing about handlers is handlers are tasks they're the same as any other task I could copy this out and create a handler for it so you could have a handler that installs a package there's I haven't ever had to do that but I'm guessing maybe there's some reason that you'd want to do that someday but a handler is just a task and the name of the handler is used to notify it to run and you'll notice that I usually write my my comment my my documentation the name for each task as a full sentence with a period or a full stop at the end but for handlers I just use a simple all lowercase very simple thing like restart Apache or notify something or change something that kind of thing just because when you call a handler like will do down here I'm going to add a task that says name copy test config file and I'm going to use the copy module to do that source I have a test that config file which is an Apache virtual hosts file I'm going to use that as the source files test dot config test is going to be I know in sent to s7 it's at sea slash httpd httpd slash config dot d slash that's that config and when I sent it there and when I copy up this configuration file I want to have Apache restart because otherwise Apache won't know about this new configuration file so I'm gonna go ahead and say notify restart Apache and what this does is when this task runs if it changes something so if if you see or at like when it's okay it's not going to change anything so it won't do anything but if it's set if it results in a change it will call this this Handler it'll it'll add it to the stack of handlers to be called at the end of the playbook and at the end of the PlayBook ansible will run this handler so let's try this again now that we have this copy test config file and it should not only copy the config file up but since it reports a change it should also at the end of the playbook restart Apache which it didn't because I I think I tested this earlier and that config file was already there so what I'm gonna do is I'm going to change this config file well add a comment to it and that will result in an actual change and I should probably retest things before I try them in these demos but anyway so now it's resulting in a change and you can see at the end of the playbook it runs a handler and so it restarts Apache and on the server Apache is now restarted this is the simplest case for a handler and there's a few different things that you can do to go a little more advanced so one thing is you might want to immediately restart Apache instead of waiting until the end of the playbook so one thing that you could do and in this playbook it doesn't really matter that much because it's only managing Apache that's it but if you had a playbook that did 150 different tasks and you wanted to make sure that Apache was restarted right away and it didn't wait until all the 150 tests were done you can do something called flush handlers using pencils made-up meta modules so I'm going to say name make sure handlers are flushed immediately and then I'm gonna use the meta tasks and save flush handlers and I'm gonna go ahead and change this file again well before I do that I'm going to comment this out I'll just show you if it doesn't if it doesn't result in a change which we actually did the first time if it doesn't result in a change it's not going to notify that handler so the handler won't run you can see that it doesn't say running handler here but if we do cause a change so I'm going to remove this comment again so it changes the file and I add this flush handlers it will notify the handler right away after this so if I go like this it'll make the change and then you can see immediately it restarts that it restarts Apache it catches this and restarts it so that's one way to control when handlers are flushed instead of having them at the end of the playbook now another thing that can happen that might trip you up sometimes because you might say I want to copy this file restart Apache and then you know at the end of the playbook it gets restarted if if that has to happen if patchy has to be are started by the end of the playbook and let's say some other thing that you do later in the playbook fails the the handler could actually never run because ansible by default won't run handlers if the play fails on a host but you can you can work around that problem so let's let's add a test that's going to fail ansible conveniently has a module called fail that can do that and so if I run it without any changes it'll just get to that failure and fail in that that's not a big deal which it will do here however if I change this file so I'm going to add a comment again and then run this again I change the file and it notifies the restart handler but you'll notice that it won't actually run the handler so it goes it gets to here but it doesn't actually do it up here when we saw restart Apache it actually reported the change because it did it down here it says I wanted to do it but it didn't actually do it because there was a failure you can overcome that by passing let me get back to my notes here you can pass the flag to the playbook for force handlers I think it is they can say force handlers and I'm gonna have to make that change to this file again force handlers will will make it run the handler even if the play fails on a given host so it's running changes the file and it's still gonna restart that restart Apache and run that handler so there's there's a few things to keep in mind when you're using handlers one is to don't presume that they will always be running another one is to know that they run at the end of your PlayBook unless you use that meta flush handlers module so you know some some things that you might need to keep in mind when you're when you're working with handlers and another thing to keep in mind is all these top-level things the an ansible playbook is a yamo file that has keys and values dictionary basically and a list of plays so this doesn't have to be defined at the top you can actually define it at the bottom if you want it's just up to your style that you want to have defined handlers tasks roles whatever other types of things in your PlayBook that you're defining I usually define mine at the top just so that I can have a reference when I'm looking at a playbook what handlers I have available to me another thing that's interesting that you might want to do sometimes is let's say whenever you restart your web server you also have something else that you need restarted this restarted there are two ways to do that one is I can add a handler so let's say name restart I'm cashed memcache is a key value caching system basically it's a really simple thing kind of like Redis and a lot of people use it to store data that's cached in front of a database or something like that and let's say whenever you change your Apache configuration you also want to restart memcache to clear out its cache so I'm gonna say service name memcached whoops then cached state we started and one way that you can do this is notify can actually be a list it doesn't have to be just a string like it was here I can make notify a list like this and say restart and then cached and actually have memcached running on the server already I don't have it in this playbook but I have it on that particular server so I can demonstrate this and I'm gonna take this fail out as well because we want the PlayBook to run and then I'll make a change to this file again I'll just remove this comment completely and now what it should do is that should notify both of these handlers and then ansible will at the end of the playbook ideally restart Apache and restart memcache so let's see if that works I can take out the force handlers somebody from Russia too and Ghana hello to all of you and let's see so it restarts Apache and it restarts memcache now if it's a handler that always needs to do something else after that handler runs or if let's say you're using one of an Sable's notification modules like you're using the slack module to to ping a slack channel and say hey this deployments finished and you want that to happen whenever Apaches restarted or something like that you can notify a handler directly or a handler since it's just a normal ansible tasks can actually notify another handler so I'm gonna say notify restart memcached like that and then if I remove that from here we'll see what happens I'm gonna change this file again add a comment to it and now I'm just notifying the restart Apache handler which is going to call this but since I'm notifying from that handler another handler it should do both still so it should be the same as the above so let's see if that's the case and you can see it did both of them so it just illustrates that handlers are basically ansible tasks that can be called by using the notify property on any other task so it they can be they can be very powerful if you need them to need them to be able to do things from from other tasks reacting to different changes or different situations I'm not going to get so much deeper here there's a few examples later in the book and we might or might not get to those examples in the ansible 101 series but there's a lot of different ways to use handlers and typically it's simple like this if you start doing really complicated things and having a large chain of handlers there might be a better way to manage that but this is this is how I use handlers mostly just restarting services or notifying somebody in a slack channel or sending off an API request that sounds like something's done that kind of thing so that is handlers I'm going to remove this memcached handler just for now and we'll keep this playbook because we'll use it for some other things momentarily and the next thing I wanted to talk a little bit about is environment variables ansible works with environment variables many different ways and Markus is asking about notifying handlers on another machine that's a little more advanced and I'm not going to get into that particular topic today one thing to keep in mind is that we're working with one server right now this is just one sent to a server when you work with multiple servers which we will do later in this streaming series is there are some some things that you have to keep in mind with how that works like targeting one particular server and a set of servers for instance if you're doing a database operation you might not want to do it on all your servers at the same time because I could cause errors but anyway well we'll get to that later and people are asking about how to get the book look in the description below this video there's a link to the books there's a link to support me on github there's a link to support me on patreon there's all the information that you need down there anyway so environment variables one of the simplest ways that you can work with environment variables is you can actually set the environment in the remote users session which ansible will then pick up because it's an ssh connection it'll pick it up just like any other ssh connection wouldn't pick up the users environment variables when you run commands remotely so one way to do that one way to manage the remote environment I'm actually gonna log into the server here at the show how one would typically manage their own environment SSH sent to us on that server and there are some some files in Michelle B musica type of files bash RC bash history bash profile if you're using zsh or if you're using fish or some other terminal thing then then your environment would be stored in one of those variables but in this case and for most systems Bash is is standard so we can set environment variables for of this user in the bash profile so I'll see what's in there right now right now there's a path defined and that's about it and it also is going to load your bash RC if that's present which it is so if we wanted to we can just drop an environment variable and into here and the simplest way to do that is using the an Sable's line and file module there's definitely better ways to do it if you're managing environment variables and and bash profile or your your global environment and we'll talk a little bit about that in a few minutes but but this is this is the simplest quickest way so I'm gonna say name add an environment variable to the remote users shell and I'm going to use the line in file module and you can look up documentation either using ansible dock on the command line or just searching it on Google and going to an Sable's documentation site so I'm gonna say dust is that bash profile in the home folder and I'll tell you how this works in just a second rig X equals or that line is and far equals value and these are just placeholders these and var doesn't mean anything it's just environment variable so what this what the line and file module does is if you give it a file a dest so that it's it's telling us look at the bash profile file right here and then you give it a regular expression and actually I don't think I need a space there and then you give it a line the line will be placed in the file wherever it finds this and you can there's there's other options that you can use to to say like insert after the end of the file or before the start of the file or that kind of thing but by default it'll just inject this at the end of the file if it's not already there so I'm going to go ahead and run this playbook and here and it should be in this file now so if I cat the file it's not there oh and that the reason for that is because I'm using become so it's in the root users the root users bash profile I actually want this in the sent to us user that I'm logging in as so I can check it out here so I'll actually mention this now I was going to mention it later but you can you can use you can turn off become basically for any task so right now I'm becoming the root user for all tasks and all handlers in the playbook because it's required for these things but it's not required for this so I'm gonna say become false or you can say no or you can say 0 but I'm gonna say false because I like being particularly like that and now it should actually change the file in this n to s user because it's not going to become the root user and we can see that it added in var environment variable equals value there excuse me while I grab another drink so if we wanted to get a get an environment variable like that one note is that ansible shell module is required to work with environment variables easily at least and the simplest way to grab an environment variable I'm gonna say name I get the value of an environment variable and then I'm gonna use the shell module and I'll use source - bash profile and echo bar and I'm gonna use ansible register functionality and what I can do here is it's basically gonna run the command using shell because I'm using us I'm using the ampersand - to do the next task if this one succeeds and I'm using echo the command module kind of doesn't work with this this scenario so you got to use the shell module to be able to do this but I can get the environment variable out of here and this is going to output it to the screen but ansible doesn't know about that unless you tell it to register that variable and then you can use this variable in the rest of your playbook but we're just gonna see what's inside so I'm gonna use the debug module and again I could put a name like debug and use it this way but I'm a lot of times when I'm debugging a playbook I just throw a bug in here I'm gonna say message equals the variable is food that's out so when when you register a variable from the shell modular command ansible gives you a dictionary with the standard error the standard output with standard out by line in an array that you can look through that way so if you know what line it's gonna be on the output that you need that you can just get it that way and the RC value and anything else about that command but in this case I know that it's going to be that the output of this echo is going to be the value but the value of the variable so if I run this I should value output the variable is value and there it is right there so that's one way to get get environment variables out of ansible out of the environment and if you wanted to in addition to setting setting variables environment variables for the particular user you can set a global variable in that's the environment and that that will let you set system-wide variables that can then be used later there's a few gotchas with this one is if you're using ansible and you have the SSH is configured the with what is it chaining or I forget the name of the configuration setting for it but if you have the environment set from an earlier task you you need to reload the environment or override your your variable values to be able to use the environment and later tasks but I'm also going to talk about how you can set environment variables for particular tasks and for playbooks to overcome that because this is this is more for setting setting environment variables that are on the server and will persist on that server but I'll get into that now well let's see and I'm sorry if this this chapter is a little bit hard to to go through and kind of a step-by-step fashion just because this this chapter in chapter 5 in the book kind of goes through a lot of different things and I don't have a structured example for it mostly because there's no easy way to get through all these different things with one structured example but anyway so we'll talk about a task-based environment setting and playbook based environment settings so for any given tasks let's say named download file and let's see I'm just gonna grab and with test file I'm just gonna grab a test file here we'll grab a small file copy link and I'm gonna use get URL URL is that dust is the student temp and let's say so so this will work because this particular server doesn't have a proxy setup but let's say you're using a proxy and this is something that happens quite a bit in a corporate environment when when you're when you're working with proxies you need to make sure that you have like the HTTP proxy the HTTP proxy maybe the FTP proxy other proxies all set in the environment otherwise utilities that do downloads and utilities that interact with external services won't go through the proxy and they'll fail so the simplest way to do this is just set environment and you can set things like HTTP proxy and then you can set your proxy for it so you know if like example proxy 80 something like that whatever your corporate proxy is or your your cloud proxy that you're going through and you can do the same for HTTP like that and since I don't have a proxy set up it's not going to work here but another thing that you can do like let's say you have five or six tasks that you need to define this for you can actually set these things in in a variable so we'll go up to the top of the playbook and save ours and we'll say proxy VARs and we'll put these up here like this and then instead of defining defining these for each thing you can say environment proxy VARs and it will inject these variables into your environment wherever it is in the play and the wherever this exists in a task another place that you can set the variables though is on the on the play level so it can be a universal thing that applies to all tasks in your place you can set environment like this and then you don't even have to set it there because it applies to the entire play and all tasks inside of it so there's a few different ways to set those environment variables that are just specific to a play or tasks and note that the reason I mentioned earlier that you can set global environment on the server itself is these these environment variables will apply to each task in a play or to a play itself but it won't be persisted on the server so the next time you run the play book or if you have other automation running on the server or if you're trying to control things on the server that need environment variables these won't be persisted on the server you still need to inject the environment variables that way into the that's the environment file or into a bash profile or wherever that it needs to be on the server so that your systems and applications can see them yes Aaron mentions that sometimes proxies need credentials and and that is true I'm not going to cover proxy credentials in this particular 101 stream just because it's already 30 minutes in we have plenty to cover today but we will talk about ansible vault on how you can keep secrets secret a few few more notes on variables that will that will talk about we've we've done it we've added variables to play books a few different ways one way is we added VARs up here and you can directly add a variable like that we've also added VARs files and you can give it a file so like let's say VARs slash made that Amal and then I can create a folder called VARs and inside file called main camel like that and we'll add the same variable here so both of these do the same exact thing we have a an included VARs file or VARs defined inline in the playbook these both do the exact same thing it's just easier to organize if you have lots of variables it sees are easier to organize them in external variable files but I wanted to show an example of of one of the one of the things that you can do when you use VARs files and include them with ansible since it's all dynamic and that is to make a playbook runs on multiple environments or multiple operating systems in this particular case we're going to get Apache to install both on sent to us and on the abun 2 server and a bun 2 and Debian or similar sent to us and Red Hat and Fedora are similar so it basically we're gonna take this playbook that right now only works on Red Hat based systems and make it work on both Red Hat and a bun - using some dynamic variables so the first thing is httpd is the name of the package and the service on sent to us but on Ubuntu it's a little different so first of all I'm gonna say I'm gonna make this a variable so it'll be easier for us to manage it so I'm going to save ours Apache serve a patchy package is httpd Apache service is HD and now I can go up here and say they're packaging packages this and I'm going to put it there and remember I mentioned this earlier and whenever you're using the handlebars which is ginger sand text paste in a variable basically whenever you're using them in this syntax I always surround them in quotes otherwise it's not valid EML you can see that my amel my ml syntax highlighting actually makes that apparent so always surround them in double quotes and then I'm gonna put the service in here right here and right here oops okay so now now this playbook will run the same if I run it here it'll still run the same but it's going to use these variables but what happens if I run this playbook on a bunt - I'll switch this remember in my inventory I have a sent to us group up here and a bunt to group here so I'm going to switch this to a bunt - and it's not going to work because a bunt - uses different names for Apache you can see that it can't find a package HTTP has no installation candidate that means it can't find httpd so for a bun - this needs to change to Apache - and the service name is going to be Apache - I believe we'll see if that works I'm just operating on memory here and my brain always gets a little bit scrambled since I usually work on four different distros depending on the projects that I'm working on in a given day let's see yeah oh okay so another thing that's happening is this is not the right configuration directory on a bun - because the config directory name is different - so I'm going to say Apache config there and it's this on sent to us but on a bug - it's Apache - and actually the the config for virtual hosts is in sites enabled I believe so we'll do that and I I think that'll work we'll see again I'm operating completely on memory and sometimes my brain gets a little scrambled oh I didn't actually use this variable that would be the problem so I'm gonna do that here and again since I'm using Jinja I'm gonna surround this in double quotes to make it valid syntax and run that here and someone's talking about oh using the package manager you might notice that this actually worked on a bun - the task is yum that's actually a bug it's not a horrible terrible bug but the yum module and the pac-man module and the apt module and the package module they all actually kind of in a weird way go back to package and find the right package manager but yes to be more destroyed gnostic it's better to use the package module which it makes it explicit that I'm installing a package and use whatever system is best they're so good for pointing that out I actually found out about that and I posted a bug on the ant Sable's issue queue a few months ago about that it's a very weird situation actually I think that only affects the yum module if you zapped on sent to us it fails but if you use yum on Debian it actually succeeds because yum is kind of an alias to DNF and threw the package module or something weird like that anyway by the time you're watching this video that might that bug might have been fixed but it this all works now but if I switch it back to sent to us I'll wait for that playbook run to finish if I switch it back to sent to us it's going to fail so I want to make this work on both operating systems and I'm getting way ahead of myself here so what I'm going to do is include two variable files one is going to have the default variables and one of them will have the variables for specific distribution so you can do that in ansible using VARs files and I'm gonna give it Apache defaults camel and I'm gonna use a special variable and I'll tell you more about these in a minute Apache ansible OS family you know and what I can do is take these variables out so I'll just delete them from this file and I'm gonna create a file actually I'll put these in a VARs folder Fars new file and this will be called Apache default animal and I'm gonna put these in here and my default will be the abun two settings so this will be the defaults but I want to create another file called new file and this will be Apache sent OS daddy animal I think that's what it needs to be and then I'm going to change this to HTTP HTTP B and change this to slash config dot B so now I have the different settings for sent to us and what this is gonna do is it's going to load the default variables no matter what and then it's gonna see if there's a file for this if there is it's going to load those values if there's not then it won't and it will fall back to the defaults so if I run this playbook again I believe it will load the sent to us files here dick today why is it not finding that [Music] that she sent to us do I need quotes on it I don't believe so this this might actually be a change in the way that ansible does virus files from when the book was written and this is another reason why you should always rehearse things beforehand but I think what is it Fars with first or something like that [Music] actually yeah so this is this is a little different this did change and ansible two points something recently I believe because it is somebody's mentioned gather facts and this this special variable which I'll talk about in a minute but what I'm gonna do here is I'm going to add pre tasks name load variable files and I'm going to use include bars instead like that wonderful stackoverflow question says I can't type with first found and that's I use this instead and I wasn't going to describe it with first found until sometime later but we'll see was first found copy that out and delete this part now what this is going to do is it this is a third way of loading variables into in Hanceville playbook using include VARs and it's using the with first found loop so it's going to go through and it's gonna see if there's a file like this and if there's not that then it's going to load this one I believe and we'll see if that works so it found a patchy default didn't find a West family I wonder what is the OS family maybe that's my problem here debug maybe the OS family is actually Red Hat and that sent to us which means I have a bug in my book that I need to fix which I should actually note to myself so that I can fix this yeah it's Red Hat so I need to name this Red Hat live debugging my book in front of an audience always a fun thing so let's try that and see if it loads that all right so this time it worked because we're actually doing the right thing and my book was wrong shame on whoever wrote this thing anyway so what this is doing instead of the wrong way is the right way is in ansible two point four or five and forget what version its stopped letting you use dynamic variable names in the vars files directive for a playbook so now the best way to do it is to use the include VARs module which will load variables from a file the same way but you can use with first found which will find the file and if it doesn't find it so if I switch back to a bun to here and then I run this whoops I'm gonna run this playbook again then it should still work because it won't find the Red Hat file because this is a bun too but it'll still load the default VARs which is here so sorry about the technical difficulties but that's life work and with ansible sometimes so looks like that works and and since I have this playbook now working for both servers I can actually change this to all and it will run on all the different servers so sent to us in the bun two at the same time and it will dynamically load the variables that are correct for that particular server and it should load everything and install everything correctly which it seems to be doing here yeah and people are mentioning on the chat too that it is Red Hat and that sent to us so thank you for finding that and pointing that out the wonderful benefit of live streaming if this were pre-recorded you wouldn't have seen that that the the secret behind how I actually do things I just search Stack Overflow and find answers from other people to fix my problems I think that's how 90% of programming is anyways so that is that is using dynamic inventory files based on OS family I do this a lot in a lot of my roles because I work with fedora abun too sometimes Amazon Linux Red Hat sent to us Debian etc etcetera so that's that's one way to get variables for different types of systems that way and if you wanted to support more systems you just add another variable file for that system if it has different settings let's see what else am I missing in this there's a few other things that I didn't mention like one is where does this ansible OS family thing come from that's what I like to call the magic variables but it's its facts that ansible gathers about a system and you can actually get all these facts I have a note about it in the book which I am not finding right now but it's you can get all the facts that ansible knows about your system using the setup module so either in a playbook or just using ansible I can say inventory sent to us M setup I believe I mentioned this in one of the earlier live streams but this this module gives you all of the things that ansible can figure out about a system and you can use that to change things in your PlayBook like for instance if you have a database that you want to use half of the machines available memory you can get the ansible mem total MB and then half that and use that value in your config file but it has things like the ansible OS family the fqdn the host name for it the ipv4 address ipv6 address all that kind of stuff is in this you can get the ansible distribution so I think in the book I might have used ansible distribution when I started working on and then I changed OS family but never updated the text to use Red Hat instead of sent to us oh well that that kind of thing happens I mean you can even get things like the version of the distribution so you can flag on if I'm on Red Hat 7 vs. Red Hat 6 versus right had 8 that kind of thing but those are all things that ansible gets when you gather facts if you if you have a playbook and you have gather facts no or false then it won't get these types of things and then this would fail because it won't know the family in fact I'll show you how that looks sometimes you run a playbook and it's not gathering facts and so it will fail on the sent to us machine because it doesn't know it didn't pick up this file because it didn't have this fact available to it so let's see anything else we talked about registering a variable now pretty much any any test that you have you can register so I could do register my computer starting to be a tiny bit slow the the CPUs are still doing okay but anyway we'll see how that works so you can register any variable on any task and if I could say debug far equals foo it'll get it I'm going to remove this gather facts you know I'll just turn it on sent to us for now but you can register a variable from any task and get information about that variable and use debug to see what's in it so that you can get down to whatever you want from it and another interesting thing about variables is there's there's different ways to drill down into the data so this is all the data I got out of this task I can see that it it's not changed it's not failed there was no message that was returned the RC was zero so it was successful and it gave me the results a line from I guess the yum command saying like Yeomans is it installed and it already is so what I can do is I can say if I just want the value of RC I can say food at RC and if I run this again it's going to give me 0 because that's the value of food RC that's one way to access properties of a dictionary in Python and in Jinja and ansible but another way is to use brackets and I tend to use brackets when I'm being a little more formal because there are less surprises with brackets so if I do foo RC like this it'll give me the same value and the reason this is important to know is if you always do food dot R see if you always use the dot dot syntax to access properties there are some things that will trip you up and cause errors like let's say the the actual key is coming from Amazon and the key is like RC - status or something like that if you try doing that it's going to fail because there's a dash in the name and dashes are not valid ways of accessing properties using the dot notation so for this you would always have to use the square the square bracket syntax to be able to access properties so something to keep in mind when you're when you're trying to access variable data deeply nested inside of a dictionary something like that because I've done things like food that fizz that buzz that's something and then access the first array item dot something else and then you get an error and you're like where does this error come from it's because there's a dash in one of these keys so you have to use for that this syntax and when you do that it starts getting a little messy so at that point I'm like okay well I'll just use that syntax for everything because that that way it's a little more consistent logically for me anyway so that is that is how to access variables and register variables and again every task in your playbook I could put register on here I could put it anywhere and get the information that comes back from that task and JE main is asking can we only get a few facts instead of all there's a lot of different ways you can control fats coming from ansible one is obviously you can turn it off you can say gather facts no but it's either no or everything but you can also give ansible a fax script you can put a facts like a Python script or anything that outputs facts about a system into a special directory on the remote server and then that script will be run when ansible gathers its facts but there's there's other things you can do to control effects I'm not going to get too deeply into that because usually facts gathering is not a big deal it only takes a couple seconds per server and if it takes longer than that there might be some other issues that you can fix that help with performance more than that but but for something like running on a on a docker container or something you might want to turn off facts gathering completely but but I'm not going to get too much into that right now it's up to mention that if you also are used to what are they I have them listed in here if you're used to things from like puppet or chef like factor or oh hi and you have them installed on your servers and so will actually by default gather facts those systems as well and mix them into the mix prefixed by factor underscore in Ohio underscore so that's that's one convenience if you're working in multiple configuration management systems and I do mention in the book on page 98 of this edition in Chapter five stuff about local fax that you can put onto a server typically I avoid doing that though I don't mess around too much with facts and ansible just because I have the inventory managed outside of the server's themselves so I make sure that I get the data into ansible through my inventory system whatever it is for example device 42 so the information comes from there and that way the server's themselves don't have to store any special facts about themselves that's just that's the way that I do it but you know as I say a lot there's a lot of times a lot of different ways to do things and what's the way the way that I do it is not always the right way it's just the way that I do it but you know I believe it's the right way that's why I do it but it's not always the right way for everyone so we've actually hit the end of time for today and I was just getting to instable vault and it looks like it will have to stay a secret for another week but next week I'm going to talk about ansible vault and how to keep things secret ansible using ansible vault and that that should just be a short time I'm not going to go super deep into ansible vault but I will mention that ansible vault is a very convenient alternative to using a key management system for certain tasks and for certain things if you just need to throw a secret into a playbook like a database password or something like that it's a it's a secure enough way to do that and it doesn't require you to run external systems or servers to manage your your secrets that you manage with that playbook and it conveniently allows you to store secrets alongside your PlayBook in a place like source control as long as you can have that secret decrypted by ansible using ansible tower or at runtime at the playbook but I'll I'll talk a little bit more about that at the beginning of next episode and then we'll talk about roles how to organize your playbook a little more efficiently using roles and of just having lots and lots of tasks inside one playbook so we'll get into that next week and then everybody keeps asking about this every episode asking about how do i do linting how do i do testing how do you make it easier to see when you're gonna have an error when you're writing a playbook and you're in your editor like this so in two episodes my plan is to talk about molecule ansible lint and Yemma lint and how you can integrate those with your workflow to make it easier to test and develop ansible playbooks interval rolls in small collections and another ansible content yes vault remains a secret for now it is secret knowledge that you'll gain by subscribing to the channel which is right below me and coming back next week I will bring up my little fancy social links at the bottom of the screen here and I'll say again thank you for watching I hope that these videos are helping you sorry about today today's was a little bit more difficult just because there's a lot of different sections in chapter 5 without one really cohesive example that I could get through so I was kind of winging it I don't know if you could tell by the fact that some of the clay books kept failing but I hope you'll come back next week we'll talk about secrets talk about rolls and hope hope that you're safe another quick little bit of news is next week is Red Hat summit and at Red Hat summit which is now going to be a virtual event they're gonna have some sessions on ansible and openshift and things like that so consider registering for that I think it's free now I don't have the link to it but you can ask me on Twitter somebody might paste it in the live chat but Red Hat summit is always a worthwhile event and especially this year since it's free and there's a lot of really good sessions that will be at it so in addition to of course blocking out the 10:00 a.m. us central our next Wednesday for this you can watch the Red Hat summit so thank you and I believe that now I kind of know when the end stream button actually ends the stream so it probably won't cut me off mid-sentence but thanks for

Channel: Jeff Geerling

Views: 62,564

Keywords: ansible, ansible 101, devops, playbook, automation

Id: HU-dkXBCPdU

Length: 59min 28sec (3568 seconds)

Published: Wed Apr 22 2020