There are a few ways to provide variable values within Terraform:
- Via the console using -var flags: You can use multiple -var flags with the variable_ name=variable_value string to supply the values.
- Via a variable definition file (the .tfvars file): You can use a file containing the list of variables and their values ending with an extension of .tfvars (if you prefer HCL) or .tfvars. json (if you prefer JSON) via the command line with the -var-file flag.
- Via default variable definition files: If you don’t want to supply the variable definition file via the command line, you can create a file with the name terraform.tfvars or end it with an extension of .auto.tfvars within the Terraform workspace. Terraform will automatically scan these files and take the values from there.
- Environment variables: If you don’t want to use a file or pass the information via the command line, you can use environment variables to supply it. You must create environment variables with the TF_VAR_<var-name> structure containing the variable value.
- Default: When you run a Terraform plan without providing values to variables in any other way, the Terraform CLI will prompt for the values, and you must manually enter them.
If multiple methods are used to provide the same variable’s value, the first method in the preceding list has the highest precedence for a specific variable. It overrides anything that is defined in the methods listed later.
We will use the terraform.tfvars file for this activity and provide the values for the variables.
Add the following data to the terraform.tfvars file:
subscription_id = “<SUBSCRIPTION_ID>”
| app_id | = “<SERVICE_PRINCIPAL_APP_ID>” | |
| password | = | “<SERVICE_PRINCIPAL_PASSWORD>” |
| tenant | = | “<TENANT_ID>” |
If you are checking the Terraform configuration into source control, add the file to the ignore list to avoid accidentally checking it in.
If you use Git, adding the following to the .gitignore file will suffice:
*.tfvars
.terraform*
Now, let’s go ahead and look at the Terraform workflow to progress further.
Terraform workflow
The Terraform workflow typically consists of the following:
- init: Initializes the Terraform workspace and backend (more on them later) and downloads all required providers. You can run the init command multiple times during your build, as it does not change your workspace or state.
- plan: It runs a speculative plan on the requested resources. This command typically connects with the cloud provider and then checks whether the objects managed by Terraform exist within the cloud provider and whether they have the same configuration as defined in the Terraform template. It then shows the delta in the plan output that an admin can review and change the
configuration if unsatisfied. If satisfied, they can apply the plan to commit the changes to the cloud platform. The plan command does not make any changes to the current infrastructure.
- apply: This applies the delta configuration to the cloud platform. When you useapply by itself, it runs the plan command first and asks for confirmation. If you supply a plan to it, it applies the plan directly. You can also use apply without running the plan using the -auto-approve flag.
- destroy: The destroy command destroys the entire infrastructure Terraform manages. It is, therefore, not a very popular command and is rarely used in a production environment. That does not mean that the destroy command is not helpful. Suppose you are spinning up a development infrastructure for temporary purposes and don’t need it later. In that case, destroying everything you created using this command takes a few minutes.
To access the resources for this section, cd into the following:
$ cd ~/modern-devops/ch8/terraform-exercise Now, let’s look at these in detail with hands-on exercises.
