Term
|
Definition
| a way to consistently deploy stuff onto the cloud with scripts |
|
|
Term
|
Definition
| multi cloud IaC solution that works with all different cloud providers. Also works with on-prem resources. Similar solutions are AWS CloudFormation or Azure Resource Manager (ARM) |
|
|
Term
|
Definition
| is a plugin that acts as a bridge between Terraform and an external service. For example you can have a provider for Dominos, that lets you type the order into Terraform and it translates that into being able to talk to the Dominos API. To add one, add the provider version requirement in the terraform.tf config file and run terraform init |
|
|
Term
|
Definition
| a "dry run" that shows you what changes Terraform will make to your infrastructure without actually making them, so you can review them first. |
|
|
Term
|
Definition
| command that takes that plan and executes it, creating, updating, or deleting the resources to match your desired configuration. |
|
|
Term
|
Definition
| shows the "state file" or memory of your existing infrastructure so that Terraform doesn't have to scan it every time. Stores in a state file. Multiple people need access to this state file to make changes to infrastructure. |
|
|
Term
|
Definition
| current setup of your infrastructure. Used as main contact point when making changes to your infrastructure via Terraform |
|
|
Term
|
Definition
command to show a less detailed version of your current infrastructure than Terraform Show |
|
|
Term
|
Definition
| first command you'll run when you want to use a configuration file. It downloads providers plugins, installs modules, preps directory, etc. specified in the terraform.tf file. |
|
|
Term
|
Definition
| used to check the configuration file to make sure no typos. Like looking at instruction book before doing anything. Different in plan because it's not a dry run, it just looks at your config files and makes sure they look good. |
|
|
Term
|
Definition
| Terraform files that you define what you're building, destroying, or modifying. Things like main.tf, variables.tf, modules.tf, etc.. |
|
|
Term
| How save terraform plan to use later |
|
Definition
| terraform plan -out PLAN_NAME. Then use Terraform apply PLAN_NAME to run it |
|
|
Term
|
Definition
Terraform's proprietary coding language HCL that works with all other cloud platforms. Organized into "blocks"
Here is an example of 1 type of block, a "Resource block"
<block type> "<block label>" "<block label>" {
<identifier> = <expression>
EXAMPLE:
resource "aws_instance" "web_server" {
ami = "ami-9328f8v39v43g0"
Instance _type = var.instance_type |
|
|
Term
|
Definition
| a section of code in your Terraform to represent something. Can be one of these types of blocks: provider, resource, data, variable, output, module, locals |
|
|
Term
| How list all terraform providers installed |
|
Definition
| "Terraform providers" lists all current providers that are installed on your Terraform instance |
|
|
Term
|
Definition
Mainly used to define how to connect to a provider in your code. Can also be used to define variables for your providers. You can change certain things like the region to change where all IaC stuff is deployed.
Different than the settings block since this goes into more detail for your provider. The settings block just sets the provider and the version.
Example, placed into Main.tf file:
provider "aws" {
region = "us-east-1"
access_key = "AKIA55YS4XKR5GX3JB6Q"
secret_key = "ZKAT3b5cejVeWozJIyN/vkTF4teit2sC5fWKYI8S"
} |
|
|
Term
|
Definition
define certain resources in your cloud provider, like virtual networks, compute instances, or higher-level components such as DNS records.
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
Example, placed into Main.tf file:
resource "aws_route_table" "public_route_table" {
vpc_id = aws_vpc.vpc.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.internet_gateway.id
nat_gateway_id = aws_nat_gateway.nat_gateway.id
}
tags = {
Name = "demo_public_rtb"
Terraform = "true"
}
}
|
|
|
Term
|
Definition
block of text to be used to declare a variable to be used across your Terraform environment. Typically placed into it's own file called variables.tf. Good to set for things that will be the same in all of your terraform scripts, like availability zones, instance types, sizing or capacity, etc. Call it later by using "var.VARIABLE_NAME"
variable “<VARIABLE_NAME>” {
# Block body
type = <VARIABLE_TYPE>
description = <DESCRIPTION>
default = <EXPRESSION>
sensitive = <BOOLEAN>
validation = <RULES>
}
Example, placed into a variables.tf file
variable "aws_region" {
description = "AWS region to deploy resources"
type = string
default = "us-east-1"
}
Then call it by using:
provider "aws" {
region = var.aws_region
}
|
|
|
Term
Locals Variables Block
(how call local variable?)
(work with what other Terraform thing?) |
|
Definition
variable blocks located inside the actual code of your terraform script, like the main.tf file. To call it: Instead of var.VARIABLE_NAME you would use local.VARIABLE_NAME. Typically work together with input variables (var.VARIABLE_NAME) to build variables that all depend on each other. These are just used locally in the actual script you're running.
locals {
local_variable_name = <EXPRESSION OR VALUE>
local_variable_name2 = <EXPRESSION OR VALUE>
}
Example:
locals {
time = timestamp()
application = "api_server"
server_name = "${var.account}-${local.application}"
|
|
|
Term
|
Definition
block of data that is used to go out and find data based on an API query from the provider. It can find details about a resource that already exists, so you can use that detail in your config. Providers have a list of data blocks that they can return, certain resources only return certain data that you can play with.
data “<DATA TYPE>” “<DATA LOCAL NAME>” {
<IDENTIFIER> = <EXPRESSION>
}
Example will find the CPU core count for your EC2 instance. Cpu_core_count is pre-defined by AWS and is queried in this request
data "aws_instance" "my_ec2" {
instance_id = "i-0123456789abcdef0"
}
output "cpu_core_count" {
value = data.aws_instance.my_ec2.cpu_core_count
}
|
|
|
Term
| Configuration or Settings Block |
|
Definition
declaration of minimum requirements for your terraform script to run. Things like setting the minimum version for Terraform or the providers before your script even starts. Can set greater/lesser than arguments. Placed into a terraform.tf file.
Example, put this at the top of your main.tf terraform file
terraform {
required_version = ">= 1.0.0"
} |
|
|
Term
|
Definition
Small sections of Terraform code to be re-used to deploy stuff. usually saved into a modules folder, then each module has it's own main.tf, variable.tf, and output.tf files. So there would be a vpc_module for deploying VPCs, or a subnet_module for deploying subnets in those VPCs. |
|
|
Term
|
Definition
export data about your resources that you're creating/editing. Good for using with modules to export data from 1 module and import into another. Typically placed into an outputs.tf file. Will show at the end of your terraform script in a small text box in the terminal after running a terraform apply.
output “<NAME>” {
value= <EXPRESSION>
}
Example
output "web_server_ip" {
description = "Public IP Address of Web Server on EC2"
value = aws_instance.web_server.public_ip
sensitive = true
}
|
|
|
Term
|
Definition
runs scripts or commands on a resource after Terraform has created it. Consists of 3 types, local-exec, remote-exec, or files. Will either run a command on local machine or remote machine, or copy files to a resource. Placed in a resource block to define what you'd like to do to that resource.
Example, remote-exec is a provisioner that is used to run commands on a remote instance rather than locally. Will run the lines defined in the script on the ubuntu instance.
resource "aws_instance" "web" {
ami = "ami-12345678"
instance_type = "t2.micro"
provisioner "remote-exec" {
inline = [
"sudo apt-get update -y",
"sudo apt-get install -y nginx"
]
}
connection {
type = "ssh"
user = "ubuntu"
private_key = file("~/.ssh/id_rsa")
host = self.public_ip
}
} |
|
|
Term
How ensure provider is set to a specific version?
Where place the code? |
|
Definition
Must be defined in settings block usually at the top of your main.tf file.
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
|
|
|
Term
| Command to have Terraform format your code. Will auto-indent and line everything up and make it easy to use. |
|
Definition
|
|
Term
Terraform Taint
(how enter one in?)
(new version of this command?) |
|
Definition
Manually mark a resource for recreation. Informs Terraform that a particular resource needs to be rebuilt even if there has been no configuration change for that resource. Once a resource is "tainted" it will be destroyed/created every time script is ran.
To enter one in, run a terraform state list, then just use command below
Terraform taint <RESOURCE NAME>
Will see this:
terraform taint aws_instance.web_server
Resource instance aws_instance.web_server has been marked as tainted.
New command for this is "-replace=RESOURCE" on Terraform Apply. Will find the Terraform State List resource name, and mark as replace when your config runs:
terraform apply -replace="aws_instance.web_server" |
|
|
Term
|
Definition
Allows you to import existing infrastructure into it's existing state file. If something was created manually, or using another IAC tool, will need to do this to get that stuff into your state file.
Synax:
Terraform import <terraform resource name in state file> <ID of the resource>
Example:
terraform import aws_instance.aws_linux i-0bfff5070c5fb87b6 |
|
|
Term
|
Definition
A separate backup of your terraform config files. Like a github of your state file. Will allow you to have multiple configs (like Test, Dev, etc.) for your Terraform config files and set 1 as the default.
Syntax:
Terraform workspace COMMAND WORKSPACE_ENVIRONMENT
terraform workspace new development
Will create a new workspace, then you are automatically switched to it
terraform workspace show
development
Then you can run a Terraform apply and it will check the state file and create resources in your new state file
|
|
|
