Terraform Configuration Language Tutorials Flashcards
resource block
Resource blocks declare a resource type and name.
Together, the type and name form a resource identifier (ID) in the format resource_type.resource_name
Resource types always start with the _________ followed by an underscore.
provider name
Resource Arguments
configure a particular resource; because of this, many arguments are resource-specific.
Resource Attributes
Attributes are values exposed by an existing resource.
References to resource attributes take the format resource_type.resource_name.attribute_name
Resource Meta-arguments
Meta-arguments change a resource’s behavior, such as using a count meta-argument to create multiple resources.
Meta-arguments are a function of Terraform itself and are not resource or provider-specific.
Terraform Core
reads the configuration and builds the resource dependency graph.
Terraform Plugins
(providers and provisioners) bridge Terraform Core and their respective target APIs.
Terraform provider plugins implement resources via basic CRUD (create, read, update, and delete) APIs to communicate with third party services.
Sensitive values in state file
Terraform stores the state as plain text, including variable values, even if you have flagged them as sensitive.
Since Terraform state can contain sensitive values, you must keep your state file secure to avoid exposing this data.
locals
named values that you can refer to in your configuration
Unlike input variables, locals are not set directly by users of your configuration!
Data sources
Data sources allow Terraform to use information defined outside of Terraform, defined by another separate Terraform configuration, or modified by functions.
A data block requests that Terraform ….
read from a given data source and export the result under the given local name
data "data_source" "local_name" {
#Most arguments in this section depend on the data source
}
e.g.,
data “azurerm_virtual_machine” “example” {
name = “production”
resource_group_name = “networking”
}
output “virtual_machine_id” {
value = data.azurerm_virtual_machine.example.id
}
Managed resources (resource {}) vs. data resources (data {})
Both kinds of resources take arguments and export attributes
Managed resources cause Terraform to create, update, and delete infrastructure objects
Data resources cause Terraform only to read objects.
terraform_remote_state data source
Retrieves state data from a Terraform backend.
Allows you to use the root-level outputs of one or more Terraform configurations as input data for another configuration.
Backends
Backends define where Terraform’s state snapshots are stored.
Resource Dependencies
Terraform infers the dependencies between resources in most cases.
Occasionally, an dependency will need be defined explicitly with the depends_on argument
depends_on
An argument to define explicit dependencies
Accepted by any resource of module block
You can specify multiple resources in the depends on argument
e.g.,
resource "aws_instance" "example"{
...
depends_on = [aws_s3_bucket.example]
}
module “example_sqs_queue” {
…
depends_on = [aws_s3_bucket.example, aws_instance.example]
}
The count argument
replicates the given resource or module a specific number of times with an incrementing counter. It works best when resources will be identical, or nearly so.
resource "azurerm_virtual_network" "example" {
#create 6 instances of a vnet
count = 6
name = "example-vnet0${count.index}"
...
}
The for_each argument
meta-argument accepts a map or a set of strings, and creates an instance for each item in that map or set. Each instance has a distinct infrastructure object associated with it, and each is separately created, updated, or destroyed when the configuration is applied.
The each object
In blocks where for_each is set, an additional each object is available in expressions, so you can modify the configuration of each instance.
This object has two attributes:
each. key — The map key (or set member) corresponding to this instance.
each. value — The map value corresponding to this instance. (If a set was provided, this is the same as each.key.)
Limitations on values used in for_each
The keys of the map (or all the values in the case of a set of strings) must be known values
Sensitive values cannot be used as arguments to for_each
Referring to instances (within the config file) that were declared using for_each
TYPE.NAME refers to the block (e.g., azure_resource_group.rg)
TYPE.NAME.[KEY] refers to individual instances (e.g., azure_resource_group.rg[“rg01”], azure_resource_group.rg[“rg02”])
the templatefile Function
reads the file at the given path and renders its content as a template using a supplied set of template variables.
templatefile(path, vars)
*.tftpl is the recommended naming pattern to use for your template files
the file function
reads the contents of a file at the given path and returns them as a string.
template sequences
Within quoted and heredoc string expressions, the sequences ${ and %{ begin template sequences. Templates let you directly embed expressions into a string literal, to dynamically construct strings from other values.
String Interpolation
A ${ … } sequence is an interpolation, which evaluates the expression given between the markers, converts the result to a string if necessary, and then inserts it into the final string:
“Hello, ${var.name}!”
string directives
A %{ … } sequence is a directive, which allows for conditional results and iteration over collections, similar to conditional and for expressions.
string directives: if else
The %{if }/%{else}/%{endif} directive chooses between two templates based on the value of a bool expression:
e.g., “Hello, %{ if var.name != “” }${var.name}%{ else }unnamed%{ endif }!”
string directives: for
The %{for in } / %{endfor} directive iterates over the elements of a given collection
e.g., “%{ for ip in aws_instance.example.*.private_ip } server ${ip} %{ endfor }”
