Table of Contents

1. Terraform State File

2. Remote Back-End

3. State Lock

4. Hands-on Practice

Terraform State file

• As a DevOps engineer, when you write a Terraform configuration to create resources like instances, storage, network components, databases, etc., Terraform interacts with your chosen cloud provider to provision these resources according to your specifications..

• Now, imagine you later decide to modify the instance configuration. If the Terraform state file is missing or not used, Terraform would have no record of the existing resources. Without the state file, Terraform would treat the modified configuration as entirely new, leading to the creation of additional resources instead of updating the existing ones. This could result in resource duplication and potential conflicts, causing your infrastructure to become disorganized or broken.

• This is where the state file plays a crucial role. The state file acts as a track recorder, maintaining a detailed record of all the resources and configurations that Terraform has applied. It keeps track of each resource's current state, including the provider details, resource IDs, and any changes made.

• When you run Terraform again after making changes, it uses the state file to determine what already exists and what needs to be updated, deleted, or created. This ensures that Terraform only applies the necessary changes, keeping your infrastructure consistent and preventing the mess that could occur if it started from scratch every time.

• You don’t need to create the state file manually; it is created automatically when you run the command terraform apply and has the extension .tfstate.

• There are two drawbacks to the state file. First, it contains sensitive information. Second, there's the issue of synchronizing the tfstate file when multiple DevOps engineers work on the same configuration. If two or more people update the configuration at the same time, it could create conflicts in the state file.

• These are drawbacks, but we can mitigate them by taking proper actions. Let's understand what actions can be taken to avoid these issues.

• In summary, the Terraform state file is essential for tracking and managing your infrastructure's lifecycle, ensuring that Terraform can accurately apply changes without disrupting your existing resources.

Remote Back-end:-

• • Now that we understand the state file, let's discuss how we can mitigate the associated issues. The solution lies in using a remote back-end.

    • Storing the state file on a local machine is not ideal. Instead, we should store this file on a remote server, which could be a cloud server or a physical server.

    • By doing this, any updates to the configuration will be tracked and recorded by the remote back-end. A remote back-end serves as a storage solution, and in AWS, this is typically achieved using an S3 bucket.

    • Storing the .tfstate file on a remote back-end helps address the problem of sensitive information. Now, let's address the synchronization issue.

    • State Lock

• To solve the issue of synchronizing the configuration file, we use a state lock. A state lock prevents multiple users from making changes to the Terraform state file at the same time, which could cause conflicts or corruption.

• When Terraform works on a configuration, it places a state lock on the state file. This lock ensures that only one operation can change the state at a time, stopping others from making changes until the lock is released. This is especially important in environments where multiple DevOps engineers are working on the same infrastructure.

• The state lock is automatically managed by Terraform and is usually stored in the back-end (e.g., DynamoDB when using AWS). This keeps the state file intact and ensures all changes are made in an orderly way.

Now let’s get hands-on! We will create an EC2 instance, an S3 bucket, and a DynamoDB table for the state lock file.

# This is backend.tf file
terraform {
backend "s3" {
    bucket = "amitt-backend-bucket"
    key = "amittashok/terraform.tfstate"
    region = "ap-south-1"
    dynamodb_table = "terralock"
    }

}

# This is main.tf file
# AWS cloud provider block

terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
    }
  }
}
provider "aws" {
region = "ap-south-1"
}

# EC2 instance block

resource "aws_instance" "new_server" {
    ami = "ami-0522ab6e1ddcc7055"
    instance_type = "t2.micro"
    key_name = "server-new"
    tags = {
        Name = "Server_1"
            }
    }

# S3 bucket for storing terraform.tfstate file

resource "aws_s3_bucket" "demo_bucket" {
    bucket = "amitt-backend-bucket"
    tags = {
        Name = "my-back-bucket"
           }
    }
# This is dyanmodb table, for state lock configuration

resource "aws_dynamodb_table" "terraform_lock" {
    billing_mode = "PAY_PER_REQUEST"
    hash_key = "LockID"
        name = "terralock"
    attribute {
        name = "LockID"
        type = "S"
        }

}

💬 I'd love to hear your thoughts!

Have you worked with Terraform before? What challenges have you faced, and how did you overcome them? Drop your insights in the comments below!

Thank You for the day...

Thank You....

In this article, we explored what a state file is and discussed its drawbacks. We then examined how these drawbacks can be overcome using a remote back-end and state lock. Additionally, we looked at how to create a back-end configuration file for a remote back-end.

Thank you for the day..

See you Soon….