DEV Community: Bartłomiej Danek

Terragrunt folder structure and include

Bartłomiej Danek — Wed, 15 Apr 2026 12:21:09 +0000

folder structure

Terragrunt projects split config into two layers: a root hcl file with shared settings, and per-unit terragrunt.hcl files that inherit from it.

root.hcl
environments/
├── dev/
│   ├── vpc/
│   │   └── terragrunt.hcl
│   ├── rds/
│   │   └── terragrunt.hcl
│   └── eks/
│       └── terragrunt.hcl
└── prod/
    ├── vpc/
    │   └── terragrunt.hcl
    ├── rds/
    │   └── terragrunt.hcl
    └── eks/
        └── terragrunt.hcl

Each leaf terragrunt.hcl is one Terraform unit - its own state file, its own apply.

`include` - inherit from root

# environments/prod/vpc/terragrunt.hcl
include "root" {
  path = find_in_parent_folders("root.hcl")
}

terraform {
  source = "git::https://github.com/org/tf-modules.git//vpc?ref=v1.2.0"
}

inputs = {
  name       = "prod-vpc"
  cidr_block = "10.0.0.0/16"
}

root.hcl

# root.hcl
locals {
  env    = basename(dirname(get_terragrunt_dir()))
  region = "eu-west-1"
}

remote_state {
  backend = "s3"
  config = {
    bucket         = "my-tf-state"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = local.region
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "aws" {
  region = "${local.region}"
}
EOF
}

`find_in_parent_folders`

Walks up the directory tree until it finds the file - no hardcoded paths needed.

include "root" {
  path = find_in_parent_folders()          # finds root.hcl by default
}

include "root" {
  path = find_in_parent_folders("root.hcl") # explicit name
}

Originally published at https://bard.sh/posts/terragrunt_folder_structure/

Terragrunt remote_state and generate blocks

Bartłomiej Danek — Wed, 15 Apr 2026 12:19:59 +0000

`remote_state`

Defines the backend once in root.hcl - Terragrunt auto-generates the backend config for every unit that includes it.

# root.hcl
remote_state {
  backend = "s3"
  config = {
    bucket         = "my-tf-state"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "eu-west-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
}

path_relative_to_include() resolves to the path of the calling terragrunt.hcl relative to root.hcl - e.g. environments/prod/vpc - giving each unit a unique state key automatically.

`generate` block

Writes any file before running Terraform - typically used for provider.tf and backend.tf so they don't need to be duplicated in every module.

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "aws" {
  region = "eu-west-1"

  default_tags {
    tags = {
      ManagedBy   = "terraform"
      Environment = "prod"
    }
  }
}
EOF
}

`if_exists` options

overwrite_terragrunt - overwrite only if Terragrunt generated the file (safe default)
overwrite - always overwrite
skip - skip if file exists
error - error if file exists

generating multiple files

generate "versions" {
  path      = "versions.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
EOF
}

Originally published at https://bard.sh/posts/terragrunt_remote_state/

What is Terragrunt and why you need it

Bartłomiej Danek — Wed, 15 Apr 2026 12:19:14 +0000

the multi-env problem

With plain Terraform, managing multiple environments means duplicating config - same modules, different variable files, same backend boilerplate repeated everywhere.

environments/
├── dev/
│   ├── main.tf        # copy
│   ├── variables.tf   # copy
│   └── backend.tf     # copy with different key
├── staging/
│   ├── main.tf        # copy
│   ├── variables.tf   # copy
│   └── backend.tf     # copy with different key
└── prod/
    ├── main.tf        # copy
    ├── variables.tf   # copy
    └── backend.tf     # copy with different key

Any change to the module requires updating all three.

what Terragrunt does

Terragrunt is a thin wrapper around Terraform that adds:

DRY backend config - define once, inherit everywhere
dependency blocks - wire modules together without a monolith
run-all - apply/plan/destroy across multiple modules in one command
generate blocks - auto-generate files (provider configs, backend configs)
mock_outputs - unblock plan in CI when dependencies haven't been applied yet

terraform vs terragrunt

	Terraform	Terragrunt
Backend config	per-module	inherited from root
Multi-module apply	manual	`run-all`
Module wiring	`terraform_remote_state`	`dependency` block
DRY config	variables only	full config inheritance

installation

asdf plugin-add terragrunt
asdf install terragrunt 0.67.0
asdf local terragrunt 0.67.0

or developer.hashicorp.com/terraform/tutorials/automation/terragrunt

what the structure looks like

Instead of duplicated .tf files, you get one root.hcl and small terragrunt.hcl files per unit that only define what's different:

root.hcl
environments/
├── dev/
│   ├── vpc/
│   │   └── terragrunt.hcl   # 5 lines: include + inputs
│   ├── rds/
│   │   └── terragrunt.hcl
│   └── eks/
│       └── terragrunt.hcl
└── prod/
    ├── vpc/
    │   └── terragrunt.hcl
    ├── rds/
    │   └── terragrunt.hcl
    └── eks/
        └── terragrunt.hcl

A typical leaf terragrunt.hcl:

include "root" {
  path = find_in_parent_folders("root.hcl")
}

terraform {
  source = "git::https://github.com/org/tf-modules.git//vpc?ref=v1.2.0"
}

inputs = {
  name       = "prod-vpc"
  cidr_block = "10.0.0.0/16"
}

The backend, provider, and locking config all come from root.hcl - no repetition.

See folder structure and include for the full root.hcl setup.

Originally published at https://bard.sh/posts/what_is_terragrunt/

Terraform data sources

Bartłomiej Danek — Wed, 15 Apr 2026 12:19:13 +0000

data sources

Data sources let you read existing infrastructure without managing it - useful for referencing resources created outside Terraform or in another state file.

data "aws_vpc" "main" {
  filter {
    name   = "tag:Name"
    values = ["main"]
  }
}

resource "aws_subnet" "app" {
  vpc_id     = data.aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

common data sources

# latest Amazon Linux 2 AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# current AWS account ID
data "aws_caller_identity" "current" {}

output "account_id" {
  value = data.aws_caller_identity.current.account_id
}

# existing S3 bucket (not managed by this config)
data "aws_s3_bucket" "shared_logs" {
  bucket = "my-shared-logs"
}

reading from another state file

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "my-tf-state"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_instance" "app" {
  subnet_id = data.terraform_remote_state.network.outputs.private_subnet_id
  ami       = data.aws_ami.amazon_linux.id
}

data source vs resource

	`resource`	`data`
creates/modifies	yes	no
shows in plan	yes	no
can destroy	yes	no
reads on	apply	plan + apply

Originally published at https://bard.sh/posts/terraform_data_sources/

Terragrunt run-all

Bartłomiej Danek — Wed, 15 Apr 2026 12:18:43 +0000

`run-all`

Runs a Terraform command across all units in the current directory tree, respecting dependency order.

cd environments/prod
terragrunt run-all plan
terragrunt run-all apply
terragrunt run-all destroy   # reverse order

dependency-aware ordering

environments/prod/
├── vpc/
├── rds/          # depends on vpc
└── eks/          # depends on vpc

run-all apply applies vpc first, then rds and eks in parallel.

real CI pipeline

# .github/workflows/deploy.yml
- name: Plan all
  run: terragrunt run-all plan --terragrunt-non-interactive
  working-directory: environments/prod

- name: Apply all
  run: terragrunt run-all apply --terragrunt-non-interactive -auto-approve
  working-directory: environments/prod
  if: github.ref == 'refs/heads/main'

Detect drift in CI without applying:

# exit code 2 = changes detected, 0 = no changes, 1 = error
terragrunt run-all plan \
  --terragrunt-non-interactive \
  -detailed-exitcode

filtering

# skip a unit
terragrunt run-all apply --terragrunt-exclude-dir environments/prod/rds

# target a single unit and its dependencies
terragrunt run-all apply --terragrunt-include-dir environments/prod/eks

parallelism

# default is unlimited parallel - cap it if you hit API rate limits
terragrunt run-all apply --terragrunt-parallelism 4

output

Each unit prefixes its own output:

[environments/prod/vpc] Apply complete! Resources: 12 added.
[environments/prod/rds] Apply complete! Resources: 4 added.
[environments/prod/eks] Apply complete! Resources: 31 added.

Originally published at https://bard.sh/posts/terragrunt_run_all/

Terraform S3 backend with state locking

Bartłomiej Danek — Wed, 15 Apr 2026 12:18:42 +0000

S3 backend with state locking

S3 stores the state file, DynamoDB handles locking - prevents two apply runs from corrupting state simultaneously.

setup

terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

create the S3 bucket and DynamoDB table

resource "aws_s3_bucket" "tf_state" {
  bucket = "my-tf-state"
}

resource "aws_s3_bucket_versioning" "tf_state" {
  bucket = aws_s3_bucket.tf_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "tf_state" {
  bucket = aws_s3_bucket.tf_state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_dynamodb_table" "tf_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

state locking in action

$ terraform apply
Acquiring state lock. This may take a few moments...

# if another process holds the lock:
Error: Error acquiring the state lock
Lock Info:
  ID:        abc-123
  Path:      prod/terraform.tfstate
  Operation: OperationTypeApply
  Who:       alice@machine
  Created:   2024-10-14 12:00:00

force-unlock (use carefully)

terraform force-unlock <lock-id>

per-environment keys

# dev
backend "s3" {
  key = "dev/terraform.tfstate"
}

# prod
backend "s3" {
  key = "prod/terraform.tfstate"
}

Originally published at https://bard.sh/posts/terraform_s3_backend/

.terraform.lock.hcl - commit it

Bartłomiej Danek — Wed, 15 Apr 2026 12:15:18 +0000

`.terraform.lock.hcl` - commit it

Terraform generates this file on terraform init - it pins the exact provider versions and their checksums so every team member and CI run uses the same binaries.

provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.50.0"
  constraints = "~> 5.0"
  hashes = [
    "h1:abc123...",
    "zh:def456...",
  ]
}

what it contains

version - exact version that was selected
constraints - the constraint from required_providers
hashes - checksums for each platform (linux, darwin, windows)

why commit it

reproducible builds - everyone gets the same provider binary
audit trail - version changes are visible in git diff
faster CI - Terraform can skip checksum verification with -lockfile=readonly

updating it

# upgrade a specific provider
terraform init -upgrade

# upgrade all providers
terraform init -upgrade -reconfigure

CI flag

# fails if lock file is out of date - use in CI
terraform init -lockfile=readonly

Originally published at https://bard.sh/posts/terraform_lock_hcl/

Terraform and HCP Terraform

Bartłomiej Danek — Wed, 15 Apr 2026 12:15:17 +0000

what is terraform

Terraform is a CLI tool for building and managing infrastructure as code. You describe what you want, it figures out how to get there.

written in HCL
no enforced file structure
dependencies between resources are expressed in code
API wrapper for AWS, GCP, Azure, Kubernetes, GitHub, and many more
immutable infrastructure by default

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.small"
}

CLI

terraform init            # initialize, download providers
terraform plan            # dry run - shows what will change
terraform apply           # apply changes
terraform destroy         # destroy everything
terraform validate        # validate config files
terraform fmt             # auto-format
terraform state           # inspect and manipulate state
terraform output          # show outputs
terraform console         # interactive expression evaluator

topics

variables

variable "env" {
  type        = string
  description = "Deployment environment"
  default     = "dev"
}

# use it
resource "aws_instance" "web" {
  tags = { Environment = var.env }
}

Pass values via terraform.tfvars, -var flag, or TF_VAR_ env vars.

locals

locals {
  prefix = "${var.env}-${var.region}"
}

resource "aws_s3_bucket" "logs" {
  bucket = "${local.prefix}-logs"
}

outputs

output "instance_ip" {
  value = aws_instance.web.public_ip
}

output "db_password" {
  value     = aws_db_instance.main.password
  sensitive = true
}

modules

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "main"
  cidr = "10.0.0.0/16"
}

good practices

always commit .terraform.lock.hcl
use for_each over count for named resources
specify exact provider versions: ~> 5.50
use encrypted remote backend
terraform fmt before every commit
use moved blocks instead of destroy + recreate
avoid null_resource - there is usually a better way

Originally published at https://bard.sh/posts/terraform/

Terraform lifecycle rules

Bartłomiej Danek — Wed, 15 Apr 2026 12:14:44 +0000

lifecycle rules

lifecycle controls how Terraform creates, updates, and destroys a resource.

resource "aws_db_instance" "main" {
  identifier = "main-db"

  lifecycle {
    create_before_destroy = true
    prevent_destroy       = true
    ignore_changes        = [password, engine_version]
  }
}

`create_before_destroy`

By default Terraform destroys then creates. With create_before_destroy it creates the replacement first - useful for resources that can't have downtime (load balancers, DNS records, certificates).

resource "aws_instance" "web" {
  ami           = data.aws_ami.latest.id
  instance_type = "t3.small"

  lifecycle {
    create_before_destroy = true
  }
}

`prevent_destroy`

Blocks terraform destroy and any plan that would delete the resource. Good for databases and S3 buckets you can't lose.

resource "aws_s3_bucket" "critical" {
  bucket = "company-backups"

  lifecycle {
    prevent_destroy = true
  }
}

# this will error:
terraform destroy
# Error: Instance cannot be destroyed

`ignore_changes`

Stops Terraform from overwriting fields that change outside of Terraform - e.g. auto-scaling group sizes, passwords rotated by another tool.

resource "aws_autoscaling_group" "app" {
  name             = "app-asg"
  desired_capacity = 2

  lifecycle {
    ignore_changes = [desired_capacity]
  }
}

Use ignore_changes = all to ignore every attribute - useful for resources fully managed externally.

`replace_triggered_by`

Force replacement when another resource or attribute changes:

resource "aws_instance" "app" {
  ami = data.aws_ami.latest.id

  lifecycle {
    replace_triggered_by = [aws_security_group.app.id]
  }
}

Originally published at https://bard.sh/posts/terraform_lifecycle/

Nomad

Bartłomiej Danek — Wed, 15 Apr 2026 12:14:43 +0000

Nomad

workload orchestrator (containers, java, vm, windows, binaries)
single binary (linux, arm, osx, windows)
unified workflow for deployments
- zero downtime (blue-green, canary, rolling-release)
- batch
- service / system
easily integrates with Consul and Vault
plugin system: CSI, CNI
uses HCL to define workloads

installation

asdf plugin-add nomad
asdf install nomad 1.8.0
asdf local nomad 1.8.0

or developer.hashicorp.com/nomad/downloads

CLI

nomad run    <job>       # run/update a job
nomad stop   <job>       # stop a job
nomad status [job]       # check status
nomad agent  -dev        # run agent in dev mode
nomad exec   <alloc> sh  # exec into allocation
nomad -help              # global help

architecture

Job - declared workload; defines desired state
Task Group - set of tasks that must run together
Driver - tool to run a workload (docker, exec, java...)
Task - smallest unit of work
Client - machine where tasks run
Allocation - mapping of task group to client
Evaluation - scheduling decision mechanism
Server - brain of the cluster

job
  \_ group
        \_ task

job spec

job "api" {
  datacenters = ["dc1"]
  type        = "service"

  update {
    max_parallel = 2
    stagger      = "30s"
  }

  group "api" {
    count = 3

    network {
      port "http" {}
    }

    task "server" {
      driver = "docker"

      config {
        image = "my-org/api:1.2.3"
        ports = ["http"]
      }

      resources {
        cpu    = 500
        memory = 256
      }

      service {
        name = "api"
        port = "http"

        check {
          type     = "http"
          path     = "/health"
          interval = "10s"
          timeout  = "2s"
        }
      }
    }
  }
}

dev mode

$ nomad agent -dev
# UI at http://localhost:4646
# do NOT use in production

deployments

rolling update

update {
  max_parallel     = 1
  min_healthy_time = "10s"
  healthy_deadline = "3m"
}

canary

update {
  canary       = 1
  max_parallel = 2
  auto_promote = false
}

Promote manually after verifying:

nomad deployment promote <deployment-id>

blue-green

update {
  canary       = 3   # equal to group count
  max_parallel = 3
  auto_promote = false
}

plan and apply

$ nomad job plan api.nomad
Job Modify Index: 7
To submit with version verification:
  nomad run -check-index 7 api.nomad

$ nomad run -check-index 7 api.nomad

history and revert

$ nomad job history api
Version = 3  Stable = true  Submit Date = ...
Version = 2  Stable = true  Submit Date = ...
Version = 1  Stable = false Submit Date = ...

$ nomad job revert api 2

scheduled batch jobs

job "nightly-report" {
  type = "batch"

  periodic {
    crons = ["0 2 * * *"]
  }

  group "report" {
    task "run" {
      driver = "docker"
      config {
        image   = "my-org/reporter:latest"
        command = "/app/report"
      }
    }
  }
}

For service discovery and load balancing with Consul - see Consul service discovery.

Originally published at https://bard.sh/posts/nomad_and_consul/

Terraform dynamic blocks

Bartłomiej Danek — Wed, 15 Apr 2026 12:10:46 +0000

dynamic blocks

dynamic generates repeated nested blocks from a variable - avoids copy-pasting the same block for each item.

variable "ingress_rules" {
  default = [
    { port = 80,  protocol = "tcp", cidr = "0.0.0.0/0" },
    { port = 443, protocol = "tcp", cidr = "0.0.0.0/0" },
    { port = 22,  protocol = "tcp", cidr = "10.0.0.0/8" },
  ]
}

resource "aws_security_group" "web" {
  name = "web"

  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = ingress.value.protocol
      cidr_blocks = [ingress.value.cidr]
    }
  }
}

iterator name

By default the iterator is the block label (ingress above). Override it with iterator:

dynamic "ingress" {
  for_each = var.ingress_rules
  iterator = rule
  content {
    from_port = rule.value.port
    to_port   = rule.value.port
    protocol  = rule.value.protocol
  }
}

conditional block

To make a block optional, pass an empty list or a one-element list:

variable "enable_logging" {
  default = true
}

resource "aws_s3_bucket" "main" {
  bucket = "my-bucket"

  dynamic "logging" {
    for_each = var.enable_logging ? [1] : []
    content {
      target_bucket = "my-logs-bucket"
    }
  }
}

nested dynamic blocks

dynamic "rule" {
  for_each = var.rules
  content {
    action = rule.value.action

    dynamic "condition" {
      for_each = rule.value.conditions
      content {
        field  = condition.value.field
        values = condition.value.values
      }
    }
  }
}

Originally published at https://bard.sh/posts/terraform_dynamic_blocks/

for_each over tuple in Terraform

Bartłomiej Danek — Wed, 15 Apr 2026 12:10:45 +0000

`for_each` over tuples in terraform

Terraform does not allow to iterate through a tuple with for_each, but you can create one in the fly.

locals {
  cron_jobs = [
    {
      name    = "every-15-minutes"
      command = "rake send:sms:notification"
      cron    = "*/15 * * * * *"
    },
    {
      name    = "every-30-minutes"
      command = "rake send:sqs:notification"
      cron    = "*/30 * * * * *"
    }
  ]
}

resource "nomad_job" "cron_jobs" {
  for_each = { for cj in local.cron_jobs : cj.name => cj }

  jobspec = templatefile("cron_job.tpl", {
    name    = each.key
    command = each.value.command
    cron    = each.value.cron
  })
}

Inside the block, each.key is the map key (cj.name) and each.value is the full object.

`for_each` over a plain list

For a simple list of strings, convert it to a set first with toset() - this is required because sets have no index.

variable "buckets" {
  default = ["logs", "backups", "artifacts"]
}

resource "aws_s3_bucket" "this" {
  for_each = toset(var.buckets)
  bucket   = each.key
}

each.key and each.value are identical when iterating a set.

`for_each` over a map

variable "buckets" {
  default = {
    logs      = "us-east-1"
    backups   = "eu-west-1"
  }
}

resource "aws_s3_bucket" "this" {
  for_each = var.buckets
  bucket   = each.key
  region   = each.value
}

Originally published at https://bard.sh/posts/for_each/

DEV Community: Bartłomiej Danek

Terragrunt folder structure and include

folder structure

include - inherit from root

root.hcl

find_in_parent_folders

Terragrunt remote_state and generate blocks

remote_state

generate block

if_exists options

generating multiple files

What is Terragrunt and why you need it

the multi-env problem

what Terragrunt does

terraform vs terragrunt

installation

what the structure looks like

Terraform data sources

data sources

common data sources

reading from another state file

data source vs resource

Terragrunt run-all

run-all

dependency-aware ordering

real CI pipeline

filtering

parallelism

output

Terraform S3 backend with state locking

S3 backend with state locking

setup

create the S3 bucket and DynamoDB table

state locking in action

force-unlock (use carefully)

per-environment keys

.terraform.lock.hcl - commit it

.terraform.lock.hcl - commit it

what it contains

why commit it

updating it

CI flag

Terraform and HCP Terraform

what is terraform

CLI

topics

variables

locals

outputs

modules

good practices

Terraform lifecycle rules

lifecycle rules

create_before_destroy

prevent_destroy

ignore_changes

replace_triggered_by

Nomad

Nomad

installation

CLI

architecture

job spec

dev mode

deployments

rolling update

canary

blue-green

plan and apply

history and revert

scheduled batch jobs

Terraform dynamic blocks

dynamic blocks

iterator name

conditional block

nested dynamic blocks

for_each over tuple in Terraform

for_each over tuples in terraform

for_each over a plain list

for_each over a map

`include` - inherit from root

`find_in_parent_folders`

`remote_state`

`generate` block

`if_exists` options

`run-all`

`.terraform.lock.hcl` - commit it

`create_before_destroy`

`prevent_destroy`

`ignore_changes`

`replace_triggered_by`

`for_each` over tuples in terraform

`for_each` over a plain list

`for_each` over a map