WEBVTT - This file was automatically generated by VIMEO 0 00:00:00.300 --> 00:00:03.600 In this lecture, let us create a new module in 1 00:00:03.600 --> 00:00:06.900 terraform and then put it to use to deploy multiple environments 2 00:00:06.900 --> 00:00:08.200 of the same infrastructure. 3 00:00:10.700 --> 00:00:13.700 Let us assume that an organization called Flex IT 4 00:00:13.700 --> 00:00:16.800 consulting has a blueprint of a prototype payroll 5 00:00:16.800 --> 00:00:19.200 software that needs to be deployed in several countries. 6 00:00:20.600 --> 00:00:24.100 Each country will have its own instance of the software deployed 7 00:00:23.100 --> 00:00:26.800 on AWS Cloud using the same architecture. 8 00:00:28.300 --> 00:00:31.900 It has a single ec2 instance using a custom Ami that 9 00:00:31.900 --> 00:00:33.200 will hold the application server. 10 00:00:34.100 --> 00:00:37.200 A dynamodb no SQL database that will be used to 11 00:00:37.200 --> 00:00:39.400 store the employee and payroll data. 12 00:00:40.400 --> 00:00:43.400 And then we have an S3 bucket, which will be used to 13 00:00:43.400 --> 00:00:46.200 store documents such as pay stubs and tax forms. 14 00:00:48.100 --> 00:00:51.600 Users access the application which is hosted on this ec2 15 00:00:51.600 --> 00:00:52.100 instance. 16 00:00:53.700 --> 00:00:56.600 This is an architecture in its most simplified form 17 00:00:56.600 --> 00:00:59.200 that uses the default VPC and does not 18 00:00:59.200 --> 00:01:02.300 consider things like VPC endpoints or I 19 00:01:02.300 --> 00:01:03.300 am rules for the services. 20 00:01:04.400 --> 00:01:07.300 The architecture diagram at a very high level looks like 21 00:01:07.300 --> 00:01:07.700 this. 22 00:01:09.400 --> 00:01:12.900 So the idea here is to create a reusable tefl 23 00:01:12.900 --> 00:01:15.300 module and use it to deploy the same stack of 24 00:01:15.300 --> 00:01:16.800 resources in different countries. 25 00:01:18.700 --> 00:01:21.300 And based on this high level architecture. We can 26 00:01:21.300 --> 00:01:23.500 create our configuration in a directory. 27 00:01:24.200 --> 00:01:27.000 Since we plan to create a module we created under the 28 00:01:27.800 --> 00:01:30.500 directory called modules. For instance. Let's use 29 00:01:30.500 --> 00:01:33.500 of the path / root terraform projects / 30 00:01:33.500 --> 00:01:34.100 modules. 31 00:01:34.900 --> 00:01:37.400 This is where we plan to store all our reusable 32 00:01:37.400 --> 00:01:37.800 modules. 33 00:01:38.900 --> 00:01:41.000 Inside this we have the resource block 34 00:01:41.300 --> 00:01:45.100 for all the required services such as the ec2 instance S3 35 00:01:44.100 --> 00:01:46.400 bucket and dynamodb. 36 00:01:47.100 --> 00:01:50.600 To ensure that we have consistent environments and 37 00:01:50.600 --> 00:01:53.300 to use a specific instance type for all the 38 00:01:53.300 --> 00:01:56.900 environments created by the module. The value of instance type 39 00:01:56.900 --> 00:01:59.300 has been hard coded into the configuration file like 40 00:01:59.300 --> 00:01:59.500 this. 41 00:02:01.100 --> 00:02:03.000 Will soon see why this is done. 42 00:02:04.400 --> 00:02:07.900 The Ami however is set to the variable called Ami 43 00:02:07.900 --> 00:02:10.500 and is user configurable based on the region 44 00:02:10.500 --> 00:02:13.700 where we want to deploy the application. Same goes 45 00:02:13.700 --> 00:02:16.300 for the tag call name here. We are 46 00:02:16.300 --> 00:02:19.500 making use of an interpolation expression to use the value 47 00:02:19.500 --> 00:02:22.300 of name which depends on the region where we 48 00:02:22.300 --> 00:02:23.500 want to deploy this application. 49 00:02:24.700 --> 00:02:27.500 Also note that an explicit dependency is defined 50 00:02:27.500 --> 00:02:30.200 in the ec2 resource block to ensure that it 51 00:02:30.200 --> 00:02:33.700 is only created after the dynamodb and the S3 52 00:02:33.700 --> 00:02:34.600 buckets are provisioned. 53 00:02:36.100 --> 00:02:39.400 And the same goes for the S3 bucket name to ensure 54 00:02:39.400 --> 00:02:42.300 that we have a globally unique name for the bucket. We are 55 00:02:42.300 --> 00:02:45.000 adding the region as a prefix for the bucket name. 56 00:02:46.400 --> 00:02:49.400 Finally the dynamodb name and the primary key 57 00:02:49.400 --> 00:02:52.300 for the table have also been assigned fixed values. 58 00:02:53.500 --> 00:02:56.900 Please note that to improve the readability the configuration 59 00:02:56.900 --> 00:02:59.000 files that you see here have been truncated. 60 00:03:03.600 --> 00:03:06.100 And a variables for this configuration would look like 61 00:03:06.100 --> 00:03:09.600 this the variables called app underscore region 62 00:03:09.600 --> 00:03:12.700 and Ami just have the variable type defined in 63 00:03:12.700 --> 00:03:13.000 the block. 64 00:03:13.700 --> 00:03:16.300 The variable called bucket. However has a 65 00:03:16.300 --> 00:03:17.800 default value assigned to it as well. 66 00:03:18.800 --> 00:03:21.500 These variables have been used in the configuration files 67 00:03:21.500 --> 00:03:22.200 that we just saw. 68 00:03:25.400 --> 00:03:28.800 Now, let's deploy an instance of this application stack 69 00:03:28.800 --> 00:03:31.200 first in the US each one 70 00:03:31.200 --> 00:03:31.500 region. 71 00:03:32.200 --> 00:03:35.500 To do this. Let us create another directory called us 72 00:03:35.500 --> 00:03:38.300 payroll app and inside this directory. We 73 00:03:38.300 --> 00:03:41.400 create a main.tf file with the contents like this. 74 00:03:42.200 --> 00:03:45.400 Here we will make use of the module block and specify the 75 00:03:45.400 --> 00:03:48.400 path to the payroll app module that we created earlier. 76 00:03:49.400 --> 00:03:52.600 To make sure that we deploy to the US East one 77 00:03:52.600 --> 00:03:55.200 region and use the custom Ami ID in 78 00:03:55.200 --> 00:03:58.400 that region. We can specify the app underscore region 79 00:03:58.400 --> 00:04:01.000 and the Ami in a root module like this. 80 00:04:02.400 --> 00:04:05.600 And that's it. Since this is our working configuration 81 00:04:05.600 --> 00:04:09.000 directory the path / root slash terraform 82 00:04:08.200 --> 00:04:11.400 project / us payroll app 83 00:04:11.400 --> 00:04:14.700 is now the root module and the modules directory 84 00:04:14.700 --> 00:04:17.300 which is modules / payroll app, 85 00:04:17.300 --> 00:04:20.400 which is used as the source is the child module. 86 00:04:21.400 --> 00:04:24.400 You would have noticed that the only configurable value in 87 00:04:24.400 --> 00:04:27.600 this main.ta file is the app region and 88 00:04:27.600 --> 00:04:28.500 the Ami ID. 89 00:04:30.200 --> 00:04:33.600 We can also optionally provide a specific value for the bucket argument. 90 00:04:33.600 --> 00:04:36.400 But if it is not it'll take the default value 91 00:04:36.400 --> 00:04:40.200 that was set at the module level which in this case is flexit 92 00:04:39.600 --> 00:04:42.700 - payroll Dash Alpha - 93 00:04:42.700 --> 00:04:44.300 22001c 94 00:04:46.300 --> 00:04:49.100 We do not want the instance type the Dynamo DB name 95 00:04:49.100 --> 00:04:52.400 and the primary key to change and this is why we have hardcore 96 00:04:52.400 --> 00:04:54.200 to the values in the module configuration. 97 00:04:57.300 --> 00:05:00.300 With just this module block. Our configuration file is 98 00:05:00.300 --> 00:05:02.100 now complete and ready to be applied. 99 00:05:02.800 --> 00:05:05.200 If you enter from in it now, we'll see 100 00:05:05.200 --> 00:05:08.300 that terraform downloads the module from Source along with 101 00:05:08.300 --> 00:05:10.800 the AWS plugin, which is used by that module. 102 00:05:12.400 --> 00:05:16.000 A plan followed by apply will show that the dynamodb table 103 00:05:15.400 --> 00:05:19.000 the S3 bucket and the AWS ec2 104 00:05:18.400 --> 00:05:20.100 instance are created. 105 00:05:21.400 --> 00:05:24.500 Observe that the dynamodb table name the primary key and 106 00:05:24.500 --> 00:05:27.600 the instance type for the ec2 instance take values 107 00:05:27.600 --> 00:05:29.600 that we have defined at the child module. 108 00:05:30.700 --> 00:05:33.200 The bucket name and the Ami ID on 109 00:05:33.200 --> 00:05:36.300 the other hand makes use of the values that we have defined in 110 00:05:36.300 --> 00:05:37.100 the root module. 111 00:05:40.400 --> 00:05:43.700 To deploy the same stack in the UK region. Let's create 112 00:05:43.700 --> 00:05:46.400 another directory called UK payroll app. 113 00:05:47.200 --> 00:05:50.600 We then follow the same process of creating a main.tf file 114 00:05:50.600 --> 00:05:53.900 and then make use of the same module block inside this 115 00:05:53.900 --> 00:05:57.400 module block. We use the value of Euless 2 116 00:05:57.400 --> 00:06:00.700 for the app region. We have also changed the Ami ID 117 00:06:00.700 --> 00:06:03.000 to select the one that's available in this region. 118 00:06:03.900 --> 00:06:06.600 Running the terraform workflow now will create 119 00:06:06.600 --> 00:06:09.600 the exact same stack but in the London region. 120 00:06:10.800 --> 00:06:13.500 Notice that the name of the S3 bucket created now 121 00:06:13.500 --> 00:06:16.300 has the prefix of EU waste 2. 122 00:06:16.900 --> 00:06:19.300 Since we are making 123 00:06:19.300 --> 00:06:22.600 use of a module the dynamodb table resource 124 00:06:22.600 --> 00:06:25.600 that has been created is now identified by the addressing 125 00:06:25.600 --> 00:06:26.900 syntax that goes like this. 126 00:06:27.800 --> 00:06:30.500 First comes the module address, which is the keyword 127 00:06:30.500 --> 00:06:33.200 module followed by the module name, which is 128 00:06:33.200 --> 00:06:34.500 separated by a DOT. 129 00:06:35.400 --> 00:06:38.300 Next comes the resource address, which is the resource type followed by 130 00:06:38.300 --> 00:06:40.800 the resource name also separated by a DOT. 131 00:06:42.100 --> 00:06:45.100 So in this example the dynamodb table resource in 132 00:06:45.100 --> 00:06:48.900 the root module can be addressed as module dot us 133 00:06:48.900 --> 00:06:51.900 payroll dot AWS dynamodb table 134 00:06:51.900 --> 00:06:53.700 dot payroll DB. 135 00:06:56.600 --> 00:06:59.400 We have now successfully created a terraform module 136 00:06:59.400 --> 00:07:02.600 and use it to deploy multiple instances of our application 137 00:07:02.600 --> 00:07:03.800 in different regions. 138 00:07:04.900 --> 00:07:07.100 Modules are comparable to libraries or 139 00:07:07.100 --> 00:07:09.900 packages that are used in most programming languages. 140 00:07:10.700 --> 00:07:13.900 This brings in a lot of benefits such as simpler configuration 141 00:07:13.900 --> 00:07:16.300 instead of having configuration files that 142 00:07:16.300 --> 00:07:18.800 contain hundreds and thousands of lines of code. 143 00:07:19.800 --> 00:07:22.300 Our root module now is very short easy to 144 00:07:22.300 --> 00:07:23.400 understand and manage. 145 00:07:24.200 --> 00:07:27.600 Using a pre-configured module that has been tested and validated 146 00:07:27.600 --> 00:07:30.600 also decreases the risk of human errors resulting 147 00:07:30.600 --> 00:07:32.300 in inconsistent environments. 148 00:07:33.500 --> 00:07:36.400 As we just saw the same module can be used to deploy 149 00:07:36.400 --> 00:07:39.500 the infrastructure in different regions. Thereby improving 150 00:07:39.500 --> 00:07:41.300 the reusability of our code. 151 00:07:42.200 --> 00:07:45.200 And finally by making sure that certain aspects of 152 00:07:45.200 --> 00:07:48.200 our configuration are fixed such as the dynamodb table 153 00:07:48.200 --> 00:07:51.400 name the primary key and the instance type which are 154 00:07:51.400 --> 00:07:54.000 not user configurable from the root module. We can 155 00:07:54.200 --> 00:07:57.400 make sure that the provisioning process maintains a standard configuration. 156 00:07:59.300 --> 00:08:02.300 That's it for this lecture in the next one. We'll see how to make 157 00:08:02.300 --> 00:08:05.000 use of modules from the public terraform registry.