In this lecture, we will see the purpose of using State in Terraform.
We already saw how Terraform uses state file
to map the resource configuration to the real world infrastructure.
This mapping allows Terraform to create execution plans,
when a drift is identified between the resource configuration files
and the state.
Hence, a state file can be considered to be a blueprint
of all the resources that are for managers out there in the real world.
When Terraform creates a resource, it records its identity in the state.
Be it the local file resource that creates a file in the machine,
a logical resource such as the random pet, which just throws out the random pet name
or resources in the cloud,
each resource created and managed by Terraform
would have a unique ID which is used to identify the resources in the real world.
Besides the mapping between resources and the configuration and the real world,
the state file also tracks metadata details such as resource dependencies.
Earlier, we learn that Terraform supports two types of dependencies,
the implicit and the explicit.
If we inspect the example configuration file,
we can see that we have three resources to provision here.
The local file resource called pet depends on the random pet resource.
This is evident from the content argument in the local file resource block
that uses a reference to the random pet resource.
The local file resource called cat is unrelated to the other
and hence it can be created in parallel with the random pet resource.
When we apply this configuration,
the random pet resource called my-pet and the local file called cat
can be created first at the same time,
but the local file resource called pet
can only be created after the random pet resource is created.
We can see that the local file with the name cat
and the random pet resource with the name my-pet are the first resources to be created.
Once that is done, only then is the local file resource called pet created.
Until now, we do not rely on state for the provisioning,
but what if we decide to delete the random pet resource
and the dependent local file from the configuration.
Let us now look at what happens when we remove resources from the file.
For example, we remove the local file and the random pet resource from the file.
If we were to apply the configuration now,
Terraform knows that it has to delete these resources.
However, in which order does it delete it?
Should it delete the random pet resource first or the local file?
The information about the resource dependency
is no longer available in the configuration file,
as we have removed those lines from it.
This is where Terraform relies on the state and the fact that it tracks metadata.
Within the state file, we can clearly see that the local file resource called pet
has a dependency on the random pet resource.
Since these two resources have now been removed from the configuration,
Terraform now knows that it should delete the local file first
followed by the random resource.
One other benefit of using state is performance.
When dealing with a handful number of resources,
it may be feasible for Terraform to reconcile state
with the real world infrastructure after every single Terraform command
such as plan or apply.
In the real world, Terraform would manage hundreds and thousands of such resources.
When these resources are distributed to multiple providers
and especially those that are on the cloud,
it is not feasible for Terraform to reconcile state
for every Terraform operation.
This is because it would take several seconds to several minutes, in some cases,
for Terraform to fetch details about every single resource from all the providers,
which are configured.
For larger infrastructures, this may prove to be too slow.
In such cases, the Terraform state can be used as the record of truth
without having to reconcile,
this would improve the performance significantly.
Terraform stores a cache of attribute values for all resources in the state.
We can specifically make Terraform to refer to the state file alone
while running commands and bypass having to refresh state every time.
To do this, we can make use of the -refresh=false flag
with all the Terraform commands that make use of state.
When we run the plan with this flag, you can see that Terraform does not refresh state.
Instead, it relies on the cache attributes
and in this example, the content which has changed in the configuration file,
and as a result, the execution plan plots a resource replacement.
The final benefit of state that we are going to look at is
collaboration when working as a team.
As we have seen in the previous lectures,
the Terraform state file is stored in the same configuration directory
in a file called terraform.tfstate.
In a normal scenario, this means that the state file resides in the folder
or a directory in the end user's laptop.
This is all right when starting off with Terraform,
learning and implementing small projects individually.
However, this is far from ideal when working as a team.
Every user in the team should always have the latest state data
before running Terraform
and make sure that nobody else runs Terraform at the same time.
Failure to do so can result in unpredictable errors as a consequence.
In such a scenario, it is highly recommended to save the Terraform state file
in a remote data store rather than to rely on a local copy.
This allows the state to be shared between all members of the team securely.
Examples of remote state stores are Amazon web service's S3 service,
HasiCorp's consul and Terraform cloud.
We will learn more about remote state stores in much more detail in a later section.
We will also learn about Terraform cloud in a separate section of its own.
Now, let's head over to the hands-on labs and explore working with Terraform state.