Terraform: Infrastructure as Code and Your First Configuration
Edited by Dev Kilaru, Senior Data Analyst. How we make our content
Introduction
Infrastructure as Code means describing servers, networks, and services in files instead of clicking through consoles, so environments are repeatable, reviewable, and version controlled. Terraform is the most widely used tool for this. In this first lesson of four, you learn the workflow using the free local and random providers, so there is no cloud account and no cost.
Prerequisites
- A terminal
- Terraform installed (see the install step)
Step-by-Step Guide
Step 1: Understand what Terraform does
You write configuration in HashiCorp Configuration Language (HCL) describing the resources you want. Terraform compares that with what exists, shows you a plan of the changes it would make, and applies them when you approve. Provider plugins, such as those for AWS, Azure, Google Cloud, and many others, let it manage each platform. The record of what it manages is kept in a state file.
Step 2: Install Terraform
On macOS use Homebrew with HashiCorp's tap. On Windows, download the zip from HashiCorp's install page, extract terraform.exe, and add its folder to your PATH. On Linux, use HashiCorp's apt or yum repository from the install page. Confirm the installation with the version command. Terraform 1.16 was the current release when this was written; check the install page for the latest.
# macOS
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
terraform versionStep 3: Write your first configuration
Create an empty folder and a file named main.tf. The terraform block declares the providers you need, with version constraints. The configuration creates a random pet name and writes a text file containing it. The ~> constraint allows newer releases within the same major version, which keeps upgrades safe.
terraform {
required_providers {
random = {
source = "hashicorp/random"
version = "~> 3.0"
}
local = {
source = "hashicorp/local"
version = "~> 2.0"
}
}
}
resource "random_pet" "name" {
length = 2
}
resource "local_file" "greeting" {
filename = "${path.module}/hello.txt"
content = "Hello from ${random_pet.name.id}!\n"
}
output "pet_name" {
value = random_pet.name.id
}Step 4: Run the core workflow
init downloads the providers and prepares the folder, and writes a lock file. fmt formats your files and validate checks them. plan previews changes: a plus means create, a minus destroy, a tilde change in place. apply makes them after you confirm. destroy removes everything Terraform created, and you can run it safely here.
terraform init
terraform fmt
terraform validate
terraform plan
terraform apply
terraform output
terraform destroyStep 5: Know what to commit and the OpenTofu option
Commit your .tf files and the .terraform.lock.hcl lock file, which records the exact provider versions so everyone on the team uses the same ones. Do not commit the .terraform folder, state files, or plan files. Terraform is licensed under the Business Source License, and the community fork OpenTofu, an open-source project hosted by the Linux Foundation, uses the same core workflow with a command called tofu. Check OpenTofu's migration guide before switching an existing project.
# .gitignore
.terraform/
*.tfstate
*.tfstate.*
*.tfplanFAQs
- Why plan before apply?
- The plan shows exactly what Terraform intends to create, change, or destroy, so mistakes are caught before they affect real systems. In team pipelines, the reviewed plan is what gets applied.
- Does Terraform only work with cloud providers?
- No. It can manage anything with a provider, including Kubernetes, DNS, monitoring tools, and, as here, local files, which makes it a safe place to practice.
Summary
Describe resources in HCL, then init, plan, and apply to make reality match. Commit the code and lock file, ignore state and the .terraform folder, and practice with the local and random providers before touching a cloud account.
Comments
Log in or create a free account to join the discussion.