2 Terraform-Overview

Terraform – Getting Started
Provisioning infrastructure
through software to achieve
consistent and predictable
environments.
Core Concepts
Stored in source Declarative or

Defined in code
control imperative
Idempotent and
Push or pull
consistent
Infrastructure as Code Benefits
Automated deployment
Consistent environments
Repeatable process
Reusable components
Documented architecture
Automating Infrastructure Deployment
Provisioning Planning Using Source Reusing

Resources Updates Control Templates
Terraform
● A provisioning declarative tool that based on Infrastructure as a
Code paradigm
● Uses own syntax - HCL (Hashicorp Configuration
Language)
● Written in Golang.
● Helps to evolve you infrastructure, safely and predictably
● Applies Graph Theory to IaaC
● Terraform is a multipurpose composition tool:
○ Composes multiple tiers (SaaS/PaaS/IaaS)
○ A plugin-based architecture model
● Open source. Backed by Hashicorp company and
Hashicorp Tao (Guide/Principles/Design)
Other tools
● Cloudformation, Heat, etc.

● Ansible, Chef, Puppet, etc.
● Boto, fog, apache-libcloud, etc.
● Custom tooling and scripting
AWS Cloudformation VS OpenStack Orchestration (Heat)
● AWS Locked-in ● Open source

● Initial release in 2011 ● Initial release around 2012
● Sources hidden behind a scene ● Heat provides
● AWS Managed Service / Free
● Cloudformation Designer
CloudFormation-compatible
○ Drag-and-drop interface. Query API for Openstack
● Json, Yaml (since 2016) ● UI: Heat Dashboard
● Rollback actions for stack updates
● Change sets (since 2016)
● Yaml
Ansible, Chef, Puppet, etc
● Created for the purpose to be a configuration management tool.

● Suggestion: don’t try to mix configuration management and resource
orchestration.
● Different approaches:
○ Declarative: Puppet, Salt
○ Imperative: Ansible, Chef
● The steep learning curve if you want to use orchestration capabilities of some
of these tools.
● Different languages and approaches:
○ Chef - Ruby
○ Puppet - Json-like syntax / Ruby
○ Ansible – Yaml | python
Boto, fog, apache-libcloud, etc.
● low-level access to APIs

● Some libs focused on specific cloud providers, others provide common
interface for few different clouds
● Inspires to create custom tooling
Custom tooling and scripting

● Error-prone and tedious
● Requires many human-hours
● The minimum viable features
● Slowness or impossibility to evolve, adopt to quickly changing environments
Terraform is not a cloud agnostic tool
It’s not a magic wand that gives you power over all clouds and systems.
It embraces all major Cloud Providers and provides common language to orchestrate your infrastructure resources.
Architecture
Architecture
Architecture
Architecture
Architecture
Terraform Components
Terraform Executable Terraform File
Terraform Providers Terraform Statefile
API Terraform config file

Terraform Executable
Terraform Providers
Terraform Providers
IaaS, PaaS, and SaaS

Community and HashiCorp
- AWS, Azure, GCP, and Oracle
Open source using APIs

Resources and data sources
Multiple instances
Terraform: Providers (Plugins)
1125+ infrastructure providers
Major Cloud Partners

Terraform: Providers
Can be integrated with any API using providers framework
○ Note: Terraform Docs → Extending Terraform → Writing Custom Providers
● OpenFaaS ● Docker
● GitLab ● OpenAPI ● Kubernetes
● GitHub ● Generic Rest API ● Nomad
● BitBucket ● Stateful ● Consul
● DNS ● Vault
● Palo Alto Networks ● Terraform :)
● F5 BIG-IP
● Template
● Random
● NewRelic ● Digital Ocean
● Null
● Datadog ● Fastly
● External
● PagerDuty ● OpenStack
(escape hatch)
● Heroku
● Archive
Provider Example
provider “azurerm” {
subscription_id = “subscription-id”
client_id = “principal-used-for-access”
client_secret = “password-of-principal”
tenant_id = “tenant-id”
alias = “arm-1”
}
Terraform Code
Terraform Syntax
HashiCorp configuration language

Why not JSON?
Human readable and editable
Interpolation
Conditional, functions, templates

Terraform: Example (Simple resource)
Type Name
Terraform: Example (Simple local resource)
variable "aws_access_key" {} Variables
variable "aws_secret_key" {}
provider "aws" {
Provider
access_key = "access_key“
secret_key = “secret_key”
region = “us-east-1”
}
resource "aws_instance" "ex"{
Resource
ami = "ami-c58c1dd3"
instance_type = "t2.micro"
}
output "aws_public_ip" {
Output
value =
"${aws_instance.ex.public_dns}"
}
Code Example
provider “azurerm” {
subscription_id = “subscription-id”
client_id = “principal-used-for-access”
client_secret = “password-of-principal”
tenant_id = “tenant-id”
alias = “arm-1”
}
resource “azurerm_resource_group”{
name = “resource-group-name”
location = “East US”
provider = “azurerm.arm-1”
}
Terraform Syntax
#Create a variable
variable var_name {
key = value #type, default, description
}
#Use a variable
${var.name} #get string
${var.map[“key”]} #get map element
${var.list[idx]} #get list element
Terraform Syntax
#Create provider
provider provider_name {
key = value #depends on resource, use alias as needed
}
#Create data object
data data_type data_name {}
#Use data object
${data_type.data_name.attribute(args)}
Terraform Syntax
#Create resource
resource resource_type resource_name {
key = value #depends on resource
}
#Reference resource
${resource_type.resource_name.attribute(args)}
Terraform Workflow
Workflow: Adoption stages
Single
contributor
Terraform Core: Init
1. This command will never delete your existing configuration or state.

2. Checkpoint → https://checkpoint.hashicorp.com/
3. .terraformrc → enable plugin_cache_dir, disable checkpoint
4. Parsing configurations, syntax check
5. Checking for provisioners/providers (by precedence, only once)→
“.”, terraform_bin_dir, terraform.d/plugins/linux_amd64
.terraform/plugins/linux_amd64
6. File lock.json contains sha-512 plugin hashes (.terraform)
7. Loading backend config ( if it’s available, local instead )
Backend Initialization: Storage for terraform state file.
Terraform Core: Plan + Apply
1. Starting Plugins: Provisioners/Providers

2. Building graph
a. Terraform core traverses each vertex and requests each provider using parallelism
3. Providers syntax check: resource validation
4. If backend == <nil>, use local
5. If “-out file.plan” provided - save to file - the file is not encrypted
6. Terraform Core calculates the difference between the last-known state and
the current state
7. Presents this difference as the output of the terraform plan operation to user
in their terminal
Terraform Core: Destroy
1. Measure twice, cut once

2. Consider -target flag
3. Avoid run on production
4. No “Retain” flag - Remove resource from state file instead
5. terraform destroy tries to evaluate outputs that can refer to non existing
resources #18026
6. prevent_destroy should let you succeed #3874
7. You can’t destroy a single resource with count in the list
Terraform state
Terraform State
JSON format (Do not touch!)

Resources mappings and metadata
Locking
Local / remote
Environments
Terraform state file
1. Backup your state files + use Versioning and Encryption

2. Do Not edit manually!
3. Main Keys: cat terraform.tfstate.backup | jq 'keys'
a. "lineage" - Unique ID, persists after initialization
b. "modules" - Main section
c. "serial" - Increment number
d. "terraform_version" - Implicit constraint
e. "version" - state format version
4. Use “terraform state” command
a. mv - to move/rename modules
b. rm - to safely remove resource from the state. (destroy/retain like)
c. pull - to observe current remote state
d. list & show - to write/debug modules
Terraform State
• Terraform keeps the remote state of the infrastructure
• It stores it in a file called terraform.tfstate
• There is also a backup of the previous state in
terraform.tfstate.backup
• When you execute terraform apply, a new terraform.tfstate
and backup is written
• This is how terraform keeps track of the remote state
• If the remote state changes and you hit terraform
apply again, terraform will make changes to meet the
correct remote state again
• e.g. you terminate an instance that is managed by
terraform, after terraform apply it will be started again
Terraform State
• You can keep the terraform.tfstate in version control
• e.g. git
• It gives you a history of your terraform.tfstate file (which is
just a big JSON file)
• It allows you to collaborate with other team members
• Unfortunately you can get conflicts when 2 people
work at the same time
• Local state works well in the beginning, but when you
project becomes bigger, you might want to store your state
remote
Terraform State
The terraform state can be saved remote, using the backend functionality in
terraform.
The default is a local backend (the local terraform state file)

Other backbend's include:
s3 (with a looking mechanism using dynamoDB)
consul (with locking)
terraform enterprise (the commercial solution)
Simple workflow
UpdatingYour Configuration
with More Resources
Adding a New Provider to Your
Configuration
Terraform Command Overview
Terraform Advance Workflow
Team
Collaboration
Multiple
Teams
Examine the Terraform file
Demo
Deploy the configuration
Review the results
Play along!
- AWS account
- Demo files
Deploy theconfiguration
Demo Review theresults Play along!

- AWS account
- Azure subscription
- DNS domain
- Terraform software (terraform.io)
- Demo files
Demo Deploy the configuration
Review the results
Play along!
- AWS account
- Demo files
Demo Deploy the configuration
Review the results
Play along!
- AWS account
- Demo files

2 Terraform-Overview

Uploaded by

Copyright:

Available Formats

2 Terraform-Overview

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 Terraform-Overview

Uploaded by

Copyright:

Available Formats

Terraform – Getting Started

Stored in source Declarative or

Provisioning Planning Using Source Reusing

● Cloudformation, Heat, etc.

● AWS Locked-in ● Open source

● Created for the purpose to be a configuration management tool.

● low-level access to APIs

Custom tooling and scripting

Terraform Executable Terraform File

Terraform Providers Terraform Statefile

API Terraform config file

IaaS, PaaS, and SaaS

Open source using APIs

1125+ infrastructure providers

Major Cloud Partners

Can be integrated with any API using providers framework

○ Note: Terraform Docs → Extending Terraform → Writing Custom Providers

HashiCorp configuration language

Conditional, functions, templates

1. This command will never delete your existing configuration or state.

1. Starting Plugins: Provisioners/Providers

1. Measure twice, cut once

JSON format (Do not touch!)

1. Backup your state files + use Versioning and Encryption

The default is a local backend (the local terraform state file)

Demo Review theresults Play along!

You might also like