WEBVTT 00:00.220 --> 00:04.620 In this lecture, we will see the purpose of using State in Terraform. 00:05.380 --> 00:07.920 We already saw how Terraform uses state file 00:07.920 --> 00:11.380 to map the resource configuration to the real world infrastructure. 00:12.340 --> 00:15.440 This mapping allows Terraform to create execution plans, 00:15.440 --> 00:18.840 when a drift is identified between the resource configuration files 00:18.840 --> 00:19.900 and the state. 00:20.540 --> 00:23.600 Hence, a state file can be considered to be a blueprint 00:23.600 --> 00:27.740 of all the resources that are for managers out there in the real world. 00:28.720 --> 00:32.860 When Terraform creates a resource, it records its identity in the state. 00:33.280 --> 00:36.780 Be it the local file resource that creates a file in the machine, 00:36.780 --> 00:41.680 a logical resource such as the random pet, which just throws out the random pet name 00:41.680 --> 00:43.580 or resources in the cloud, 00:43.880 --> 00:46.460 each resource created and managed by Terraform 00:46.460 --> 00:51.220 would have a unique ID which is used to identify the resources in the real world. 00:52.300 --> 00:56.400 Besides the mapping between resources and the configuration and the real world, 00:56.400 --> 01:00.860 the state file also tracks metadata details such as resource dependencies. 01:02.040 --> 01:05.840 Earlier, we learn that Terraform supports two types of dependencies, 01:06.160 --> 01:08.320 the implicit and the explicit. 01:08.960 --> 01:11.720 If we inspect the example configuration file, 01:11.720 --> 01:15.080 we can see that we have three resources to provision here. 01:15.320 --> 01:19.580 The local file resource called pet depends on the random pet resource. 01:19.820 --> 01:23.500 This is evident from the content argument in the local file resource block 01:23.500 --> 01:26.480 that uses a reference to the random pet resource. 01:27.240 --> 01:30.920 The local file resource called cat is unrelated to the other 01:30.920 --> 01:35.040 and hence it can be created in parallel with the random pet resource. 01:36.200 --> 01:38.160 When we apply this configuration, 01:38.160 --> 01:41.860 the random pet resource called my-pet and the local file called cat 01:41.860 --> 01:44.580 can be created first at the same time, 01:44.880 --> 01:47.140 but the local file resource called pet 01:47.140 --> 01:50.680 can only be created after the random pet resource is created. 01:51.740 --> 01:54.360 We can see that the local file with the name cat 01:54.360 --> 01:59.280 and the random pet resource with the name my-pet are the first resources to be created. 02:00.240 --> 02:05.240 Once that is done, only then is the local file resource called pet created. 02:05.940 --> 02:09.400 Until now, we do not rely on state for the provisioning, 02:09.720 --> 02:13.060 but what if we decide to delete the random pet resource 02:13.060 --> 02:16.340 and the dependent local file from the configuration. 02:17.540 --> 02:21.440 Let us now look at what happens when we remove resources from the file. 02:21.440 --> 02:26.440 For example, we remove the local file and the random pet resource from the file. 02:27.080 --> 02:29.400 If we were to apply the configuration now, 02:29.400 --> 02:32.180 Terraform knows that it has to delete these resources. 02:32.360 --> 02:35.360 However, in which order does it delete it? 02:35.780 --> 02:39.600 Should it delete the random pet resource first or the local file? 02:40.200 --> 02:42.440 The information about the resource dependency 02:42.440 --> 02:44.960 is no longer available in the configuration file, 02:45.080 --> 02:47.100 as we have removed those lines from it. 02:48.360 --> 02:53.080 This is where Terraform relies on the state and the fact that it tracks metadata. 02:53.620 --> 02:58.160 Within the state file, we can clearly see that the local file resource called pet 02:58.160 --> 03:00.720 has a dependency on the random pet resource. 03:01.260 --> 03:04.620 Since these two resources have now been removed from the configuration, 03:04.620 --> 03:07.880 Terraform now knows that it should delete the local file first 03:07.880 --> 03:09.880 followed by the random resource. 03:11.140 --> 03:14.400 One other benefit of using state is performance. 03:14.780 --> 03:17.600 When dealing with a handful number of resources, 03:17.600 --> 03:20.280 it may be feasible for Terraform to reconcile state 03:20.280 --> 03:23.640 with the real world infrastructure after every single Terraform command 03:23.640 --> 03:25.300 such as plan or apply. 03:26.080 --> 03:30.400 In the real world, Terraform would manage hundreds and thousands of such resources. 03:30.600 --> 03:33.820 When these resources are distributed to multiple providers 03:33.820 --> 03:35.840 and especially those that are on the cloud, 03:35.840 --> 03:38.400 it is not feasible for Terraform to reconcile state 03:38.400 --> 03:40.400 for every Terraform operation. 03:40.740 --> 03:44.900 This is because it would take several seconds to several minutes, in some cases, 03:44.900 --> 03:48.880 for Terraform to fetch details about every single resource from all the providers, 03:48.880 --> 03:50.020 which are configured. 03:50.980 --> 03:54.220 For larger infrastructures, this may prove to be too slow. 03:54.740 --> 03:58.720 In such cases, the Terraform state can be used as the record of truth 03:58.720 --> 04:00.440 without having to reconcile, 04:00.640 --> 04:03.420 this would improve the performance significantly. 04:04.260 --> 04:08.580 Terraform stores a cache of attribute values for all resources in the state. 04:09.120 --> 04:12.820 We can specifically make Terraform to refer to the state file alone 04:12.820 --> 04:16.980 while running commands and bypass having to refresh state every time. 04:17.400 --> 04:21.880 To do this, we can make use of the -refresh=false flag 04:21.880 --> 04:25.180 with all the Terraform commands that make use of state. 04:26.420 --> 04:31.200 When we run the plan with this flag, you can see that Terraform does not refresh state. 04:31.300 --> 04:33.980 Instead, it relies on the cache attributes 04:34.080 --> 04:38.020 and in this example, the content which has changed in the configuration file, 04:38.760 --> 04:42.980 and as a result, the execution plan plots a resource replacement. 04:44.040 --> 04:47.300 The final benefit of state that we are going to look at is 04:47.300 --> 04:49.400 collaboration when working as a team. 04:50.120 --> 04:52.020 As we have seen in the previous lectures, 04:52.020 --> 04:55.560 the Terraform state file is stored in the same configuration directory 04:55.560 --> 04:58.220 in a file called terraform.tfstate. 04:58.780 --> 05:02.860 In a normal scenario, this means that the state file resides in the folder 05:02.860 --> 05:05.520 or a directory in the end user's laptop. 05:06.060 --> 05:08.580 This is all right when starting off with Terraform, 05:08.580 --> 05:11.340 learning and implementing small projects individually. 05:11.580 --> 05:15.000 However, this is far from ideal when working as a team. 05:15.680 --> 05:19.540 Every user in the team should always have the latest state data 05:19.540 --> 05:20.700 before running Terraform 05:20.760 --> 05:24.400 and make sure that nobody else runs Terraform at the same time. 05:25.180 --> 05:29.680 Failure to do so can result in unpredictable errors as a consequence. 05:30.320 --> 05:35.120 In such a scenario, it is highly recommended to save the Terraform state file 05:35.120 --> 05:39.040 in a remote data store rather than to rely on a local copy. 05:39.300 --> 05:43.560 This allows the state to be shared between all members of the team securely. 05:44.020 --> 05:48.660 Examples of remote state stores are Amazon web service's S3 service, 05:48.660 --> 05:51.360 HasiCorp's consul and Terraform cloud. 05:51.480 --> 05:55.700 We will learn more about remote state stores in much more detail in a later section. 05:55.920 --> 05:59.640 We will also learn about Terraform cloud in a separate section of its own. 06:00.740 --> 06:05.680 Now, let's head over to the hands-on labs and explore working with Terraform state.