Sunday, October 13, 2019

Terraform Definitions



A variable is a symbolic name associated with a value.

In Terraform, “variables” almost always refers to input variables, which are key/value pairs used in a run. Terraform modules can declare variables to allow customization. For child modules, the parent module provides a value when calling the module; for the root module, values are provided at run time.


A plugin for Terraform that makes a collection of related resources available. A provider plugin is responsible for understanding API interactions with some kind of service and exposing resources based on that API.

Terraform providers are generally tied to a specific infrastructure provider, which might be an infrastructure as a service (IaaS) provider (like AWS, GCP, Microsoft Azure, OpenStack), a platform as a service (PaaS) provider (like Heroku), or a software as a service (SaaS) provider (like Terraform Cloud, DNSimple, CloudFlare).

In simple words the vendor that you create VMs on, is the provider. If you have to use multiple providers of same infrastructure provider like multiple AWS providers, you can specify alias for each one of them and call the data source later. Ex, if you have to create 2 VMs under 2 different azure subscriptions, you can create one provider as azure and add “alias = subscription1” and so on.


In Terraform’s configuration language: A block that describes one or more infrastructure objects. Resources can be things like virtual networks, compute instances, or higher-level components such as DNS records.

In other Terraform-related contexts: An infrastructure object of a type that could be managed by Terraform.

A resource block in a configuration instructs Terraform to manage the described resource — during a run, Terraform will create a matching real infrastructure object if one doesn’t already exist, and will modify the existing object if it doesn’t match the desired configuration. Terraform uses state to keep track of which real infrastructure objects correspond to resources in a configuration.

Terraform uses cloud provider APIs to create, edit, and destroy resources. Terraform providers are responsible for defining resource types and mapping transitions in a resource’s state to a specific series of API calls that will carry out the necessary changes.


Data exported by a Terraform module, which can be displayed to a user and/or programmatically used by other Terraform code. Using output you can get some information after a task is completed. Example, get aws instance ip after it is created.


Terraform’s cached information about your managed infrastructure and configuration. This state is used to persistently map the same real world resources to your configuration from run-to-run, keep track of metadata, and improve performance for large infrastructures.

Without state, Terraform has no way to identify the real resources it created during previous runs. Thus, when multiple people are collaborating on shared infrastructure, it’s important to store state in a shared location, like a free Terraform Cloud organization.

This state is stored by default in a local file named “terraform.tfstate”, but it can also be stored remotely, which works better in a team environment. Terraform uses this local state to create plans and make changes to your infrastructure. Prior to any operation, Terraform does a refresh to update the state with the real infrastructure.

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. If you are working alone on the config files, then locking may not be that useful. If multiple team members are working on the config files, locking prevents others from making changes to the environment.

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.

Your state file can be on a local or remote location.


The terraform plan command is used to create an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files.

This command is a convenient way to check whether the execution plan for a set of changes matches your expectations without making any changes to real resources or to the state. For example, terraform plan might be run before committing a change to version control, to create confidence that it will behave as expected. The optional -out argument can be used to save the generated plan to a file for later execution with terraform apply, which can be useful when running Terraform in automation.

One of the stages of a run, in which Terraform compares the managed infrastructure’s real state to the configuration and variables, determines which changes are necessary to make the real state match the desired state, and presents a human-readable summary to the user. The counterpart of an apply. Terraform plan, which only performs a plan. It can optionally output a plan file, which terraform apply can use to perform that exact set of planned changes.

Data Source (data):

Data sources allow data to be fetched or computed for use elsewhere in Terraform configuration. Use of data sources allows a Terraform configuration to make use of information defined outside of Terraform, or defined by another separate Terraform configuration. Each provider may offer data sources alongside its set of resource types.

These are like functions in other programming languages. You specify them once and call them anywhere in the script as needed. You do not specify any static information like username = “1234” etc.. but you specify as username = ${var.username}


Provisioners can be used to model specific actions on the local machine or on a remote machine in order to prepare servers or other infrastructure objects for service. If you are creating a FTP server, you create a VM and specify commands to install ftp software under provisioners section in your TF file. There are some pre-defined provisioners which are: chef Provisioner, file Provisioner, habitat Provisioner, local-exec Provisioner, puppet Provisioner, remote-exec Provisioner, salt-masterless Provisioner. To install ftp on the new server you have to use remote-exec provisioner. Similarly to copy a some data from the remote machine to our local machine, we have to use local-exec provisioner.

If something fails while using provisioners, it will be marked as tainted, and script will continue.

Terraform Functions:

The Terraform language includes a number of built-in functions that you can call from within expressions to transform and combine values. The general syntax for function calls is a function name followed by comma-separated arguments in parentheses:

max(5, 12, 9)

The Terraform language does not support user-defined functions, and so only the functions built in to the language are available for use. The navigation for this section includes a list of all of the available built-in functions.

You can experiment with the behavior of Terraform’s built-in functions from the Terraform expression console, by running the terraform console command:

> max(5, 12, 9)


Leave a Reply

Notify of