WEBVTT 0:00:02.820000 --> 0:00:07.100000 Hello and welcome to this video titled an overview of network automation 0:00:07.100000 --> 0:00:11.260000 tools. In this video, the things I'm going to cover, I'm going to talk 0:00:11.260000 --> 0:00:14.380000 about the capabilities of configuration management tools. 0:00:14.380000 --> 0:00:17.140000 What can you actually expect them to do for you? 0:00:17.140000 --> 0:00:20.340000 I'll give you an overview of some common configuration management tools 0:00:20.340000 --> 0:00:23.400000 and their similarities so you're familiar with their names. 0:00:23.400000 --> 0:00:28.380000 We're going to talk about some generic topics of masters and agents and 0:00:28.380000 --> 0:00:30.380000 the push and pull models. 0:00:30.380000 --> 0:00:33.900000 We're going to look at what is a configuration file and why is that important 0:00:33.900000 --> 0:00:35.980000 in the world of network automation. 0:00:35.980000 --> 0:00:38.620000 And then we're at a very high level just going to sort of differentiate 0:00:38.620000 --> 0:00:44.040000 three of the most common tools, puppet, chef and Ansible by explaining 0:00:44.040000 --> 0:00:47.760000 some terminology and concepts so you're familiar with those terms when 0:00:47.760000 --> 0:00:50.020000 you see them elsewhere. 0:00:50.020000 --> 0:00:54.220000 So let's talk about the capabilities of configuration management tools. 0:00:54.220000 --> 0:00:57.980000 What can these things actually do to make your life as a network admin 0:00:57.980000 --> 0:01:01.020000 or engineer easier in your job? 0:01:01.020000 --> 0:01:06.780000 So the main goal of all these tools is to remove the box by box dependency 0:01:06.780000 --> 0:01:09.480000 of CLI management. 0:01:09.480000 --> 0:01:13.760000 Up until now, if you had a network of 50 switches and 200 routers, if 0:01:13.760000 --> 0:01:19.360000 you had to make a change, you had an SSH or telnet into each box one at 0:01:19.360000 --> 0:01:22.380000 a time and apply your configuration statements. 0:01:22.380000 --> 0:01:25.880000 They may be used notepad or Wordpad or some other text editor and just 0:01:25.880000 --> 0:01:30.180000 copied and pasted in there, but you still had to initiate the SSH session, 0:01:30.180000 --> 0:01:33.860000 type in the specific enable password or whatever it was and then copied 0:01:33.860000 --> 0:01:37.520000 and pasted your iOS commands, hoping you did it right in your text editor 0:01:37.520000 --> 0:01:41.580000 and you didn't screw it up, exit out that box, move into the next one. 0:01:41.580000 --> 0:01:44.880000 So all these tools we're about to talk about here are meant to automate 0:01:44.880000 --> 0:01:50.820000 that process. So they centralized the configuration and software management 0:01:50.820000 --> 0:01:54.240000 tasks onto a single controller. 0:01:54.240000 --> 0:01:57.760000 Now these network management tools we're going to talk about either can 0:01:57.760000 --> 0:02:01.600000 be run standalone on their own server, so when we talk about things like 0:02:01.600000 --> 0:02:06.320000 Ansible or Puppet or Chef, you absolutely could load those things onto 0:02:06.320000 --> 0:02:10.480000 your own Ubuntu or Linux server or something like that and then from there 0:02:10.480000 --> 0:02:15.860000 use that as the central point to automate everything or these tools in 0:02:15.860000 --> 0:02:20.020000 turn can speak to an SDN controller that you already have. 0:02:20.020000 --> 0:02:23.860000 For example, you could have an SDN controller of like Cisco DNA Center 0:02:23.860000 --> 0:02:27.860000 already set up in your environment and you could have another server somewhere 0:02:27.860000 --> 0:02:32.840000 running Ansible, Chef or Puppet that's talking to DNA Center and sending 0:02:32.840000 --> 0:02:34.300000 the commands through it. 0:02:34.300000 --> 0:02:36.880000 That's certainly possible as well. 0:02:36.880000 --> 0:02:43.060000 These also allow for day zero provisioning of devices and here's the real 0:02:43.060000 --> 0:02:46.340000 power right here creating resources that can be applied against a single 0:02:46.340000 --> 0:02:51.340000 node. Think of a node as being a router, a switch, a firewall, or against 0:02:51.340000 --> 0:02:52.300000 groups of nodes. 0:02:52.300000 --> 0:02:54.900000 Now what do we mean here by create resources? 0:02:54.900000 --> 0:02:59.440000 A resource is basically anything you could do on that device. 0:02:59.440000 --> 0:03:03.320000 So for example, a resource represents like adding a VLAN, that would be 0:03:03.320000 --> 0:03:06.560000 a resource or applying a route filter. 0:03:06.560000 --> 0:03:07.780000 That would be a resource. 0:03:07.780000 --> 0:03:12.000000 So any action you want to push down to a node or a group of nodes would 0:03:12.000000 --> 0:03:15.540000 be considering resource from the standpoint of these network automation 0:03:15.540000 --> 0:03:21.060000 tools. And you can also automate deployment of changes either by schedule 0:03:21.060000 --> 0:03:22.820000 process or manually. 0:03:22.820000 --> 0:03:23.960000 So you've got a choice. 0:03:23.960000 --> 0:03:27.340000 You can either log into your server that's running Ansible or Chef or 0:03:27.340000 --> 0:03:33.240000 Puppet and implement one command in the CLI and off it goes and starts 0:03:33.240000 --> 0:03:38.080000 logging individual devices and doing its thing automatically or you could 0:03:38.080000 --> 0:03:40.560000 schedule it. You could type in a command or something and say, hey, at 0:03:40.560000 --> 0:03:44.380000 three o'clock in the morning on Tuesday, I want you to automatically log 0:03:44.380000 --> 0:03:48.340000 into every device and collect these statistics for me or pull down this 0:03:48.340000 --> 0:03:50.740000 change I want to do. 0:03:50.740000 --> 0:03:54.380000 So what are some common configuration management tools? 0:03:54.380000 --> 0:03:56.680000 These are the ones you're going to see most often. 0:03:56.680000 --> 0:04:01.940000 Ansible, Salt Stack, Puppet and Chef. 0:04:01.940000 --> 0:04:06.020000 So we're going to focus primarily on the bottom three here, Ansible, Puppet 0:04:06.020000 --> 0:04:09.820000 and Chef. But I do want you to know that Salt Stack is also a contender. 0:04:09.820000 --> 0:04:13.480000 If this is something you're thinking of implementing your own network, 0:04:13.480000 --> 0:04:16.840000 you will want to spend at least a day or two researching all four of these 0:04:16.840000 --> 0:04:19.320000 to see which one works best for you. 0:04:19.320000 --> 0:04:23.380000 Now, regardless of which one you pick, there are some real high-level 0:04:23.380000 --> 0:04:25.700000 similarities with all these. 0:04:25.700000 --> 0:04:31.260000 For number one, unfortunately, you can't get away with not knowing anything 0:04:31.260000 --> 0:04:34.580000 about CLI or scripting. 0:04:34.580000 --> 0:04:40.680000 So all of these tools require some sort of command line interface, some 0:04:40.680000 --> 0:04:45.240000 sort of thing, some of it looks like Cisco iOS, but some of them have 0:04:45.240000 --> 0:04:49.480000 a command line that's completely different than Cisco iOS using a language 0:04:49.480000 --> 0:04:52.720000 like YAML or Ruby or something like this. 0:04:52.720000 --> 0:04:54.960000 So why do you have to know this? 0:04:54.960000 --> 0:05:01.460000 Well, because as you can see right here, go down here, the foundation 0:05:01.460000 --> 0:05:05.780000 of all these tools is that you have to script out in advance what you 0:05:05.780000 --> 0:05:07.240000 want the thing to do. 0:05:07.240000 --> 0:05:09.500000 Do you want the tool to create VLANs? 0:05:09.500000 --> 0:05:11.240000 Well, you got to create a script to do that. 0:05:11.240000 --> 0:05:15.940000 Do you want the tool to automatically pull devices and retrieve information? 0:05:15.940000 --> 0:05:17.880000 You got to write a script to do that. 0:05:17.880000 --> 0:05:21.480000 Do you want the tool to automatically program OSBF on everything? 0:05:21.480000 --> 0:05:23.160000 You got to create a script for that. 0:05:23.160000 --> 0:05:25.400000 So all of these things require the front end. 0:05:25.400000 --> 0:05:29.040000 You create some sort of a configuration file which has to be done with 0:05:29.040000 --> 0:05:30.660000 the scripting language. 0:05:30.660000 --> 0:05:35.140000 And then from there, if they provide a GUI, the GUI can then be used to 0:05:35.140000 --> 0:05:38.440000 pull that configuration file and push it down to the devices that you 0:05:38.440000 --> 0:05:43.820000 wish. So what you're seeing right here, I'll make this a little bit bigger, 0:05:43.820000 --> 0:05:47.120000 this graphic in the lower right hand corner is actually an example of 0:05:47.120000 --> 0:05:51.120000 puppet. This is an example of the scripting language that puppet uses 0:05:51.120000 --> 0:05:54.640000 to create its configuration file. 0:05:54.640000 --> 0:06:00.400000 All right, another term you're going to hear a lot is this term of masters 0:06:00.400000 --> 0:06:07.840000 and agents. So as it mentions, these configuration management things have 0:06:07.840000 --> 0:06:12.340000 two pieces a lot of times, not always, a master which is installed in 0:06:12.340000 --> 0:06:17.380000 your Linux server or your Ubuntu server or whatever, and an agent. 0:06:17.380000 --> 0:06:21.360000 And the agent is what is actually being acted upon. 0:06:21.360000 --> 0:06:25.140000 So an agent might be your router or your switch. 0:06:25.140000 --> 0:06:29.780000 A puppet and chef and salt stack are all examples of configuration management 0:06:29.780000 --> 0:06:37.640000 tools that use this concept of masters and agents. 0:06:37.640000 --> 0:06:41.440000 Now, as far as this terminology here, masters and agents, just so you 0:06:41.440000 --> 0:06:44.900000 know, different software calls it by different things. 0:06:44.900000 --> 0:06:47.940000 For example, puppet, it does call it master and agent. 0:06:47.940000 --> 0:06:52.040000 You have a puppet master, which is software running in a server somewhere. 0:06:52.040000 --> 0:06:55.900000 And that puppet master is talking to a puppet agent, so the agent is what's 0:06:55.900000 --> 0:06:58.580000 being controlled by the master. 0:06:58.580000 --> 0:07:02.480000 Similarly with chef, chef also has a master agent component. 0:07:02.480000 --> 0:07:07.500000 Now salt stack, which is kind of funny, has masters and minions. 0:07:07.500000 --> 0:07:12.280000 Same general idea, the minion is controlled by the master. 0:07:12.280000 --> 0:07:17.000000 Now, just to be aware, puppet also has an agentless feature. 0:07:17.000000 --> 0:07:21.540000 I am not a network management guru by any stretch of the imagination, 0:07:21.540000 --> 0:07:25.200000 but a little bit of what I was reading was about puppet was that a lot 0:07:25.200000 --> 0:07:29.320000 of people have been concerned about puppet because many networking devices 0:07:29.320000 --> 0:07:34.420000 don't have a puppet agent component built into the software. 0:07:34.420000 --> 0:07:37.780000 If you think about your typical Cisco switch or Cisco router or Cisco 0:07:37.780000 --> 0:07:40.480000 firewall, there's no puppet in there. 0:07:40.480000 --> 0:07:44.640000 There's no puppet agent software built into that device and it doesn't 0:07:44.640000 --> 0:07:47.040000 have the ability to load that. 0:07:47.040000 --> 0:07:50.440000 So someone might shy away from puppet saying, oh, well, there's no way 0:07:50.440000 --> 0:07:54.320000 for me to install the puppet agent inside my Cisco router or my Cisco 0:07:54.320000 --> 0:07:56.200000 switch. So I don't want to use puppet. 0:07:56.200000 --> 0:07:57.240000 I'll go with something else. 0:07:57.240000 --> 0:08:00.100000 Well, puppet wants to make you aware that there is something called an 0:08:00.100000 --> 0:08:04.240000 agentless feature of puppet, which means you still have your puppet master 0:08:04.240000 --> 0:08:08.360000 and you still have to have some sort of an agent, but instead of the agent 0:08:08.360000 --> 0:08:12.020000 actually being software inside of your router or switch, your your managed 0:08:12.020000 --> 0:08:16.100000 device, you could have some other device like what they call a proxy agent 0:08:16.100000 --> 0:08:19.960000 that's speaking on behalf of the router or the switch. 0:08:19.960000 --> 0:08:23.620000 So the puppet master would talk to that proxy device, that agent, and 0:08:23.620000 --> 0:08:28.480000 then that agent in turn would most likely open up like an SSH session 0:08:28.480000 --> 0:08:31.860000 and send command lines down to the router switch to control it. 0:08:31.860000 --> 0:08:33.480000 So puppet can do that. 0:08:33.480000 --> 0:08:37.860000 That's what they call agentless with puppet. 0:08:37.860000 --> 0:08:43.000000 All right. Now these configuration management software programs, one way 0:08:43.000000 --> 0:08:45.540000 they are sort of different from each other is whether or not they use 0:08:45.540000 --> 0:08:48.540000 the push or the pull model. 0:08:48.540000 --> 0:08:52.760000 So the push model, both of these are pretty simple in concept. 0:08:52.760000 --> 0:08:58.060000 The push model simply means that on the master, you either execute a command 0:08:58.060000 --> 0:09:02.220000 to say, go, do your thing right now, or maybe you automate it. 0:09:02.220000 --> 0:09:05.460000 Maybe you say, okay, it's three o'clock in the afternoon, go and reach 0:09:05.460000 --> 0:09:06.840000 out to these devices. 0:09:06.840000 --> 0:09:10.880000 Either way, the master is ready to go and in the push model, the master 0:09:10.880000 --> 0:09:15.340000 would push down whatever you want it to do right then and there. 0:09:15.340000 --> 0:09:18.820000 And then the configured device is the agents, for example, or the nodes 0:09:18.820000 --> 0:09:22.700000 would have that change put on them. 0:09:22.700000 --> 0:09:26.600000 So it can be invoked manually or after a defined schedule. 0:09:26.600000 --> 0:09:33.620000 Now a lot of people prefer the push model because when you make a change, 0:09:33.620000 --> 0:09:38.160000 like you change your routing protocol or you add a VLAN or you shut down 0:09:38.160000 --> 0:09:42.740000 an interface, most likely you probably want that change to take effect 0:09:42.740000 --> 0:09:46.860000 right now immediately or as close to the time you hit the enter button 0:09:46.860000 --> 0:09:51.120000 as possible. And the push model is good for that as opposed to the reverse, 0:09:51.120000 --> 0:09:52.700000 which is the pull model. 0:09:52.700000 --> 0:09:56.120000 So Ansible and SaltStack utilize the push model. 0:09:56.120000 --> 0:10:01.340000 The pull model is typically where you have a master as an agent. 0:10:01.340000 --> 0:10:05.680000 So notice the push model, good method for tools that require no agent 0:10:05.680000 --> 0:10:09.660000 component. But when you have a master and agent, you're most likely using 0:10:09.660000 --> 0:10:15.920000 the pull model, which means that the agents are polling the master periodically. 0:10:15.920000 --> 0:10:19.060000 Think of like SNMP in reverse. 0:10:19.060000 --> 0:10:23.160000 So in the world of SNMP, you've got the SNMP manager, which is your server 0:10:23.160000 --> 0:10:25.440000 running your SNMP software. 0:10:25.440000 --> 0:10:29.220000 It's got your pie charts and all your red and green blinking lights. 0:10:29.220000 --> 0:10:32.640000 And then you have your SNMP agent, which is running on your router or 0:10:32.640000 --> 0:10:37.320000 your switch. Well, in an SNMP environment, that SNMP manager, your software 0:10:37.320000 --> 0:10:42.680000 on your server is polling your routers or switches. 0:10:42.680000 --> 0:10:45.880000 You know, you get to decide how often you want to pull, maybe every five 0:10:45.880000 --> 0:10:46.720000 minutes or every 10 minutes. 0:10:46.720000 --> 0:10:49.740000 But it's going around and polling saying, how are you doing? 0:10:49.740000 --> 0:10:50.560000 What's the health of you? 0:10:50.560000 --> 0:10:52.160000 What do your interface look like? 0:10:52.160000 --> 0:10:54.200000 What's your CPU look like? 0:10:54.200000 --> 0:10:59.100000 And the problem with the polling method is that, let's say I pull you 0:10:59.100000 --> 0:11:01.560000 right now and I say, how's your health, Mr. 0:11:01.560000 --> 0:11:05.020000 Router? And via SNMP, you come back to me and say, I'm good, everything 0:11:05.020000 --> 0:11:08.000000 looks great. Now, let's say my timer is set up where I'm not going to 0:11:08.000000 --> 0:11:09.920000 pull you again for another 10 minutes. 0:11:09.920000 --> 0:11:13.040000 But right after I pull you right now, everything goes crazy. 0:11:13.040000 --> 0:11:16.740000 Something happens and now your CPU has spiked, your memory has messed 0:11:16.740000 --> 0:11:18.800000 up, and you're having all sorts of problems. 0:11:18.800000 --> 0:11:23.140000 Well, in a polling model, I'm not going to know about that until I pull 0:11:23.140000 --> 0:11:26.420000 you again 10 minutes later. 0:11:26.420000 --> 0:11:29.480000 So from this perspective here of network automation, if you're using the 0:11:29.480000 --> 0:11:34.480000 poll model, now you are still the router, but you've got the agent software 0:11:34.480000 --> 0:11:38.100000 on you, I am the master. 0:11:38.100000 --> 0:11:40.500000 Okay, so this is like, for example, how puppet and chef works. 0:11:40.500000 --> 0:11:44.560000 You're the puppet agent, I am the puppet master. 0:11:44.560000 --> 0:11:49.260000 Well, as a puppet agent, it's your response to reach out to me, the master, 0:11:49.260000 --> 0:11:53.080000 every so often, by default, it's about every 30 minutes. 0:11:53.080000 --> 0:11:56.540000 Every 30 minutes you query me and you say, hey, Keith, has there been 0:11:56.540000 --> 0:11:59.900000 any change to my configuration file I should be aware of? 0:11:59.900000 --> 0:12:03.560000 At that point in time, I would say, yes, here's what your configuration 0:12:03.560000 --> 0:12:05.880000 file should look like. 0:12:05.880000 --> 0:12:10.240000 Now, if stuff is not all that time sensitive to you, if you're okay with 0:12:10.240000 --> 0:12:13.600000 making changes in the puppet master about what interfaces should be up 0:12:13.600000 --> 0:12:16.760000 or down, what routing protocol should be working, and you're okay that 0:12:16.760000 --> 0:12:21.020000 the fact that that change is not actually going to take effect until the 0:12:21.020000 --> 0:12:26.000000 agent pulls the master, well, then this poll model works great. 0:12:26.000000 --> 0:12:27.480000 That's the way it's designed to do. 0:12:27.480000 --> 0:12:29.660000 But I just want to make you aware of the differences here between the 0:12:29.660000 --> 0:12:33.600000 push model, which is pretty much instant changes versus the poll model 0:12:33.600000 --> 0:12:37.320000 where the agent is periodically querying the master. 0:12:37.320000 --> 0:12:40.760000 And you can see which network automation tools here use which of these 0:12:40.760000 --> 0:12:46.520000 models. Now, as I mentioned at the beginning of this video, one of the 0:12:46.520000 --> 0:12:50.060000 first things you have to do in any of these tools is to create a configuration 0:12:50.060000 --> 0:12:52.600000 file. And these go by different names. 0:12:52.600000 --> 0:12:54.400000 Sometimes they're called configuration files. 0:12:54.400000 --> 0:12:56.280000 Sometimes they're called modules. 0:12:56.280000 --> 0:12:58.040000 Sometimes they're called manifest. 0:12:58.040000 --> 0:12:59.240000 But it's the same basic idea. 0:12:59.240000 --> 0:13:03.160000 You're scripting something out that says, okay, this device right here 0:13:03.160000 --> 0:13:05.620000 should have a configuration that looks like this. 0:13:05.620000 --> 0:13:09.760000 It should be running OSPF with these IP addresses with this access list. 0:13:09.760000 --> 0:13:12.460000 Here's another configuration file for a different switch or a different 0:13:12.460000 --> 0:13:16.960000 router. That's something you have to script in advance. 0:13:16.960000 --> 0:13:20.800000 And that is really where the complexity of all these tools comes into 0:13:20.800000 --> 0:13:23.980000 play, because now you're going to have to know something like Ruby or 0:13:23.980000 --> 0:13:27.460000 YAML or something else to create those configuration files. 0:13:27.460000 --> 0:13:29.620000 And that can be a little bit complex. 0:13:29.620000 --> 0:13:33.700000 What's fortunate though, is that most of the time, you don't have to create 0:13:33.700000 --> 0:13:37.320000 a configuration file from nothing from scratch. 0:13:37.320000 --> 0:13:41.960000 All these configuration tools, puppet, chef, Ansible, they all have their 0:13:41.960000 --> 0:13:45.920000 own websites, and they all have data repositories where you can go out 0:13:45.920000 --> 0:13:50.560000 and find manifests or configuration files that other people have made. 0:13:50.560000 --> 0:13:51.880000 And then you can just tweak it. 0:13:51.880000 --> 0:13:52.740000 You can just edit it. 0:13:52.740000 --> 0:13:56.520000 So very rarely will you have to build a configuration file from absolute 0:13:56.520000 --> 0:14:00.420000 ground zero on up. 0:14:00.420000 --> 0:14:06.520000 So puppet and chef utilize their own DSLs, which is called domain specific 0:14:06.520000 --> 0:14:12.740000 languages. And some people have said that puppet and chef are much more 0:14:12.740000 --> 0:14:17.600000 complex to learn and work with because of this very reason. 0:14:17.600000 --> 0:14:20.420000 Now I don't know YAML, but what I've heard from other people, we have 0:14:20.420000 --> 0:14:22.740000 a lot of software developers here at INE. 0:14:22.740000 --> 0:14:25.060000 They say that YAML is very easy. 0:14:25.060000 --> 0:14:26.560000 It's very human readable. 0:14:26.560000 --> 0:14:29.480000 It's very easy to understand and work with YAML. 0:14:29.480000 --> 0:14:33.040000 So for that reason, a lot of people prefer Ansible and Saltstack because 0:14:33.040000 --> 0:14:36.500000 creating these initial configuration files, it's a lot easier to understand 0:14:36.500000 --> 0:14:39.340000 how they're put together and how they're formatted. 0:14:39.340000 --> 0:14:42.940000 Whereas puppet and chef, their configuration files are a little bit more 0:14:42.940000 --> 0:14:47.860000 complex to do because their language is not quite as friendly as human 0:14:47.860000 --> 0:14:52.760000 readable as what Ansible and Saltstack happen to use. 0:14:52.760000 --> 0:14:56.140000 Here's a great URL if you want to dig into this a little bit more about 0:14:56.140000 --> 0:15:01.820000 the differences between puppet, Ansible, and Salt and Chef. 0:15:01.820000 --> 0:15:04.820000 So now for the last part of this video here, for three of these protocols 0:15:04.820000 --> 0:15:08.800000 or three of these network configuration tools, I just want to talk about 0:15:08.800000 --> 0:15:10.960000 some high level concepts, some terminology. 0:15:10.960000 --> 0:15:14.660000 So if you're looking at that tool, you'll sort of understand what these 0:15:14.660000 --> 0:15:16.460000 words mean when you see it. 0:15:16.460000 --> 0:15:18.160000 So let's go into that. 0:15:18.160000 --> 0:15:21.220000 Let's start with puppet. 0:15:21.220000 --> 0:15:26.320000 So in puppet, you have the puppet master and the puppet agent. 0:15:26.320000 --> 0:15:31.880000 So the software that resides on the server that pulls the node, the router, 0:15:31.880000 --> 0:15:34.600000 the switch, the firewall is called the puppet master. 0:15:34.600000 --> 0:15:38.980000 The puppet agent is clearly the node is being pulled. 0:15:38.980000 --> 0:15:43.460000 It's that's the device that's actually being acted upon. 0:15:43.460000 --> 0:15:53.640000 Puppet modules. Now remember, a lot of these network automation tools 0:15:53.640000 --> 0:15:59.500000 originally were not developed to automate networking devices like router, 0:15:59.500000 --> 0:16:00.560000 switch, and firewalls. 0:16:00.560000 --> 0:16:03.180000 They were built to automate servers. 0:16:03.180000 --> 0:16:07.720000 Like if you have a VMware environment where you might have servers dynamically 0:16:07.720000 --> 0:16:12.900000 being virtualized, oh, I need three or four web servers built right now 0:16:12.900000 --> 0:16:16.220000 on the fly and I need them to look like this and do this type of thing 0:16:16.220000 --> 0:16:18.960000 and have this much memory and CPU. 0:16:18.960000 --> 0:16:21.440000 And then later on, I want them to go away. 0:16:21.440000 --> 0:16:23.360000 I want to free up those resources. 0:16:23.360000 --> 0:16:27.320000 A lot of these automation tools were built to do that type of thing. 0:16:27.320000 --> 0:16:30.540000 And then later on, people said, hmm, this could also be used to automate 0:16:30.540000 --> 0:16:35.720000 my network infrastructure as well as my virtualized servers. 0:16:35.720000 --> 0:16:41.940000 So these network automation tools can operate on a lot of different things, 0:16:41.940000 --> 0:16:46.340000 different types of servers, different type of operating systems. 0:16:46.340000 --> 0:16:49.760000 And when you talk about network infrastructure, you could have it operate 0:16:49.760000 --> 0:16:54.880000 on Cisco devices, Juniper devices, or Rista devices. 0:16:54.880000 --> 0:16:59.120000 So the puppet master, when you're building a manifest or building a configuration 0:16:59.120000 --> 0:17:03.480000 file, it has to know what type of device am I talking to? 0:17:03.480000 --> 0:17:08.280000 Because that will dictate what am I capable of doing to that device. 0:17:08.280000 --> 0:17:12.960000 So a puppet module gives providers and types. 0:17:12.960000 --> 0:17:17.000000 Basically, what this is talking about is that because the puppet master 0:17:17.000000 --> 0:17:22.960000 can control multiple types of agents, servers, non-Sisco networking gear, 0:17:22.960000 --> 0:17:27.460000 etc., the master has to be loaded with information about providers and 0:17:27.460000 --> 0:17:30.180000 types, which is downloaded into the modules. 0:17:30.180000 --> 0:17:34.680000 This gives puppet the ability to understand and talk to something like 0:17:34.680000 --> 0:17:38.180000 a Cisco router or Cisco switch or whatever it is that it's talking to. 0:17:38.180000 --> 0:17:43.500000 All right, the puppet manifest, that is your configuration file. 0:17:43.500000 --> 0:17:47.180000 That is what you're going to have to script out and write that's going 0:17:47.180000 --> 0:17:50.380000 to be pushed down to the puppet agent. 0:17:50.380000 --> 0:17:55.720000 And puppet forge, this is puppet's own website where people have uploaded 0:17:55.720000 --> 0:18:00.920000 their manifests, that you can get samples of them and you can edit those. 0:18:00.920000 --> 0:18:06.020000 So the puppet forge is where you can download the puppet software itself. 0:18:06.020000 --> 0:18:10.520000 And this is an example right here of a very, very simple puppet manifest. 0:18:10.520000 --> 0:18:11.900000 This is dealing with OSPF. 0:18:11.900000 --> 0:18:15.620000 You can see the first line there is creating the protocol in the first 0:18:15.620000 --> 0:18:21.120000 place. The second line is adding OSPF to a VRF and assigning some cost 0:18:21.120000 --> 0:18:25.500000 to it. And then the third section of the manifest is ensuring that a particular 0:18:25.500000 --> 0:18:30.060000 interface, interface ethernet 1 slash 2, is actually working with OSPF, 0:18:30.060000 --> 0:18:33.840000 has a certain cost and has been assigned to area 200. 0:18:33.840000 --> 0:18:37.920000 So that's an example of what a puppet, puppet manifest would look like. 0:18:37.920000 --> 0:18:41.380000 Now let's compare this stuff in these terms with another one which is 0:18:41.380000 --> 0:18:46.300000 called Chef. So what are the components of Chef? 0:18:46.300000 --> 0:18:51.700000 Well Chef has a Chef server, a workstation, and a node. 0:18:51.700000 --> 0:18:53.280000 How these work together? 0:18:53.280000 --> 0:18:57.100000 Well you would start on your Chef workstation. 0:18:57.100000 --> 0:19:01.320000 This would be like a personal computer or a virtual server where all of 0:19:01.320000 --> 0:19:06.780000 your configuration code and scripting is created, tested, and changed. 0:19:06.780000 --> 0:19:11.980000 So that's you create your configuration files on the workstation. 0:19:11.980000 --> 0:19:17.920000 Then the Chef server would manage, basically at a configuration file would 0:19:17.920000 --> 0:19:20.600000 be pushed to the Chef server. 0:19:20.600000 --> 0:19:28.220000 The Chef server in turn is pulled from the server to the node. 0:19:28.220000 --> 0:19:29.720000 So look at the flow here. 0:19:29.720000 --> 0:19:33.340000 Changes are pushed from the workstation to the server so you make your 0:19:33.340000 --> 0:19:36.620000 script, your configuration file on the workstation that's pushed to the 0:19:36.620000 --> 0:19:39.840000 server. And then this is a pull model. 0:19:39.840000 --> 0:19:41.500000 This is not a push model. 0:19:41.500000 --> 0:19:46.600000 So the node periodically has to pull the Chef server and say, hey, you 0:19:46.600000 --> 0:19:47.760000 got any changes for me? 0:19:47.760000 --> 0:19:49.180000 Is there anything I should know? 0:19:49.180000 --> 0:19:52.180000 And now the Chef server can say, oh yeah, I've got this configuration 0:19:52.180000 --> 0:19:55.640000 file that this workstation over here gave me for you. 0:19:55.640000 --> 0:19:58.140000 Let me download it to use that you're asking me. 0:19:58.140000 --> 0:20:05.540000 You'll also hear this term Chef Cookbooks and Chef Recipes. 0:20:05.540000 --> 0:20:11.260000 So a Chef Cookbook is the main software construct that gives Chef the 0:20:11.260000 --> 0:20:16.100000 knowledge necessary to speak with a specific type of device. 0:20:16.100000 --> 0:20:20.420000 For example, there's a Cisco Cookbook that allows Chef Devices to talk 0:20:20.420000 --> 0:20:22.240000 to Cisco Devices. 0:20:22.240000 --> 0:20:28.060000 And then a recipe is a subcomponent within a Cookbook that actually says, 0:20:28.060000 --> 0:20:30.400000 what do you want to do with that Cisco Device? 0:20:30.400000 --> 0:20:37.180000 So for example, if you want to tell a bunch of switches, here are the 0:20:37.180000 --> 0:20:41.760000 VLANs you need. Here's a loopback address for you. 0:20:41.760000 --> 0:20:42.840000 Here's your interfaces. 0:20:42.840000 --> 0:20:44.880000 You would create all that in a recipe. 0:20:44.880000 --> 0:20:47.040000 So you'd script that out in a recipe. 0:20:47.040000 --> 0:20:50.860000 And if those things are supposed to be applied to Cisco devices, you would 0:20:50.860000 --> 0:20:58.980000 put it in the Cisco Cookbook. 0:20:58.980000 --> 0:21:04.220000 Here's some more information about Chef and the bottom link is specific 0:21:04.220000 --> 0:21:07.120000 to Cisco and Chef. 0:21:07.120000 --> 0:21:12.560000 And just like we saw a previous configuration file for Puppet for OSPF, 0:21:12.560000 --> 0:21:15.240000 here's an example of what something similarly looks like in Chef. 0:21:15.240000 --> 0:21:18.360000 So this would be examples of Chef Recipes. 0:21:18.360000 --> 0:21:21.980000 These Chef Recipes here basically do the same type of thing. 0:21:21.980000 --> 0:21:25.000000 The one the upper left hand corner is creating OSPF. 0:21:25.000000 --> 0:21:28.400000 The one in the middle is assigning OSPF to a VRF. 0:21:28.400000 --> 0:21:32.160000 And the one on the lower right is applying OSPF and various OSPF elements 0:21:32.160000 --> 0:21:35.900000 to an interface. 0:21:35.900000 --> 0:21:40.400000 So doing basically the same thing we previously saw in Puppet, but this 0:21:40.400000 --> 0:21:44.200000 is Chef's formatting or methodology for it. 0:21:44.200000 --> 0:21:49.240000 And the last one I want to talk about, some terminology is Ansible. 0:21:49.240000 --> 0:21:55.320000 Now Ansible is probably is arguably the most popular network automation 0:21:55.320000 --> 0:21:59.140000 scripting tool when it comes to networking infrastructure devices like 0:21:59.140000 --> 0:22:00.760000 routers and switches. 0:22:00.760000 --> 0:22:05.300000 From the primarily from the standpoint that the previous ones we saw, 0:22:05.300000 --> 0:22:10.420000 Puppet and Chef typically require there to be some sort of an agent running 0:22:10.420000 --> 0:22:13.960000 on the node. So running on the Cisco router or switch, it had to have 0:22:13.960000 --> 0:22:20.260000 some Puppet or Chef software running in it as an agent that was periodically 0:22:20.260000 --> 0:22:25.080000 pulling the Puppet master or the Chef master. 0:22:25.080000 --> 0:22:29.300000 But unfortunately, as we know, a lot of networking devices don't have 0:22:29.300000 --> 0:22:34.480000 that. There's no way to install a Puppet or a Chef component within the 0:22:34.480000 --> 0:22:38.760000 software of your router or your switch or your firewall. 0:22:38.760000 --> 0:22:41.200000 Ansible does not require that. 0:22:41.200000 --> 0:22:45.640000 All Ansible requires is an Ansible master, which is running on your server. 0:22:45.640000 --> 0:22:50.900000 And the net simply just utilizes SSH to connect down to the device and 0:22:50.900000 --> 0:22:52.220000 send commands down to the device. 0:22:52.220000 --> 0:22:56.340000 So you don't have to have any special software running on your infrastructure 0:22:56.340000 --> 0:23:00.500000 components in order for them to be automated by Ansible. 0:23:00.500000 --> 0:23:04.860000 You just have to make sure that they speak SSH, they've got some SSH credentials, 0:23:04.860000 --> 0:23:07.980000 which you can then put into Ansible. 0:23:07.980000 --> 0:23:14.360000 So some other terminology here are Ansible playbooks and Ansible modules. 0:23:14.360000 --> 0:23:16.600000 Let's just make sure you understand what these are. 0:23:16.600000 --> 0:23:22.900000 So a playbook is a collection of scripts that defines the work for a server. 0:23:22.900000 --> 0:23:26.180000 What is a server going to do? 0:23:26.180000 --> 0:23:35.320000 And a module is the actual configuration that you've applied. 0:23:35.320000 --> 0:23:39.520000 So let me talk a little bit about this. 0:23:39.520000 --> 0:23:43.480000 So let's say I want to create a configuration file that once again created 0:23:43.480000 --> 0:23:48.320000 some VLANs, delete some other VLANs, applied some access lists. 0:23:48.320000 --> 0:23:51.460000 I would do all of that within the context of what's called an Ansible 0:23:51.460000 --> 0:23:56.280000 module. For example, the iOS config module is where I would go to put 0:23:56.280000 --> 0:23:58.000000 all those commands and do what I want to do. 0:23:58.000000 --> 0:23:59.660000 That would be my Ansible module. 0:23:59.660000 --> 0:24:06.660000 Now, how do I get the Ansible master to do that module to actually implement 0:24:06.660000 --> 0:24:09.240000 that module? Well, I have one of two ways. 0:24:09.240000 --> 0:24:14.040000 So in Ansible, they have ad hoc method, which simply means I log into 0:24:14.040000 --> 0:24:16.700000 the Ansible master using the command line. 0:24:16.700000 --> 0:24:21.700000 And I type in a command to say, run this module, do this right now. 0:24:21.700000 --> 0:24:22.680000 So I could do that. 0:24:22.680000 --> 0:24:26.260000 That's called ad hoc mode, where you're basically just doing it manually. 0:24:26.260000 --> 0:24:31.820000 But the real power behind network automation is that you can have your 0:24:31.820000 --> 0:24:36.840000 network automation tool run whatever you want to run whenever you want 0:24:36.840000 --> 0:24:39.580000 to run against however many nodes you want to run. 0:24:39.580000 --> 0:24:44.520000 So let's say I want to say, well, I've got all these configurations here 0:24:44.520000 --> 0:24:49.900000 created my modules, my various modules, like my Cisco iOS config module. 0:24:49.900000 --> 0:24:55.920000 Now, at 3 a.m. in the morning, well, I want this Ansible master to start 0:24:55.920000 --> 0:25:01.260000 up, connect to these 50 different devices, and run this module over and 0:25:01.260000 --> 0:25:02.900000 over against these 50 different devices. 0:25:02.900000 --> 0:25:06.640000 Well, I don't want to be an ad hoc mode to do that, because I'd have to 0:25:06.640000 --> 0:25:07.640000 wake up at 3 a.m. 0:25:07.640000 --> 0:25:09.660000 and log into the server and manually do that. 0:25:09.660000 --> 0:25:11.560000 That's where you would use a playbook. 0:25:11.560000 --> 0:25:16.900000 A playbook is what gives you the real automation functionality of Ansible. 0:25:16.900000 --> 0:25:19.860000 So the playbook interfaces with the modules. 0:25:19.860000 --> 0:25:22.420000 The playbook says these are the modules I want. 0:25:22.420000 --> 0:25:25.220000 A playbook could say, hey, I want to run that module and this one and 0:25:25.220000 --> 0:25:26.540000 this one over here. 0:25:26.540000 --> 0:25:29.960000 The playbook says I want to apply it against these five devices and then 0:25:29.960000 --> 0:25:33.300000 these four devices and here's the time of day or the day of the week I 0:25:33.300000 --> 0:25:36.420000 want to do it. So the playbook is what gives you the ability to really 0:25:36.420000 --> 0:25:40.600000 automate everything that the module has been defined to do. 0:25:40.600000 --> 0:25:45.340000 And our last thing here, I want to give you an example of what a module 0:25:45.340000 --> 0:25:54.160000 looks like once again to be able to create one of these from scratch. 0:25:54.160000 --> 0:25:56.600000 But you could take something like this, you can probably see how you could 0:25:56.600000 --> 0:26:01.620000 very easily start editing that to apply to your own environment. 0:26:01.620000 --> 0:26:07.580000 So that concludes this module on an introduction to network automation. 0:26:07.580000 --> 0:26:12.000000 And I hope that you found it interesting and useful.