Ansible 101 - Episode 3 - Introduction to Playbooks

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

Did you miss the live Ansible 101 episode earlier today? That episode is available for replay here (and see all past episodes here). You can make it to the next episode, coming up in one week, same time and same YouTube channel!

Be sure to subscribe to the channel if you want notifications when the episodes air. I may get some time to do some other videos in the meanwhile, since I'm cooped up inside during this pandemic!

And grab a copy of my two Ansible books courtesy of /u/Device42 if you haven't already! (Details).

👍︎︎ 9 👤︎︎ u/geerlingguy 📅︎︎ Apr 01 2020 🗫︎ replies

Thanks Jeff. I appreciate everything you give to the community. I've plagiarized (ahem, derived from,) many of your roles in galaxy.

👍︎︎ 3 👤︎︎ u/Paul_Aiton 📅︎︎ Apr 02 2020 🗫︎ replies

/u/geerlingguy the book "Ansible for DevOps" that you wrote is amazing. I'm still a newbie but it's thanks to you that I can write something practical this soon. Thank you!

👍︎︎ 3 👤︎︎ u/InvertedDick 📅︎︎ Apr 06 2020 🗫︎ replies

Thanks !!! u/geerlingguy - The Anisble Galaxy King ! Please give some details on Dynamic inventory stuff ( with VMware & AWS say ) , and how to integrate the roles & playbooks in bitbuket/git/github & your take on AWX vs Jenkins plugin of Ansible , Also what is your take on CLoudFromation vs Ansible for AWS automation, thanks & stay safe

👍︎︎ 1 👤︎︎ u/kiranp2015 📅︎︎ Apr 06 2020 🗫︎ replies
Captions
all right good morning everybody good afternoon good evening good night whatever time it is wherever you are or if you're watching this after the fact and that's streaming I don't know what time it is so good whatever time it is where you are before we get started I wanted to thank a few people today first of all device 42 I mentioned last week it's a it's a company that makes products to help you to see all of your IT infrastructure and they contacted me a couple weeks ago and said we want to sponsor another week another month of giving away instable for DevOps and ansible for kubernetes so thank you to them and I wanted to give them a plug so I asked them first for some way to describe them and they're basically a tool that goes along well with the ansible and so ansible is a great tool for IT automation but to make that automation work you need to make sure you have an accurate real-time picture of all of your IT infrastructure and that's where device 42 comes in device 42 provides comprehensive discovery of your entire IT estate from mainframes to kubernetes and just like ansible it's agentless and you can try it for free you can download a trial today at device 42 comm and see how it can take your ansible automation to the next level I also wanted to thank a lot of people for sponsoring me on github and patreon I every video I've kind of just said you know if you are interested in these things want to see more and want to support my work on ansible roles and collections and content and books and things when I sell a book I sell at one time and I give away updates free forever so you know if you're interested in trying to help me be able to keep updating those books without necessarily getting revenue over time from from increased book sales because once you buy it you don't have to rebuy it I really encourage you to support me on patreon or github sponsors or send me a venmo or whatever kind of thing you want to do but thank you especially on patreon to Karl's silly PO and again I'm very sorry about butchering names I'm not great at anunciacion also mark Winkler on github I'll just say the usernames because it's easier than the real names SS Barnea decroux Keijo SC and Dan quoi Laurent David rrw get res adopts e t Lizotte sometimes the username has the the actual name in it so it's a little harder a Colby and d4 and there's also a few other people who are private sponsors thank you so much you're giving me the ability to spend a little more time working on these things this video series updating the books updating the the projects that are used in the books making them continuously relevant to to new readers and to old readers I also thank you to everybody who subscribed I mentioned on Twitter last week that this year I started out the years thinking you know one one small goal would be to increase my youtube subscriber base to maybe five thousand subscribers and a couple weeks ago I started doing this ansible 101 series and now I'm at 7500 subscribers so I think I set my sights a little lower parently and now I'm trying to think of what I can do if I hit 10,000 subscribers what kind of fun things I can do on the channel to to give people fun content and if I hit 10,000 before all this pandemic stuff is over I'll definitely be trying to think of ways to to make some more entertaining fun content for the channel some people on chat are asking if you're late no you're not late just going through some thanks and being grateful for for everything that's going on I also wanted to call out to people please consider giving donations to your food food pantries local food pantries a friend if you're in the US there's a website freedom feeding america calm you can search for local food pantries to donate to since they can't get in person food donations as much anymore some of them are really struggling to have food on the shelves to give people and there's more people trying to get food because of layoffs and furloughs and people who are not able to get the same work that they used to so consider giving to a local food bank especially a money donation right now so they can get the food that they need to get to help people there were a few questions from last week's episode - one of them was for idempotence i mentioned last week idempotence is the principle of being able to do something once or many times and it doesn't make a change after that first time and it's part of what makes ansible really powerful is you can you can set a state that you desire and then ansible makes that state happen on your servers what if you need to do something like update apps cache using the in the apt module there's a there's the ability to run basically app update and that's not idempotent because it always results in a change well ansible is can it can be configured to be more intelligent about that you can set a cache lifetime like a day or an hour or something like that where it won't update the cache if it's already updated within the past hour or day or whatever so that's usually what I do for idempotence there another way you can say it can maintain idempotence with something you know is not going to make a substantial changes you can set changed underscore win equals false and that will tell ansible this doesn't actually change anything you know don't have a report that this changes something if you're running the date command you can do that because running bait is not going to change anything on your system it's just getting information a lot of people all over the place Twitter and on YouTube on the YouTube comments in the live chat everybody's asking about using molecule for testing ansible roles or testing instable play books or testing things with kubernetes don't worry we will get to that it's not actually in the book yet I'm working on the chapter revamping the testing chapter so we'll get to that later in the series don't worry about that right now but I do have a blog post up on Jeff Garlin com and you can go there and find out how to use and how to use molecule for testing your rules or just look at any of the roles that I have on galaxy all of them have a molecule directory with all the test setups in them can you post your answer recipes for elasticsearch I mentioned a couple episodes ago all of the things that I'm doing in this book not only are they in the book but most of these examples also are in the books repository on github which I'm in right now it's killing guys / ansible for DevOps and this is linked to from the books website so ansible for DevOps comm scroll down to the bottom and there's a link to the books repository it has all the examples almost all the examples from the book and they're listed by a chapter here I'm actually moving a few more examples into here as well over the next few weeks one thing that is missing is working inventory system somebody asked this it was funny in last episode is there a way to have a UI or some central display of all this server information for my infrastructure and that dovetailed nicely with the sponsor of this this month's videos and the free books this month which is device 42 because they have a system that does that ansible is not ansible is not a system that's built to like maintain an inventory of all your IT infrastructure usually you'd have a tool like that already and ansible can pull the inventory information out and work on those servers and work on those network devices and windows boxes things like that so those are a few questions from last episode I always run through the the live chat and the comments on the the episodes before the next one so I'll try to keep up with this and you know if you ask something and I don't see it live during this episode that's fine usually I can find it later or if I don't put post it as a comment on the video because I see those as well and I'll get to it in the next episode like we did here so let's get into things again last week the last thing that we did was talked about ad hoc commands and running them against multiple servers so I'm gonna switch over to our vagrant file that we created last week we created two app servers and a database server in vagrant and vagrant creates a VirtualBox machine you can also use vagrant with other systems as well but I'm using VirtualBox locally and we describe those servers in an Sable's inventory so we have the app servers in an app group and this inventory file is using ansible ini style inventory syntax so we have an app group with these two servers and then we have a DB group with this server and then we created a group of groups called multi that has all the servers and we set some variables for it so that ansible knows how to connect to those servers and last week we did a lot of commands like getting the date on the servers and things like that but I'm going to pick up back in ansible for DevOps which again is free right now you can get it on lean pub for free if you desire or also ansible for kubernetes we're going to go back into chapter 3 and we're on write in version 1 point 22 page 36 talking about running operations in the background so a lot of times you can run a run something and it's it's relatively quick so I think we had the example instable - hi I'm in the wrong directory right now it's well - I inventory and we wanted to run it on all the servers so we have the multi group and we just ran date and that is gonna run the date command on all the servers and give back the output if it ever finishes we had this problem last week where things are a little slower when I'm live-streaming I think somebody oops I hid Safari so I can't see my own live chat window but somebody somebody mentioned last week what what streaming software are using and that kind of stuff talking about how I should consider using a Linux machine instead of a Mac or Windows or all these different things and it just comes down to I have like a five-year old Mac right now and and I I'm considering upgrading at some point this year and maybe this will forced me to do it sooner just because things are a little faster with a newer computer with more CPU but anyway so we ran a command and just going back over how this works ansible is a way to run ad-hoc tasks or if you're in britain ad hoc so ansible is that command most of the time in ansible Europe you'll be using the ansible playbook command or if you use tools like tower you don't even have to know the commands that are being run in the background but you'll be running a playbook and that commands like this but we always pass an inventory there's another way you can tell it's all about your inventory file using an ansible configuration file we'll get to that later but ansible has to know about where your servers are so we specify an inventory file and we'll also get into later different ways that you can use inventories for more flexibility you can actually pass folders and scripts and other things that give inventory then we tell ansible about what servers we want to run this command on so I using multi matched to this which tells ansible to run it on App and DB which tells it to run it on all these three and we also mentioned last week how when you tell ansible to run commands by default it uses five Forks so every time you run the command it can it can run them in a different order on these servers so you can see it did the dot 5.6 and dot four so it did it in a different order and if you wanted to change that to make it so that it runs on the first server to find first second server second you can define - f1 and then it should run on that four than that five then that six but it's slower because it has to it does it in sequence instead of in parallel and then finally if you pass - a it's going to pass a command straight to an Sable's command module that's the default if you don't specify module but this is the equivalent of saying - M command and then - eight date it's gonna do the same thing but sometimes commands take a long time so one thing that could take a long time is yum upgrades or apt upgrades if you're on WN or bun - running a script that that takes an hour to to complete maybe it's a job to maintain your server or to copy some giant file or something like that any of those kind of commands can take a while so ansible also lets you background tasks so instead of running it right away and then waiting for it to finish and then giving you the output you can start the task in the background and then you can get the job status later so when you're doing that there's two main options for it one is the - uppercase B command with a number of seconds and that's how long in seconds you want to allow the job to run so it can run you know you can you can give it an hour and then if it takes more than an hour instable kill it something like that just to make sure that it doesn't go on forever and then also there's a - P - P gives you a polling time in seconds and that's how often ansible will check in to see if the job is complete or not and you can run it you can run a command and have it back rounded on the command line with polling but usually what I would do is set the - P option to zero and the interesting thing is there's actually a bug in the instable 2.0 which is now a little bit old and later that the polling doesn't actually work correctly on the command line it's a little bit complicated why that is but but in the book it links to the issue where you can track progress on that it's not that useful anyway so if you're gonna run a command that's gonna take an hour you're not gonna leave it sitting on your your desktop too often and if we were gonna do that you don't even have to use the back rounding and run a synchronous commands anyways but we're gonna run a yum update on these servers since that could take a long time especially with the fact that my computer's dying from from the streaming but we're gonna run a yum update command in the background and then we can check on the progress so I'm gonna do the same thing ansible - I inventory - or multi for all the servers and then I'm gonna use - B to become the root user so - B is the clone of become user and that uses by default sudo to become the root user on the server because we need to be root to be able to do this yum yum update command then I'm gonna pass - B 3600 that's what is 3600 divided by 60 so that's 60 minutes one hour usually I have these numbers memorized but I know 86400 is a day and you know 500 is five minutes and those kind of things but this is a second so a 3600 is allow for an hour for this test to complete I'm gonna do - p0 that means that it's just gonna exit out it's the equivalent of passing the output to like nohup and and the command just goes back to your terminal but it runs in the background but ansible will manage this on the server side and then I'm gonna say - a yum - why update and again if I don't give it a module so no there's no - em it's going to default to the command module so it'll pass this command to the command module and this should kick the process off on each of the servers and when it gives me output it will also give me a results file for each server and that results file gives us a job ID and the job ID can be used to check on the progress of that job so the dot six is our database server so this is the job ID on the database server and it gives us a different job ID for each server actually the ansible job ID has the job ID so i'm gonna grab this job ID and i can check the progress of that command on that server using the job ID with the async status module so I'm going to say ansible inventory multi - yeah I don't actually I don't think I need the root user but I have it in the book so I'm gonna keep it here so I'm gonna use the async status module and give it the argument job ID equals that and actually since that since it's unique per server this job ID won't exist on the - app server so I'm just going to run this on the DB server instead so I'm gonna use the group DB and run that command and it should give me back the job status as well as it will give me the output from that job so this again this this is something that you probably won't use too much but every once in a while it can come in handy to be able to just kick off a job on your servers with ansible using your same inventory and then later on you can check the status or even if you don't check the status not the end of the world but here's the the job status it says that it finished finished is 1 this is when it finished and this is how long it took to run the command and then it gives you the output it gives you two options most things in ants will give you output all in one blob here or it also breaks up the lines depending on how you want to consume that if you write some some automation to deal with the output so that's that's one thing that you can do to to run tests in the background and another note that I have in the book is that if you're not tracking the progress of something remotely it's still a good idea to make sure that whatever it's doing is being logged somewhere because if this fails ansible is not going to put that failure on your screen automatically you're gonna have to check on it manually so it's not always a great and not always a great idea but it can come in handy sometimes another thing that you can do with ad hoc commands is check on logs this is again something where it's typically better to have a central logging system for this kind of thing but if you did need to glance at the end of some log files on a bunch of servers really fast it's a way to do it so I can say in scible multi - B - a and that again - B is there because I need to become route to see some of those log log files that are in the log directory tail bar log messages whoops I didn't give it an inventory file inventory and that's just gonna dump out the messages from each of these different each of these three servers to the screen so sometimes that can be useful for debugging there's a bunch of other things you can do another quick note is if you're going to do something like let's say I wanted to see how many lines were in each of these each of these messages you can also let's see so one of the things I want to see is how many times was ansible command run in the log so I want to pass through grep ansible of command because I can see it was in here and it was in here and then I want to see how many times that occurred so WC - L if I do this it's going to fail because an Sable's command module doesn't happen handle pipes and redirection and things like that so what you want to do if you ever need to do that is use the shell module which is - M shell it's generally best practice not to use shell unless you absolutely need to use shell so but shell will work with pipes and redirection so I can get back the output of that that full command there's plenty of other things you can do I'm not going to go through all of them here but I will say that you can manage cron jobs using the cron module and you give it a name equals something and an hour equals whatever it is you know an hour minute day all those kind of things and then give it a job path to script SH something like that so you can manage cron jobs through it you can also delete a cron job using state equals absent you can also use other modules like one thing that you could do if if you needed to run a command to update a server's get repository is you could use the git module - M get and you can give it a repo so github URL goes here and give it a destination best equals apt app and update oops update equals yes version equals one point two point four so some people sometimes use this just to update a repository that's on their server for an application that's deployed again this is something where you should probably have a playbook and more automation for this if you're using instable tower you'd have a project and a job template set up for this so that when you update your app maybe when you create the tag on github it can it can use a web hook and tower to tell tower to do the deployment and anything else that needs to happen after that deployment is complete but I'm just showing here that it is possible you could do all of your infrastructure automation just using the command line with ansible I don't recommend it though because that's not getting closer to infrastructure as code and you can't really test it as well and in the book and the end of chapter 3 I talked a little bit about an Sable's ssh connection history how it started with paramiku and uses OpenSSH now and one important thing to note is that I believe that the default for ansible is still to not have pipelining turned on and that can actually slow down your playbooks quite a bit so one thing that I typically recommend doing is if you have an ansible configuration file so I'm going to save this file called ansible Galan vincible dot CFG in your ansible configuration file you can say under SSH connection pipe lining pipe a hack nice belt mining equals true that's going to use SSH pipelining to make sure that when it creates an SSH connection to your server it can reuse that connection over and over for commands instead of having to re-establish a connection I believe that's still the default in Hanceville 2.9 but that might have changed recently I need to check on that but if if it did change then the faults great but if it didn't I this is going to help you have faster playbooks which we'll get to in chapter 4 which we're getting to now so any if there's any questions about ad-hoc commands or anything that I've just done in the few past couple of minutes please post them in the live chat I'll check on that really quick while I take a quick drink yeah and again the Omega BK asked do you have a session for using molecule and step by step and yes earlier in this episode I talked a little bit about that how we'll get to that at some point in the next few episodes something about vagrant and oh I'm glad I helped you in your internship with vagrant and Arin thank you for mentioning that yeah if you if you can pay for the book I would love if you paid for the book but the main thing I've mentioned this a couple times before I really hope that you know especially if you're you're in a situation where you're furloughed or your pay has been reduced or anything like that I don't want to worry so much about the money I just want you to learn the skills and maybe later on down the line if you do end up being helped by the book and find it valuable and have the means then you could support me some other way but the main thing is to get the book now and worry about the payment later unless you can't pay now nothing else right no just and thank-yous all right so we're going to get into chapter 4 which is ansible playbooks and instable playbook so on the command line it's all it's all it's not super discoverable it's not super readable you can't version control this stuff you could shell script it but that that defeats the purpose of using ansible play books are written in the amyl and if you if you hang out on Hacker News there's there's always this fun battle there's there's people who hate you animal and then people who are pragmatic about animal and I'm somebody who's pragmatic about animal and it's the fact that like it's not great for complex configuration but nothing else is either and it's the best thing that we have and it's way better than something like JSON and it's better in my opinion than using a programming language or something derived from our programming language because then you limit the audience that can work with it and understand it greatly so ansible has a good abstraction layer that pulls out a lot of things that are hard to do in shell scripts and makes them easy to do using amal using ansible x' modules and that's what we're gonna get into it I think one of the things that I like the most about the way that ants will play books work is I work a lot of times with people who are PHP developers Ruby developers Python developers go developers Java developers all of them can understand ansible at least at the basic levels very easily they can pick it up in an hour or less when I tried using other tools like puppet or chef or a salt stack is a little bit different it's a little easier in some ways but it also has a little bit more difficult model of usage I think but when I tried using the other ones that a lot of times wasn't that easy to pick up unless you were already a person who understood the base language it was written and with ansible that's not the case it's it just so happens to be written in Python which is an approachable easiest language to learn but you don't have to know anything about Python to start using ansible and that's why I liked it a lot also really quick here Aaron mentioned something about using 2.10 much ansible 2.10 is not yet released it won't be probably till later this year but there will be some changes in Hanceville to Quentin and the book will be updated for those changes and so will some examples almost everything you see in these videos though will still work with 2.10 there might be some minor differences and unfortunately that's just the nature of the world when you're doing anything tech related I'm considering doing some kubernetes live streams as well and those will be out of date by the time probably the live stream is over like things will work when I start the live stream when it's over there'll be a new kubernetes version releases that deprecates everything I just used that's kind of the nature of the beast with tech stuff but hopefully these videos will be relevant through 2.11 2.12 and beyond but there will be some things that change anyway so one thing that would happen a lot of time so I'm gonna go over - I'm gonna say vagrant destroyed - eff that's gonna kill these three VMs that we've been using and practicing with on these examples and I'm gonna go over to another directory called playbooks and close this out and I'm going to open this directory in here and I have a server set up in my inventory it's an Amazon ec2 server this is at IP address and this is the key pair file that I downloaded from Amazon for the server and so I can connect to the server and we're going to create a playbook soon but first I'm going to create a quick shell script so I'm gonna say touch we'll call it patchy we'll call it shell script that SH and I'm gonna make it executable plus-x shell script and in the shell script I'll show how up until the time I started using Ansel this is how I usually configured a quick web server using Apache and this is this example uses why this is also a small font sorry about that if you can't read this this example is running on sent to us but it would be similar but a little bit different if you're running on Debian or a bun - and in the book there's examples for both but the first thing that I would do is install apache if you're on debian or bunty the first thing you would do is probably update the app to caches but I'm gonna say yum install - - quiet and the reason I'm adding these commands is I'm making a shell script to do it if I was doing it interactively I could just do like um install httpd and then I could answer the prompts and things but in a shell script you have to know more things about like how to make sure that your shell script doesn't stop or how would make sure the shell script isn't giving you output that makes you confused so I'm going to do that with HT PD httpd that is so hard to say httpd devel so that's going to install Apache I'm gonna copy copy configuration files in place so I'm going to say CP httpd be that config - at sea HTTP config httpd I'm just gonna stop saying that word because I cannot pronounce that we host HTTP because that config so we would install Apache copy over some of our customized configuration files and then configuration files and then we'd start Apache and configure it to run at boot so we'd say service HT service HTTP start and check config HT on so this shell script is not I mean it's gonna it's going to do what it says it's gonna install Apache but you're not gonna know whether it was already installed or not it's gonna copy this these files blindly on top of whatever's there but it's not gonna give you the opportunity to say you know whether it wasn't copied or not or give you a thing like back up the file if I wanted to back up the file I'd have to check out some files there back it up if it's there then copy the file all that kind of stuff then it's gonna just blindly try starting the service even if it's running it'll it'll try starting it again which typically won't cause a problem for a properly configured service and then it's going to make sure that it's set up on system boot so this is a pretty common pattern for any application you're gonna install you're gonna do something like you're gonna build it from source download it from somewhere or install it using your system package manager then you're gonna copy some configuration files in place and then make sure that the thing is running and set up to run on boot or if it's a container set the entry point or something like that so we're gonna do the equivalent type of thing but using an ansible playbook and I'm not going to run this shell script on the server because it's not item potent in it will and it'll cause some funny things to happen with our ansible playbook but I'm gonna create a separate file called playbook that yml and you can call your playbook whatever you want one common pattern is to call it main that Yamma whatever the main thing is that's gonna automate your server you'd call that mean that amyl and then any other playbooks you have could be like I often have one main dot animal that sets everything up and deploys my application they have a separate play book called deploy dot animal that does deployments only and the the main that animal can even call that other playbook at the end if it needs to but I'm gonna call this play book mammal and this is not strictly required but I always do it for EML files I start the document with this three dashes and that is a yell document separator and it's a good practice to get into just because later on when you get more advanced usage you might have multiple llamo documents in one file especially if you're doing things like kubernetes work so I always start with a the dashes just say I'm starting a gamified here because technically speaking and this is something that may or may not work depending on what language you're using an Amal parser this text here is plain text and not Gamal but below here this is now Hamill and you can separate multiple documents by using more of these so this would be M 1 and channel 2 however with ansible zml parser this would actually be evaluated as Amal but will not get into that this is one of the one of the many reasons some people hate Amal is because there are some ambiguities and some differences between different languages and platforms and Stephan mentions in the chat that the the separator is actually required by Gamal int and yeah that's another good reason to but some people ignore linting and don't follow best practices but whatever so like that like the playbook that we did and I believe as a episode 1 you start off by saying well some sometimes you start off by saying name of the play is install apache so that's the play name and then host is all i want it to run on any host that's in the inventory I could also say host ec2 that's the group that this one server is under or I could even say host and then just list this this IP address or host name but I'm just gonna say host all and then I'm gonna give it some tasks and the first task will be installing yum so in this one we did it using yum install - quiet that's why in ansible we'll say name install apache so already we have the ability to give it this is kind of like a comment and a name for the task that will appear in our output so in the shell script when it runs this it's not gonna give us any indication besides yums output that it's installing apache but in the ansible it's going to print this above whatever it does to install apache so that's that's a nice convenience feature right there and then I'm gonna say command yum install bash - quiet - why HTTP Givi httpd I cannot spell and I can't type it either the vel and I'm gonna say name copy configuration files and I can already see a few people probably steaming it wait he's just putting the command straight into his playbook this is terrible you're not using ansible to its full potential and that's true but I'll get to that configuration files and then command and since this command is a little bit longer and it might run off the screen over here I'm gonna use a Gamal convention this is called the folded scaler you don't have to know what that means but this just basically means take everything from this line down that's indented at the same level and merge it using a space between each line so in this case I'm just gonna have one line which is the same as this copy this file but and the only reason I did that was because if I don't do it well actually it fits on the screen here but sometimes it goes off the screen depending on what zoom level I'm at and sublime and then I'm gonna have another one Oh so in the book example I actually have two separate commands like this whoops and I do the next one here again this is not the best way to do it with ansible but I'm just illustrating a point which I'll get to very soon name start apache and configure it to run moved and then command service HTTP start and command check config needs to be on so this playbook is the equivalent of the shell script already though we're getting a few things that we don't get in the shell script one is that ansible will start checking did this command change anything unfortunately because command can't be super intelligent about these tasks it's always going to report a change because it can't know all the details about when IAM performs changes and not all that kind of stuff but it does give us labels for every section of the PlayBook that we're running and it can let us put all this put all these commands into a more formatted and structured list and you can you can space things out a little nicer so that you can see more of the sections of what's happening here and the reason why I did it this way is just to show this is how I started using ansible in the first place I already had a lot of shell scripts like this setup for my servers and and instead of spending all the time to try to make like learn everything about ansible and do everything the ansible way right away the cool thing about ansible was I could just literally pop in a bunch of commands and and you could even do things like instead of having all these commands separate tasks like this which is a better way to get started doing it because you're separating everything out into an individual task and you can you can put a name and label on each task but you could even do something like this where I'm gonna say shell and then I can copy multiple lines in here and you could literally dump a shell script into an ansible playbook like this and it will run all these commands this is I forget exactly what that's called let's see yeah mol pipe so the little this little guys a folded scaler and the pipe is a multi-line scalar so what this does is instead of merging these lines with a space in between them when it runs them it merges them with a new line between them so it literally runs it like a shell script and tip number 2,000 or so is I always Google everything anyways some people think I know all these things out of my head but I just know how to Google that's most of computer science I guess most of real world computer science some people have to I guess make algorithms and things but that's not what I do so anyway I'm gonna go back to how this was here so that that's a cool thing about ansel is you can just take anything that's in a shell script and dump it in the ansible right away and it it starts working and you're already a little bit better off but we want to get a lot better off so let's see and also in the book I start to mention too that there's a few different ways that you can do these start writing ansible tests so we'll start with this top one here and if you actually if you run this task ansible will print out a warning that says like you shouldn't use the UM you shouldn't use Y um in a command and you can actually sculpt that warning if you want to squelch or disable it turn off that morning if you are using yum for something that the Antipodes particular yum module doesn't work that well for which is very limited in the module does almost anything so you shouldn't ever really have to do it but everyone so you might have to but we'll take this first sorry this first task and I'm going to grab it and put it in a new line and we're going to install Apache using an swells yum models so instead of using command I'm going to say yum and there's two ways that you can format ansible tasks one way is more of the structured vml way where it's it's an object that is passed to the UM the yum command the other ways I guess it's called like ansible shorthand syntax and we've been using that on the command line a lot over here where you give a key and then equal sign and then a value and so you could say yum with let's see yeah I'm with name equals httpd actually it's interesting I don't know if it's a list like this that you'd use and this is one reason why this this particular syntax is not usually preferred but you could say name equals httpd state equals present and that will make sure that it's installed but the syntax that's preferred for most cases when you're writing playbooks is to use the structured gamal so I can say name and then you can pass it one or more items in a list or if you're just installing one thing you can give it the name I think HTTP like that but since we're installing two things I'm going to give it a list HTTP devel and then it's you don't have to do because the default that I always do it just to be specific and because later on when I'm revising the playbook to make it so I can also uninstall things it's easier if you already have this all set up and you can use a variable to state whether it's present or absent you give it a state and we're gonna say we want this to be present and you might wonder again like last week where am I getting all these things for me I've memorized a lot of them but if you don't know what options are available for a module you can see the ansible doc yum I believe it is and that's going to give me the documentation for the yum module and give me all the options so that's there but I to look at the information online so if you say ansible yum module it usually is the first first thing in the list you can find all the gory details about options you can pass them along with examples the examples are usually the best part of this because we're writing a task that's almost identical to this first task here and you can as it says here you can use state latest to get the latest version and update it if it's already installed it'll update it to the latest version that's available in your package manager but we're just making sure it's installed right now we don't want to update it if it's already installed so that's the yum module and what this gives us versus the first command is ansible has a yum module that will do everything that we need to check if it's installed if it's installed it's going to report that there's no change and just bail and say that it's no changes happen it's just going to be okay it also will use all the right commands and implications to answer the prompt to install it it it preserves the output and an Sable's output it doesn't dump it to the screen so it's quiet by default but you can make it more verbose easily so it does all that stuff for us and we don't have to worry about it so that's the first command and the second command is we're going to use another module from ansible called the copy module I'll just copy this coppy configuration file so instead of using CP to copy a file which this file would already need to be present on the server which means that we'd also need to like our sync it to the server or use SCP or something to copy it up it's the shell script where being run from your local machine or a central CI system we're gonna use ansible is copy module and we're actually going to use another feature of ansible called loops or there's a shortcut to it called with items that I use a lot so we're going to copy two files so we have two items and a loop that we're going to run through so with a copy module there's the the the basic way to use it is to give a source for the file and this is going to be templated so I'll get to that in a second a destination and I'll get to that in a second because that's going to be templated to an owner for the file so in this case we want the file to be owned by root once it's copied in a group and this saves us from having to copy the file and change permissions using chmod and change the ownership using Chone and all that kind of stuff and we can pass it a file mode oh 6 4 4 is the right file mode for these two configuration files in Apache obviously these things will change depending on what kind of application you're managing and how its configuration files are managed but this is for Apache and then what I'm going to do is I'm going to say with items and this tells ansible that there's multiple things that we're going to we're going to process the first one and we're going to use a llamo list which is if you have just a little dash that starts the first item in a list or an array and the first item is going to have two properties a source HTTP need that config and a best which is this right here and then the second item is going to have a source of what is the second one this with that config I missed that dust is this guy here and then now to use these in the test so I left these empty because I was going to show how to use these things we're going to use Jinja which is a syntax for templating in Python Jinja is very similar to I forget what it's called and gogo template or something it's it's a syntax for replacing variables and it has filters and things right now we're just going to put a variable in here and these two the open and closed brackets this indicates I'm gonna use a Jinja variable and I'm gonna use Jinja so I'm gonna do that for both of these and then when you use with items ansible creates a magic variable called item that has the data for each of these items and then it's going to run the task once for each of these items so it'll run it run it once for this and then run it again for this so we'll have item and then that SRC this is an important thing to understand when you're using ansible and Jinja and this is one of the few cases where it is helpful to know how Jinja works and how ansible works and how how it uses python on the back end typically it's convenient to access properties of something in python using dot notation so item dot source is the item that's this whole thing and then it's the SRC that's that's the part of it that you want there's another way that's a little more verbose to do this is you can do this syntax which is I don't know exactly what it's called it's similar in PHP if you want to access a property of something well and I should get out of PHP because I could confuse myself and everyone else here oh I have the wrong destination here sorry about that thanks Oliver and I still have the wrong destination HUD these this is the equivalent of doing item SRC however sometimes it's safer to do it this way if you are accessing an array item that has let's say a dash in it so like let's say that that's the variable if you do it this way then Python doesn't really like that so that's not going to be a problem in any of the examples that we're gonna get to in this especially the first week chapters of the book but it's it's something to keep in mind if you do if you go off from this episode you start building a bunch of play books and run into weird issues sometimes it's due to that so just wanted to get that clear that road mine for now and so for this one it's simply item that best so that's going to say pass these to the copy module do it first with this item do it second with that item and then next up we have the the service state we want to make sure it started and it's enabled on boot-up so we're gonna use the ansible service module for that so i'm going to say name me I'll do this here another thing that I do a lot of times when I'm writing tasks is instead of saying start Apache because this is technically here won't start Apache if it's already if it's already started so to name the task appropriate I say like ensure Apache is started or something like that or I say in the book I have make sure patching is started now and at boot just to be a little more precise in with what it's doing and we're gonna use ansible service module for that and we're gonna say name equals our name is httpd and state is started and enabled is yes another note on yeah Mille syntax is yes and you can use yes or no for a boolean or you can say true or false and in some cases but this is always a bad idea you can use a 1 or a 0 it's always a bad idea to do that because you start running into weird typing issues and that's a problem with any dynamically defined language and I always stick to true and false just to be super clear but it's often seen you can also see people using yes and no a lot and you'll notice that my editor I'm using sublime text 3 my editor has a yeah Mille syntax for matter in it that that identifies these things for me so it's it's easier for me to see things where I'm you know like for instance the mode here this is an octal and so I done it identifies that with a different color which makes it more helpful for me to know what's going on here it also would do that for a simple integer but but it's helpful to have a code editor that it highlights yeah Mel for you so that you can see what you're doing and if you if you accidentally have an extra typo in there this is going to break because that's a string and not a boolean anymore so anyway I'm gonna say true there just to be super clear about it and now if I delete all this this playbook will install Apache copies and configuration files and start the service and make sure it's enabled there's a couple caveats to it we're not going to get into everything right now because this is the first playbook the first real playbook we've ever written with item Potence but one thing is that let's say it's the second time you're running this playbook and you have this configuration file and you change something in it you'd want to restart the service and this is gonna make sure it's started but you know and and you could say restarted and that would make sure it's always restarted but you don't every time you run the playbook if you didn't want to make a change you don't want this to restart the service because anyone connected to your server might have an error while it's restarting something like that so it would be better to also say like if these files change restart the service and we'll get into that in a little bit but for this playbook I'm just defining some of the basics we're also getting up on time so I you know I don't think we'll get into other examples but I did want to run the server against and run this playbook against that server show you what happens one unfortunate thing is I don't have a HCB httpd config file or v host config file right now so I'm just going to comment this this particular section actually you know what I'm gonna do is I'm going to copy them and then we'll just let it we'll let this fail and then well well it's just to illustrate how to run the playbook so I'm gonna create an HTTP HT I can't say it I'm just gonna create it not going to say the word touch HTTP that config I said it didn't I Touch vhosts that config okay so we have these two files and they're empty so Apache is gonna blow up and hate us but that's okay for now so I'm gonna run this playbook I'm gonna say ansible playbook and just like the ansible command you can pass it an inventory file and then playbook that EML and I'm gonna see if I had any typos here because I haven't I didn't check the syntax of the playbook it looks like it's working so that's good so it the first step is it always gathers facts you can actually turn that off if you don't need that if you know everything about your server and you don't need to change anything in your playbook you can do that but for me I like to leave it enabled if I do need to use it for flagging on it any differences now the first thing is I just noticed I need to be route to perform this command so there's a few different ways you can approach that one is you can call the playbook with bash be to become the root user for the entire playbook another way is if there's just one task that you need to do it so like let's say it was just this I could say become true or become yes or become one but I'm gonna say true just to be super explicit so if it was just this task I can do that and it'll become the root user using sudo for that in this case though this is going to require me to be root and this is gonna require to be right I can't speak at all today all these are gonna require me to be root so I'm going to at the playbook level and become true and that's going to make me the root user on the server using sudo for all the different tasks in the playbook so I'll go ahead and run that and our our West mentions that these are called mustaches yes I was completely missing on that blanking on that name but in in many templating languages use mustaches to template things and it's extremely rare that you have to have mustaches inside the template and output but when you need to do that you can do something like back there for words with that's a / you know something like that that we won't get there none of the examples in the book have that so as I as I mentioned since I copied the these files and we basically blew up Apache and this won't work but since I used an Sable's modules for everything the second time I run this it's going to check if these are installed and it's gonna see yes they're already installed and doesn't have to make any changes so it just gives me okay and for this it checks those those files and make sure the content is the same if it's the same it reports okay and then for the service obviously it's still gonna fail because of the fact that that the configuration files are empty and I can actually use ansible to check on what that is doing inventory what is it you see - is the server - a just run the command that this gives me and it's gonna give me the output for that service and I can see let's see what is it saying in process exited it's not going to be anything really helpful there but I know that the problem is that I just gave it an empty configuration and the Apache does not like that kind of situation but anyway so we've gotten through our first playbook there's there's some other things you can do so in this in the let me open this back up if you had multiple servers another thing that you can do when you're running ansible playbook this works for ansible - but I didn't mention it till now if you have multiple servers and you just wanted to if you wanted to run a command on all but one server let's say you could say ansible playbook and this is the other directory so don't don't sue me about that but you could say ansible playbook - I inventory Multi multi man my spelling has taken a dive as we get into the end of the hour but I can give it a limit and the limit can can do a few different things one is you can say limit DB and that's just going to run it on the database server obviously you could also just target the database server but you can also limit it to one server in particular so like one 92168 16.6 so that would just run it on that one server or I could say limit equals one 92168 60.5 for just one of the two app servers you can also use things like negations which i believe is like exclamation point : or something like that you'd have to look up the documentation for that but you can do not DB something something along those lines so you can limit where playbooks run you can also another thing that i didn't mention before is there's I believe it's a Hansel inventory command ansible inventory and you can say - just list and what this does on it I didn't give it let me clear that out I didn't give it the inventory file so - I inventory if you ever need to see if a server is available or if you're using the right inventory or something like that you can use this command and ansible inventory to get a list of everything it knows about all your servers through the inventory this is also helpful if you're debugging inventory script or an external inventory system integration with ansible but I think that's that's all get - now chapter 4 has plenty more I'm I've been kind of going through the different examples to see what's what's better - to run through on the live stream because I probably won't be able to get to all of the examples in detail that are in the book on this live stream just for time limitations I don't want this I don't want to spend six months on Chapter four but we'll probably get into another playbook that's a little more of a real-world scenario with an application that runs on your server and you do a deployment through get all that kind of stuff I will probably get to that in the next episode and I'll I'll go through a few more of the options you can pass the ansel ansible playbook command for debugging and and for more information about it but anything else in chat that I need to run through let's see doo doo where's my mouse there it is it's on the other screen some people talking about a to view X we'll be talking about a WX later on as well that's gonna be in I think it's like chapter chapter 10 or chapter 9 or something like that again if you don't have my book this this live stream is basically following along with different examples in my book so if you don't have the book please go and grab it go to ansible for DevOps comm and most of the questions you're asking a lot of them have answers in the book somewhere and we'll get to them in the livestreams but again thank you for being on if you want to put really quick I forgot to ask this earlier I always like to know where you're from in the in the live chat it's cool to see where all the different people that are watching this are from just to see kind of the global community and also I really hope that you're doing well it's it's kind of sad when I hear some people having some issues with their jobs and job security right now know that I'm I'm still praying for you whether or not you're you're religious or not I will say some prayers to help help get everybody through this time and please consider if if you are benefiting from this and you have the means please consider either paying for the book or supporting me on github or patreon the links are below also if you like this hit the like button hit subscribe all the YouTube things hit the notification bell I don't care too much about it but apparently it helps with algorithms and things so I guess it's helpful to me but thank you very much and I will see you next week same time same place 10 a.m. US central 3 p.m. UTC so day evening morning wherever you are in the world depending on where you are but it's it's great to see so many people it looks like we have California in the USA Bulgaria UK Orlando Florida in the USA New Jersey Pennsylvania Canada India that's one person from India but in Toronto so awesome to see that Canada it's funny it's one country I have never been into but I've had like five chances and they've all come very close and then I just never got up there I was in Seattle last year and had a chance to up to Canada but obviously not gonna happen in the next few months but I will hopefully get up there every Canadian that I've met is very kind and generous so thank you very much I'm gonna go ahead and end the stream and I never know when it actually ends so it'll probably cut me off mid-sentence we'll see or if my computer will lock up and I won't be able to end the stream and he'll just hear me rambling because I clicked on the end stream button and nothing's happening yet
Info
Channel: Jeff Geerling
Views: 35,355
Rating: 4.9881186 out of 5
Keywords: ansible, automation, playbook
Id: WNmKjtWtqIc
Channel Id: undefined
Length: 62min 7sec (3727 seconds)
Published: Wed Apr 08 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.