Terraform

What is Infrastructure as Code?

What is Infrastructure as Code?
Provisioning and managing infrastructure through code instead of manually

Creating resources manually Infrastructure as Code (IaC)

Teams Console Infrastructure Teams Code IaC tool

Check for changes

CLI
Plan deployments

■ IaC tool normally runs on a CI/CD

Apply modifications
environment.
■ Hard to reproduce large infrastructures.
■ Infrastructure is version controlled.
■ Hard to track and revert changes.
■ Easier to spot and fix configuration Infrastructure
■ Imperative rather than declarative. issues.

■ Very error-prone in terms of configuration. ■ Declarative rather than imperative.

Terraform
 Terraform
Benefits of Infrastructure as Code
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ Resources, environments, and complex infrastructures can be easily created and destroyed.

■ Automation considerably frees up the time of developers and infrastructure maintainers.

■ Tagging strategies and requirements can be easily implemented across entire infrastructures.

■ It becomes much easier to obtain an overview of all resources created by a specific IaC project.

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ Well-developed IaC tools guarantee a consistent behavior.

■ IaC tools provide multiple ways of deploying configurations: locally, as part of a CI/CD pipeline, triggered via API calls.

■ IaC tools validate infrastructure configuration as part of the deployment process.

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ Infrastructure can be easily copied and deployed multiple times with the same structure.

■ Modules can be created and made publicly or privately available.

■ Different environments can be created based on the same / similar configuration files.

■ Resource counts can be easily increased or decreased when needed.

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ Automation saves a lot of time and effort when deploying infrastructure.

■ Prevents configuration drift by identifying and reverting unexpected changes.

■ Creating, updating and destroying resources becomes fully integrated with other CI/CD tasks.

■ Changes to infrastructure are version controlled, being easier to revert in case of incompatibility or error.

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ The planning stage shows all the changes that are expected to be carried out, and can be inspected by the engineers.

■ Connecting and integrating different resources becomes more intuitive due to developer-friendly identifiers.

■ Many IaC tools support validation and integrity checks with custom conditions.

■ Many IaC tools support protection rules against deletion of critical resources.

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ Validation and integrity checks can be used to ensure the infrastructure complies with security requirements.

■ Shared infrastructure modules are normally maintained by teams with a strong focus on securing these resources.

■ Security strategies (for example, IAM users, roles and their respective policies) can also be configured via IaC tools.

■ The infrastructure configuration files can be inspected by security software for vulnerabilities.

Terraform
Benefits of Infrastructure as Code

Improved Self
Better cost consistency & Fewer human documenting
management scalability errors infrastructure

Improved Improved
Improved deployment security
reliability process strategies

■ The created infrastructure is the infrastructure documented in the code.

■ Many IaC tools allow detailed inspection of the resources created.

■ Run logs are normally stored for a period of time, allowing inspection in case of any errors or unwanted changes.

Terraform
 Terraform
Why Terraform?
Why Terraform?
Advantages of Terraform over other Infrastructure-as-Code tools

Platform-agnostic High-level abstraction Modular approach Parallel deployment

Terraform can be used with Terraform can be used to We can create modules Terraform builds a dependency
multiple providers, both in the manage resources across grouping resources, and then graph of resources and
cloud and on-premises. multiple providers. combine and compose these supports parallel changes.
modules to build a bigger
solution.

Resource protection &

Separation of plan and apply State file
validation

We can execute only plan Terraform Provides several Terraform is very fast due to its
commands to inspect the ways to protect resources implementation of a state file,
potential changes before against accidental changes or saving the entire snapshot of
actually applying them. deletion, as well as ways of the current deployment.
validating the deployed
infrastructure.

Terraform
 Terraform
Terraform's Architecture
Terraform's Architecture
How does Terraform manage resources in so many different places?

■ Terraform providers allow Terraform to Terraform ecosystem Remote APIs

know how to interact with remote APIs.

■ Providers provide the logic to interact

Providers
with upstream APIs:

□ Read, create, update, and delete Amazon Web Services AWS API
resources through that provider’s API.

■ Anyone can write and publish a provider Google Cloud Google Cloud API
for a remote API, as long as it follows
Terraform
Terraform's specifications.
core Azure Azure API
■ We declare the necessary providers in the
Terraform project configuration, and
… …
Terraform installs those providers during
initialization.

Terraform
 Terraform
Provisioning Infrastructure
Provisioning Infrastructure
How does Terraform provision and manage infrastructure?

Plan Apply Destroy

1 3 1 3 1
State

Terraform Plan Plan Terraform State State Terraform

core core core
Config
files 2 2 2
Check for the
Create, modify, or Delete
current state
delete real-world real-world
of real-world
objects objects
Providers objects Providers Providers

Terraform
 Terraform
Terraform Block
Terraform Block
Used for configuring the Terraform project (backend, providers, required versions)

■ Only constants are allowed within the terraform

block. Input variables or resource references are terraform { Version constraints
not allowed. required_version = "1.7.0"
= : allows only the specified version.
■ cloud block: used to configure Terraform Cloud.
backend "s3" {
!= : excludes an exact version.
■ backend block: used to configure a state backend ./ ...
for the project. } >=, <=, >, < : allow versions for
which the comparison is true.
■ required_version key: used to specify the required_providers {
accepted versions of Terraform for the current ~> : allows only the rightmost digit
aws = {
project. to increment.
source = "hashicorp/aws"
■ required_providers block: specifies the version = "~> 5.33.0"
required providers for the current project or } required_version = ">=1.7.0"
module, including their accepted versions. } required_version = ">1.5.0, <1.7.0"
required_version = "~> 1.5.0"
} required_version = "~> 1.5"

Terraform
 Terraform
Terraform State
Terraform State
Terraform State maps resources from the configuration to real-world objects

■ State is always required in Terraform.

State file
■ Important! The state contains extremely sensitive data, so be careful
regarding who has access to it.
Primary goal
■ The state file also stores metadata, such as resource dependencies, so that
Terraform knows in which order resources must be created, updated or Backend
deleted. configuration

■ Before any planning operation, Terraform refreshes the state with the Binding to
information from the respective real-world objects. real-world
object
□ This is essential to avoid configuration drift. If a real-world object has been Resource Outputs
modified outside of Terraform and the respective configuration has not configuration
been updated, Terraform will revert the changes.

■ State can be either stored locally (default) or in several remote backends (S3,
Google Cloud Storage, Terraform Cloud, among others). Sensitive
Metadata
values
■ State locking: locks the state while executing write operations to prevent
concurrent modifications and state corruption.

Terraform
 Terraform
Backends
Backends - Overview
Backends define where Terraform stores its state file

■ There are multiple types of backends, which can be place into three categories:

□ Local: the state file is stored in the user's local machine.

□ Terraform Cloud: the state file is stored in Terraform Cloud. Offers additional features.

□ Third-party remote backends: the state file is stored in a remote backend different from Terraform Cloud (for
example S3, Google Cloud Storage, Azure Resource Manager / Blob Storage, among others).

■ Different backends can offer different functionalities (for example, state locking is not available for all remote backends)
and require different arguments (we'll discuss more of that in the next slide).

■ A Terraform configuration can provide only one backend.

■ The backend block cannot use any input variables, resource references, and data sources.

■ Remote backends require authentication credentials in order for Terraform to properly access the files.

■ When changes are made to the configured backend, we must rerun the terraform init command.

■ Terraform offers the possibility of migrating state between different backends.

Terraform
Backends - Local and Remote
Terraform provides different options for backends, both local and remote

Local S3 Terraform Cloud

State
Terraform Terraform Terraform

Local backends: are stored in the same S3 backends: are stored in an S3 bucket Terraform Cloud backends: are stored
machine as the Terraform project. in AWS. in a Terraform Cloud project and
workspace.

Terraform
 Terraform
Providers
Providers Overview
Providers are how Terraform interacts with remote APIs and platforms

■ Each provider adds a set of resource Terraform ecosystem Remote APIs

types and data sources that the
Terraform project can use.
Providers
■ Providers are developed and maintained
separately from Terraform. They fit into
Terraform's plugin architecture. Amazon Web Services AWS API

■ The Terraform configuration must declare

all the providers it requires. Google Cloud Google Cloud API
Terraform
■ Provider configurations belong to the root
core Azure Azure API
module of a Terraform project. Child
modules receive their provider
configuration from the parent module. … …
■ We can use the same version constraints
as when specifying the Terraform version,
and we can create a dependency lock file
to ensure that the exact versions of
providers are installed.

Terraform
 Terraform
Resources
Resource Blocks
Resources are used to configure real-world infrastructure objects

■ They are used to manage any infrastructure that we want to manage resource "aws_instance" "backend" {
with Terraform, and are the most important blocks within Terraform.
ami = "ami-12345"
■ Resource blocks represent things like virtual networks, compute instance_type = "t2.micro"
instances, DNS records, storage disks, among others.
}
■ The arguments depend on and vary based on the resource type.

■ The combination of resource type and resource name must be unique resource "aws_s3_bucket" "example" {
within a module. This is how Terraform links the resource to its bucket = "my-bucket-${random_id.suffix.id}"
respective real-world object.
tags = {
■ If no other provider is specified, Terraform will use the default Environment = "Dev"
provider to provision the infrastructure. We can use the provider }
meta-argument to explicitly pass a different provider.
}
■ Terraform offers a few local-only resources, such as generating
random strings or IDs, private keys, or self-issued TLS certificates. resource "random_id" "suffix" {
byte_length = 4
■ We can create multiple instances of resources by using Terraform }
loops (for_each, count).

Terraform
 Terraform
Resource Dependencies
Resource Dependencies
Terraform supports both parallel and sequential creation of resources

■ Certain resources can be created in parallel, while other resources depend on

each other and must be created in a certain order.

■ Terraform supports both parallel and sequential management of resources.

■ Terraform inspects the expressions to automatically establish implicit

Terraform apply
dependencies between resources.

■ Additionally, we can define explicit dependencies via the depends_on

meta-argument.

■ If the operation on an upstream resource fails, Terraform will not continue the
operations on downstream resources.

■ We can also force Terraform to replace a parent resource in case a child resource
is modified by using the replace_triggered_by meta-argument.

Terraform
 Terraform
Meta-Arguments
Meta-arguments
Meta-arguments allow us to configure Terraform's behavior in many ways

depends_on lifecycle

Used to explicitly define dependencies

between resources. create_before_destroy prevent_destroy

Prevents Terraform's default behavior of Terraform exits with an error if the

count and for_each destroying before creating resources planned changes would lead to the
that cannot be updated in-place. The destruction of the resource marked with
Allow the creation of multiple resources behavior is propagated to all resource's this.
of the same type without having to dependencies.
declare separate resource blocks.
ignore_changes
replace_triggered_by
provider
We can provide a list of attributes that
Replaces the resource when any of the should not trigger an update when
Allows defining explicitly which provider referenced items change. modified outside Terraform.
to use with a specific resource.

Terraform
 Terraform
Data Sources
Data Sources
Query or retrieve data from APIs or other Terraform projects

Terraform configuration External Project Use-case

Retrieve data from

infrastructure that is not
managed by the current
Data source Terraform project.

RDS resource Existing VPC

Data source

EC2 resource Existing Role

Terraform
 Terraform
Input Variables
Input Variables
Customize values based on variables to create reusable and composable code

Motivation for input variables:

Default values for variables Lower precedence
■ To be able to customize aspects of Terraform configurations and
modules without having to alter the source code.
Environment variables
Notes around variables:

■ It's convention to declare them inside of variables.tf file, and we

use them via var.<NAME> terraform.tfvars file

■ When defining a variable, we can set the type, provide a description,

give a default value, set sensitive to a boolean value, and provide
terraform.tfvars.json
validation rules.

■ When we run terraform plan or apply and don’t provide

*.auto.tfvars or
command-line arguments for the variables, it will ask us to provide the
*.auto.tfvars.json
values for each of the variables.

□ If we provide defaults, Terraform will not ask for these values.

Command line -var and --var-file Higher precedence

Terraform
 Terraform
Creating Multiple Resources
Creating Multiple Resources
Avoid code duplication by leveraging count and for_each meta-arguments

■ count: used to define the number of instances of a specific

resource Terraform should create. resource "aws_instance" "multiple" {
count = var.ec2_count
□ It can be used with modules and with resources.
ami = data.aws_ami.ubuntu.id
□ Must be known before Terraform performs any remote
resource actions. instance_type = "t2.micro"

□ <TYPE>.<LABEL>.<INDEX.] refers to a specific instance of a

resource, while <TYPE>.<LABEL> refers to the resource as a tags = {
whole.
Project = local.project
□ We can use count.index in the resource's arguments to
retrieve the index of the specific instance. Name = "${local.project}-${count.index}"
}
}

Terraform
Creating Multiple Resources
Avoid code duplication by leveraging count and for_each meta-arguments

■ for_each: accepts a map or a set of strings and creates an

instance for each entry in the received expression. resource "aws_subnet" "main" {
for_each = var.subnet_config
□ We can access the key and value via the each object. Key and
value are the same if the received value is a set. vpc_id = aws_vpc.main.id
□ We should not use sensitive values as arguments to the cidr_block = each.value.cidr_block
for_each meta-argument.

□ The for_each value must be known before Terraform tags = {

performs any remote operations.
Project = local.project
□ We can chain for_each resources into other for_each
expressions if we need to create multiple resources based on Name = "${local.project}-${each.key}"
a map or set. }
}

Terraform
Terraform
Modules
Modules
Organize, encapsulate, and re-use Terraform components

■ Modules are used to combine different resources that are normally used together. They are just a collection of .tf files kept in the same
directory.

□ Root module: the set of files in the main working directory.

□ Root modules can then call other modules (child modules), defined either locally or remotely.

■ The goal is to develop modules that can be reused in various ways.

■ Why use modules?

Organize configuration Encapsulate configuration Re-use configuration Ensure best practices

Group related parts of the Encapsulate sets of resources Modules make it much easier Provide configuration and
infrastructure to make the to prevent unintended to reuse entire sets of infrastructure best practices,
code easier to understand changes and mistakes that components, thus improving and publish modules both
and improve maintainability. can happen in complex code consistency, saving time, and publicly and privately for use
bases. preventing errors. by other teams.

Terraform
 Terraform
Standard Module Structure
Standard Module Structure
Which files are recommended, and what they are used for

main.tf

Main entry point for module resources. More complex modules should split the resources into multiple
files with relevant names.

outputs.tf

File containing all outputs from the module. Used by Terraform Registry to generate documentation.

variables.tf

File containing all variables for the module. Used by Terraform Registry to generate documentation.

README.md

File containing documentation for the module. Used by Terraform Registry to generate documentation.

Terraform
 Terraform
Building Modules
Building Modules
When to create modules and which best practices to follow?

■ Creating a module is as simple as creating a directory and a couple of terraform files within that directory.

■ When to build modules?

□ When useful abstractions of our infrastructure can be identified.
□ When certain groups of resources always need to be created together and strongly depend on each other.
□ When hiding the infrastructure details of a certain part of our infrastructure will lead to better developer experience.

■ Which best practices to follow?

□ Use object attributes: group related information under object-typed variables.

□ Separate long-lived from short-lived infrastructure: resources that change rarely should not be grouped together with resources
that change often.

□ Do not try to cover every edge case: this can quickly lead to highly complex modules, which are difficult to maintain and configure.
Modules should be reusable blocks of infrastructure, and catering to edge cases goes against that purpose.

□ Support only the necessary configuration variables: do not expose all the internals of the module for configuration via variables.
This hurts encapsulation and makes the module harder to work with.

Terraform
Building Modules
When to create modules and which best practices to follow?

■ Which best practices to follow?

□ Output as much information as possible: even if there is no clear use for some information, providing it as an output will make the
module easier to use in future scenarios.
□ Define a stable input and output interface: All used variables and outputs create coupling to the module. The more coupling, the
harder it is to change the interface without breaking changes. Keep this in mind when designing the module's interface.
□ Extensively document variables and outputs: this helps the module's users to quickly understand the module's interface and to
work more effectively with it.

□ Favor a flat and composable module structure instead of deeply nested modules: deeply nested modules become harder to
maintain over time and increase the configuration complexity for the module's users.

□ Make assumptions and guarantees explicit via custom conditions: do not rely on the users always passing valid input values.
Thoroughly validate the infrastructure created by the module to ensure it complies with the requirements the module must fulfill.

□ Make a module's dependencies explicit via input variables: data sources can be used to retrieve information a module needs, but
they create implicit dependencies, which are much harder to identify and understand. Opt for making these dependencies explicit by
requiring the information via input variables.
□ Keep a module's scope narrow: do not try to do everything inside a single module.

Terraform
 Terraform
Publishing Modules
Publishing Modules
Make your Terraform module available to others via Terraform Registry

■ Anyone can publish a module, as long as the following conditions are met:

□ The module must be on GitHub and must be a public repo. This is required only for using the public registry; for private ones, this can
be ignored.

□ Repositories must use a naming format: terraform-<PROVIDER>-<NAME>, where PROVIDER is the provider where resources are
created, and NAME is the type of infrastructure managed by the module.

□ The module repository must have a description, which is used to populate the short description of the module. This should be a simple
one sentence description of the module.

□ The module should adhere to the standard module structure (main.tf, outputs.tf, variables.tf). The registry uses this
information to inspect the module and generate documentation.

□ Uses x.y.z tags for releases. The registry uses these tags to identify module versions. Release tag names must be a semantic version,
and can be optionally prefixed with a "v".

■ Published modules support versioning, automatically generate documentation, allow browsing version histories, show examples and
READMEs, and more.

Terraform
 Terraform
Object Validation
Object Validation
More reliable infrastructure through pre and postconditions, and check assertions

Preconditions Postconditions Check assertions

lifecycle { lifecycle { check "my_custom_check" {

precondition { postcondition { assertion {
condition = ... condition = ... condition = ...
error_message = "..." error_message = "..." error_message = "..."
} } }
} } }

■ Used from within resources and data ■ Used from within resources and data ■ Used from outside resources and data
blocks blocks blocks

■ Cannot reference the resource itself. ■ Can reference the resource itself. ■ Can reference information from across
the current Terraform project.
■ Can be used to check the validity of data ■ Can be used to check the validity of the
blocks or variables that the resource resource's configuration. ■ Results only in a warning and does not
references. stop the apply process.

Terraform
Object Validation - Pre and Postconditions

No Terraform exits
without going into the
apply phase

Yes Validation
executed apply phase
Yes
Validation
successful?
Validation
successful? Terraform exits
Validation deferred Validation No without applying
No
plan phase until the apply executed downstream
phase resources

Yes
Information
already available?
The apply phase executes until there are no more
changes to be applied.

Terraform
 Terraform
State Manipulation
State Manipulation
Recreate, import, refactor, and untrack infrastructure within Terraform

Tainting Importing Refactoring

Force the recreation of a resource that is Import existing resources into a Rename resources without recreating
tracked by a Terraform configuration. Terraform project, and start managing them, and move them inside and outside
Can be used when a certain resource them with Infrastructure as Code. of modules whenever needed. Prevents
goes into an invalid state, but the recreation due to changing resource
configuration is correct and hasn't addresses in Terraform.
changed.

Untracking Generating Configuration Fine-grained State File Changes

Remove a resource from a Terraform Leverage Terraform's code generation Force state unlocking, and pull and push
configuration without actually destroying feature to generate a best-effort the state file from remote backends to
that resource. Useful when we want to configuration based on existing perform careful, fine-grained editing in
manage the resource independently of resources. Can be used when importing case something is wrong with it.
the Terraform project. resources into Terraform.

Terraform
 Terraform
Workspaces
Workspaces
Use a single code-base for different environments

■ Workspaces allow us to leverage the same configuration directory to create different environments.

□ As a result, we can reduce code duplication and avoid installing multiple copies of modules and providers.

■ When using the CLI in a workspace, resources from other workspaces are not considered.

■ Different workspaces correspond to different state data. Terraform stores them in different .tfstate files.

■ Terraform always has at least one workspace called default.

□ The default workspace is created when we initialize the Terraform project.

□ It is used by default when we do not specify any other workspace.

■ Most, but not every, remote backend support workspaces.

■ We can use terraform.workspace to access the current workspace, and change options based on the selected workspace.

□ Recommendation: do not use terraform.workspace for conditional operations. Instead, receive the information via variables.

■ This is different from Terraform Cloud's workspaces.

Terraform
 Terraform
Terraform Cloud
Terraform Cloud
Execute Terraform code in a secure remote environment instead of locally

■ Terraform Cloud is a solution from HashiCorp to manage Terraform projects remotely. It offers several features:

□ Access control to approving infrastructure changes

□ Secure state and secret storage

□ Graphical representation of managed resources

□ Private registry for sharing modules within an organization

□ Policy controls for managing the contents of Terraform projects

□ Run history

■ Offers a free and a paid tier.

■ Resources are organized into workspaces, and workspaces can be organized into projects.

■ Workspaces store resource definitions, environment and input variables, and state files.

Terraform
Terraform Cloud - Workspaces
Organize workspace information in a single place

■ They are a required component of Terraform Cloud Local Terraform Terraform Cloud
projects.
Configuration Saved on disk VCS repository,
■ In addition to managing information in a central place, API/CLI
workspaces are also a major component of role-based
access to Terraform projects in Terraform Cloud.
Variables Passed via the different Saved in workspace
■ Paid plans offer workspace-based health checks that methods we explored
support drift detection and continuous infrastructure (.tfvars, CLI arguments,
validation, as well as other advanced features. etc.)

■ Workspaces can be linked to branches of VCS repositories, State file Saved locally or by using a Saved in workspace
and we can specify which files and directories within the remote backend
VCS repository trigger runs.
Secrets Passed via environment Saved in workspace
variables or through the
prompt

Terraform
 Terraform
Terraform Cloud Workflows
Terraform Cloud Workflows
Trigger runs from the CLI, UI, connected VCS repositories, or the Terraform API

CLI UI / API VCS Repository

Terraform CLI push Terraform

commands Terraform Terraform
files Terraform files
Cloud Terraform Cloud Cloud
files

CLI-driven workflow: developers or UI or API-driven workflow: developers VCS-driven workflow: developers push
CI/CD systems login to Terraform Cloud or systems manually trigger and code to a remote repository, which then
via the CLI and interact with the remote manage runs by interacting with triggers the terraform plan and apply
environment via CLI commands. Terraform Cloud's UI or API. commands.

Terraform