Techreads

Terraform has recently launched the version 1.5.0 which introduced the much awaited feature of creation of configurations for imported resources. With the introduction of this new feature, users don't need to write the imported resources configuration manually.  Let's understand in detail about this new way of importing the resources to bring them under the management of terraform. The new way of Terraform Import In new way of terraform import, Terraform has introduced a new import block which you can add to any Terraform configuration file. A common pattern is to create a separate file for all of your import blocks with the name "imports.tf". Syntax # Write an import block import { to = RESOURCE_ADDRESS id = RESOURCE_ID } Let's see the new workflow for importing the resources. Example : Let's say, we have manually created a vpc and two subnets inside it in google cloud. Now we want to import and manage these manually created resources using terraform. Ste...

Recently, Terraform has launched the version 1.5.0 with the feature of configuration generation for resources to be imported and bring them under terraform management. But make a note of it that configuration generation is available in Terraform v1.5 as an experimental feature. Terraform Import before Terraform v1.5 Before v1.5, `terraform import` command was used to import existing resources into Terraform.  The import command takes two arguments - the resource address and ID. Import will find the existing resource using its ID and import it into your Terraform state at the given ADDRESS in your state file. Syntax > terraform import ADDRESS ID Let's see the import workflow in steps to understand it better. Example : Let's say, we have manually created a subnet inside a VPC in google cloud. Now we want to import and manage this manually created subnet using terraform. Step 01 Write a blank resource block according to the resource being imported. In our case, we will use the ...

Where possible, Terraform automatically converts values from one type to another in order to produce the expected type. If this isn't possible, Terraform will produce a type mismatch error and you must update the configuration with a more suitable expression. Example 01 If, You have declared a variable with the type - bool and provided its value - "true" i.e. string as mentioned below. # Variable  Declaration variable "example" { type = bool } # Variable  Definition example = "true" In this case, Terraform will internally transform the value to "true" to true (i.e. a bool type). Example 02 If, You have declared a variable with the type - list(string) and provided its value - ["a", 15, true] i.e. Tuple as mentioned below. # Variable  Declaration variable "example" { type = list(string) } # Variable  Definition example = ["a", 15, true] In this case, Terraform will internally transform the value to ["a...

A variable is something which can hold a value of a particular type that we usually use to make our configuration dynamic by passing those variables as parameters. Variable Declaration To declare any variable in terraform, use "variable" key word before variable name with a pair of curly braces. Below are the arguments which we can use for it to define its properties and other stuffs. Though all of these are optional. We can use them as per our need. 1. default -  This is to provide a default value for the variable. 2. type -  This is to specify the variable's data type. 3. description -  This is used to provide a description of variable for better understanding of code. 4. validation -  This block is used to do a certain type of validation against the variable value. 5. sensitive -  If this is set to true, you won't see these values in output console and these values won't be captured in Log files. Example 01: variable "sa_name" {} Example 02: variabl...

A module is bunch of files or a file with input and output variables defined, which can be reused to create terraform resources. It is just like any other terraform configuration which runs independently. Every Terraform configuration must have at least one module, which is called root module. So, a root module consist of your terraform configuration files in your working directory. You can call several child modules in your working directory. A module which calls other module is know as calling module. An example could be - you have called a module via root module (can be known as calling module as well in this case). Module Block A module can be called using below syntax. module "vpc" { source = "" ... } 1.  The "source" argument is mandatory for all the modules. It could be a local path or remote location from where terraform will download it during initialisation. 2. "version" argument is supported only for modules installed from a modu...

Drift means when state of your infrastructure differs from what is defined in terraform configuration files. Reasons for this this drift could be many, one is - changing the infrastructure manually thru cloud provider portal. To understand how Terraform deal with this kind of drifts and to maintain the consistency with the terraform configuration, let's go through few capabilities of Terraform. Terraform State As per Terraform documentation, The primary purpose of this file is to store the bindings between a remote system and resource instances declared in the terraform configuration files. Terraform state file can be stored locally and remotely both. which can be defined using the provider backend under terraform block. While writing the terraform code from scratch, you will get the state file (Local Name - terraform.tfstate) after execution of "terraform apply" command. Drift Detection Prior to execution of plan, apply and destroy commands, terraform executes refresh co...

Terraform logging becomes very important when you are getting an error while executing terraform commands and you want to debug the issue. In Terraform, You can enable logging by using environment variables. Terraform logging mainly depends on two environment variables. These two variables are TF_LOG and TF_LOG_PATH . TF_LOG and TF_LOG_PATH 1.  To set any value to TF_LOG enables logs to appear on stderr. 2.  You can set TF_LOG to one of the log levels TRACE, DEBUG, INFO, WARN or ERROR to change the verbosity of the logs. TRACE is the most verbose and it is the default log level when TF_LOG is set to something else other than an accepted Log Level. 3.  To save the logs to a file, use TF_LOG_PATH variable but remember, TF_LOG must be set in order for any logging to be stored on a file. Logs won't be saved in a file only by setting TF_LOG_PATH. Setting Environment Variables for Current Session To set these variables for a current session in PowerShell or Bash, use below syn...