In this lecture, we will learn how to make use of an S3 bucket
and a DynamoDB table to configure a remote backend
for our terraform configuration.
For this, we need two things,
an S3 bucket which will be used to store the terraform state file
and a DynamoDB table which will be used to implement state locking
and consistency checks.
First, make sure that these two prerequisites have been completed
before beginning to configure a remote backend.
After these two services have been created,
keep a note of the bucket name, the key to be used, the region,
and the name of the DynamoDB table.
Now let's go over to our configuration directory.
We have a main.tf file that creates a local file resource.
When we run terraform apply, the resource is created
and as expected, terraform creates a local state file called terraform.tfstate.
To configure a remote backend in terraform,
we must define additional settings by making use of the terraform block.
As a recap, we have already used the terraform block once
when we wanted a specific version of the provider plugin
to be used within our configuration.
In this case, we want to configure a remote backend for storing the state file
and for that, the terraform block should now look like this.
Within the terraform block, we specify another block called backend.
Here, we provide the values we recorded as part of the prerequisite step.
The backend name specifies the type of the backend that we want to use
and for making use of an AWS S3 as the backend, we use the name S3.
The backend block with S3 expects three arguments.
First is the name of the existing S3 bucket.
Next is the key, which is an S3 object part where the state file should be stored.
In this case, we want to store the terraform state file within a folder called finance,
and this folder should exist within a bucket called kodekloud-terraform-state-bucket01.
The final argument that is required is the region.
This is the region where the S3 bucket has been created
and in this example, it is set to US-West-1.
In order to achieve state locking, we can optionally provide a DynamoDB table.
This table should have a primary or a hash key with the name lockID.
We have already created a DynamoDB table called state-locking for this purpose.
As a standard practice, let's not store the terraform block inside the main.tf file,
instead, let's move it to a separate file called terraform.tf.
We now have the infrastructure configuration and the backend configuration
segregated into main.tf and terraform.tf file respectively.
The terraform state is now configured to be stored in a remote S3 bucket.
However, if we run the terraform apply command now,
we will see an error that says backend reinitialization required.
Running the terraform init command will initialize the new backend to be used.
Since we already have a local state file in the configuration directory
the init process gives us an option to copy the terraform state file
into the remote S3 backend.
Giving a value of yes will copy the state file to the S3 bucket.
We can now delete the local state file from the configuration directory.
Running a terraform plan or apply now will lock the state file
and pull it down from the S3 bucket into the memory.
Any subsequent changes to the state will be uploaded to the backend instantaneously
and once the operation is complete, the lock will be released.
The state file will not be stored in the local configuration directory anymore.
That's it for this lecture.
Let's head over to the hands-on labs
and practice working with remote backends in terraform.