DevOps Track · Day 1 Foundation · 20 min

IaC Foundations & Local Docker Infra
DevOps Terraform Sprint — Day 1

Install Terraform CLI, configure kreuzwerker/docker provider, provision an Nginx web container, and audit terraform.tfstate

🛠️ Tooling: Terraform 1.5+ & Docker Engine🎭 Role: DevOps & Infrastructure Quality Engineer

TerraformDockerIaCHCLCross-PlatformState Audits

About Today's 20-Minute Lab

Welcome to Day 1 of the DevOps Infrastructure as Code (IaC) Roadmap. Instead of requiring paid AWS/GCP cloud accounts, today you will build and provision real, declarative infrastructure locally on your machine (macOS, Windows, or Linux) using Terraform and the Docker Provider. You will write HashiCorp Configuration Language (HCL), inspect the local state engine (terraform.tfstate), and verify container port bindings.

🎬 Day 1 Video Walkthrough

⚡In a rush? Watch a quick knowledge bit in under 1 minute on today's lesson!

Watch Reel 📸

📦Sample Codebase & Working Solution (Day 1)Available Now

View on GitHub

The official reference codebase for Day 1 is hosted in our private GitHub repository. Clone the repository and navigate to the day-1-nginx directory to run the working solution.

Git Clone — Private Monorepo Solution

git clone https://github.com/letstrnsfrm-ai/devops-terraform-roadmap.git
cd devops-terraform-roadmap/day-1-nginx

Cross-Platform Tooling & Environment Setup

GOAL

Install Terraform CLI and ensure Docker Desktop or Docker Engine daemon socket is active on your machine.

INSTALLATION

Choose your operating system to install the Terraform CLI:

Terminal — macOS (Homebrew or Standalone Release)

# Option A: Homebrew (recommended)
brew tap hashicorp/tap && brew install hashicorp/tap/terraform

# Option B: Standalone Release Binary (if Homebrew compiler is out-of-date)
curl -O https://releases.hashicorp.com/terraform/1.7.5/terraform_1.7.5_darwin_arm64.zip
unzip terraform_1.7.5_darwin_arm64.zip && sudo mv terraform /usr/local/bin/

PowerShell — Windows (winget / Chocolatey)

# Option A: Windows Package Manager (winget)
winget install HashiCorp.Terraform

# Option B: Chocolatey
choco install terraform

Terminal — Linux (Ubuntu / Debian)

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

VERIFY DAEMON

Verify CLI versions and container daemon connectivity:

Terminal / PowerShell — Tooling & Daemon Check

# 1. Verify Terraform CLI version
terraform -version

# 2. Verify Docker daemon is running
docker --version
docker ps

# Note for macOS Colima users: colima start (and export DOCKER_HOST="unix://$HOME/.colima/default/docker.sock")

EXPECTED OUTPUT

Terminal Response

Terraform v1.7.5 (or higher) and active Docker container daemon details should be printed without connection errors.

🏭Production Context & Enterprise Real-World Implementation

💡 Why We Are Doing This: Before executing any automated infrastructure pipeline, CI/CD runners must establish deterministic binary versions and container daemon connectivity to prevent runtime failures.

🏢 Real-World Production Usecase: Enterprise platforms like Netflix and Stripe run CLI verification checks inside GitHub Actions runners and HashiCorp Terraform Cloud workers before executing automated infrastructure deployments.

⚙️ How Implemented in Production: In production, CLI binaries and container runtime daemons are pre-packaged into immutable Docker runner images (e.g. hashicorp/terraform:1.7) managed by Kubernetes runners or Atlantis server instances.

HCL Provider & Resource Blueprint

GOAL

Create a workspace directory and construct your declarative main.tf blueprint defining the Docker provider, image, and container resources.

DIR SETUP

Create a clean project folder on your machine:

Terminal / PowerShell — Create Project Directory

mkdir -p local-labs/day-1-nginx
cd local-labs/day-1-nginx

MAIN.TF CODE

Create a file named main.tf in your new directory:

HCL — main.tf

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0.1"
    }
  }
}

provider "docker" {}

# Pull Nginx Docker Image
resource "docker_image" "nginx" {
  name         = "nginx:alpine"
  keep_locally = false
}

# Provision Nginx Container with Port Forwarding (8080:80)
resource "docker_container" "nginx_web" {
  image = docker_image.nginx.image_id
  name  = "qe_terraform_nginx_day1"

  ports {
    internal = 80
    external = 8080
  }
}

🏭Production Context & Enterprise Real-World Implementation

💡 Why We Are Doing This: Declarative Infrastructure as Code (IaC) ensures that your cloud infrastructure is defined as code in version-controlled repositories, replacing error-prone manual UI click-ops.

🏢 Real-World Production Usecase: Production e-commerce platforms (like Shopify or Airbnb) store AWS/GCP infrastructure blueprints in Git repositories. Every change is reviewed via Pull Requests before provisioning microservices.

⚙️ How Implemented in Production: In production, provider definitions connect to cloud APIs (e.g. hashicorp/aws or google) using IAM assume-role credentials and automated OIDC authentication without storing secrets in code.

Provisioning & State Inspection

GOAL

Initialize the Terraform workspace to download provider plugins, plan the changes, apply the blueprint, and inspect the state file.

WORKFLOW

Run the classic 3-step Terraform lifecycle workflow:

Terminal / PowerShell — Init, Plan & Apply

# 1. Download kreuzwerker/docker provider plugin
terraform init

# 2. Dry-run execution plan
terraform plan

# 3. Apply the infrastructure changes
terraform apply -auto-approve

STATE AUDIT

Inspect how Terraform tracks managed infrastructure in JSON:

Terminal / PowerShell — Inspect terraform.tfstate

# macOS / Linux
cat terraform.tfstate | grep -E '"name"|"ip_address"|"ports"' -A 3

# Windows PowerShell
Get-Content terraform.tfstate | Select-String -Pattern "name","ports"

EXPECTED OUTPUT

Infrastructure Applied

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Terraform automatically creates terraform.tfstate mapping the HCL resource block to the active Docker container ID.

🏭Production Context & Enterprise Real-World Implementation

💡 Why We Are Doing This: Terraform's state file acts as the authoritative truth mapping HCL code declarations to real cloud resource IDs. Without state tracking, Terraform cannot detect modifications or clean up resources.

🏢 Real-World Production Usecase: In high-traffic products (like Uber or DoorDash), multiple SREs and developers deploy microservices concurrently. Centralized state management prevents simultaneous conflicting infrastructure updates.

⚙️ How Implemented in Production: In real production systems, local tfstate files are forbidden. Teams configure remote backends (AWS S3 + DynamoDB state locking, or Terraform Cloud) with AES-256 encryption and state locking enabled.

Local Verification & Resource Cleanup

GOAL

Test HTTP traffic against your newly provisioned web server, then destroy the infrastructure cleanly.

HTTP CHECK

Query the Nginx web container endpoint via curl or PowerShell:

Terminal / PowerShell — Verify Nginx Endpoint

# macOS / Linux
curl -I http://localhost:8080

# Windows PowerShell
Invoke-WebRequest -Uri http://localhost:8080

CLEANUP

Destroy all managed infrastructure resources when done:

Terminal / PowerShell — Tear Down Infrastructure

terraform destroy -auto-approve

EXPECTED OUTPUT

Verification Success

HTTP/1.1 200 OK returned by Nginx on port 8080.
Destroy complete! Resources: 2 destroyed. Container and image deleted cleanly.

🏭Production Context & Enterprise Real-World Implementation

💡 Why We Are Doing This: Automated post-provisioning smoke tests verify that provisioned infrastructure is healthy and routing network traffic correctly before routing live end-user traffic.

🏢 Real-World Production Usecase: Fintech applications (like Square or Klarna) rely on automated teardowns (`terraform destroy`) in ephemeral staging environments to save millions of dollars in idle cloud compute costs.

⚙️ How Implemented in Production: Production CI/CD pipelines run automated synthetic E2E tests against newly deployed staging environments, automatically triggering a automated rollback or teardown if HTTP health checks fail.