Using Input Variables and Outputs

Overview

• Supplying Inputs
  • providing values to Terraform for use in configuration

• Constructing values
  • construct internal values inside of configuration for re-use

• Specifying Outputs
  • export information from configuration once deployed

• Validate configurations
  • validate configurations before deployment to ensure everything is correct

Working with Data in Terraform

• we can transform values inside config and return values as output
  • like working with variables in C, and then returning a value to indicate error or success

1. Input variables
   1. which pass info to terraform configuration
   2. defined inside configuration, and supplied when terraform is executed, like adding arguments when running a c program?

2. Local values, or locals
   1. computed values inside the config which can be referenced throughout
   2. like variables
   3. aren’t inputted, but can be based on input variables or internal references

3. Data is returned by Terraform with output values
   1. outputs defined in config
   2. depends on reference
   3. can be constructed from one or more elements, like locals

Input variable syntax

• variables are defined inside a block, like everything else in terraform

• starts with variable keyword, followed by name label

• all other properties are defined in block

• preferred to have arguments inside block, but they all are optional

  

• The type argument defines the data type
  • error checking

• Description argument provides context for user if error

• Default arguments sets default if none inputted

• If no default set and nothing inputted, Terraform will prompt user at command line to supply a value

• The sensitive argument accepts a boolean value, if set to true, will not show variable in logs or terminal output
  • for passwords, or API keys
  • buy default, all variables are not sensitive

Example

• To refer to the value stored in variable
  • use the var identifier

  e.g.

  • var.<name_label>
  • var.aws_region

Terraform Data Types

1. Primitive
   1. string, number, boolean

2. Collection
   1. list (ordered group), set (unordered), map (group of key-value pairs)
   2. a grouping of the primitive data types, like an array in C
   3. for each collection, all values must be same data type

3. Structural
   1. similar to collection, but allow you to mix data types
   2. like a struct in C
   3. Tuples (like lists), objects (like maps)
   4. not used in basic configs

Referencing Collection values in a list

• type arguments takes the form of collection type and data type stored in it

• lists are ordered data type, so we can refer to element by a number

• first number is referenced by 0

• this reference would return “us-east-1”

Referencing Collection values in a map

Globomantics Scenario

Potential improvements

Local Values Syntax

Example

• local value computed inside config

• cant be submitted

• all that’s needed outside block is locals

• inside block are key-value pairs, any terraform supported data-type

• a value can be a maps defining even more key-value pairs

• you can refer to other values from inside confider for values in local

• can reference the locals block multiple times inside configuration if you want
  • however, each key must be unique through config locals block

Terraform locals reference

starts with local keyword, not plura

• e.g

  local.<name_label>

  local.instance_prefix

  local.common_tags.company

  local.common_tags gets entire map

The above image shows how to use interpolation syntax to reference two variables together as a string

Output Values Syntax

• starts with output keyword with name_label

• inside config block, only required argument is the output value
  • can be any supported terraform data type
  • optional arguments include
    • description, not very useful as only seen when looking at config code
    • sensitive, pass value from one module to another without printing to terminal or logs

EXAMPLE

Validate and Update the configuration

• find out if config is syntactically correct

• a command called validate can help

• before you run command you will need to run terraform init

• checks syntax and logic
  • if it finds any errors, it will print out the error and line where it found the issue
  • sometimes makes a suggestion

• does not validate state, only the content of config

• does not guarantee updated deployment will be successful
  • fail due to insufficient capacity, incorrect instance size, overlapping address space, etc.

  terraform validate

Supplying Variable Values

1. using defaults

2. or in the command line, with - var flag

3. or in a -var-file flag and all values in that file

4. terraform.tfvars or terraform.tfvars.json, if in ssme directory as config file

5. .auto.tfvars or .auto.tfvars.json, if in same directory as config file

6. Environment variable TF_VAR_

• If you don’t provide a value using any of these methods at runtime, Terraform will prompt you for a value

The Evaluation preference

Summary

• configuration is now more variable

• supplied date through input variables, more secure and repeatable

• there are many ways to submit values

• receive data through outputs

• validate config before deployment to catch errors in logic and syntax