Terraform on ¬ just serendipity 🍀

terraform police

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 08 Jun 2026 01:21:44 +0200

♠ The Master wakes to a pager. Coffee is ready.

Apprentice: “Master, who created the drift?”

Master: “Which drift?”

Apprentice: “The bucket tag — live state ≠ terraform config in git.”

Master: “Show me the chain.”

They follow: pipeline → cronjob → github actions container → terraform CI bot → github pull request → human.

Apprentice: “We found them. Shall we ~~retaliate~~ punish?”

Master: “What would punishing do to the state?”

Apprentice: “Teach them not to drift.”

Master: “Teach the pipeline to ask ‘why’ first.”

Apprentice: “And what if entropy persists?”

Master: “Record why. The record is a lamp in the fog.”

Apprentice: “Who made the first drift in all systems?”

Master: “Entropy.”

Apprentice: “Then we’ll blame entropy?”

Master: “Blame nothing. Write the JIRA ticket.”

The apprentice writes the ticket. The pipeline asks “why” and then sleeps. The pager blinks once. Dawn sets. Just another ordinary day goes by.

What does the “Terraform police” do, you asked?

It pursues active drifts in the terraform repository.

It chases the individual(s?) responsible for deepening chaos.

It teaches them how not to do so anymore.

Rinse and repeat.

Will the workload of the “Terraform police” ever end?

Is drift an ephemeral state?

Is this world a simulation?

Is this a world simulation?

— § —

Reply via email

#dev #serenity #terraform

just apply it

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 04 Feb 2026 11:08:58 +0100

Thiago: now that your PR is merged, you can just apply it

Teammate: ah never did that, what would I need to do?

Thiago: just apply github-{corp}-ai-resources¹

I love these accidental word puns (ft. just).

In this context, just apply is a wrapper of terraform apply. ↩︎

— § —

Reply via email

#dev #serenity #terraform

terraform import arrays

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 24 Jan 2026 17:00:07 +0100

♠ Given an existing resource module.atlas_mongo_external.mongodbatlas_alert_configuration.maintenance_no_longer_needed[0] to be imported into terraform state through an imports.tf file with import blocks, a targeted imported can be performed like this:

terraform apply -target='module.atlas_mongo_external.mongodbatlas_alert_configuration.maintenance_no_longer_needed[0]'

Nothing special here. The “TIL” bit of the day is that the array suffix [0] is not needed:

terraform apply -target='module.atlas_mongo_external.mongodbatlas_alert_configuration.maintenance_no_longer_needed'

…works as well.

It feels like a silly optimization to know about but, when you double-click the resource name in most terminal emulators, only module.atlas_mongo_external.mongodbatlas_alert_configuration.maintenance_no_longer_needed gets selected by default, stopping right before [.

— § —

Reply via email

#dev #terraform

Terraformer

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Nov 2025 10:22:18 -0300

♠ terraformer:

CLI tool to generate terraform files from existing infrastructure (reverse Terraform). Infrastructure to Code

In other words: “reverse terraform”.

I was quite excited to add this project to my tool belt, as it can save a lot of time with scaffolding and terraform import commands.

Then Claude Code, once again, surprised me.

It turns out there’s absolutely no need to adopt terraformer if you have a superb agent available and a few cents/dollars to spare.

Claude can figure out which CLI arguments to pass to aws, az, etc. to list all relevant cloud resources. Then it can generate / scaffold a basic set of Terraform files to manage them¹. And then it can craft an one-off shell or python script to import them all in terraform.

Easy. Quick. Painless.

The interesting part is that I had initially asked Claude to explicitly use terraformer to do so, but it turned out to be more complicated / less efficient than having the agent perform the task directly.

I am sorry if you were expecting a terraformer tutorial.

You’ll need to refactor these later for maintainability. ↩︎

— § —

Reply via email

#aws #dev #terraform

terraform: update outputs only

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 17 Nov 2025 12:04:26 -0300

♠ Problem statement: Given a Terraform project full of pending changes (terraform plan), update its outputs only.

I would expect to be able to use -target to do so, but that’s not possible. This flag is intended for resources only.

The correct approach is terraform apply -refresh-only:

Running terraform apply -refresh-only should take care of any new outputs. It will read the latest data from each resource and then update all of the outputs in terms of those updates, which includes re-evaluating your output expressions to incorporate any changes.

I tested this and it indeed works as expected.

The next action from here would be to run terraform apply for select -target resources, a few at a time, until drift is completely eliminated.

— § —

Reply via email

#dev #terraform

terraform: bypass lock

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 04 Aug 2025 11:49:16 +0200

♠ Terraform supports state locking:

If supported by your backend, Terraform will lock your state for all operations that could write state. This prevents others from acquiring the lock and potentially corrupting your state.

Neat, right?

% op run --env-file=.env -- terraform plan
╷
│ Error: Error acquiring the state lock
│
│ Error message: operation error S3: PutObject, https response error
│ StatusCode: 412, RequestID: {redacted}, HostID:
│ {redacted},
│ api error PreconditionFailed: At least one of the pre-conditions you
│ specified did not hold
│ Lock Info:
│   ID:        {redacted}
│   Path:      {redacted}/chartmuseum.tfstate
│   Operation: OperationTypePlan
│   Who:       {redacted}
│   Version:   1.10.5
│   Created:   2025-08-04 09:46:55.995791 +0000 UTC
│   Info:
│
│
│ Terraform acquires a state lock to protect the state from being written
│ by multiple users at the same time. Please resolve the issue above and try
│ again. For most commands, you can disable locking with the "-lock=false"
│ flag, but this is not recommended.

It even uses a custom HTTP Status:

The HTTP 412 Precondition Failed client error response status code indicates that access to the target resource was denied. This happens with conditional requests on methods other than GET or HEAD when the condition defined by the If-Unmodified-Since or If-Match headers is not fulfilled. In that case, the request (usually an upload or a modification of a resource) cannot be made and this error response is sent back.

If you’re sure no one else is working on that workspace, you can proceed with -lock=false:

% op run --env-file=.env -- terraform plan -lock=false
uptime_check_http.chartmuseum: Refreshing state... [name=chartmuseum]
data.aws_availability_zones.available: Reading...
data.aws_availability_zones.available: Read complete after 1s [id=us-east-1]
[...]

That’s an one-off. A subsequent run without that argument will fail again:

% op run --env-file=.env -- terraform plan
╷
│ Error: Error acquiring the state lock
[...]

In this case it would be better to simply remove the lock with force-unlock:

% op run --env-file=.env -- terraform force-unlock {lock-id}
Do you really want to force-unlock?
  Terraform will remove the lock on the remote state.
  This will allow local Terraform commands to modify this state, even though it
  may still be in use. Only 'yes' will be accepted to confirm.

  Enter a value: yes

Terraform state has been successfully unlocked!

The state has been unlocked, and Terraform commands should now be able to
obtain a new lock on the remote state.

The lock-id can be obtained from the plan output.

Now we can plan as usual:

% op run --env-file=.env -- terraform plan
uptime_check_http.chartmuseum: Refreshing state... [name=chartmuseum]
data.aws_availability_zones.available: Reading...
data.aws_availability_zones.available: Read complete after 0s [id=us-east-1]
[...]

— § —

Reply via email

#dev #terraform

Terraform: rename resources

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 19 Mar 2025 11:40:43 +0100

♠ Sometimes I need to make a simple refactoring rename change to a terraform resource that has already been applied. For example:

resource "aws_api_gateway_request_validator" "delete" {
  name                        = "Validate body, query string parameters, and headers"
  rest_api_id                 = aws_api_gateway_rest_api.this.id
  validate_request_body       = true
  validate_request_parameters = true
}

resource "aws_api_gateway_request_validator" "this" {
  name                        = "Validate body, query string parameters, and headers"
  rest_api_id                 = aws_api_gateway_rest_api.this.id
  validate_request_body       = true
  validate_request_parameters = true
}

The simplest way to do so is to terraform apply. However, that incurs destruction + re-creation of the resource, which would incur downtime in case it’s already deployed in prod.

The best way is % terraform state mv aws_api_gateway_request_validator.{delete,this}. In-place move, simple and easy.

When doing it at scale, running multiple terraform state mv commands could be cumbersome.

There’s a second way, using the moved block in HCL:

moved {
    from = aws_api_gateway_request_validator.delete
    to = aws_api_gateway_request_validator.this
}

Note: terraform docs call this operation “move”, instead of “rename”.

— § —

Reply via email

#aws #dev #terraform

Terraform: create zip files

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 17 Mar 2025 21:06:28 +0100

♠ When creating .zip files with terraform, for example, with the purpose of uploading them to an AWS Lambda, at least two approaches exist to do so.

In the examples below, assume a NodeJS source file named index.mjs. It should be packaged into a lambda.zip archive.

1) Use `null_resource` #

resource "null_resource" "build_lambda" {
  triggers = {
    source_code_hash = filebase64sha256("${path.module}/lambda/index.mjs")
  }

  provisioner "local-exec" {
    command = <<EOF
            cd ${path.module}/lambda
            zip -r lambda.zip index.mjs
        EOF
  }
}

resource "aws_lambda_function" "this" {
  function_name = "dns-changer-delete"
  role          = aws_iam_role.this.arn

  filename         = "${path.module}/lambda/lambda.zip"
  source_code_hash = filebase64sha256("${path.module}/lambda/lambda.zip")
  handler          = "index.handler"
  runtime          = "nodejs22.x"

  depends_on = [null_resource.build_lambda]
}

2) Use `archive_file` #

data "archive_file" "lambda_zip" {
  type        = "zip"
  source_file = "${path.module}/lambda/index.mjs"
  output_path = "${path.module}/lambda/lambda.zip"
}

resource "aws_lambda_function" "this" {
  function_name = "dns-changer-delete"
  description   = "Delete DNS record sets for DNS Changer"
  role          = aws_iam_role.this.arn

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
  handler          = "index.handler"
  runtime          = "nodejs22.x"

  depends_on = [data.archive_file.lambda_zip]
}

I prefer the second approach.

Furthermore, it only requires one terraform apply per file update, whereas the first one requires two.

— § —

Reply via email

#dev #terraform

Terraform: generate diagrams

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 17 Mar 2025 13:42:57 +0100

♠ There are a few options to visualize a terraform module in the form of a graph or diagram.

`terraform graph`: dot / graphviz #

terraform graph outputs a DOT graph, which can be manipulated / visualized with graphviz:

terraform graph | dot -Tpng > graph.png

The graph can then be embedded into a markdown file:

![graph](graph.png)

`terramaid`: mermaid #

The terramaid project generates Mermaid diagrams from Terraform configurations:

% brew install terramaid
% terramaid run --output README.md
Mermaid diagram successfully written to README.md

The default filename is Terramaid.md.

Why use Mermaid? It was previously covered here.

TL;DR: Mermaid has native integration with GitHub and GitLab, and that’s hard to beat. Graphviz, sadly, does not.

— § —

Reply via email

#dev #terraform

Terraform: AWS deployment to random availability zones

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 21 May 2024 14:31:03 +0200

♠ A common scenario: there’s a new deployment you would like to roll out to AWS. Let’s say you pick “us-east-1” as your cloud region. There are multiple availability zones within it:

us-east-1a
us-east-1b
us-east-1c
us-east-1d
us-east-1e
us-east-1f

Suppose you want to pick two of them for your service/app, and you don’t particularly care about which one. How to proceed?

Option #1: Hard-coding #

Pick two arbitrary zones and hard-code them.

variable "availability_zones" {
  type    = list(string)
  default = ["us-east-1a", "us-east-1b"]
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.chartmuseum.id
  cidr_block        = element(var.private_subnets, count.index)
  availability_zone = element(var.availability_zones, count.index)
  count             = length(var.private_subnets)
}

Caveat: The paradox of choice, unnecessary decision fatigue.

Option #2: Pick the first two #

Use the AWS data source to dynamically find all zones, and pick the first two.

data "aws_availability_zones" "available" {
  state = "available"
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.chartmuseum.id
  cidr_block        = element(var.private_subnets, count.index)
  availability_zone = element(data.aws_availability_zones.available.names, count.index)
  count             = length(var.private_subnets)
}

Note that terraform plan should display the full zone list.

Caveat: Heavily biased towards the first two zones.

Option #3: Random shuffling #

Pick two zones at random!

data "aws_availability_zones" "available" {
  state = "available"
}

resource "random_shuffle" "aws_availability_zone_names" {
  input        = data.aws_availability_zones.available.names
  result_count = 2
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.chartmuseum.id
  cidr_block        = element(var.private_subnets, count.index)
  availability_zone = element(random_shuffle.aws_availability_zone_names.result, count.index)
  count             = length(var.private_subnets)
}

Winner: In my opinion, this is the most elegant approach.

random_shuffle will output the selected regions upon running terraform apply.

— § —

Reply via email

#aws #dev #terraform

★ Integrating terraform with ansible

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 01 Feb 2024 14:02:28 -0300

♠ This post is a follow-up of Terraforming a Linode: hello world.

In a future post, we will continue from here by using Ansible to install and set up Miniflux in our new Linode.

Before we extensively use Ansible to configure our VPS instance, first let’s set up a basic integration between Terraform and Ansible.

First of all, here’s an overview of where I stopped last time. There were a couple of lightweight modifications since then. I’ll explain some of them below.

variable "github_username" {
  type    = string
  default = "thiagowfx"
}

variable "linode_hostname" {
  type    = string
  default = "coruscant"
}

variable "linode_region" {
  type    = string
  default = "eu-central"
}

All variables were moved to a variables.tf file. This is to follow standard terraform conventions / recommendations for module structures. Furthermore, it becomes easier to manage variables when they are all stored in a single place.

The main module file now looks like this:

terraform {
  required_providers {
    http = {
      source = "hashicorp/http"
    }
    linode = {
      source = "linode/linode"
    }
  }
}

provider "linode" {}

data "http" "github_keys" {
  url = "https://api.github.com/users/${var.github_username}/keys"
}

locals {
  keys = jsondecode(data.http.github_keys.response_body)[*].key
}

resource "linode_instance" "nanode" {
  type             = "g6-nanode-1"
  image            = "linode/alpine3.19"
  label            = var.linode_hostname
  region           = var.linode_region
  authorized_keys  = local.keys
  backups_enabled  = "false"
  booted           = "true"
  watchdog_enabled = "true"
}

I removed the token from the linode provider. Now it is supplied via the LINODE_TOKEN environment variable. In order to automatically populate that variable, I use direnv. There’s an .envrc file that provides its value, like so:

#!/bin/sh
# terraform init

export LINODE_TOKEN="my-token-here"

I also created a repository for this project: https://github.com/thiagowfx/knol. That’s enough for preliminaries, now let’s go back to Ansible.

The first component we’ll need is an Ansible inventory file, containing the IP address of the host we’ll manage. It could look like this:

[all]
1.2.3.4 ansible_user=root

…wherein 1.2.3.4 is the IP address of our VPS.

That said, due to the fact the VPS instance is created dynamically, maintaining that IP address manually would be tedious. Therefore, let’s have Terraform manage it.

We can do so with a local_file. Heck, we could even use a template_file, however it would be overkill as there are only two simple lines in our inventory at this point. A local_file is created upon terraform apply and deleted upon terraform destroy. Therefore it doesn’t even need to be tracked by our VCS:

resource "local_file" "ansible_inventory" {
  content  = <<-EOF
[all]
${linode_instance.nanode.ip_address} ansible_user=root
EOF
  filename = "inventory.ini"
  file_permission = "0644"
}

Once we run terraform (plan + apply), an inventory.ini file should be created with the above contents.

Because the IP address is ephemeral and dynamic, we should have a straightforward way to see its value. A terraform output is perfect for that:

output "ip_address" {
  value = linode_instance.nanode.ip_address
}

Later on (after terraforming) we will be able to use terraform output to see the server IP address.

We have the inventory file. Now we need a playbook. A playbook contains a sequence of tasks to be applied to our server.

Let’s start with a basic playbook that just installs and starts nginx:

---
- hosts: all
  tasks:
    - name: Install the web server (nginx)
      community.general.apk:
        name: nginx
        state: present
    - name: Start the web server
      service:
        name: nginx
        state: started

Save this to a playbook.yml file.

After terraforming, we should now be able to run ansible:

% ansible-playbook -i inventory.ini playbook.yml

In order to make this setup more ergonomic, let’s create a Makefile:

TERRAFORM := terraform

all: terraform ansible

ansible:
	ansible-playbook -i inventory.ini playbook.yml

terraform:
	$(TERRAFORM) init
	$(TERRAFORM) plan
	$(TERRAFORM) apply

clean:
	$(TERRAFORM) destroy

.PHONY: all ansible terraform clean

Then we can just run make terraform or make ansible for granular steps. Or just make to run everything in the right order.

I extracted the terraform binary to its own variable because it facilitates the use of OpenTofu (a fork) in lieu of terraform.

And that’s it for today! In a future post, we’ll look into extending our Ansible usage to fully bootstrap Miniflux on the server.

— § —

Reply via email

#bestof #dev #terraform

★ Terraforming a Linode: hello world

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 23 Jan 2024 23:27:04 -0300

♠ I host my own Miniflux instance, which happens to be my favorite RSS reader. Currently it is hosted on Linode (Akamai Cloud) running Alpine Linux.

My current setup was performed manually. I was thinking that, for fun, it would be cool to fully automate it under the principles of IaC.

The current setup does not use any containers. I had proudly made it as KISS as possible at the time:

Linode is a very beginner-friendly (and cheap) VPS
Alpine Linux is a first-class citizen on Linode
There’s an apk package for miniflux
There’s an OpenRC¹ script for miniflux (so that it can be controlled via service)

For the first part of this automation we will look into provisioning a Linode with an Alpine Linux installation. In order to do so we will use HashiCorp Terraform.

Requirements #

Provision a new Linode
Deploy it in Europe
Use the smallest shape (a so-called Nanode)
Run Alpine Linux
Set it up with my public ssh key, which is hosted on Github

Terraform setup #

Install a provider for Linode: https://registry.terraform.io/providers/linode/linode/latest/docs

Scaffold it like this, in a main.tf file:

terraform {
  required_providers {
    linode = {
      source = "linode/linode"
    }
  }
}

Then run:

% terraform init

Generate a Linode API token

Go to https://cloud.linode.com/profile/tokens, create a new token called terraform. with the “Linodes” scope set to “Read/Write”.

Append this API token to main.tf:

provider "linode" {
  token = "<your token here>"
}

Add a linode_instance with the appropriate fields set according to the documentation:

resource "linode_instance" "coruscant" {
  label  = "coruscant"
  image  = "linode/alpine3.19"
  region = "eu-central"
  type   = "g6-nanode-1"
  authorized_keys  = ["<your ssh public key here>"]
  backups_enabled  = "false"
  watchdog_enabled = "true"
  booted           = "true"
}

Then run:

% terraform plan

“Plan” is basically a dry-run. Terraform will output what it intends to do, but nothing will be done yet.

Analyze the output and double check that it looks correct.

To actually perform the provisioning, run:

% terraform apply

Then confirm the prompt.

Within a few seconds (or maybe minutes), you should see your new Linode in the Linode Console.

We can test our deployment by ssh’ing to our new machine:

% ssh root@<public IP address> -i ~/.ssh/my_ssh_key
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <https://wiki.alpinelinux.org/>.

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

Let’s take a pause to appreciate how lightweight it is:

localhost:~# df -h
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                 10.0M         0     10.0M   0% /dev
shm                     487.8M         0    487.8M   0% /dev/shm
/dev/sda                 24.1G    238.1M     22.6G   1% /
tmpfs                   195.1M    268.0K    194.8M   0% /run

Only 238 MiB!

To deprovision it, run:

% terraform plan -destroy

If everything looks correct, run:

% terraform destroy

Warning: It turns out the “Linodes” scope was not enough to do the deprovisioning. I needed to create a new scope, with more permissions, in order to do so.

As you can see, terraform makes it very trivial to deprovision systems.

Bonus points: run terraform fmt to format your file. Never go out of style.

Tip: At any point you can run terraform validate to verify your main.tf file is syntactically correct.

Two things could be improved in the previous setup:

We could use authorized_users to pass in our linode username. If we add an SSH key to our linode account, then that key would be automatically deployed to the system, thereby removing the need to specify authorized_keys.
Alternatively, we could fetch our key from an URL endpoint with the use of the hashicorp/http provider, like so:

terraform {
  required_providers {
    http = {
      source = "hashicorp/http"
    }
  }
}

data "http" "thiagowfx_ssh_keys" {
  url = "https://github.com/thiagowfx.keys"
}

resource "linode_instance" "coruscant" {
  # ...
  authorized_keys  = compact([for line in split("\n", data.http.thiagowfx_ssh_keys.response_body) : chomp(line)])
  # ...
}

The “list comprehension” above does line splitting magic to convert them to a list of string, and the compact removes the empty new line at the end.

We could improve the example above even further.

For starters, let’s parameterize out the username to a variable:

variable "github_username" {
  type    = string
  default = "thiagowfx"
}

data "http" "user_ssh_keys" {
  url = "https://github.com/${var.github_username}.keys"
}

resource "linode_instance" "coruscant" {
  # ...
  authorized_keys  = compact([for line in split("\n", data.http.user_ssh_keys.response_body) : chomp(line)])
  # ...
}

We could then easily supply another username with -var:

% terraform plan -var github_username=torvalds

Note that the above example leverages string interpolation.

We could also extract the SSH keys list to its own “variable” (locals):

locals {
  ssh_keys = compact([for line in split("\n", data.http.user_ssh_keys.response_body) : chomp(line)])
}

resource "linode_instance" "coruscant" {
  # ...
  authorized_keys  = local.ssh_keys
  # ...
}

A more robust (and stable) way to query the key though is through the Github API:

data "http" "github_keys" {
  url = "https://api.github.com/users/${var.github_username}/keys"
}

locals {
  ssh_keys = jsondecode(data.http.github_keys.response_body)[*].key
}

Note that a typical response body looks like the following:

[
  {
    "id": "<id>",
    "key": "<ssh key>"
  }
]

API endpoint documentation: https://docs.github.com/en/rest/users/keys?apiVersion=2022-11-28#list-public-keys-for-a-user

If we use output instead of locals, then we can debug (inspect) it with terraform output.

And that’s it for today! In a future post, we will continue from here by using Ansible to install and set up Miniflux in our new Linode.

Alpine Linux does not use systemd. ↩︎

— § —

Reply via email

#alpine-linux #bestof #dev #terraform

Terraform on ¬ just serendipity 🍀

terraform police

just apply it

terraform import arrays

Terraformer

terraform: update outputs only

terraform: bypass lock

Terraform: rename resources

Terraform: create zip files

1) Use null_resource #

2) Use archive_file #

Terraform: generate diagrams

terraform graph: dot / graphviz #

terramaid: mermaid #

Terraform: AWS deployment to random availability zones

Option #1: Hard-coding #

Option #2: Pick the first two #

Option #3: Random shuffling #

★ Integrating terraform with ansible

★ Terraforming a Linode: hello world

Requirements #

Terraform setup #

1) Use `null_resource` #

2) Use `archive_file` #

`terraform graph`: dot / graphviz #

`terramaid`: mermaid #