WEBVTT - This file was automatically generated by VIMEO 0 00:00:00.300 --> 00:00:03.600 In this section, we will learn what modules are and 1 00:00:03.600 --> 00:00:06.300 how to use them within our terraform configuration. 2 00:00:07.900 --> 00:00:10.300 While progressing through the course you'd have 3 00:00:10.300 --> 00:00:13.600 noticed that our terraform configuration files have become increasingly 4 00:00:13.600 --> 00:00:14.000 long. 5 00:00:14.800 --> 00:00:17.600 We started off with resources such as the local file 6 00:00:17.600 --> 00:00:20.500 and the random pet to begin with but since 7 00:00:20.500 --> 00:00:23.400 the beginning of the AWS section, we have been deploying. 8 00:00:23.400 --> 00:00:26.900 I am rules policies S3 buckets 9 00:00:26.900 --> 00:00:29.500 dynamodb tables and easy to instances 10 00:00:29.500 --> 00:00:30.200 to name a few. 11 00:00:30.900 --> 00:00:33.200 For example the resource blocks that 12 00:00:33.200 --> 00:00:36.400 we see here have the definition for two easy to instances 13 00:00:36.400 --> 00:00:39.400 a key pair a security group and a 14 00:00:39.400 --> 00:00:40.300 dynamodb database. 15 00:00:41.300 --> 00:00:44.600 The two ec2 instances can be quite similar with 16 00:00:44.600 --> 00:00:47.700 much of their code being duplicated between the two configuration 17 00:00:47.700 --> 00:00:48.200 blocks. 18 00:00:49.400 --> 00:00:52.600 When dealing with large infrastructure projects with hundreds 19 00:00:52.600 --> 00:00:55.600 of resources, we can still opt to write the configuration 20 00:00:55.600 --> 00:00:58.600 with an a single file like this terraform does 21 00:00:58.600 --> 00:01:01.600 not impose any limit on the number of resources per 22 00:01:01.600 --> 00:01:04.300 configuration file. However, this would mean 23 00:01:04.300 --> 00:01:07.300 that our configuration file will contain hundreds to 24 00:01:07.300 --> 00:01:09.500 thousands of lines of code within no time. 25 00:01:10.500 --> 00:01:13.900 Alternatively, we can also split the configuration into 26 00:01:13.900 --> 00:01:16.800 multiple files within the configuration directory and 27 00:01:16.800 --> 00:01:18.300 things will work the same way. 28 00:01:19.600 --> 00:01:22.300 We saw earlier that terraform will consider every 29 00:01:22.300 --> 00:01:25.600 file within the configuration directory as a configuration file 30 00:01:25.600 --> 00:01:28.700 as long as it has the dot DF extension. 31 00:01:29.700 --> 00:01:32.300 While this would organize arter from code a 32 00:01:32.300 --> 00:01:35.700 bit better as compared to writing it all in a single configuration 33 00:01:35.700 --> 00:01:38.900 file. There are still a lot of disadvantages in 34 00:01:38.900 --> 00:01:41.200 following this approach when implementing terraform 35 00:01:42.400 --> 00:01:45.400 For starters, it does not fix the complexity of 36 00:01:45.400 --> 00:01:48.700 the code that is written within the configuration directory or 37 00:01:48.700 --> 00:01:50.200 the problem of duplication. 38 00:01:51.300 --> 00:01:54.300 Due to the complexity of the configuration. It also 39 00:01:54.300 --> 00:01:57.000 becomes increasingly difficult to update a resource. 40 00:01:57.500 --> 00:02:00.200 Updates to one part of the configuration can have 41 00:02:00.200 --> 00:02:02.400 unintended effects on other resources. 42 00:02:03.200 --> 00:02:06.800 And finally this configuration severely limits the reusability. 43 00:02:07.900 --> 00:02:10.400 If you want to share a part of this code with 44 00:02:10.400 --> 00:02:13.400 a teammate for instance, the only plausible way would 45 00:02:13.400 --> 00:02:16.400 be to copy and paste the relevant part of the code, which can 46 00:02:16.400 --> 00:02:17.500 be prone to errors. 47 00:02:18.400 --> 00:02:21.500 These problems can be addressed by making use of modules 48 00:02:21.500 --> 00:02:22.400 in terraform. 49 00:02:24.600 --> 00:02:27.500 Funnily enough module Is Not A New Concept and it 50 00:02:27.500 --> 00:02:30.200 is something that we have been using all throughout this course. 51 00:02:31.100 --> 00:02:34.800 Any configuration directory containing a set of configuration files 52 00:02:34.800 --> 00:02:36.400 is called a module. 53 00:02:37.500 --> 00:02:40.700 For example, let us consider a configuration directory called 54 00:02:40.700 --> 00:02:43.100 AWS instance in our local machine. 55 00:02:44.300 --> 00:02:47.800 This directory is created under slash root terraform projects. 56 00:02:48.600 --> 00:02:51.400 This directory has terraform configuration files that 57 00:02:51.400 --> 00:02:54.100 is used to create a simple ec2 instance in the 58 00:02:54.100 --> 00:02:55.800 AWS Cloud as shown here. 59 00:02:57.300 --> 00:03:00.300 Since this directory has the terraform configuration files. It is 60 00:03:00.300 --> 00:03:01.300 also a module. 61 00:03:02.600 --> 00:03:05.400 If we directly run Tera from commands from within 62 00:03:05.400 --> 00:03:08.800 this directory as we've been doing so far this directory 63 00:03:08.800 --> 00:03:10.600 is considered to be the root module. 64 00:03:11.900 --> 00:03:14.300 But how does this address the issues that we 65 00:03:14.300 --> 00:03:15.000 just discussed? 66 00:03:16.200 --> 00:03:19.500 Let us consider a use case where we want to make use of 67 00:03:19.500 --> 00:03:22.600 the quote written inside AWS instance directory 68 00:03:22.600 --> 00:03:25.500 to create a new development web server instance. 69 00:03:26.400 --> 00:03:30.000 For this let us create a new directory called development within 70 00:03:29.100 --> 00:03:31.600 the terraform projects directory. 71 00:03:32.400 --> 00:03:35.200 Now instead of writing the configuration for 72 00:03:35.200 --> 00:03:38.600 creating the dev AWS instance from scratch or copy 73 00:03:38.600 --> 00:03:41.300 and paste the code. We can use a module block 74 00:03:41.300 --> 00:03:45.100 to use the code, which is already inside the AWS instance 75 00:03:44.100 --> 00:03:45.500 directory. 76 00:03:46.800 --> 00:03:49.600 To do this inside the development directory create 77 00:03:49.600 --> 00:03:52.700 a configuration file containing a module block like 78 00:03:52.700 --> 00:03:52.800 this. 79 00:03:53.700 --> 00:03:56.400 Within this module block, we can provide the path 80 00:03:56.400 --> 00:03:59.600 to the local AWS instance directory which contains 81 00:03:59.600 --> 00:04:02.500 the actual terraform configuration to create the ec2 82 00:04:02.500 --> 00:04:02.900 instance. 83 00:04:04.300 --> 00:04:07.500 Since our configuration directory where we will be running terraform 84 00:04:07.500 --> 00:04:10.600 commands is now the development directory. It becomes 85 00:04:10.600 --> 00:04:13.500 the root module and the AWS instance directory 86 00:04:13.500 --> 00:04:16.200 that we are calling from within our main.tf file 87 00:04:16.200 --> 00:04:18.400 is considered to be the child module. 88 00:04:20.400 --> 00:04:22.900 Let us inspect the syntax of the module block closely. 89 00:04:24.400 --> 00:04:27.500 We use the module keyword followed by The Logical name 90 00:04:27.500 --> 00:04:30.500 of the module. In this case. We have called it Dev 91 00:04:30.500 --> 00:04:31.200 web server. 92 00:04:32.500 --> 00:04:35.300 Inside the module block. We have one required argument, which 93 00:04:35.300 --> 00:04:36.000 is the source. 94 00:04:36.600 --> 00:04:39.200 This is the path where the child module is stored. 95 00:04:41.100 --> 00:04:44.300 Make a note that in this example the path for the child 96 00:04:44.300 --> 00:04:47.500 module is specified as a relative path with respect to 97 00:04:47.500 --> 00:04:50.300 the configuration directory or the root module which in 98 00:04:50.300 --> 00:04:52.100 this case is the development directory. 99 00:04:53.800 --> 00:04:56.300 This could also have been the absolute part to 100 00:04:56.300 --> 00:04:59.500 the child module. We just happen to be using the relative part 101 00:04:59.500 --> 00:05:00.200 in this example. 102 00:05:02.200 --> 00:05:05.500 In this case the child module which is the directory called 103 00:05:05.500 --> 00:05:08.800 AWS instance is located under the terraform projects 104 00:05:08.800 --> 00:05:11.500 directory just like our configuration directory. 105 00:05:12.300 --> 00:05:15.200 This part can be defined as a relative path from 106 00:05:15.200 --> 00:05:18.500 the development directory by making use of two dots followed 107 00:05:18.500 --> 00:05:21.000 by the directory name, which is AWS instance. 108 00:05:21.500 --> 00:05:24.300 The Source path for the module can hence be declared as 109 00:05:24.300 --> 00:05:26.800 dot dot slash AWS instance 110 00:05:28.100 --> 00:05:31.500 Well, that's it for this lecture in the upcoming lecture. 111 00:05:31.500 --> 00:05:34.200 We'll learn how to create our own module and use 112 00:05:34.200 --> 00:05:35.200 it within terraform.