WEBVTT 1 00:00.000 --> 00:04.560 So friends, let me talk you through my solution to this particular problem. 2 00:04.560 --> 00:09.440 So here it is, we are managing a network of around 1000 devices spanning three 3 00:09.440 --> 00:10.240 different countries. 4 00:10.240 --> 00:15.370 Now this part here is really quite relevant. A large proportion of the devices 5 00:15.370 --> 00:17.520 are 15 years old or more. 6 00:17.520 --> 00:22.960 So I'm thinking are these devices really equipped to handle model automation? 7 00:22.960 --> 00:26.720 Or are they more likely to be a little bit more limited in that respect? 8 00:26.720 --> 00:30.640 Yeah, I would kind of say so that is more likely the case. So I'm already WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:26.720 --> 00:30.640 Yeah, I would kind of say so that is more likely the case. So I'm already 9 00:30.640 --> 00:33.200 thinking here about a solution 10 00:33.200 --> 00:38.720 that is agentless i.e. we don't have to install any particular fancy software 11 00:38.720 --> 00:40.000 on these old devices. 12 00:40.000 --> 00:44.320 Now it does say here that currently configuration changes are made manually 13 00:44.320 --> 00:46.080 over SSH. So we do have 14 00:46.080 --> 00:50.900 SSH connectivity to these devices. And also here is the next important part. 15 00:50.900 --> 00:52.240 Nobody on the team has 16 00:52.240 --> 00:56.160 any experience writing code. This can be a little bit of a limiting factor. 17 00:56.160 --> 00:57.520 Despite this, your team 18 00:57.520 --> 01:01.420 leader would like you to introduce automation. So which automation tool are you WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:57.520 --> 01:01.420 leader would like you to introduce automation. So which automation tool are you 19 01:01.420 --> 01:02.720 going to recommend 20 01:02.720 --> 01:07.910 and why? Now it may not be such a surprise to you to learn that the utility 21 01:07.910 --> 01:08.640 that I'm suggesting 22 01:08.640 --> 01:12.400 is going to be Ansible. Now if you two also suggested Ansible, then I think 23 01:12.400 --> 01:13.520 that's a good idea. 24 01:13.520 --> 01:18.520 However, I am more really curious not just about the tool that you chose but 25 01:18.520 --> 01:19.600 why you chose that 26 01:19.600 --> 01:24.800 specifically. For me, the very fact that nobody in the team has any experience 27 01:24.800 --> 01:25.840 writing code, Ansible 28 01:25.840 --> 01:30.150 for me is a very, very good shout because we can interact with, well, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:25.840 --> 01:30.150 for me is a very, very good shout because we can interact with, well, 29 01:30.150 --> 01:32.160 underlying Python code via 30 01:32.160 --> 01:36.940 this Yamel abstraction layer. Now Yamel is very, very human readable. It really 31 01:36.940 --> 01:37.840 lowers the barrier 32 01:37.840 --> 01:42.480 of entry. So this to me already is much better than trying to write some unique 33 01:42.480 --> 01:43.680 Python code yourself 34 01:43.680 --> 01:48.080 and connecting to the device over some type of SSH channel. You know, that can 35 01:48.080 --> 01:49.280 be done. But this part 36 01:49.280 --> 01:53.750 here, the lack of experience really is a limiting factor and Ansible does help 37 01:53.750 --> 01:55.520 solve that. Now obviously 38 01:55.520 --> 02:00.540 Ansible is an agent less solution, which also ties into the fact that these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:55.520 --> 02:00.540 Ansible is an agent less solution, which also ties into the fact that these 39 02:00.540 --> 02:02.160 devices are 15 years old 40 02:02.160 --> 02:06.830 or more and Ansible supports SSH connectivity. So straight away despite the 41 02:06.830 --> 02:07.760 fact that these are 42 02:07.760 --> 02:11.010 old machines and are going to be administered by people with limited code and 43 02:11.010 --> 02:12.000 experience or no 44 02:12.000 --> 02:15.870 code and experience rather should I say Ansible is not shutting off any doors 45 02:15.870 --> 02:16.640 to us right here. So this 46 02:16.640 --> 02:21.060 is a good, good sign. Now as it says here, many of the configurations are 47 02:21.060 --> 02:22.800 location specific. So for 48 02:22.800 --> 02:27.350 example, some configurations should only be applied to particular devices in 49 02:27.350 --> 02:28.960 one particular time. 50 02:28.960 --> 02:33.760 So specifically, some configurations are only going to be applied to particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:28.960 --> 02:33.760 So specifically, some configurations are only going to be applied to particular 51 02:33.760 --> 02:34.880 devices in one 52 02:34.880 --> 02:38.370 particular country. So how would the solution that you are suggesting solve for 53 02:38.370 --> 02:39.040 this particular 54 02:39.040 --> 02:43.840 problem? Well, as we know Ansible actually gives us access to an inventory. So 55 02:43.840 --> 02:44.640 what we can do is we 56 02:44.640 --> 02:50.080 can logically segment our devices and make sure that within our inventory, we 57 02:50.080 --> 02:52.160 actually have location 58 02:52.160 --> 02:57.210 specific groups. So we would actually have a UK group or rather not a UK group 59 02:57.210 --> 02:58.240 forget that. We 60 02:58.240 --> 03:03.580 would have a USA group as well as a Brazilian group and a German group. Now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 02:58.240 --> 03:03.580 would have a USA group as well as a Brazilian group and a German group. Now 61 03:03.580 --> 03:05.440 because of this, we can 62 03:05.440 --> 03:10.680 then subdivide our 1000 devices into their respective camps, whether they're in 63 03:10.680 --> 03:11.920 the USA, Brazil or 64 03:11.920 --> 03:16.070 Germany. Now when we want to actually connect these devices within our playbook 65 03:16.070 --> 03:17.520 , we just use the host 66 03:17.520 --> 03:21.220 keyword and just point it to a particular group and we can now target that 67 03:21.220 --> 03:22.400 particular subset of 68 03:22.400 --> 03:26.640 devices within our management. The devices dependent on that particular 69 03:26.640 --> 03:28.480 location you want to target 70 03:28.480 --> 03:32.690 and not just that. If you want to utilize some particular configurations that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 03:28.480 --> 03:32.690 and not just that. If you want to utilize some particular configurations that 71 03:32.690 --> 03:33.440 are location 72 03:33.440 --> 03:37.700 specific, then we also have the ability to utilize things like group bars. So 73 03:37.700 --> 03:38.720 we would have an 74 03:38.720 --> 03:42.820 American group variable file, a Brazilian group variable file, Andy German 75 03:42.820 --> 03:44.080 group variable file, 76 03:44.080 --> 03:48.540 and we can easily suck in these values depending on their membership to that 77 03:48.540 --> 03:49.520 particular location. 78 03:49.520 --> 03:55.160 And again, we still have the flexibility to override those values with these 79 03:55.160 --> 03:56.800 host specific values. 80 03:56.800 --> 04:00.290 So even though we have these groups, we are not tied down and bogged down with WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 80 03:56.800 --> 04:00.290 So even though we have these groups, we are not tied down and bogged down with 81 04:00.290 --> 04:01.200 them. Ultimately, 82 04:01.200 --> 04:04.940 we still have full flexibility. So for me, once again, this is just a very good 83 04:04.940 --> 04:06.000 reason why Ansible 84 04:06.000 --> 04:10.000 does shine in this particular example, I think it's a very good solution. But 85 04:10.000 --> 04:10.880 for whatever reason, 86 04:10.880 --> 04:14.840 if you got a different solution or perhaps maybe parts of the question confused 87 04:14.840 --> 04:15.040 you, 88 04:15.040 --> 04:19.200 then a good idea would be to try to rewatch this skill and just give yourself a 89 04:19.200 --> 04:20.000 little bit more time 90 04:20.000 --> 04:24.320 for these concepts to sink in. But for now, that is us for our validation 91 04:24.320 --> 04:25.600 section on configuration 92 04:25.600 --> 04:28.970 management. I hope it's been informative for you and I'd like to thank you for 93 04:28.970 --> 04:29.600 viewing.