Terraform (IaaC) - S3 backend :

Terraform Variables

As a good infrastructure developer, you should not hardcode values in the configuration. Hence, Terraform variables facilitate that the values will be kept in one place storing them into a variable and replacing the variable name in everywhere you need the value to be placed in.

• When terraform configuration values need to be reused we can go with terraform variables in terraform and terraform variables are a great way to define centrally controlled reusable values.

• The information in Terraform variables is saved independently from the deployment plans, which makes the values easy to read and edit from a single file.

Variable.tf: This is the file where you define variables for your terraform configuration. This contains the variable definitions as well as the optional default value for the variable. Example variable.tf shown here

variable region { description = "Please provide region details" default = "us-west-1" type = string }

variable "vpc_cidr" { default = "192.168.0.0/16" }

Terraform.tfvars: This is the file where you can assign a value to the variables that are declared in the variable.tf file.

• Note that if you are not provided the values in the terraform.tfvars but the variable is declared then terraform prompts a user to input the value at the time of execution/apply.

• If the values are supplied in tfvars and also in the default value in the variables.tf then tfvars will take precedence.

• You should not keep sensitive values in the tfvars as they are exposed to the readers. Hence, the values can also be supplied as command-line arguments using the below syntax.

• terraform apply -var="vpc_cidr=192.168.0.0/16"

• Input values can be of any data type based on the requirement. Below are the data types that terraform supports. Follow the LINK to learn more about data types.

Below is the syntax for how to assign values to the variables in the terraform.tfvars file.

region = “us-west-1”
vpc_cidr = “192.168.0.0/16”

Terraform output

The terraform output command is used to extract the value of an output variable from the state file.

Below is the syntax to define an output variable.

output "vpc_nme" {
value = aws_vpc.vpc1.id
}

Terraform S3 backend

Terraform backend is the concept of keeping the state file safe in the remote location rather than keeping it in the local system.

Follow the LINK to learn more about available backends. If your infrastructure provider is AWS then S3 backend is the opted one to store the state file. 

• Stores the state as a given key in a given bucket on S3.

• This backend also supports state locking and consistency checking via Dynamo DB, which can be enabled by setting the dynamodb_table field to an existing DynamoDB table name.

• A single DynamoDB table can be used to lock multiple remote state files. Terraform generates key names that include the values of the bucket and key variables.

• Terraform 'apply' command to follow the below workflow

  1. First, check for the state lock and if the lock is not already set then, it acquires the lock.

  2. Check if the state file has resource configuration and compare with the desired state as per the code block and it checks in the provider platform if the resources are actually there with the actual configuration.

  3. Create a plan of resources that need to be modify/create/destroy based on the statefile comparison.

  4. If the plan was auto-approved using –the auto-approve flag then the plan of resources will be deployed else it prompts the user to approve.

  5. Once the resources are deployed, it updates the statefile with the resource details

  6. Once deployment is completed it releases the lock.

Terraform state lock

If supported by your backend, Terraform will lock your state for all operations that could write state. This prevents others from acquiring the lock and potentially corrupting your state

• State locking happens automatically on all operations that could write state.

• You won't see any message that it is happening. If state locking fails, Terraform will not continue.

• You can disable state locking for most commands with the -lock flag but it is not recommended.

• If acquiring the lock is taking longer than expected, Terraform will output a status message. If Terraform doesn't output a message, state locking is still occurring if your backend supports it.

Force Unlock:

Be very careful with this command.

If you unlock the state when someone else is holding the lock it could cause multiple writers. Force unlock should only be used to unlock your own lock in a situation where automatic unlocking fails.

To protect you, the force-unlock command requires a unique lock ID. Terraform will output this lock ID if unlocking fails. This lock ID acts as a nonce(a nonce is an arbitrary number that can be used just once in a cryptographic communication), ensuring that locks and unlocks target the correct lock.

Task 1- Create S3 backend

To create S3 bucket through terraform code i have written below terraform files:

1. provider.tf

   

2. variables.tf

   

3. terraform.tfvars

   

4. s3.tf

   

5. dynamodb.tf

   

6. After writing the code lets create infrastructure terrafrom init

1. terraform validate

1. terraform plan : lock will create once I'll run 'terraform apply' 'aws_dynamodb_table.terraform-lock will be created'

After running 'terrafrom apply' dynamo db, s3 bucket and lock on dynamo db created.

1. Verifying S3 bucket from AWS console after creation of infrastructure=-
   namg-tws-terraform-state bucket created.

1. Dynamo DB with 'tws_table' created.

The purpose of above created S3 bucket and dynamo db is to store terraform state files separately instead of any version control system like Git/Bitbucket to protect the sensitive data from other users.

Task 2- Store the terraform state file in the S3 backend

1. I have written code to create custom vpc through terraform code.

2. The task is to:

   Create VPC Create Internet Gateway Create Public subnet Create Private Subnet Create Public route table Create Private route table
   provider.tf

   Variables.tf
   terraform.tfvars
   backend.tf

3. provider.tf

   

4. variables.tf

   

5. terraform.tfvars

   

6. vpc.tf

   

7. public-subnet.tf

   

8. private-subnet.tf

   

9. route-table.tf

   

10. Internet-gateway.tf

    

11. output.tf

    

12. backedn.tf

    

13. terraform init

    

14. terraform validate

    

15. terraform plan

    

16. terraform apply

    

    

17. After the creation of vpc my 'terraformtf.statefile' is not showing locally

    

18. 'terraformtf.statefile' has stored in s3 bucket

    

19. custom vpc created

    

20. I have destroyed vpc infrastructure through terrafrom destroy

    

21. Destroyed s3 bucket through terraform destroy, before that make sure you delete the terraform state file, delete s3 bucket and then destroy s3.

Conclusion:

A backend defines where Terraform stores its state data files. Storing your state remotely also adds an increased layer of durability, it’s a lot harder to accidentally delete your tfstate file when it is stored remotely.

"Thank you for reading my blog! Happy Learning!!!😊

Stay tuned for more DevOps articles follow me on Hashnode and connect on LinkedIn (https://www.linkedin.com/in/namratakumari04/ for the latest updates and discussions.