Hi, and welcome to an introduction to Ansible for network engineers. My name is Jason Belk and I am a senior technical advocate at Cisco Systems in the learning and certifications organization. First, what is ansible? Well, Ansible is a free and open source command line tool that does runbook style automation. It's owned by Red Hat and it's been broadly used in the industry, especially in the cloud compute and storage space, for over ten years. So when Ansible runs, it gathers all the resources it needs and then goes out and talks to all the differences, network devices, cloud resources, whatever you're doing. So it doesn't store any state in any type of database. It basically loads in variables and different components that you've set up ahead of time and then goes out and makes the configuration or read actions that you're looking to do. So it works for all different types of infrastructure resources, not just for network devices, but as well. You might even have existing licenses if you're in a larger company in your compute, storage, other parts of your it teams, they're probably already using this in different ways, and so you might be able to leverage some of that as well. But why should you care? As a network engineer, for me, I know when I was getting started in network automation, there's just so many things to learn at once. And for Ansible there are a number of things you do need to learn. But I think the power of it is that the playbooks and the way that it's written are easy to read, easy to share with others. So it makes collaboration easy, and it makes reusing other people's playbooks for getting started very easy as well. You can take your existing lines of configuration that you're going to make for a change, or your list of verification commands you're going to send in your next change request and integrate that into Ansible. So that way you can start having automation trickle into your existing workflows. And as your confidence increases in the tool and your ability to use the tool, you can then start having more and more of your things that you're doing manually, just made just for one device, and you go into the next device with Ansible, you can scale that out to many devices it has built in scaling and threading. And so if you're going to maybe make a change window for 30 different devices, you could have Ansible talk to all those 30 devices at the same time, more or less send this verification commands before your change. You could still do the change manually, then you have it automatically send the verification commands and save those all to a file. And eventually once you build up your confidence, you can use the powerful configuration templating engine of ginger two that's included in ansible to then also abstract away and start templatizing your configuration for all those changes that you do on a common basis. So what are the basic building blocks of Ansible? You have an inventory file for listing off your devices. You have modules that are in a playbook. The playbook has these modules that are basically the workhorse, the functions that are actually talking to your different devices, that you define your inventory. And then finally you have an application configuration file that just defines the default values that you'd want to have within the application. And that's something you don't touch very often, but we'll talk about, just so you know it's there. So first, the Ansible inventory. It can be either in an INI format, you can see on the top there where it uses brackets to define groupings such as a device group of iOS XE. And then you also have the yaml format of a different inventory file below where it uses indentation base and colons to define the structure of that. And Ini Yaml, there are things that you should look up and see examples of your own, but they're relatively intuitive to work with. And this Ansible inventory file devices, what you call your device, it doesn't have to be the same thing of the actual device name, but it makes sense to do that just to be consistent. So you have your login credentials. I mean, in a production area you wouldn't have plain text credentials, but just for demo purposes, we're doing that to keep it simple. And then you have your IP address, device types, things like that. So ansible knows how to connect to the devices. All that is basically started and hidden away in the Ansible inventory file and you don't touch it very often. So that way when you're working with a playbook, all those details are not in the playbook. It'll be hidden from you, but it'll be assumed that Ansible will be loading in. So what is a playbook? An ansible playbook is basically a sequence of a series of tasks where it goes to the first task, let's say it's configuring SNMP. So it sends a series of lines of configuration to the one or many hosts that you've defined in your inventory file that you've associated when you're running it. So when you run Ansible you say, hey, Ansible playbook, bring in this particular inventory file. I want to work on this device or group of devices, and then it will go down your list of tasks and say the first task is configuring the SNMP, it'll go to each device, see if the configuration is present. If it's not present, it'll push the configuration, and if it's already present then it won't push the configuration. It basically does a simple diff to check to see if the configuration you're working with is already in the device, and then following tasks might be sending verification commands. Maybe you can use the Webex teams or slacks modules to be able to have ansible talk through the APIs to then maybe have those verification commands that you're sending to the device, the output saved and then stored and then pushed out to your different operations chat. So you could have really easy integration across a broad range of things. And the ansible modules are what I was referring to before. So these sequence of tasks in the playbook have these functions that are called modules, and there's over 750 of them available. So there's broad ones as well as purpose built ones for specific situations. Ones we'll be using in our demos later today will be focused on working with iOS devices, and so they'll be making configuration changes to iOS devices as well as we'll be working with the ginger two templating language. But you can work with Webex teams, you can work with ServiceNow. There's a lot of different pre built modules that you can just pull it in, swap out a few of the parameters that you read on the docs, the inputs, the parameters, and then you're off and running. So there's just a huge amount of power in being able to have a level of abstraction on commonly used it processing tools in these modules. Finally, the ansible application config, also called Ansible CFG file. This is either in your current working directory wherever you're running ansible, or in your ansible folder if you're on a Linux system and you don't touch this very often, but it's good to know about. So it has in an ini format you say we want to have. Here's the default place we're looking for the inventory file, or maybe here's some custom libraries where we're going to pull in custom modules because you can customize ansible and so it's good to know about that's where those things would be stored. You can turn off host key checking if you don't want to have that verification for your lab and just your testing. So that's basically where all those different components live. And now putting it all together with ansible templates and variables. So now we've talked about playbooks, modules, the inventory and Ansible config file. One of the other huge, really important things about Ansible is working with templates and variables. This is really where the huge productivity increases, just skyrocket for network engineers. You're able to take existing network configuration, let's just say you copy it from the running config and then you swap out some of the key values for variables. So you can see on the right hand side there, it has some markup there for, for loop. And you can start very basic, you don't need to start with looping, but basically genja two is a templating language used within a web programming. Ansible is able to leverage that language to then give you more complex logic if you want to use it for say, looping over a list of interfaces. Because if you look at a list of interfaces, you see particular syntax that's repeated over and over again. And the only parts that change are, let's say the interface name, the IP address, the subnet description, and you can have those particular values stored in a variable file serialized in YAML. And then you have a template that says, hey, this is the form that it's going to look like every time. And then my Yaml file defines the thing that I'm going to feed into that template. And ansible is able to associate those variable files with particular devices. So you can have different variables for different devices socially. Router one has these particular set of IP addresses. Router two has these particular set of IP addresses. San Jose region has these particular sets of variables. And then Ansible is then as you set it up and tell where the groupings are, what devices you're working with, you're able to then feed those into your template files, and then it renders the configuration that you can then push to your network devices. So it helps a lot with abstraction and saving you time in your configuration management. And the last major part I'll talk about here with Ansible is facts. So ansible facts are something that it automation does where when it connects to a network device, unless you tell it not to, which you can to save some time. But Ansible facts parse through the run config, parse through other operational data from the different devices that you're working with. This is not just for iOS devices, it's across the board and it has standard naming connecting for variables that it stores in memory at runtime. So when you're running the Ansible playbook, you can refer to these variables and make logical decisions off of them, or just print them out and store them to a file for report. So interesting things like the OS version, if you're doing OS upgrades or some type of security audit, these allow you to get access to that information and refer to them specifically as variables that then you can make logical decisions off of while you're running your playbooks. And now let's look at our first demo we have here using the vs code text editor, viewing a YAMl file that is a playbook called Basically Playbook iOS XC configure interface using the cLI config yAML. And we're going to work with the Routers Devices group. And if you remember that routers device group is going to refer to our inventory file. In this case, our inventory file is Inv Yaml. We're using the YAML format and it has just one device, sandbox iosxe recommended one, cisco.com. And it's in a device group of routers. Based on the indentation, that's the way the YAML format tells us the groupings of the devices. So we have one device in a device group called routers with one iOS XE device. And looking back on line three, you can see our hosts is routers. And so that's referring to our inventory file. And our credentials are started in a relevant variables file based on our group of devices named routers. So our first task is going to use the CLi config module to look up a ginger two template, and that ginger two template is going to be called interface template J two, it's going to load in that template, load in the associated variables for the loopbacks we want to render and then push it to our devices. And now let's take a look at those ginger two templates and YAML files. And right here I'm using a productivity tool. It's not part of Ansible itself, but built by one of the people who work at Red Hat with Ansible called the template design for automation or TD four a for short. So I took the contents of the YAML variables file and the Ginger two template file and put them into this web tool. So on the left hand column we can see the yAML variables of the different loopbacks 100 through 104 with the different nested variables of the description, the IPV four address, and the subnet. Basically, when we run ansible, it would load in that variable data associated for the device. We want to configure each of those loopbacks, the descriptions, the addresses, and then feed it into that middle column of the ginger two template. So that would be in a separate file in our ansible directory. And so when we run ansible, it would feed in the loopback, names, the descriptions, IPV four addresses into that for loop and then render out our configuration. So if I click render, we can see what that configuration would look like and we can see it has the interface 100 through 104 with the associated descriptions and IP addresses. The indentation is a little off in this image because I need basically to fit this window in the screen we have here, but the indentation would be correct for what the iOS platform is looking for. And now let's actually run our playbook and see those configuration lines sent to the device. And now we're going to execute the ansible playbook that is going to configure those loopback interfaces. So I'll do an LS command to show you the files we have here. We have our inventory file and then directory for all of our playbooks. If we look at our playbooks, we are going to be using the playbook iOS XC configure interfaces ClI config mod Yaml and now if I just paste in, we have ansible playbook as the command we're using, and we're telling to use that particular YAML file. I'm just going to add an additional b so we can have a little more verbose output. Now it's executing that first play, that first task where it's going to load in those ginger templates, load in the variables, and then send the configuration commands to the device. Now Ansible has said we have successfully sent the following lines of configuration to our one device. We have our interface loopback 100 through 104 with the associated descriptions and IP addresses. You saw that happen just in the blink of an eye. And if we were working with multiple devices, it would have sent the associated commands with the loaded variables for each of those devices as well. If there are any errors, it would have told us, or if the configuration is already present, like if I send this again, it should tell us that these configuration lines are already present and it won't need to send anything. And we can see there, see, changed equals false. So ansible is checked. Oh, we've already configured this so we don't need to send anything actually at all. And that is our first demo configuration, an iOS Xe device with junior two templates for loopbacks 100 through 104. And now let's move on to our second demo. Build reports with Ansible. We're going to be using the ansible facts and let's take a look at the ansible playbook to get started we have here a playbook define play one working on the same routers, just that one iOS device and on the first task it's going to connect to the device and use the iOS fax module to gather the fax store that into a variable. It'll print one of the variables out the Ansible hostname and the OS version to the screen. It will then print the raw output and then make sure an outputs directory exists because in ansible you can work with the Linux file system. So it creates a directory called outputs and then it uses a template called the fax template j two to basically take the variables that we've stored from those facts and then dump them into a template. So we can see the fax template here where it has some text at the top saying this is our Cisco sandbox device output and the curly brackets say we have these different variables of ansible. Net host name, the model, the iOS type version, serial number all printed out, the top fed in from our fax at runtime and then some interfaces and for each of the interfaces it's going to loop over take some of the different dictionary keys, get the values out of them and then put that into our template and render that to a report file. So now that we've seen those facts, let's take a look at the terminal and run our playbook. So we are using ansible playbook, playbooks iOS XC get facts with template and V will give us the verbose output and we should see actually the loopbacks that we created from the previous task. So first it's going to log into the network device, do the show run show version, parse all that output, store it into the variables. It's printing those variables to the screen. We're not going to necessarily look at all the different terminal outputs because you kind of get a feel for what's going on there. And the yellow shows us that it was successful and it made a change and it's created that file that we were talking about for that report. Let's take a look at the report. Pulling open our vs code again, not just looking at the template now, but we can see that we have an outputs directory and within that outputs directory we have a new file and that file is our report and that report has our device name, device type, OS version, and that loop created a different set of information for all of the facts that we had gotten for the interfaces for starting gigabit Ethernet, one going all the way down to gigabit Ethernet 100 through 104. You can see there are some other whipbacks on there from previous iterations of other people's demos. So with just a few lines on a playbook using the built in ansible facts and some Gingertooth templates, we've made a report with a list of all the interfaces and all the basic information. And now let's take a look at the third demo. Pre and post checks with Ansible first let's take a look at the playbook and what we're working with. So with Ansible you can do some complex stuff. I'm not going to go through every nitty gritty detail on what this playbook is going to accomplish, but the high level of what we're doing here is that we're including the same change that we had before of adding those loopbacks 100 through 104, and we're also adding pre and post checks. So the pre checks are going to be show IP and interface brief, show interfaces and show ip routes. So we have three show commands that we're going to send. We're going to create a directory called outputs if it's not already there, and create a subdirectory per device name for pre change, another directory for post change, another directory for the diffs between the two. And so it's going to run through the change, create the directories, do the pre checks, make the change, and then dump the outputs into the files based on the name of the device and then do a diff between the two when it does the post change. So we have a ginger two template that's going to basically format those show command results for us a little bit. So it takes the results, says what was the command that was sent? And then just dumps the output for us. So let's go ahead and pull up our terminal and we can run through. So I've actually run another playbook to clean up our demo device to remove the interfaces because we want to have that change of adding the interfaces be part of that diff as well. So I basically ran another playbook before called the good Citizen script that removes the loopbacks that we were just using. So now we can re add them with our pre and post checks. So ansible playbook playbooks pre post checks yaml with verbosity on high. So we're going to first grab our date timestamp so we have a unique file name. We're going to create a directory per device name. In this case we have the sandbox iOS Xe recommended one. Cisco.com is sending the pre checks of our three different show commands. It's taking the output of those different commands, dumping them into a files into the directory for the pre change directory that's timestamped for when that change occurred. It's going to actually now send those three loopbacks 100 through 104 making that configuration change and now we're sequentially going to the next series of tasks of getting a new date timestamp for our post change verification we're now going to send the same set of commands, put them through that ginger two template and then dump them into a file into the post change directory. It's going to use that same ginger two template of saying hey, here's the command, here's the output for each of the different commands for our device and then it's going to do a Linux diff between the two. So it's going to take the pre change output and the post change output and then do a diff between the two and save that to our file. So now let's take a look at that output. Let's see we have our outputs on the left here and we have a directory that was created based on the device name. So we have a pre change output. So the command that was sent was show IP interface brief here's the outputs saved to our file. We have show interfaces that was sent and the show interfaces output. We scroll down a bit more from all the show interfaces output and then we have our last command that was sent was show IP route and we have our show IP route information that was all in the pre change directory for that device and we have the post change directory for show IP interface brief command output now we have the new interface loopback interfaces. We have show interfaces with the show interface output as well as the third command set show IP route so pretty similar there. And now let's look at the diff. So it takes the pre and post change and then does a Linux diff between the two. So the little arrows on the first line can tell us based on the Linux diff syntax which file was change. And we can see just in these first lines the Linux diff tells us immediately these loopbacks 100 through 104 were added to our device. So we definitely have a change between our pre and post. And in terms of operationally we see our loopback 100 is up. So that was now added because we did our show interfaces and same thing for loopbacks 100 through 104, and we can go down to our last part for the show IP interfaces to see that loopbacks 100 through 104 are also present in our div. So this just gives a huge amount of power to be able to automation have all of our pre and post checks defined. You can change those different show commands, you could have them defined in a variable file on their own. I feel like just the sky is the limit in terms of what you can do and just modifying it for your particular environment. All this code is going to be freely available on GitHub. This is just a demo that we have here at Cisco learning inserts just to show the power of what ansible is available. And Cisco's learning certifications also has a lot of neat resources for you to help your network automation journey that are free and paid resources to help you in your certifications. And we have a new certification recently for the Devnet expert that you might want to check out, but also probably start lower up the food chain for some of our other applications on automation as well. Well, thanks a lot and I hope you really enjoyed this session.