Contents

Terraform Imp Points

Important points for Terraform language

Website Visitors:

Checkout this tutorial to know about some important points in Terraform.

Terraform Important Points

  • If you have created a plan file before the infrastructure is changed (created or destroyed), that plan file becomes stale. You cannot use it after your infrastructure is changed.
  • If you look at the output, you can easily determine if it is plan or state. For plan it will be “Known after apply” but in state file it will show the resource names directly.
  • The proper indentation in terraform is two spaces not a tab. If you’re using visual studio code, install terraform extension so that it takes care of the spaces automatically.
  • Use -auto-approve parameter to skip the prompt when running terraform apply command.
  • If you want to allow all protocols in outbound SG rule with terraform you have to specify protocol = “-1” so that all protocols are open in that SG.
  • If you try to create a same resource using terraform it throws an error, resource already exists. But if you want to add other resources like an elastic ip to existing instance, it will deploy it by picking up the existing instance details.
  • Let’s say you have already configured some resources using terraform. tfstate file will be created automatically as per this configuration. If you destroy those resources and run terraform state list it will be empty because all the resources are deleted and the state file will be renamed with terraform.tfstate.backup. A new state file will be created from now on.
  • Even for the first time, when you run terraform plan, it will create a terraform.tfstate file, but as that state file will be empty (as there are no resources created or modified yet) it will delete it immediately. From there, if you create or modify resources, state file gets the content from your provider and stores it accordingly.
  • Plan is binary file and state is json file. in plan we can see as known after apply but in state, we will see the actual resource names.
  • When you modify the tf file for creating or modifying resources, terraform compares that new configuration with the state file. Only the differences are applied. Existing state file is backedup as terraform.tfstate.backup and new state file will be created with the name terraform.tfstate.
  • You should be extremely careful when running terraform destroy as it would permanently delete resources from your infrastructure. If you’d like to remove some resources, remove them from the configuration file, and run terraform apply
  • Destroy command wont work if terraform created resources are modified outside terraform or if state file is missing or corrupted.
  • In the below example, resource is the keyword, aws_vpc is the resource that you want to create in aws, and “example” is the name of that particular script block. It is the name of the script block and the script will use it to refer later ie., name given to this resource (or code block or script block) locally. Tags name will be used for that particular resouce in aws end. The local script will use the value given in “example” place given below.
1
2
3
4
5
6
# Create a VPC
resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
  Tags = {
    Name = "HelloWorld"
}

If you use the same code block multiple times with the same name, terrraform will error out and stop processing. When you use it for second time you have to use a different name like example2 as shown below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# Create a VPC
resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
  Tags = {
    Name = "HelloWorld"
}

# Create a VPC
resource "aws_vpc" "example2" {
  cidr_block = "172.16.1.0/16"
  Tags = {
    Name = "HelloWorld"
}

Conclusion

In this tutorial, we’ve covered few important points in Terraform. We hope you have learned something new in this article. All other DevOps categories are listed here: DevOps Tools. Have a look at the posts as per your topic of interest.

Please feel free to share your thoughts about this article in the comments section below.

Your inbox needs more DevOps articles.

Subscribe to get our latest content by email.