Introduction to Ansible for Network Engineers

okay we're three minutes over i think that's sufficient uh again just a disclaimer everyone these videos are recorded so um just know that if if your company has a policy for your name not showing up on a recording um that's something that you need to be cautious of but we we hope to upload these to youtube just like we did with last month's so that for all of our friends who are out on pto or just stuck in other meetings and don't have the ability to attend they can go back and and watch the videos and obviously for those of you that maybe didn't catch everything the first time around or just wanted a refresher those videos are there for you as well so with that let me just again thanks everybody for for joining uh my name is calvin remsburg i am a sales engineer here at juniper networks and this is a continuation of our monthly automation workshop the goal of these workshops is to focus in on the fundamentals of network automation specific topics and to go pretty deep on those fundamentals uh that's kind of the best way that i feel that i learned network automation was just tuning in on to what were the specific things that i really needed to worry about and then continue to develop the muscle to be able to execute on those things now today's presentation we're going to be focusing on ansible and if if you haven't heard of ansible 4 don't worry we're going to be covering just a little bit of those basics as well but for everyone else that has been within this automation space you've probably seen ansible mentioned one or two times you probably have some tertiary understanding as to what the product is and what it's going to accomplish but even with that we'll still drill down again the basic overview of the product we're going to look at this from a vendor agnostic perspective i don't want to ever come off as like saying you know one bitter is right or the other and we're going to be doing the same showcase here with these tools that we highlight and this month being specifically uh ansible so with that let's go ahead and start the presentation see here we are and oh giving away all my slides ahead of the place okay so an introduction to ansible for network engineers one of the things that i really enjoy about ansible is just how how large the breadth of the project is and how many different areas of the it environment that it can play a role in but one of the the things that i i wish i saw a little bit more of was a more networking engineer perspective because for a lot of us coming from traditional operations on the customer side we we've got a lot of things already going on for us a lot of a lot of different projects a lot of timelines operations etc and to to find finely tuned training for network engineers is sometimes pretty difficult and you'll be spending a lot of your time figuring out okay here's how ansible works but maybe in the context of server administration which ultimately doesn't play to any of our strengths so for this presentation we're going to be focusing on where ansible fits in for the network automation perspective all right uh we've got a big agenda for today again the first part i want to highlight just the basics of ansible where it came from where it's going what was its focus originally has that focus shifted since then and then i'm also going to be talking about the value of automation frameworks which ansible is kind of grouped into that categorization as an automation framework so we want to talk a little bit about what's the value proposition with automation frameworks when would you choose to use one and when you wouldn't and after we have just the basic understanding of the lay of the land then we're going to dive into the essentials of ansible and this is where we're going to be spending most of the time of our conversation today is focusing in on those core concepts of ansible and so there will be quite a bit of content right there excuse me as my mouse is jumping all over the screen i'm i'm trying to admit my friends into the meeting um after we cover the essentials of ansible we'll talk just briefly about ansible tower and ansible awx how they're different how they're the same and what kind of value that those solutions also bring to the table let me see here admit okay uh and after we go through that we're going to wrap up our content training or the the educational aspect of this and we're going to focus in on the strengths and weaknesses of ansible what does it bring to the table what are what are some of the positives of working with an ansible and then some of what what are the weaknesses of it and then we're going to be spending the rest of our time focusing on several different live automation demonstrations uh and so we'll touch upon those in just in a second but what to expect from this session and specifically what to expect with like a presentation from me before i start listening these things off i just want you to have an understanding that my style of presentation is more like the my background is doing live streams of coding on twitch and and networking so i typically deliver the content very quickly but i'm also very accustomed to being interrupted so if you would like to ask a question feel free to to pipe up uh use the chat as you see fit i think there's a raised hand function inside of uh inside of zoom feel free to use that i'll try to get to it if if it's like a a burning question that you just have to have answered feel free to unmute yourself and go ahead and and pipe up i'll be trying to check the chat as i go throughout this uh this process the time that i like to spend i i like to spend about half of our time today which is going to be two hours maybe even more if we get carried away but i like to spend half the time on the actual content just to kind of give everybody on the same page and then focus the rest of the presentation on live demonstrations and we will be sharing the code examples of all the projects and actually a lot more we'll be sharing those code examples at the end of this presentation so if you'd like to go and replicate this environment within your own personal lab or your lab at work everything will be there and ready for you as well all right so with that being said let's dig into the ansible topic here so what is ansible what is the project what were the goals of this uh solution so you should know right off the bat ansible is a open source automation framework we'll talk a little bit about those last two words just in a second but it is maintained by red hat which is now a part of the ibm family and more interestingly to note probably for our conversation today is that the original scope of ansible was on server automation which kind of makes sense when you think about it red hat being a linux company they also needed something to help manage the infrastructure and so when when the project was originally created in 2012 it then was uh enveloped by by ansible i'm sorry by red hat back in i think 2015 was around the time now since that time actually rather quickly after that acquisition actually took place ansible projects started to shift to other areas outside of server administration and one of those was was networking and we'll talk a little bit about this later but you should know that one of the things that really kind of forced red hat to start pivoting into networking is one of the biggest strengths about ansible applies to us network engineers and that is that the product doesn't have any kind of agent that that runs on the device and the transport that it uses to communicate to the remote devices our routers and our switches etc is ssh so right out of the gate every networking device is effectively ansible ready because we already use ssh because we're good engineers and we don't use telnet anymore and there's no additional ports to open up you get the inherent role-based authentication that we would have with the configuration on the devices so there's a lot of really good reasons as to why the networking world was kind of really forcing ansible to shift and focus on on networking now it's still it's still more than just networking but this is a common thread that you'll see in network automation world networking engineers will look to the devops world to look to the server world and they'll find some kind of tool or process that could work in the networking world and we'll port it to work for us and that's kind of the case here with ansible now the goals of the ansible project one has got to be really easy to understand there's there's a lot of python that goes on in the background but can we provide an abstraction on top of that python to make it more more easy to consume if you if you will and so ansible achieves this by leveraging a markdown language called yaml which you have an example on the right side of your screen right now of what that yaml actually looks like so it's it's rather easy to understand it's rather intuitive to to figure out kind of what things are happening within there so simplicity is a really big selling point within ansible another thing it's really really simple to install just takes a single command to actually install ansible on your machine and again it's just extremely easy to kind of get off the ground and running with and one other thing that's just worth noting about ansible and honestly this applies to most automation frameworks as well is that ansible project itself you will ultimately run into a situation where ansible just it's a little bit convoluted or it's not accomplishing exactly the goal that you're looking for you can actually extend ansible if your python skills are up to par and you can actually build additional functionality into the product and and reintroduce it back into the public so others can enjoy that so that extensibility is a really attractive aspect within ansible now i i did mention that ansible is an automation framework so let's talk really quick about what an automation framework's goal is what is a typical automation framework composed of and what are some of the additional automation frameworks that you might see out there today for network engineers well if anything i want you to walk away with one understanding the goal of an automation framework this is this is not an official definition by any means this is just my perception the goal of an automation framework is to make automation easier that's it that's that's the whole aspect and value proposition that we get with a an automation framework so now that we know the the primary goal of an automation framework well what is it actually composed of what does it actually look like well an automation framework will bring certain components into your environment that will make life with automation just a lot easier to work with and so if we just focus right here like on this green box on the screen these are the core components that are typically typically found within an automation framework one they have some type of mechanism that allows you to build inventory either by statically creating files where you literally type in the host name and the ip of the device or through dynamic inventory sources like uh pulling in from your network source of truth like nadobot or through solarwinds or maybe in an ipam the idea is to store as much of your inventory inside of a remote system so that your automation framework can ingest it and then make it easy to actually build automation against that another really key component is plug-in ecosystem again kind of like we mentioned earlier about the extensibility an automation framework will typically allow a developer a seasoned developer to build additional functionality into the product and we'll see a lot of those plugins with ansible actually being developed by networking vendors like juniper uh another great thing answer or sorry an automation framework will take care of they will obviously take care of the actual execution of your um of your task whatever it is you're you're looking to accomplish it will help manage the ssh connection to a remote device help run certain commands grab the output of those commands and present it to you in a way that's consumable so automation is obviously uh bound to the hip of the execution engine but those those come in different flavors based on the actual automation framework that you're using and another really important thing that i think sometimes overlooked is how to handle the results so think of this as i'm gonna do a lot of automation against 20 networking devices and i'm if i was to watch that automation whether it's a playbook an ansible or a python script in nor near or something along those lines there's going to be a lot of output and a lot of results but depending on the type of task that i'm performing an automation framework will many times provide mechanisms to send that data to a remote system like slack or microsoft teams or an email or maybe send the results to a remote web api that your team has built so that you can view them later so the results engine is is really about building this type of auditing and uh and results of your playbook task so that everyone has visibility within there now some of the more common automation frameworks that we see today by far it's ansible almost everywhere starts at least with ansible and sometimes when they find that either either ansible isn't the right fit for one reason or the other there's many many reasons and every customer has their own perception as whether or not it's fit for purpose we'll start to see customers try other automation frameworks out there nor near is an up-and-coming automation framework it's built by the the primary developers uh also created a a python package called napalm and another one kirk buyers created netmeco and there's other really great people that have also contributed heavily to this project but nor near is a pure python automation framework there's no yaml abstraction it's it's meant for python developers to do things very very quickly and another one that you'll see out there is netpalm netpalm is also another up-and-coming network automation framework its whole concept is to effectively act as a rest api broker for all of your network automation now if you attended our session last month you'll know that a rest api is an http based api think of netpom as a web api that lives within your environment that can translate your task into ssh commands running on network devices and getting the feedback back so netpalm is a really great tool that can help you interact or build intuitive web applications and and basing it off of that but we're here to talk about ansible so let's dig into the core components of ansible and some of these are going to look very similar to the slides that we just viewed within ansible we have four major components one of which is kind of nested within the other not to confuse you but we'll talk about that just in a second but we have the inventory concept just like we did with the other automation frameworks we have this concept of playbooks and playbooks are going to be where we actually construct all of our automation tasks within there ansible also provides this construct of a configuration file which enables you to to change the default behavior of ansible i'll show you some examples here just in a second but just know that when ansible ships out it ships out with hundreds of default settings and a lot of those default settings are again more tailored to the server infrastructure world so for the networking side we'll probably need to make a little bit of adjustments and and we do that by editing this configuration file the last thing i just want to talk about really quickly is the ansible modules this is that that plug-in ecosystem these are the actual python scripts that are running in the background so whenever we take a look at the ansible playbooks we'll see the modules being referenced within those playbooks and just know that whenever you see the name of that module it's literally asking for a python script by that name to be executed and that might not make a whole lot of sense just yet because you haven't actually seen an example but let's get into each one of these components just a little bit deeper so within the ansible inventory and now again this construct can be statically typed out like i have here on the screen or it can be resourced from a remote endpoint something like a network source of truth like nadobot netbox uh infoblox any of those types of things as long as there's an api on there you can build a dynamic inventory source from for the most part not all apis are created equally now within ansible i'm going to be showcasing a lot of examples just with static files because that's honestly where most people start their network automation journey with ansible they don't want to start building python scripts to do dynamic inventory it's a little bit more of an advanced topic so for today we're just going to focusing in on ansible inventory files now the inventory files is kind of interesting with ansible because it can be structured in two different formats in the example that i'm showing here i'm using a format called yaml which everything else in ansible is typically based on uh this yaml uh structure and for me it makes a little bit more sense when i start to build out logical groupings i can see that i've got the the host actually um uh listed here uh and they it's obvious what group that they're nested within so austin spine one is nested within the spine group austin le4 is nested within the leaf group etc but there's also another file format that you might see used in place of of yaml and that is an ini format now i don't have an example for you actually that's it's not entirely true i have an example of an ini file we'll showcase that in just a second but just know that when you're working with ansible you might see it structured in one or two ways when working with static inventories and again as we can see here on this example we are enabled to create not just the the host devices and assigned like ips and such to them but again we can nest those hosts into groups which then enables us to just reference a an entire group to do automation on in comparison to just a single host now the ansible playbook itself this is where all the money is made right this is all the automation is executed within here don't do automation within the inventory file the automation does not come from the config file it's right here within the playbook so let's decrypt some of the things that we're seeing on the screen so it can maybe make a little bit more sense to those that have never seen this before at the very top of your playbook first of all we recognize that the file format is in a yaml structure now if you've never seen yaml before know that yaml is kind of like an abstraction on top of json and if you don't know what json is well that probably doesn't help either but know that the two are kind of bound to the hip you and yaml is is really there to help us understand and interpret data in a structure that's fairly easy to consume as opposed to json which arguably is pretty easy to consume but maybe a little intimidating if you haven't really been in this automation space before so yaml is a little bit more friendly and this again is the primary data format that ansible uses at the top of our playbook what we see on lines one through six here we're defining how we want our play executed we're not specifying the actual things we're going to do but we're kind of setting the ground rules so that ansible knows what devices we want to to automate and and if there's any additional things that we need to import now in my example here on line one i see that i am importing or i'm going to be using this automation against a single device with the device's name is dallas firewall one the the next three next three lines are a little bit confusing uh just bear with me just for a second when i talked earlier about how ansible is originally focused in on network i'm sorry on server automation there are a few things that we need to change with an ansible to make it work a little bit better with networking devices and this is where lines two through four come in now line two is a really interesting one because it fundamentally changes how ansible works if you remember earlier i said one of the key selling points of ansible is that it's based on ssh which is enabled on all of our devices and servers now the the thing i didn't mention about that is ansible's default default behavior is it will take all of the tasks within the play and it will create a a dedicated python script for each one of your servers and it will secure copy that python script over to the remote server where it will actually execute the task get the output and then send it back over to the ansible controller now in a distributed systems world that makes a lot of sense that lets ansible operate at a uh at a lower resource reservation right because it's not doing all the work it's actually punting the heavy lifting to the remote devices to do through this python script now in the networking world we know that even if your networking device supports python you just can't put copy of python files over there and execute them willy nilly uh we the networking vendors have effectively put up walled gardens around or sandboxes how are we going to call them sandboxes around the the python runtime and we limit the types of packages so effectively that mechanism of antipole creating a python file and pushing it to the remote device it doesn't really work well for us in the networking world so on line two i specify connection local to tell ansible hey ansible don't try to take this task and wrap it into a python file and send it to my router because that router's not going to know what to do with it instead go ahead and issue these tasks locally so that's kind of where that connection local comes from now gather fax is also a a more um a server thing and it almost i mean it makes a lot of sense for us on the networking side but there's a couple things that are just a little bit different and what i mean by that is that gather facts is basically ansible's way of doing like a show version on a server right and it gets a ton of information about that server all of its interfaces all of its ip addresses all the packages installed etc sounds great for a server administrator and you would definitely want to keep gather fax to true if you are doing server automation but again for networking that type of functionality isn't really there there's there's some things being done in the background inside of ansible project to to provide like a gather fax functionality which on our devices would be like a show version or show chassis inventory or whatever it might be uh but for right now gather facts is is set to uh to false and so that we don't try to get ansible to perform that functionality and the last one i'll just talk about is line number four become equals false the it's a when we get to the weaknesses i'll talk about one of my annoyances with with uh the ansible project but essentially what become equals false means to the server world is request super user uh access to the device in the networking world there that construct isn't there not really in the same way that it is on the server world now good news is that lines two through four they're kind of confusing especially to to people's just getting started with ansible these are really good options to include inside of an ansible config file so that you never have to worry about them again so you can take some of this functionality that we're overwriting here in our playbook and you can punt that to a configuration file so that you never have to worry about setting these settings inside of your playbook lines five through six what we're seeing here is we're actually importing third-party modules into our playbook in this case i'm importing the official supported ansible modules for juniper and that is found at an ansible galaxy at the path of juniper.junos now we'll talk a little bit about this later when we talk about strengths and weaknesses but just know that right now ansible is is kind of in a is in an inflection point within the project it's making a big transition and so you'll start to see uh more of you'll start to see things like collections referenced more and more uh throughout there instead of roles but know that just collections is kind of like an abstraction on top of roles roles will ultimately fit inside a collection so you may or may not see roles referenced like this in the future it might just be referencing collections now lines 7 through 20 this is where we're actually doing the automation task this is the the nitty gritty execution that's taking place now what we see here is i've got a actually before i start explaining let's shift to the next slide because that's going to be addressing exactly this next topic here and that is the ansible module now you can think of a module like a plugin it's it's literally a python script and the back end so anytime you type out the name of a module which in my case the name of that module is juniper underscore junos underscore rpc that is there is literally a python script in the background with that name on it which has a bunch of python code that tells the script how to function now everything else that's nested within like we can see like this level of indentation anything that's nested within this uh this module is actually just an argument that we're sending to the python script so this is ansible's way if we had to kind of step back and subtract ourselves from the the deep level just know we're calling a python script called juniper underscore junos underscore rpc we we imported that python script by calling in these roles that we mentioned up here on lines five through six and we're passing into that script a series of information one of them is where is my host uh at what is the username for this device what is their password obviously you would want to secure these in a little bit better fashion than i'm showcasing here but uh and we're passing in one other argument and i'm saying the rpc remote procedure call if you remember last month's session on the netcomp api uh we're passing in an rpc saying get route information this is basically saying show route on your device um so again the module itself the the ansible module is literally the python script in the background this is you interfacing with python but by using a different file structure the the ansible yaml markdown language uh in order to actually execute that python script now ansible ships it used to ship with thousands of modules i don't think that's an exaggeration um it got kind of crazy there for a while and and some of us in the networking world are at fault for that so uh let me subtract this just for a second and talk about where ansible is and why the the module construct is is slightly changing it used to be up until pyth our ansible version 2.9 which was very recent release the the network vendor modules would ship out with ansible themselves so ansible would maintain the vendor modules like cisco fortinet they even ansible would produce modules for juniper devices as well and over time network vendors would continue to kind of flood ansible with new modules one vendor i'm not going to mention by name has over 400 different modules to select from it's 400 different python scripts that needed to be validated and maintained by red hat and ultimately red hat decided to subtract all the vendor modules from the core project this is that kind of inflection point that we're talking about so going forward you're going to be importing your vendor modules either through the construct of roles like we're showcasing here or the higher level abstraction layer which we call collections um so just know that if you're if you're familiar with how ansible was up until like a year ago um know that that's going to slightly change because ansible is going to require the customer to download and install the collections rather than them maintaining it and honestly i can't really argue with that logic i wouldn't want to maintain thousands of scripts from different vendors it's that that just doesn't scale okay uh the the last thing i'll just talk about on this playbook is we're we're storing the output of our task in a new variable that i am calling route table now ansible has chosen to reference that task basically creating a new object or create a new variable they refer to that as register so whenever you see register used within a playbook know that that means that the output of the task is going to be stored in a new object called whatever variable is is called in this case it's route table and then we can use that object in a later task to print it out to the screen so that everyone has visibility and understanding as to what's actually being executed uh the last aspect of ansible that's worth just double clicking in on is the configuration file again this is an ini structure so in contrast to everything else that we've seen today which was yaml based the ansible configuration file is still in an ini format and it's quite easy to understand what's going on we have a a set group of defaults and then in order to override some of those defaults we will type in whatever value or whatever variable we're trying to change and then right in our overriding aspect into it and so to help kind of understand a little bit of that i'm showcasing here in this example a couple of things that i always do inside of my ansible config file and so we'll just talk about them a little bit because that will help you understand or at least i hope it will help you understand a little bit of how ansible thinks and how it operates so lines two through three that i've got listed here these are to to really deal with ssh to be honest with you uh we all know if if you're on a machine and you want to ssh tour another device either through putty or secure crt if your host machine your computer your laptop your workstation if it's never seen the public key of the remote device before it'll ask you to accept it and if that public key was to change the your local machine will complain and say wait a minute you used to be sh sshing to this device that had this public and private key pair but that is no longer the case there's a new key pair on there and we don't trust it so those are some of the the default behaviors of just ssh itself lines two through three allows us to tell ansible hey i want you to kind of change relax some of those rules so line two says first of all never check to see whether the remote device's public key is the same one that i saw last time just never do it obviously for that you'd want to make sure that that's blessed and ordained within your company security posture that you're okay with that type of overwrite me in my lab yeah sure why not i i change ips and host names all the time so that's just kosher now line three is host key auto add equals to true that is kind of exactly what it sounds like when you talk to a remote device for the first time and you see its public key you will your machine will automatically add it to your list of known host which will be in your ssh configuration path at a file called known host it'll automatically do that so that you're never prompted again do you do you know this remote device uh line four is a really really interesting thing for two reasons one it's another example of ansible using words that i disagree with uh and two it it definitely highlights some of the performance tweaking mechanisms that you can do with ansible and if that second description didn't give away what this functionality is let's kind of explain it just in a little bit more detail forks is what allows or is what instructs ansible how many parallel job tasks that can be executed at the same time now if i had set the fork value to one and by the way the default i believe is 15 but if i had set the fork limit to one let's go back to that example where i had 20 devices that i wanted to automate it would log into the first device in the inventory it would execute the task get the feedback report the feedback tech to ansible log out of that device and then go to the next device and list it's a very it's a serial fashion right it's not performing the same task in parallel um and that's what forks allows you to do it allows you to take a single task and say i want to execute this task at 15 times or at least 15 or at the most 15 times so that if you were doing uh 20 devices of inventory it'll first log into the first 15 within uh the in the play or the inventory file performance task and then as devices uh are completed new connections will be built to another one so that's kind of the construct of forks um another really interesting one just to note is line number nine where i statically tell ansible where i would like my uh configuration or i'm sorry where i would like my inventory file to be located if there are there is a default path uh for an ansible inventory file but what's most common is that we'll see every project will have its own dedicated inventory file or hopefully you can get to a point where you're actually using dynamic inventory so i saw that we had a question and this is actually a really good stopping point so let's go ahead and see that we have it uh mark asked are the lines we're looking at a part of ansible or a part of the juniper.js module let me make sure my timestamp is right yeah so this is the current slide that we're looking at what we're actually looking at is uh nut is not the juniper junos what we're looking at here is an ansible configuration file now you may never see this if you're using ansible tower uh where configuration files can be set within there as well we'll talk a little bit about ansible tower in a second but we're actually looking at is if we're running ansible on our local machine or or remote server there needs to be this construct of a configuration file to enable you to to to manipulate some of the default behaviors of ansible and that's what we're looking at right here now the configuration file can again be stored in a default path like etsy ansible ansible config but most commonly at least from what i've seen within the field is every project will have its own dedicated ansible config file that we'll we'll use to address that specific project so good question mark i hope that makes sense uh so config files are built from the built-in ansible function if i understand it correctly yeah the the config file first of all it there doesn't have to be a config file in your project it could just default to the the default path for the ansible config file but if you would like to have per project mechanisms of overriding some of the default behavior then that's where you would start to look to build your ansible config file and honestly the you will not be building and editing configuration files uh frequently what i've tend to have done is over the years i take whenever i start a new project i copy the ansible config file from my last project and i just kind of over the years i'll tweak values here and there but i i pretty much have a golden template that i'll use for all of my ansible config files so it's not something that you you'll do quite often now i saw that we also had another question uh someone in the chat had raised their hand and i and i don't think i can see who that was so jason jason yeah go ahead i just want to know how many how much of this is um is predefined what we're looking at and you know how off you know how much when we go in and we want to play with these scripts or ini files can we use the defaults or do we really have to walk through step by step you don't have to use the the defaults uh i'm sorry you don't have to to make changes to the defaults um now in my case these are some of the things that i see that are really common uh the ssh key management uh and specifying the the where the inventory file is uh but even you can still use ansible and never think about the configuration file until you need to think about the ansible config file so you can get off the ground and running but when you start to stub your toe based on some of the defaults that ansible has and and you'll know and i'll show you an example of what like a failed situation is where you need to actually get into a config file to make an adjustment we have that within one of the examples so um again the majority of your time will not be spent in the config file it will be spent and the playbooks actually building the automation you'll you'll probably come to a point where you have like one ansible config file that you use for all of your projects so that you never really have to think about it until you really need to think about it does that help jason that's great thanks good good questions good questions keep them coming everybody all right now that we know about ansible we know the core concepts right we know that there's there's four fundamental things that we'll need to consider uh with one is the the inventory then there's the actual ansible playbook there's the modules that we need to call within the playbook and then if we run into an issue with some of the defaults of ansible we need to know how to override them let's now talk about ansible tower or ansible awx and you should know that i'm going to be using these uh these words interchangeably i'm sorry it's it's they're technically the same but they're technically unique so with that little bit of confusion let's talk about what ansible tower and awx bring to the table and why there might be a little bit of confusion with them so we know with ansible we know we get these core concepts right we get the the inventory playbook modules config files everything that we just listed out now there's other aspects that customers have typically wanted to do with an ansible one of those is to leverage a web user interface a gui um we don't they're the customers uh don't always work on a linux machine which by the way is a is a default requirement of ansible is to be on some kind of unix or linux based machine because of the way that the project is structured so if you're not and you still need to do ansible execution well having a web user interface is pretty attractive it also helps put oven mitts on the hands of network engineers makes them click rather than type things out and in ansible tower there's a little rocket ship that's just a really it's a lot of fun to click that rather than actually typing out ansible playbook etc so the web user interface is definitely a very big value proposition of ansible awx one of the other things that it brings to the table is a rest api so once you start getting further down in your automation story you'll ultimately even want to subtract the web user interface and you might want to say i want to execute ansible from a remote system or i want this playbook to execute whenever servicenow sends a command to it and so the rest api is is really the unsung mbp of ansible and it's one of the things that helps separate it from uh competing technologies like nornir as of today where there is no rest api interface again if you if you're unfamiliar with rest api we talked about it extensively in last month's session feel free to go back on the youtube now on another thing that you get within the web user interface and this is really important when you start thinking about it in the context of working inside of a team environment ansible tower will give you user permissions give you that aaa that we all love right the role-based authentication and and you can tie into external sources like active directory or some other kind of ldap system or some other kind of authentication system so to have the ability to automatically permit users and assign permissions based on you know maybe an active directory grouping or something is very very advantageous so that you're you're not playing the game of managing user accounts inside of ansible that's never fun uh the other point though is is killer and that is the the concept of having an audit log so that everyone on your team can go back they can view the the history of a playbook whether it was successful whether it failed what were the variables that were passed into that playbook what was the result coming back from the remote device and again who issued what commands on what devices at what time that kind of historical construct doesn't exist natively within ansible the the ansible core project because you'd be issuing it on your own computer from your own home directory and no one would ever know any of the wiser so to have that kind of audit log is extremely beneficial so i i've confused the words quite a bit of ansible awx and ansible tower let's talk about just the separation and and why there's still kind of the same thing if you've if you've played in the linux world for a while you'll know that red hat has this mechanism of of software delivery and that is they they have a a a distribution red hat enterprise linux that is the supported linux distribution that you pay red hat for that support there's licenses there's subscriptions there's all these great things and then when ansible or when red hat wants to produce new features or enhance their operating system they do that in what's called an upstream release which is now fedora exclusively uh so and honestly fedora was always the one i'm not gonna get into centos conversation here but all of the all the work for red hat enterprise linux is actually done in a different operating system called fedora and then all the bugs are worked out and then once the the packages are are rock solid and ready to be put into the supported version then they'll move those packages and constructs over into red hat enterprise linux the same is true for ansible tower ansible tower is the spade supported version of everything that we just talked about the gui the rest api users and audit lock etc however there is an upstream release where all the development for tower goes into and that's called ansible awx ansible awx is completely open source and allows the community as well as obviously the developers themselves to actually contribute into the product that will ultimately become ansible tower so just a quick note ansible tower is the licensed product that's the that's the way that red hat makes money and they definitely deserve to make money for this product because it is outstanding however with that being said what i have seen more often times than not is that customers will start network customers and not focus on on the other parts of it but networking customers will start with ansible tower because we're used to having the requirement to get support uh from a vendor etc etc for one reason or the other either it's because the delegation of responsibilities of managing ansible is is sometimes complicates i.t teams and how they're grouped sometimes the problem is licensing because the licensing scheme for tower has not always been friendly for networking devices for one reason or the other most companies when they start with ansible tower within a year or two they decide that they want to go the awx route and it enables them to have a little bit uh more let's see if we got one person coming in uh but it allows them to deploy more instances of awx there's no licensing concerns etc but you're on you're on your own as far as support goes with awx so you're well you're not entirely on your own ansible has an amazing community but just know that you're going to deal with some of the development bugs that they're working through as the product moves into ansible tower now in my use case i'm using awx because i'm on a personal budget but i also i prefer the way that ansible awx is is built and maintained through docker containers i think it's really slick so uh but just know you may see tower you may see awx you may see them called the same thing and they kind of are but they're also kind of unique so just understand the differentiation between there okay let's see here the strengths and weaknesses of ansible uh this should be a fun one uh again one of the core constructs of ansible is that there is no agent that requires to be installed on the remote device and for networking devices that is an absolute blessing previously we saw products like puppet trying to get into the network automation space and they required an agent to be installed on the remote device that's always difficult not only to actually get it blessed by your organization to run these agents on networking devices but they can typically be difficult to maintain there's a life cycle management you have to worry about so to not have a requirement for an agent to run on a device enables ansible to effectively automate really any device as long as it's ssh reachable and that's another one of the the core constructs again of ansible and is definitely a strength for us in the networking space is that its primary focus is on ssh transport now that is not to say or give the impression that you cannot do things with a rest api you can absolutely do that you can pull in powershell you can do all kinds of great things with ansible it doesn't have to be ssh but that is the default connection mechanism that ansible will use and so for us in the networking space it's already enabled on our box we already got user permissions assigned based on aaa rules and policies so that's an absolute blessing for us now the second one is interesting modules are typically item potent now before you start googling what the heck does that weird word mean let's talk about it just quickly and why i say typically item potency is this concept that says we're going to be making a network automation change if that change is already present on the box then don't push the change to the box just move on um so think about this like if i've got a firewall and that firewall's name is ansible firewall one and then i've got an ansible task that says hey log into that firewall and change its hostname to ansible firewall 1. ansible when it logs in there it will do a quick check based on the way that the module is is constructed it'll check to say is the hostname already ansible firewall 1 and if it is back out just don't do anything now in the networking world this is extremely valuable because there are some network operating systems out there that aren't driven through an api they're literal screen scraping where they're sending ssh commands and those devices that aren't built through an api they have the unfortunate reality that if you log into that box and you paste in a configuration even if that configuration is already on the boss box there's a good likelihood that you'll have a like some kind of control plane um adjacency flap or something along those lines if if you've ever logged into like config t i'm not going to say any vendors by name but like if you did config t and paste it in router bgp blah blah blah even if you paste it in the exact configuration that was already on the box there are times that i have seen that will actually cause an adjacency flap on the networking devices so it was a futile attempt to begin with right we're we're trying to make configuration changes they're already present on the device and oh by the way we just flapped our bgp adjacencies obviously a terrible situation so the fact that item potency is one of the first things that a developer will try to build in the module that's going to give us a nice warm comfortable blanket knowing hey we can execute this task over and over and over again and it won't cause uh it won't provide any kind of risk or present any kind of risk for us on the control plane now typically is a good rule of thumb it comes down to the developer of that python module that we we actually call as the module inside of ansible um a good developer will make sure that they perform the types of checks there's there's ways to achieve that i i cannot guarantee you if you go out to the third party ecosystem of ansible called ansible galaxy i cannot guarantee that it's going to be everything is going to be item potent so just be wary of that another really great thing we talked already about the extensibility but i want to highlight that one of the strengths of ansible is that it's based or or the user's interface with the yaml markdown language and it's relatively easy for new developers or network engineers coming into a developer focused role it's easy for them to kind of get off the ground and and running with it and we showed some examples before now with that in mind let's talk about one of the weaknesses and that is the reliance on yaml uh so it's a strength and it's a weakness and what i mean by that is that yaml itself is not a programming language the don't listen to the memes yaml is not a programming language it is a markdown language and so when you need to perform complex operations inside of an ansible playbook things like if you're in the python world you like if loops and for loops etc you'll start to run up against the limitations of yaml really quickly and so you'll have to either conform to doing things the ansible way inside of the ammo or you'll ultimately in many cases after you've worked with the product over a couple of years you'll start writing your own plugins to actually break out of yaml into python and then dump the task back into the playbook i don't have any examples on that and filter plugins are kind of an advanced topic so i'm not going to get into them for here just know that yaml is a strength and it's got its own little bumpy warts on top of it uh we we showcased several examples of where i personally have a problem with some of the vernacular and the vocabulary that's used by ansible it's really confusing just as another glaring example when we look a little bit later at ansible tower the execution of a playbook is not called a playbook it's called a template and if you didn't know what you were looking for you'd be looking all over the place like where are my playbooks where's my playbooks well they use the word template so it's it's kind of all over the place and i and i understand what they're actually trying to achieve by calling it a template but the vocabulary can be a little bit confusing for us network engineers if i said i want you to edit this ansible config file and i want you to enable it to do 50 concurrent tasks against my inventory you probably wouldn't have thought that the word for that was forks probably not there's there's probably a better word i haven't come up with one but forks is is kind of a stretch and so the vocabulary is a little confusing for those of us network engineers trying to get started uh a real big one though a real uh a weakness within ansible is that debugging errors can be pretty challenging especially for us network engineers this can be a difficult construct for us to get into sometimes inside of your ansible playbook when there is a problem you'll be presented with a wall of red text and you'll have to figure out where in that red text is the actual issue and here's the kicker sometimes the actual problem isn't in that wall of red text so it can be a little frustrating and and it's definitely a learning experience for you as you go through ansible and you start to figure out how the system works and how it reports errors you can get better at dealing with errors when they come from the remote device but it can be pretty daunting right off the gate and honestly pretty scary like if you if you're doing a network change against let's say 10 devices and when your play executes you get a wall of red text you're going to worry that you broke something you're going to have that like sweaty palms kind of moment like oh what did i do uh so it's i i highly recommend to to try to get familiar fortunately when you're starting out with ansible you're going to make a lot of mistakes and so you'll get quite familiar with how some of the the errors are structured but just a really quick note that it can be a little difficult uh and the last point we touched upon this earlier ansible is kind of at this inflection point um it's we we were on ansible uh 2.6 like back in 2016 and we were on 2.9 as like a year ago now we're on 3.3 like we went to 2.10 3.0 3.13 in just like a matter of like a couple of months so i i don't necessarily think that this is a weakness and that although i have it listed here uh just know that right now as we speak in april of 2021 ansible is kind of in the big transformation phase so depending on where you're looking in the documentation things might not be as you expect them to be uh but that's not to say that the project is any buggy or anything along those lines it's just red hat is is changing their their package cadence delivery of of how they they introduce the product and so this is that time where things are starting to get ramped up let's talk about uh first of all there's a question in the chat uh sorry if this has been asked before joined in late can we execute ansible playbooks without netconf enabled on the junos device you absolutely can and i would absolutely cry if you did that please please don't um and i mean you you absolutely can um it just i i i'd have to figure out what's the best way of doing it um on on junos devices everything that we do from an automation perspective also from a cli perspective is driven through this construct of an api and as we talked about last week junos uses the netcomp api for 100 coverage of configuration changes and operation data control plane data all that good information like interface counters etc we go through the netconf api uh now on ansible if you did not want to use the api first of all you wouldn't be able to use the official juniper ansible modules because they are relying on you know that construct that api construct to be there they're actually based on pi easy which is our our net conf api abstraction in python now you you might be able to use some of the uh the default like the uh i would just call it the lowest common denominator packages that ansible produces um so so know that ansible is is trying to make some changes into the core project to be kind of homogenize the network automation landscape uh and the only way that they can do that like use the same plug-in to automate cisco palo alto juniper arista you know cumulus all of the networking platforms they're trying to boil everything down into a lowest common denominator and they call that the network cli now on that network cli since we're talking about having to boil down the entire industry to the lowest common denominator which is ssh no api is involved they use a python package called parameco that will do the ssh and the screen scraping on the remote devices so i would recommend that if you're interested in bypassing the api and if your team is okay with just doing raw ssh commands and having to write regular expression parsers to understand the data etc if you're okay with that check out the network cli with it is one of the core projects or the core plug-ins that ansible actually builds and maintains uh and that would probably accomplish the goal now just note if the problem with the api is that it operates on tcp 830 by default you can override that api to also work on port 22. so if if it's like a firewall issue like you don't want to allow port 830 on the inbound on your firewall rules but you already have uh 22 you can override the default ports of the netcomp api uh to to to still execute it you don't you don't have to use 830 you can still use 22 but please if you have the opportunity please use the api this is just this is me talking to my previous life please just use the api it's there it's wonderful it's extremely mature uh and it'll make your life an absolute blessing but if you have to boil it down there there are options available in there as well uh let's talk about the right environment for ansible because this is a an interesting concept when does it make sense to consider ansible uh when does it not make sense and so right out of the gate let me just say if you're working inside of a team construct and most of you are on this call if you're working within a team ansible or really any automation framework is going to be extremely value for your uh valuable for your organization let's give an example of what it would be like without an automation framework or ansible uh to help kind of uh lay that point down so if we were just doing everything with python and i work on a team of five individuals uh we're managing 10 000 networking devices through automation if i was doing this with just python i would have my own set of scripts those scripts have their own i have my own naming structure for my functions i have my own naming structure for my classes all the all the things that we build like functionality into python i would have my own naming schema my teammate would have their own naming schema another teammate would have their own and everyone's got different coding styles everybody thinks that there's a unique way to do this and and they'll accomplish that goal through those scripts now if i was to leave someone would need to turn over and manage my scripts and it would be pretty complicated like they would have depending on the script i'm not the best coder they would have to kind of figure out what is this person doing what did they call how did they call that what were they hoping to achieve etc it can be really really difficult as teams start to build up their automation if everybody's doing things in their own individual way and that's what ansible really helps kind of bring together and as well with other automation frameworks as well is that everyone speaks a common vocabulary call things modules we call it um inventory we call them plugin whatever it is filter plugins everyone speaks the same vernacular and so it's easy for other teammates to help support whatever playbooks that you're developing or if you're running into a problem you could bring in another teammate to say hey what am i doing wrong help me out on this and they could easily identify exactly what you're doing and show you a way to actually achieve your goal so working within a team construct is extremely powerful value a proposition of ansible if you're by yourself or if you're like on a team of two people and you are seasoned python developers or golang developers hey maybe maybe ansible's not going to provide you all the value that you know that we just mentioned but uh typically teams are a little bit bigger than two individuals another reason to consider ansible is if your team just doesn't have any interest in learning python absolutely not as soon as they hear network automation their brain starts to check out and i completely get it and i've worked with a lot of teammates over the years and and some of them have had that that mindset they just don't want to have anything to do with automation and so ansible is a really great uh product to select again because it's it's relatively easy to insert in the environment you're not forcing people to learn python or ruby or golang or whatever kind of programming language people can generally be handed an ansible playbook and figure out what is what's actually doing what and that again speaks to the simplicity within the ammo another part just thinking of this um on the customer side there's there's times where um my my lovely cio or my my lovely vp will come to say hey we need some kind of network automation i went to this conference and everyone's doing automation what are we doing we need an example we need something show me that you're doing network automation ansible is a really great tool for those kind of awkward situations where you just want to say hey look we're doing automation uh and and this is what it looks like and we're supporting it so a quick win is always a good thing as well uh ansible is also great if your company has a mandate to get support from a vendor you're not going to get that type of support from alternative solutions or maybe you can with salt stack now that vmware has acquired them but generally speaking ansible has really great support not only from the paid support that we're talking about in this context but also the community support is phenomenal for ansible that should probably have been on the strengths one of the biggest strengths is the community with an ansible if you've if you're running into a problem there's going to be a dozen people that have already hit that problem on stack overflow or google find it and then execute uh and the last thing yes if you need a web user interface again if you're trying to simplify uh the execution of ansport or introducing individuals into ansible a web gui is usually a really good tool to be able to be that kind of gateway all right so that's it as far as content goes everything else today is going to be live demonstrations and q a i'm going to take just 10 seconds to get a breath and drink something uh this is a really good time if anyone wants to pipe up and ask any questions either raise your hand unmute yourself fire away if if you need if you need help with marinating some of the facts that you just learned or just pulled in and you need additional explanations let's just take a minute to honor that i've either got a shy group of 51 individuals or the content was just so rock solid that there's no questions and i know which one my ego wants to tell me it is but prove me wrong okay uh oh here we go we got a question got a question uh since junos modules are written in pi easy can't we can't it be run in the traditional way of secure copy and run on the box that's a good question uh so yes the first of all uh for your first part of the the question junos modules uh the plug-ins inside of ansible they are built entirely around the pi easy um uh package that we provide for python um so can it be ran can ansibly be ran in the traditional way of secure copy to the remote device and run on the box and the answer is no no um it's still not uh they're they're uh running things running python scripts on box on junos uh and and the same is true with the other vendors as well like the guest shell on cisco devices um the there is capability of running python scripts in this kind of construct of a sandbox but unfortunately there are a lot of things that we the networking vendors have to do to help secure and lock down that that run time environment on the device and so we'll we'll put up these walls that will prevent things like you were talking about it's a great question and i would love for it to be uh answered in a different way i i really wish that you we could take advantage of that that ansible execution of secure copy the python script and run around the box but unfortunately uh it's that functionality just isn't there so sorry uh file an enhancement request with your account team please i might have please that would be amazing um all right so jim asks a question he says uh where would run ansible tower or awx for where would ansible tower or awx live or run that's a good one um what i've seen is uh most of the time ansible tower is going to live somewhere on prem just because of the requirement for it to access internal networking devices now that's not to say that you couldn't run ansible tower in the public cloud as long as you had like uh your your your vpcs set up in a way to where you have a private connection from your public cloud into your your own local environment and and the the public cloud has been blessed to interact with your networking devices you could probably secure that with you know some kind of vrf construct or something along those lines um so that that's definitely a doable typically it's an on-prem um execution engine now now in contrast if i was like in a devops world and i just lived in the public cloud and that's all i focused on that's where i would host ansible tower uh either as a container as a dedicated virtual machine um is it within that that vpc or within that cloud construct so if you're interacting with cloud apis and everything that you're touching is available on the public internet or accessible on the public internet maybe that makes sense as well ansible tower and awx they have different um at least last time i checked the the actual um package installation is different ansible tower uh used to be like a like a package like a a deb package for ubuntu or a yum package or um rpm package on red hat um and but uh in contrast ansible ansible awx is always ran as containers it's one of the things i really like about the project is that it's it's really really easy to kind of get off the ground and running with standing up awx just because it's built around this construct of containers now previously or actually actually i think it's still the case uh they were awx was using uh docker compose as like the the orchestrator of the docker containers and by the way if this conversation doesn't make any sense or you're if i'm losing you feel free to tune out go go get a cup of tea for a second but uh ansible awx is is uh delivered through the construct of of docker containers and they they were using docker compose as kind of like the default docker itself the company the product is in kind of turmoil right now i'm not going to get into the drama behind all this uh docker going away type of thing but now kind of the default deployment for ansible is either on kubernetes or openshift which i i mean i love those those constructs but holy moly it's difficult to maintain and manage those systems so hopefully we'll see like pod man or some other kind of docker compose replacement uh be delivered within antifa awx so again it's easy for us to stand up uh another question we got uh what would you pick in the long term python first ansible for a large enterprise network just based on the large enterprise networks i've worked at in the past i would definitely pick ansible just because the the teammates that i had everyone was unique and their their desire to adopt automation and everyone was unique in their background with automation and so not to boil everything down to lowest common denominator but if you're working in a team construct i i highly highly highly recommend um using an automation framework i'll i'll put my flag on the ground and say an automation framework for many of the reasons that we talked about inventory speed of execution simplicity etc an automation framework must be picked for a large enterprise team however it doesn't have to be ansible if your team is seasoned python developers give nor near a shot give it a shot it is a phenomenal project it's super fast it's very lightweight and the people that are developing that project are the brightest in this community so give nor near a fair shot if ansible isn't your uh preferred flavor but for everybody else i would i would highly lean on ansible as kind of being the default it's worth at least exploring ansible to figure out whether or not the workflow makes sense if if if your team is picking it up etc then that then yeah absolutely i mean give ansible a shot but once you start to if you start to figure out that you know for one reason or the other you're annoyed with the way it's executed or everyone's got personal preferences right then at least give nor near a shot or something else um alec alex says 128 t oh hi elk alec 120 t would make it easy for ansible to live in the public cloud with managed elements across the enterprise absolutely a really good point absolutely okay muhammad asks can you share your twitch channel um yeah i can uh the twitch channel is kind of in turmoil right now i got banned artificial intelligence is is wonderful uh my my content was deemed as as spam or something along those lines my channel got banned i moved over to youtube to do youtube live streams that's where i am right now i'll share that information i'm looking to get back onto twitch as soon as i get unbanned of all the content that gets on there i uh my network automation was deemed not safe for work or something i don't really know uh but yeah uh i'll share my information um i am a sales guy by default so i like to sell myself um so we'll definitely do that all right getting to the uh and by the way great questions keep them coming um you have the humor to admit that yeah uh well yeah you gotta stay sane uh humor is my mechanism for that uh okay so we got five unique um uh automation examples today um one of them is we're going to basically transport a cli configuration that we would have done manually uh we're gonna translate that into an ansible playbook i want you to understand just how easy it is to to take current change control tasks that we're doing and wrap them into automation so that's going to be our first task the second one is we're going to be retrieving lldp neighbor information from our devices and we're going to write that to a file uh and as always with uh with working with an api that data is going to come back in structured data format xml or json or something along those lines which is an absolute blessing uh rather than getting like a clear wall of plain text and having to write parsers so we'll take a look at that one as well uh third one is really interesting because it's not really a networking thing but it kind of is we're gonna deploy a brand new firewall a virtual firewall to protect an application within our data center on vmware and we're not only going to deploy the firewall itself the virtual firewall we're also after ansible deploys it it's going to log in and make configuration changes so that the device is online and operational uh then we'll transition back into uh into the more networking centric stuff we'll talk about the jsnappy product that juniper delivers and that helps us provide the ability to do assertions in the environment saying log into the device and assert that there are no errors on the chassis that there's no problems with the fans no problems with no problems with my ospf neighbors that my transmit and receive light levels on my sfps are operating in within the current spectrum that i've got you know this amount of routes from this neighbor jsnappy is a really great tool to build those network assertions and one other thing that it can do actually arguably the primary driver behind jsnappy is to do pre and post automation checks and validations that is to say log into the firewall or switch your router get an overall snapshot like what's my mac addresses in my table what are my ip addresses in my art table what's the status of my neighbors etc perform this big snapshot and then perform some kind of change on the device whether it's like upgrading the version to a new release of code or maybe we're going to be configuring a new bgp pair or whatever the configuration change actually is and then log back in and take another snapshot and then do a diff in between the before and after snapshots and if there's any variation in between them then create an alert create a report send an email send the message to slack whatever those types of functionalities is jsnappy is a wonderful wonderful tool that can help us help validate the overall health and state of our networking devices so we'll be showing a little bit of that and the last one just kind of the cherry on the top we're gonna build an entire data center today uh with ansible and we'll be showcasing this construct that i call or i call i branded it yeah infrastructure as code we're going to be showing how ansible can be used in an infrastructure s code format to completely build a full vxlan evpn configuration that is perfect 100 perfect uh and uh so we'll be showcasing that so uh without any further delay uh we're pretty good on time we might go over a few minutes i hope that's okay with you guys let's go ahead and start our automation journey off by getting out of powerpoint there's a there's a challenge within itself there we go all right now i'm going to be performing all of my automation changes and demonstrations in a product called microsoft visual studio code this is in my humble opinion the absolute greatest piece of software microsoft has ever created and it is also like the number one favorited program or project on github it's completely open source uh and there's also plugins to help you manage and interpret junos configurations as well and one of the things that it provides to us is a text editing construct where we're going to be editing our playbooks but we can also have a direct terminal so that we can actually execute them as well uh within the program so we're going to be using visual studio code quite a bit here now the very first task or the very first playbook that we talked about was doing some basic configuration on a remote device and so let's let's dig into this playbook and by the way all of these are already available online i'll be sending out a link as promised at the end of the presentation uh and and within each one of these projects whenever you go and investigate it just know that there's a lot of extra goodies that i use in there to help it help make this execution just a little bit easier but typically all the ansible files will be stored in a directory called files and then ansible so in this case configure with cli commands let's go ahead and look at my playbook here and let's take a little bit of time to just kind of deconstruct what we got going on here now with me my memory is terrible so i like to spend like at least half of my playbook on comments so that i have an understanding as to what the heck is going on because once you start building these things in mass you're going to quickly forget maybe and i hope your memory is better than mine but so a lot of these lines that you'll see here are actually comments that i'm just leaving myself so that i can understand what's going on here and you'll see those comments they'll start with a pound sign or a hashtag based on your generation whatever we whatever you want to call them uh so let's go ahead and disregard this this is just a comment that says we're going to configure our device with basic parameters okay right out of the gate i understand what's the what's the purpose of this ansible playbook now again like we talked about at the beginning the first few lines of the ansible play are are us kind of tuning how we want this execution to run which devices we want to actually execute with and again overriding some of the defaults of ansible and then importing the third-party package for the juniper modules now it's worth noting uh we're going to take a look at the playbook we'll take a look at the inventory file and we'll take a look at the config file like we you know we kind of highlighted as the core constructs here this is the playbook let's take a look at my ansible config file uh there's there's kind of a lot going on here you don't have to know all these like i said this is this is like the default config file i use for all of my projects and i tune it as i see fit but i very rarely uh ever deviate away from this uh so what we have here is um basically the ssh keys um i'm also saying hey execute up to 15 consistent workflows uh and i'm pointing to the path for my inventory file let's actually look into that inventory file right now as well so here it looks like i've got a yaml file that's got a single device called ansible firewall one i'm declaring it's got this static ip address just in case your dns doesn't work you can overwrite ansible's defaults by passing in a static ip into this value called ansible host that's what you're seeing here ansible host is a member of the firewalls group and the firewalls group is a group of the all group so when i look back into my ansible playbook and i say host all just know that that needs to match something in your inventory in my case it matches the all group which would then subsequently match everything else listed in there in my case that's kind of anti-climatic because i just got a single device but i hope that you understand at least kind of the relationship between the ansible playbook and the inventory file so before we actually uh dig in actually no let's keep going on the ansible playbook there's not much left here now my playbook has two tasks associated to it we can see this task section listed out here on line 11 and i've got two different things that we're going to achieve so let's take a peek at what those are now the first task i have a description for this task that says send cli configuration commands to the remote device that again is a comment to myself but also when we execute play the playbook you will see this line printed to the screen as this text or as this task is being executed so it helps you kind of understand where ansible is within the playbook in this case if i got too task well where's the value in that but if i have 20 tasks and some of them are taking a little bit longer than others i probably want to know what's actually going on so i leave myself these big comments so that i can understand it we are calling in the ansible module called juniper underscore junos underscore config now that is a literal python script with that exact name stored in a remote directory i imported that by using this construct of here roles and juniper.junos so i'm now calling a python script from that repository and i'm passing in some basic parameters what is my username my password and look here we can actually tune how long to wait before ansible um create uh or reports that the connection timed out here i'm setting it to four minutes which is way too long you should never have a task making configuration changes it takes four minutes um so anyway there's there's that little knob that we got now i'm also telling the the python the juniper junos config module i'm also sending it some additional parameters if you've worked with juniper in the past you know that we have these set commands and these set commands are how we almost every network engineer configures a juniper device where we want to say set system host name router one set system domain server google.com etc so in that case we were calling set commands but you could pass a juniper device xml you could pass it json you could pass the config in the standard junos structure that you see whenever you do a show configuration so we're telling the ansible module we're not going to send you xml we're not going to send you like the junos config format we're actually going to send you some set commands and when you receive these set commands we want you to do a merge operation and again this is a juno specific thing but if you can have it to say only accept these commands and delete everything else that's on the other uh on the device that would be an override function in this case we're just saying hey merge these configurations into the actual config and don't take away anything that uh that that we didn't declare uh this is a commit confirmed operation where we're saying if if someone doesn't log into this device in 10 minutes and confirm the configuration change then automatically roll it back this is that one differentiating factor that most juniper engineers absolutely love especially when making remote changes on on devices the ability to automatically roll back a configuration is an absolute blessing without having to do like reload and tin or anything along those lines now now we actually define the configuration commands and if you would if you have familiar with juniper you would know that these are the actual configuration commands that you would have typed out if you had built an ssh connection to the device so let's talk about them very briefly uh one is i'm setting the host name of my firewall to router one so i'm changing the hostname on the box the other is i'm establishing a domain name for my device in this case i'm going to say wolf.com i'm also creating a loopback interface and i'm setting it with an ip address of 192.168.1.1 32 we're also enabling lldp on all of my interfaces and i'm also enabling spanning tree rapid spanning tree 802.1w on all of my interfaces as well and that's it now we're going to take the output of this task and we're going to store it in a new variable called result now you might not do this you may not want to to know what was the the change on the device you don't have to register the output to a variable but if you if you want to see exactly what changed this would be a really important thing store the output into an object this time i'm calling that object result and then we get to the second task the second time task is where we print the result to the terminal so that whoever's executing ansible playbook knows what actually changed if anything on that device will actually see that now i'm doing something that's kind of fancy i'm saying uh print the result to the screen if there was a difference if there wasn't a difference on the device don't print anything to the screen but don't get too tripped up on that um this this when logic is a is another one of those hurdles that we talked about with with working inside of yaml that if you wanted to do some kind of logic it's kind of a little challenging so with that being said let's now jump into my terminal and i'm just going to pop this open really quick the first thing i want to do is make sure that my current python environment has ansible installed on it so we'll say which ansible and here i can see that we get a response back this is my python virtual environment this is not going to be a conversation on python virtual environments um maybe some other type just know i'm in a python virtual environment that has ansible installed but if i didn't have ansible installed and i wanted to i would say pip install ansible and that will go ahead and download the ansible project to my computer if you're on a modern like ubuntu workstation you might have to say pip 3 to specify python 3 but as always i highly recommend that you consider using a python virtual environment and there's a lot of great docs on that so now that i know that i have ansible on my computer and my computer knows how to where to find it let's change it to my directory here for ansible configure with cli okay and if i type in ll to look at my folder directory uh not llc just ll uh here i can see yeah these files look exactly like this it's just structured in a little different way so we know we're in the right project directory all right let me change into my files slash ansible where all my fans fanciful where all my ansible goodies live and does that look like it's about right let's say inside of ansible yeah we got a roles directory an ansible config file in the actual configuration so before we do this let's open up another session to the device to just so that you know i'm not kind of pulling any smoke or mirrors over anything let's ssh into this device right now and make sure that its configuration is not like we're going to be doing to to change it so let's go ahead and yeah sure select that and ssh as the root user to this ip address my password is juniper123 please don't hack me all right so here we see we've got ansible firewall one and if i say show configuration protocols right this would be like my rapid spanning tree my lldp would go here i get nothing back if i say show configuration system host name well you might not be too surprised to see that the host name is currently ansible firewall one and if we say system domain name we get nothing back okay so that we know that what we described in our playbook is different than the current state on our device what would it actually look like if we executed this ansible playbook all right so i'm going to call ansible by saying ansible dash playbook and yes that will get very tiring to type out every time you'll probably look to making some kind of shortcut i always encourage that shortcut to be inside of a docker container but you could use python or invoke or any of those other constructs so i'm gonna i'm gonna specify the name of my playbook next which i always start my playbooks with the letters pb this is just uh my control freak net behavior when i'm working in a directory that's got hundreds of files i want to know exactly where all my playbooks are so i start the naming structure off with pb now i need actually let's see what's the ansible config file set for my inventory it looks like the inventory file is set so i don't need to declare it now within my playbook so let me clear the screen and say ansible dash playbook pb configure.yaml and then execute now i told you that i had coded some problems or there were some problems that i was going to showcase here that we needed to break into the ansible config file to uh to to work through and this is the first one so already on our very first ansible playbook we're getting some kind of error into the screen got the red text okay what's going on this is a big annoyance that a lot of us have in working with ansible is that ansible really struggles to work in virtual environments it all it always wants to default to your system's python version and if you didn't know what you're looking at let me explain to you when i'm issuing this playbook ansible is telling us you are trying to run a plugin that requires the junos eznc package which is juniper's pi easy package but it's saying we cannot find it it's not installed in this python environment so what we have to do is we need to break into that ansible config file and we need to override its defaults to say where our python virtual environment really is so the way that i do that again i'm going to type in which ansible playbook and then i'm going to say okay this is the directory of my virtual environment i'm going to copy this to the file and then i'm going to come back to my ansible config file and i'm going to make an adjustment by uncommenting this out this is the path for my uh my ansible uh python interpreter or for my virtual environment sorry i showed you the wrong way of doing you should have typed in which python and then just copied the actual uh full path and text and then placed it within here make no mistake you will run into this problem at some point and you'll be pulling your hair out because you're thinking i know the junos eznc package is installed in my virtual environment what is going on here so just know that this is a big annoyance with ansible and one of the reasons why i highly recommend always using docker and i always provide docker files in my projects so that you can use that rather than dealing with these annoying realities of ansible sometimes so now that we've specified we've overwritten the defaults inside the config file and told it where to find our python virtual environment let's go ahead and execute our playbook so we see that it's taken just a second we're sending all those cli commands to the remote device and now let's actually interpret what we got back so starting from the top the play is all this is saying again at the very top i didn't pass in a name for my play so it's just defaulting to my inventory uh device now we get to the task section remember we had two different tasks the very first thing was to send cli commands to the remote device we got a yellow indication coming back from the device to say something was changed there was a change on the device now if you remember we told ansible to register all the output of our changes into an object called result and print it to the screen and that's what you see in the second step here we're actually printing it out to the screen and what's great about juniper and for all of you guys that already have worked with our devices before you'll know that you'll get the diff you'll get exactly what change on the device so pluses and minuses indicate what kind of operation was performed here we can see that the hostname ansible firewall one was removed and hostname router one was replaced and all the other configuration parameters as well so let's jump back over into our device and i'm going to hit the enter key just once and what we get right away is we get a message to say that the commit confirmed will automatically roll back the last change if nobody commits this change in the next nine minutes we also see that the host name has changed from uh from ansible dash firewall dash one into just router one now if i say show me the configuration of my protocols i can now see that we've enabled lldp on all of our interfaces and then i've enabled rstp on my virtual firewall which is already not supported but it still let me do it so there we go so we know that the configuration took place and if i look for that domain name uh yes i get the domain name back as wolf.com now i told you that these modules are item potent and that well typically if the good developer wrote them they're going to be uh item potent so let's say i want this playbook to execute every hour on the top of the hour but i don't want it to make a change if the change is already present let's show you what that would actually look like right now i'm gonna hit the up arrow and execute this again and this should not take nearly as long uh we see now that we got we didn't get a changed value that came back from the device we just got the thumbs up okay meaning that no changes were done here and remember inside of our print statement we said only print to the screen when there's an actual diff in this case there was no diff because the change was already present on the device so that play or that task was was skipped by ansible because of that so again we didn't need to make the change on the device so no change was actually executed on there so uh really great we we know that we can make configuration changes and we can do it quite easily just by porting the the same commands that we would be doing already from the command line that can be easily enveloped and adjusted into the ansible execution now let's move away from the cli configuration changes and talk about that second one which was retrieving lldp information so i'm gonna dig into this playbook just a little bit but i'm gonna put on my micro machine speed racer voice because we are gonna be running out of time uh here and i wanna make sure everybody gets the full experience of all these demos um so let's just tug into this one the differences here is i'm creating some variables inside of my playbook this is not a you may do this in time in different times but there are dedicated directories to hold variables in my case i'm storing my username and password and i'm also creating a variable called backup directory and i'm telling you exactly where to find this folder in the context of my project now you can note that this this directory right here called output is is effectively empty there's a there's a file in here called get keep which will uh j it's an empty file that just lets the project be stored in a source code or lets that folder be maintained even if there's no files in the project let's go ahead and check out what it's like to receive the lldp information from our devices and to do this i'm going to back out just a little bit and change my directory to retrieve lldp neighbors information we're going to change into the files in ansible directory and yes these files and folders look very similar to what we got here so we think that we're in the right world let's look at my ansible config file again i got a single device it's in a group this one's just called colo router one i have a static ip assigned to it all right so what we're going to do is we're going to execute ansible playbook and we're going to point to the actually this might have the same ansible config issue and it's going to so let's go ahead and copy what we did for this one let's copy that config line into here or else we're going to have a python interpreter error again so let's go ahead and paste this and again this is something this python environment issue is only found with like if you're executing ansible in the command line if you do this from tower you're not going to run into those types of problems there's another value of ansible tower so ansible playbook we're going to say pb.retrievelldp.yaml what this is going to do is it's going to log into my colo router and it's going to grab all the information from my lldp neighbors and if you've got a sharp eye you would note that this file was just generated but before we dig into that let's actually look at the output that we have here on the screen we can see that we we printed the result of the screen and the ansible module is is really nice in that it will structure the output in different capacities so the the actual format that the data came back was in xml format and that is definitely there in this output as well but ansible the ansible module will also present it in yaml structure as well so if you're just looking at this and you're saying what was my neighbor on gigabit zero zero one uh rather than going through the wall of xml output you could just say okay that one's zero one three zero one two oh here's zero zero zero uh the neighbor was dallas firewall and and here was the uh the the local interface for it as well and here's the the remote systems mac address um and we can see that we actually wrote this output to a file uh here called uh colo router zero json and if i use the visual studio code plugin to format this document it'll actually format the json for us so we can see the data is presented and actually in this case it's written to a local file if you prefer xml i don't blame you it's a great protocol it's a great markup language and a great protocol here it is in xml this is the obvious the native junos data format is in xml if you prefer that you're more than welcome to uh and it even presents it in a string uh output if you wanted to actually write regular expression parsers uh maybe because you're a sadist or or something that you'd rather do things the the really really hard way you could actually parse the texturing yourself as well so there great we showcased how to use the ansible modules to actually retrieve information from our devices let's move over into the ansible tower side of things well we'll do the the deployment of a new virtual srx in our environment so i'm going to log in to my ansible awx and from here i've got a list of different templates now remember in the construct of awx and tower template think playbook it's technically a little bit different because the template has a little bit of flavor on top of it but ultimately these are going to be our ansible playbooks and i can dig into any of these these playbooks and figure out exactly who did what on what devices and what actual changes were actually executed but in reality i want to showcase the api functionality of ansible tower because i think that's going to be the really compelling thing so what i'm going to do instead of executing something from ansible tower we will see it executed in ansible tower but i'm going to use another abstraction i'm going to actually use servicenow to instantiate this new virtual firewall so go ahead and log in with my super secret password i have a servicenow instance where all the home of all my network automation is instantiated from so whether i'm doing changes on the wi-fi or data center or security or whether i'm upgrading a device i can issue all of those commands and tasks and requests through servicenow and then servicenow will make the api call to ansible tower to actually execute so let's figure out how difficult it is to deploy a new virtual srx inside of our data center i'll click on security i'll click on deploy virtual srx and i see that i have one form field that's demanded or required of me and that's the name of the virtual srx and i don't know what's a what's a random it's a random word just so you know that i'm not making oops random word i'm i'm just a little paranoid that you think i'm blown smoking mirrors what's a random word generator and this is going to be our host name out mantle okay that is a new word for me um let's go ahead and paste that here so my firewall's name will be outmantle i will select the appropriate juniper virtual firewall version which in my case i live on the bleeding edge sir so we'll go ahead and select that one select which esxi host i'll keep it on the default select which data center keep the default and select which services are required i've got a web server ansible server it could be postgres this would actually affect the firewall policies that are created and which interfaces those policies or security zones those get applied to so think about like this just for a second i'm gonna click the order now button and from that perspective uh my job would be done but i do have an additional step where i'll go through this approval process and we'll say yes that looks legit let's go ahead and and sign off on this change and then we'll execute our ansible playbook but think about like just how easy that was and think about uh turning over the deployment of your virtual firewalls to like an application developer they would just go to like a servicenow portal they don't know that it's a firewall they don't know it's a juniper device they don't know what security policies even are they don't know that it's going to vmware uh they don't even know that it's using ansible in the background all of that is is is subtracted from the equation which enables you to deliver like self-service portals for your customers which are ultimately your application developers and so here we can see ansible towers got a new deployment that's being executed we can drill into this detail if i move over to my oh we're going to miss it if we don't look right here into my vcenter i can see that a new firewall is being instantiated uh the the execution time um looks to be off yeah looks to be off by 20 minutes or so but we've created a new firewall called outmantle and if i look over here there's the outmantle firewall we can see it's currently coming online okay so as that firewall boots up that's not the end of the playbook it's actually also going to log in and make basic configuration changes and so we'll keep this on in the background it'll take a couple more minutes for us to execute but let's return back to our next uh automation example in the meantime which was using uh ansible and jsnappy to perform state validation on our devices here so i'm going to clear my screen and change back into a different directory that i've got listed here this one's going to be ospf there we go jsnappy ospf validation if i open up this directory let me just go ahead and close everything else uh if i open up this directory let's take a peek at the ansible playbook here the ansible playbook says the same things that we've been doing before defining how to execute the ansible playbook again i'm passing in some variables you would probably want to secure your variables a little bit better than i have here and let's look at the actual task we've got one two and three different tasks that are here let's take them apart just really quickly the very first tasks that we have is we're calling a python script in the background it's called juniper.junos. or underscore jsnappy you don't have to know that that's python you don't have to know anything about the code that that's actually executing but you and i know right we're in the no that's in python script there's a literal script on the device on this ansible server that's got that name and we're referring to it right now and then we're going to pass in some parameters into that script the host name the username the password the types of things that we would need to build an ssh connection to the device we also declare our test file now this is a jsnappy construct and we'll get to that in just one second but we're issuing jsnappy which again allows us to make network validations assertions i'm passing in a test file what are the things i want you to do jsnappy and we'll take a look at that just in a second there's also this action of a snapchat again jsnappy works in two different ways one is a snapchat like i'm showing you right now where we log into the device take a snapshot and compare it with the test that we're passing but you could also do the other aspect of jsnappy which is pre and post configuration change and state validations so i'm going to be showcasing one of those here we're restore we're storing the output of our test into a new object that we call test underscore ospf i'm also telling ansible ignore any errors meaning like if the test fails on a device if the result was a failure just ignore it just carry on don't stop the entire ansible workflow just because of that error don't worry so much about the tags it's not important in this construct but basically you can add a tag to a playbook and use that as a reference point later on the second task that we have we're going to print the output of our jstappy test to the screen and then the third task we're going to build an assertion we're saying thou shalt must be at per 100 percent per uh past percentage if any of the tests came back that uh that were a failure obviously you wouldn't be at a hundred percent uh validation and um that would be indicating that there was a problem so we talked about the jsnappy test let's actually take a peek as to what that actually looks like so if i go into my folder directory it looks like my folder name is test there we go it looks like i've got a file called ospf that i'm referencing let's take a peek at to that this is going to be the actual jsnappy test that we run now my test has three separate unique tests and what i'm doing is i'm running a command show ospf neighbor and then i'm pointing to that neighbor's ip address and then when the jsnappy gets the output of this command right here then we use the xml xpath um and that's a whole other conversation uh but just know we're going down the output we're using the xml that i've got listed right here to find what value that i'm looking for in this case i'm looking for the value of ospf neighbor state and i want to make sure that that neighbor state is in the full adjacency it's not in two-way it's not an init it is in a full adjacency and if there's not we're going to print an error to the screen to say exactly hey this firewall on this interface is is in a different state and will actually present that state now jsnappy you don't have to be as static as i've typed in like literally the exact host we could have done just show us pf neighbor and got a list of all the hosts and then iterated over that but i just kind of wanted to show a rather easy to hopefully and easy to understand uh execution so with that being said let's return back to our terminal here let me clear the screen and i'll type in ll and then from here i know that i need to move to my ansible directory and i'll do ll again and from here i can just simply say well i don't have an ansible inventory file let's take a look at the config file here to see the config file has the interpreter set correctly and the inventory file is also oh no it it's it's am i in the wrong directory is that that's going to fail isn't it um where is my ospf uh there is no inventory file it's actually back in here so i don't think this is going to execute correctly let's figure this one out let's go ahead and try it we'll do it live so ansible playbook pb.jsnappyospf uh so okay this is what happens uh when the ansible playbook cannot find your inventory file um and as i said earlier this is one of the things i always specify inside of my ansible config file where to find my inventory file um but in this case it was not the inventory file that i referenced it was not in this directory so that we get this kind of output that it says to the screen now rather than editing my config file i can also pass in an argument a dash i and tell ansible where to find my inventory file in my case it's in a different directory called a docker where all my docker stuff is and there's my inventory file so okay let's go ahead and execute that then we're going to go ahead and see that we're logging into the device and we got a hundred percent of our test back and everything is good and how do i know that well uh what we see in the recap we see okay is equal to three um we saw nothing was changed we saw none of the devices were unreachable nothing failed nothing was skipped nothing was ignored so everything came back good everything's hunky-dory and let's take a peek at our actual task as they execute again as we talked about we had two tasks uh actually three the first was to grab all the ospf neighbors uh within the device and by invalidating them with the jsnappy test the second where we actually print that result of the test to the screen this is beneficial for you and i as we can actually see this the output here in the screen and it tells you right off the bat three of your three of your tests passed zero failed which resulted into a hundred percent uh past percentage here's the name of the this specific device and here's the actual output from the command so for the first test that we ran uh 190 that 221 165.1 here's the result uh the result was a pass the expected was a full adjacency the actual from the device was a full adjacency so your test had passed um and it will also show the the interface and the ospf state and it says that for each one of ours let's actually break this though because that's when things start to get fun so i'm going to go ahead and open up a new terminal we're going to ssh into this device what was the iep address of my my firewall i'm still in the wrong directory jsnap there we go so this was my ip address of that router let's go ahead and ssh into it automation at this ip pass in my super secret password of juniper one two three uh and we can see here that we are show chassis hardware uh just kidding uh we are an acx 1100 router that i'm using for my mpls backbone uh here in my house because it has no fans and i just love that um okay so uh let's go ahead and uh take a peek at my show protocols ospf i'll just say display set it looks like i have ospf enabled on three physical interfaces let's go ahead and disable it on on interface uh gigabit one zero three and the way i'll do that is i'll actually deactivate the physical interface itself so the the configuration will exist in the ospf stanza but my physical interface is going to have its entire configuration deactivated so show compare okay and if i just take a look at that interface just so that we know what we're looking at here uh it looks like um uh i'm setting mtu an ip address and as mpls we deactivated that configuration as soon as i type in the word commit uh and as soon as that commit goes through we'll go back and we'll rerun our jsnappy test to see what does it look like when we have a failure from our network assertion test uh so there we go it's committed let's jump back in over to here and we'll hit the up arrow and execute yet again and what we'll see now or what we're hoping to see is that we actually have a failure on the device so let's take a peek at what that actually looks like first of all our assertion failed since the test didn't come back as all pass we know that there was some issue within the test and by the way you like i said earlier with the results you can take these results that i'm showing and you can send them to slack automatically you can send them to teams you can send them to facebook messenger if you really really want to it doesn't have to be here within the console itself but let's take a peek at our results we see total failed was one total pass two we have a total of three tests uh let's find the failure um the let's see test results um this one was a as expected as full uh its actual was null so this is our failure right here so two test pass okay so this one was a failed so rather than being the full adjacency it's actually a null adjacency meaning there is no ospf neighbor on there so this was the interface that had failed whereas this test had passed and this test had passed so just like that we can quickly build uh scripts that can validate the state of our devices and it doesn't have to be like control plane stuff right it doesn't have to be ospf it could be uh chassis alarms it could be fans it could be optical light levels it could be errors on the interface whatever thing that you're looking to capture and you want to build a test around jsnappy is is a wonderful utility and it can easily be inserted into the into the ansible project itself now let's check in on our friendly firewall over here we'll see that when it first booted up our out mantle virtual firewalls name was vsrxtemplate if i hit enter and i log into this see root and juniper123 i can see that the hostname is actually out mantle and that looks great so we see that the hostname was actually changed we didn't just deploy the virtual firewall we also made some configuration changes if we go back to the ansible tower output of that we can actually see those uh results right here and what's great about ansible is that they'll try to collapse the screen so it's not too much output in your face i think they give you like 20 20 lines of output but you can dig into this and actually figure out all the parameters that actually of that play so here we can actually see that we instantiated the virtual srx and we have another play down here that logged into that virtual srx after it was deployed and then made some configuration changes and now you get those configuration changes in your screen now since this is in your audit log it will always be here so fantastic so we know exactly over the life cycle of this device uh how long wait first of all who provisioned it uh what basic parameters were pushed onto it and all the configuration changes that would take place through ansible we can get that historical timeline uh and so that if we ever needed to roll back we would know exactly how far we need to roll back now the last one is my favorite it's the icing on the top it's the cherry it is building a full vxlan evpn data center now just to make sure that i'm not blowing smoke we're starting from scratch let me log into one of these devices and say show configuration display set this is the current configuration on my device if you've never seen juniper and you start to get a little nervous don't worry let me just tell you this is basically me creating a username me enabling netconf and ssh and then providing a static routes so that i can access it and an ip address on the management report that's it not enough for a full vxlan evpn configuration i promise you that and that's it's the same across all of our devices i actually have an ansible playbook that bootstraps this entire data center for this use case so let's just log into the spine switch to say show configuration display set yeah super simple show bgp summary bgp is not running show lodp neighbor lldp is not running right show show interfaces come on calvin show configuration interfaces uh just my my em-0 my em1 my management and my connection between my control plan and forwarding plan so this data center is not operating and because of that if i logged into one of my devices we'll say dallas server one over here and i tried to ping another server on this side which was dallas server four the servers are configured correctly although they take a second for me to get a gui into them but i cannot ping my default gateway i won't be able to ping north south and i won't be able to ping east-west this data center is broken it is in there well i mean it's in a in a i would call it like a bootstrap state uh so ipa grep inet what's my ip address okay so my default gateway is going to be 10.2.9 i cannot ping my default gateway and let me try to get the ip address of this device also connected over a or supposed to be a stretched l2 but currently doesn't exist so ipa graph inet okay so i'm dot 14 so can i ping uh 11 ping 10.2.9.11. cannot ping it things are broken can't even ping my default gateway so let's just go ahead and keep these devices uh operating in that capacity so everything's broken all right so what are we going to do here in this case we're going to be using ansible but with the constructor the concept of oops of infrastructure as code which means that all of my configuration elements are managed as code within an ansible project and so let's actually kind of pull this apart just a second this will get a little complicated because this is an advanced topic uh and i and i hate to to berate the complexities things sometimes but uh it's it's kind of cool uh so an ansible like i said earlier you can define variables inside of your playbook and that is perfectly acceptable although a little suspect at times it's not really the best for your security posture to be hard-coding your username and password into the playbook but there's also predefined places to store variables and think of a variable like a hostname a loopback ip address a interface name description any of those things that we would be configuring a device think of that as a variable and so there are predefined places to store these variables we can store them at the host bars level meaning every device has a folder and inside of every folder there's a file that has that device's variables in this case i'm looking at dallas leaf ones physical interfaces but there's no juno cli this is all defined in yaml what's going to happen when we execute this playbook the ansible will reach in and grab all the devices variables that either came in at the host level or at the group level and it's going to say okay i got all these variables now i'm going to run them through a juniper template engine which is going to be based on jinja 2 and it's going to build the entire configuration for the each device and then push it to those remote devices so let's showcase what this actually look like here let's exit out exit out and let's back out of there as well uh is it there and demos and dallas wrong one wrong one we were close there okay and let's pick on the dallas no a cd vxlan erb dallas all right so we're going to be deploying a vxlan data center and an edge drop bridge topology and we're going to be using uh an uh ansible for this task all right so if i look in my directory here let's go ahead and jump into my files my ansible directory clear the screen again do the ll cool j command and i've got a few different playbooks again i use pb to help me point to my playbooks i've got four different playbooks here one is going to build the configurations one is going to apply the configurations and if i'm in day two operations and i just want to do a diff if i want to find out what has changed from the golden configuration i can use this diff playbook and here is that other playbook that i mentioned that that basically defaults the config to exactly what we were working with here so in the our case we're going to be working with the builds playbook where again we build every single stanza of every single configuration based on the variables stored within the ansible project and then we're going to run the apply playbook which is ultimately going to push it so let's figure out how do we generate tens of thousands of lines of configuration and push it to our devices successfully a hundred percent of the time let's go ahead and work through that let's say ansible playbook i'm in the right directory i am uh which ansible make sure okay so ansible's not found i need to activate my python virtual environment uh ansible then activate okay uh let's try this again ansible playbook pb configuration dot build all right there we go and now what we see is we're going through and again we're building the apply groups we're building the system stands we're building the interfaces we're building the protocols we're building the routing instances the routing options we're building the vlans for every single device configuration uh and we build each section as its own individual file what's actually kind of lit you can actually see this taking place um in the live um you'll see files being added uh here uh as we see yeah so files different files are be constructed right so here's like my interface uh configuration file here's my snmp configuration file here's my system stanza configuration file and at the end like voltron it'll symbol all those individual files into the actual golden configuration uh let's take a peek okay so it looks like that was successful uh so right now all we've done is configured the actual built to the configuration let's look into our complete folder here and i can see yeah dallas leaf one here's my full configuration and isn't that glorious look at all that juniper glory with this configuration it's just so beautiful like i mentioned visual studio code has juniper plugins that help text and the junos config kind of pop out so that you can understand what is actually what so okay so we just generated uh 430 lines of config for this one file i can see my leaf configs as well and my spine configs okay so we think we're in a good spot this looks like a legit vxlan evp configuration let's go ahead and apply it now so we'll just say we'll run the same command except we'll change from build we'll change it to apply and we'll go ahead and press the enter key and we'll see exactly how this uh execution takes place here uh so while this is is going and pushing to the remote devices let me just first thank everybody for staying an extra 15 minutes on this uh i do get a little carried away and and and sometimes a little bit too deep on certain things so i apologize for going over on time but at least i hope it's been a little beneficial uh to this um these infrastructure as code concepts that i'm showing in this demo again these are being implemented by teams that are well along the journey they don't want to type in cli commands and in some cases vendor customers that have multiple vendors they don't want the cli hard coded on their device inside of their playbooks they actually just want to store the configuration elements as yaml and then all they need to do in theory is run the same playbook against a different vendor's template in this case i'm running it against a juniper template which produces a juniper config but you might want to run it against a cisco template or an arista template just kidding those would be the same uh a cumulus template etc um like i it the only thing that changes is the actual template the variables are consistent across the platform so here we see the configurations actually being applied to the devices it looks like it's in a serial fashion i assure you it's not what's actually happening is my virtual machine host is overwhelmed at the moment and these virtual networking devices are taking a little bit of time to actually commit their configuration uh to here but after this last one applies which should be leaf one as soon as this applies we'll get this wall of green text this is again the diff that's produced on our configurations we can actually see what things had changed in this case we got a lot of things being changed here we got uh routing protocols created we got routing instances looks here we we subtracted those static routes that i had on the device so we're making all these changes now if we return back over into our live demonstration oh look at that timing i just couldn't have timed that any better um so dallas leaf one was the last one to come online uh and that's what this server is connected to but man that timing i just i really nailed that one i'm pretty proud of myself um it it's taking time uh to build the l2 adjacency across my data center there we go now we got l2 adjacency built across my data center so we can see dallas server one is pinging a server and on dallas server 4 on the same local subnet despite the fact that they're separated by layer 3 i think i'm using isis in the underlay i don't really remember but again we just provisioned a full data center completely from code and if i said show bgp summary now yeah we've got some established bgp adjacencies uh we see we've got two vrfs i i was showing somebody this last night we were playing around i called the chuck e cheese vrf sorry about that uh but the real vrf is the dallas vrf listed here we can see the routes we can see that we have adjacency i can say show ethernet switching table to look at my mac address table and i can see that my remote neighbor 10 dot my remote neighbor 10. 2.9.14 was learned over this virtual this vxlan vtep and here's the source loopback of that so we have layer 2 adjacency we can switch ethernet frames across a layer 3 overlay like by using the vxlan technology um so with that let me see i i got a question in here let's see i love liz loves the voltron reference yeah i uh it's it's an old joke with mine i always use it uh but i'm glad that you enjoyed it as well um so yeah voltron um uh so our configuration our data center is completely consistent and just as you would imagine if we went through and we applied this again on our devices there would be no changes to be made here for two reasons one the ansible module is definitely item potent but two just like you would notice if you were managing a juniper config through secure crt or putty um no if there's no changes in the show compare if there's no diff then no change will actually uh be committed to the device so that's what we're going to see here instead of seeing these changes like what we saw here with yellows we're starting to see the devices come back with a green saying hey no changes were actually necessary for this and so now we can execute this playbook every single hour on the top of the hour to ensure that our data center is running the exact golden configuration you can even then abstract it into what we talked about earlier by using servicenow you can now extract it into servicenow and enable your developers or enable your data center teams to build these uh data centers by simply issuing your ansible queries through a construct like ansible tower where we can actually enforce the golden config or if you'd rather go down the appstore out you could absolutely build your your blueprints and execute them from here as well okay so yeah we got no do no diff was presented so no diff was actually printed to the screen we could issue this over and over again there's the item potency so check we feel confident that we are now certified jncie for data center uh and we need to update our linkedin and we're off to the races um so just real quick i do recognize for 20 minutes over again thanks for your patience uh where to go next on this first of all if you want some hands-on live interaction my first place to point you towards is nre labs this is the most amazing network automation platform in the world it's completely ran within your browser requires no email to sign up no registration no login no browser tracking cookies or anything like that we don't even put our name on this product because we don't want people to think that this is a juniper only thing nre labs is a place for you to execute and learn automation within your browser against virtual networking devices and the curriculum is provided by the community in the case of ansible ansible actually wrote the nre curriculum that you can follow and you can you can see the curriculum in your left hand page and then you can execute it on your right hand page inside of the browser terminal absolutely amazing product i highly recommend for anything that you're trying to do in automation start with nre labs first and then if if there's something missing then go elsewhere uh also juniper v labs it's another on-demand lab environment that can be spun up within your web browser no no software required on your computer the only thing you need is a juniper account and you're off to the races with vlabs you can not only just test ansible and python but you can also learn things like how does bgp work how does ospf work how to build the layer 3 mpls vpn those types of things because you're working with live juniper equipment inside of juniper b labs again free highly recommend it uh as far as ansible documentation ansible documentation in the community itself are bar none one of the biggest benefits of ansible the documentation is outstanding and it's held to high standards and it executes every time so highly recommend checking out the basic ansible documentation the last thing i'll just mention all the code that i showed today that i executed today and much much much much more is available on my private uh my personal gitlab instance here's the hard way of getting to that oh just kidding uh here's the bitly as well and if i was a good scout what i would do is i would copy this right here and i'll paste it inside of the zoom chat so that everybody has access to it there is again these examples and much much more i even have a multi-vendor example in there of validating ospf neighbors on a cisco device and a junior device within the same playbook so highly recommend checking those out feel free to download them kick the tires and everything on there they're just examples and it's just me building them so if there's problems with them don't call jtac uh call 1-800 calvin and i'll get on the phone with you and help you work through them um with that being said again almost 30 minutes over uh thank you all so much i really really enjoy doing these with you every month uh we're we're going to continue uploading them to youtube um unfortunately right now i'm still kind of this is still kind of like a skunk works operation uh i haven't involved marketing just yet so all the the youtube is on my personal uh uh youtube channel which by the way is where i also do all my live streams uh that we mentioned earlier uh if you're if you want last month's introduction to netcomp and rest apis it's right here uh introduction to ansible and nor near if you want to see kind of how both of them work if you're interested in xml and json if you just want to learn python looks like a lot of people are wanting to learn python go at it this channel is here for you guys and this is where you'll find this video also uploaded i will paste the link to my channel um i guess i'll just yeah we'll just place this into the chat as well and hopefully that's beneficial to you all so again uh thank you for your thank yous i appreciate that i'm humbled i'm glad it was uh beneficial to you all and thank you so much for hanging out way past our allocated time if you have something specific that you would like to see next month please reach out to me my email address is also going into the chat i believe this chat's going to go away as soon as i hang up the phone so grab this stuff while it's here if you would like to recommend some kind of content feel free that's my my work email address um i check it like twice a day at best oh ouch um uh but i i will try to definitely steer the next conversation toward that i'm thinking about doing either an introduction to python for the next module which by the way is already here on my youtube channel so it would be easy for me to copy and paste i'm also thinking about maybe doing a network source of truth because that's a really important part of an automation stack and and worth knowing at least you know the value proposition it provides but again it's open to your determination whether or not you you have something specific you'd like to see so uh feel free this email address i posted in the chat that's also the official complaint channel so uh if you didn't like this presentation and you just didn't like my delivery um only email that person don't email the corporate please um so uh just kidding um that being said thanks everybody i really appreciate it's been a a wonderful two and a half hours this will again be uploaded to this youtube channel that you see in the background here um and we'll we'll see you next month remember it's the last thursday of every month um and so that's that's hopefully to just kind of give you a break from your traditional work stuff because you guys have earned it as well thanks everybody and we will see you next time have a good day

Channel: Calvin Remsburg

Views: 2,934

Keywords:

Id: zhgZbaqL3Rk

Length: 144min 8sec (8648 seconds)

Published: Fri Apr 30 2021