Terraform Providers

There are several #HashiCorp Terraform providers available from HashiCorp either through official support, verified, or community support. They can be downloaded from Terraform Registry# as a Terraform Plugins# if needed and stored into the local directory .terraform/plugins/.

We can use the resources brought by the providers by specifying the requirements in a configuration file# like below: 

resource "local_file" "my_file" {
  content = "Hello World"
  filename = "/root/hello_world"
}

We defined a resource block with two parameters: local_file and my_file. The first parameter determine what resource should be use from which provider. A typical format for the parameter is similar to {provider}_{resource}. The second parameter named this particular resource. In this case, the resource will be named as my_file upon creation.

Note: Different providers provide varying resources, and each resource has different arguments which some are mandatory and some are optional.

The resource could use the values from other resource’s internal variables using reference syntax ${<provider>.<resource_name>.<variable>} such as below: 

resource "local_file" "my_file" {
  content = "${local_file.other_file.content}"
  filename = ...
}

This will establish an implicit dependency of my_file on other_file as #HashiCorp Terraform able to recognise such relationship when running terraform apply. However, in some cases, explicit dependency might exist even though it is not being referred. As such, use the #optional argument depends_on, and defined a list of dependency the resource is relying on. 

resource "local_file" "my_file" {
  ...
  depends_on = [
    local_file.other_file,
    random_pet.my_cat,
  ]
}

Note: Write down the dependencies in the format of {provider}.{resource}.

The depended resources will be created first before the resources that depend on them, and be destroyed in reversed order. Using the above example, local_file.other_file will be created before local_file.my_file since it is the dependency of the latter, and destroyed (using the command terraform destroy) after the latter has been destroyed by Terraform. Otherwise, the resource creation will always be in parallel if possible. We can fine tune how could we handle the resource using Terraform Lifecycle#.

We could put a constraint on the Provider’s version used for the current project. Normally, in the Terraform Registry#, they will provide the configuration# to use the chosen version after pressing the “Use Provider” button. It could look like the following: 

terraform {
  required_providers {
    local =  {
      version = 1.4.0
    }
  }
}

Note: terraform block states a global configuration throughout the Terraform project.

To restrict the version furthermore, we could use comparison operator such as >, <, >=, <=, and != and add it in front of the version in a string literal. In fact, we can put multiple comparison statements separated by comma ,. Other than comparison operator, Terraform has a built-in pessimistic constraint operator ~> that specifies a version or any incremental of it.

Note: == is not supported.

Links to this page
#networking #cloud #resource