DEV Community: totegamma

Bringing kustomize-like Patch Workflows to Terraform Using YAML

totegamma — Thu, 04 Dec 2025 07:43:40 +0000

Introduction

Terraform is a standard tool for infrastructure management, but once multiple environments (such as dev and prod) are involved, handling environment-specific differences can quickly become challenging.

A common approach is to create shared modules and use them across multiple tenants. However, if you need to enable a special option only for certain environments, you often end up having to modify the module itself, which is not ideal.

If Terraform had something like Kubernetes’ kustomize—where you can apply patches per environment—life would be much easier. Unfortunately, Terraform offers no built-in mechanism for this.

In this article, I’ll introduce an experiment where Terraform configuration is authored in YAML, and then patched per environment before being rendered into Terraform JSON.
This approach makes environment-specific diff management easier and improves code reusability.
Practicality aside, I hope this serves as an interesting example of an alternative Terraform workflow.

A Quick Refresher on Terraform’s JSON Syntax

Terraform configuration is typically written in HCL (.tf files), but did you know it can also be expressed in JSON?

For example, the following .tf file:

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "2.4.0"
    }
  }
}

provider "local" {}

resource "local_file" "hello1" {
  content  = "1st Hello, World!"
  filename = "hello1.txt"
}

resource "local_file" "hello2" {
  content  = "2nd Hello, World!"
  filename = "hello2.txt"
}

can be written in JSON like this:

{
  "provider": {
    "local": {}
  },
  "resource": {
    "local_file": {
      "hello1": {
        "content": "1st Hello, World!",
        "filename": "hello1.txt"
      },
      "hello2": {
        "content": "2nd Hello, World!",
        "filename": "hello2.txt"
      }
    }
  },
  "terraform": {
    "required_providers": {
      "local": {
        "source": "hashicorp/local",
        "version": "2.4.0"
      }
    }
  }
}

If you save this as <filename>.tf.json, Terraform will accept it just like regular HCL when running terraform apply.

However, authoring this JSON manually is a bit cumbersome. It would be much easier if we could write it in YAML and convert it to JSON.

yisp

yisp is a tool that allows you to embed evaluable expressions inside YAML.
For example, given the following YAML:

mynumber: !yisp
  - add
  - 5
  - 3

Running yisp build . produces:

mynumber: 8

yisp also supports features such as merging multiple YAML files, merging objects, and exporting the result as JSON.

In this article, we’ll use yisp to make Terraform JSON structures easier to write in YAML and to manage environment-specific differences.

First, Let’s Try It Out

Here’s a simple Terraform configuration that provisions a single EC2 instance, but written in YAML:

terraform:
  required_providers:
    aws:
      source: hashicorp/aws
      version: ">= 3.0.0"
provider:
  aws:
    region: ap-northeast-1
data:
  aws_ami:
    amazon_linux:
      most_recent: true
      owners:
        - "137112412989"  # Amazon
      filter:
        - name: name
          values:
            - "amzn2-ami-hvm-*-x86_64-gp2"
resource:
  aws_instance:
    example:
      ami: "${data.aws_ami.amazon_linux.id}"
      instance_type: t2.micro
      tags:
        Name: example-instance

Convert this to JSON using yisp:

yisp build tf.yaml -o json

The output will look like this:

{
  "data": {
    "aws_ami": {
      "amazon_linux": {
        "filter": [
          {
            "name": "name",
            "values": [
              "amzn2-ami-hvm-*-x86_64-gp2"
            ]
          }
        ],
        "most_recent": true,
        "owners": [
          "137112412989"
        ]
      }
    }
  },
  "provider": {
    "aws": {
      "region": "ap-northeast-1"
    }
  },
  "resource": {
    "aws_instance": {
      "example": {
        "ami": "${data.aws_ami.amazon_linux.id}",
        "instance_type": "t2.micro",
        "tags": {
          "Name": "example-instance"
        }
      }
    }
  },
  "terraform": {
    "required_providers": {
      "aws": {
        "source": "hashicorp/aws",
        "version": "\u003e= 3.0.0"
      }
    }
  }
}

Save this as rendered.tf.json, and then run terraform init and terraform apply as usual.

Creating a Makefile

Terraform unfortunately cannot take manifests via stdin, so a file must exist before running commands.
To simplify this, you can set up a Makefile so the JSON is automatically generated before terraform plan or apply.

SOURCES := $(wildcard *.yaml)

rendered.tf.json: $(SOURCES)
    yisp build . -o json > rendered.tf.json

init: rendered.tf.json
    terraform init

plan: rendered.tf.json
    terraform plan

apply: rendered.tf.json
    terraform apply

Turning It Into a Module

Next, let’s modularize this setup so both dev and prod environments can call it with different parameters—similar to how Kubernetes + kustomize structures manifests.

Here’s the directory structure:

📁 .
├── 📁 base
│   └── 📄 ec2.yaml
└── 📁 env
    ├── 📁 dev
    │   ├── 📄 index.yaml
    │   └── 📄 main.yaml
    │   ├── 📄 ec2.yaml
    └── 📁 prod (etc.)

base/ec2.yaml

Let’s suppose we want a module that provisions an EC2 instance from a shared AMI.

!yisp &default
- lambda
- [props]
- !quote
  data:
    aws_ami:
      amazon_linux:
        most_recent: true
        owners:
          - "137112412989"
        filter:
          - name: name
            values:
              - "amzn2-ami-hvm-*-x86_64-gp2"
  resource:
    aws_instance: !yisp
      - maps.make
      - *props.name
      - !quote
        ami: "${data.aws_ami.amazon_linux.id}"
        instance_type: !yisp [default, *props.instance_type, "t2.micro"]
        tags:
          Name: *props.name

This uses a lambda expression to accept a props object, then generates a resource using its fields.

env/dev/ec2.yaml

Now let’s call the module from the dev environment to create two EC2 instances:

!yisp
- import
- [ec2, ../base/ec2.yaml]
---
!yisp
- *ec2.default
- name: dev-server
  instance_type: t3.medium
---
!yisp
- *ec2.default
- name: dev-database
  instance_type: t3.medium

Running yisp build ec2.yaml yields YAML with two instances defined.

env/dev/main.yaml

Basic Terraform config for dev:

terraform:
  required_providers:
    aws:
      source: hashicorp/aws
      version: ">= 3.0.0"
provider:
  aws:
    region: ap-northeast-1

env/dev/index.yaml

Now combine all pieces into a single document:

!yisp
- lists.reduce
- - include
  - main.yaml
  - ec2.yaml
- maps.merge

Running yisp build . merges them into one consolidated Terraform JSON structure.

Applying Patches to Specific Resources

Suppose we want to enable monitoring only for the dev-database instance.
Since we aren’t modifying the base module directly, we can apply a patch at the environment level.

Create ec2.patch.yaml:

op: add
path: "/resource/aws_instance/dev-database/monitoring"
value: true

Update index.yaml to include this patch:

!yisp
- maps.patch
- - lists.reduce
  - - include
    - main.yaml
    - ec2.yaml
  - maps.merge
- - include
  - ec2.patch.yaml

Running yisp build . produces monitoring: true only on the dev-database instance.

Applying a Patch to All Resources of the Same Type

You may also want to patch all EC2 instances at once.
With yisp’s wildcard support (* in patch paths), this becomes easy.

Extend ec2.patch.yaml:

op: add
path: "/resource/aws_instance/dev-database/monitoring"
value: true
---
op: add
path: "/resource/aws_instance/*/tags"
value:
  Environment: Production
  Owner: TeamA
  Project: ProjectX

Both dev-server and dev-database will now receive the additional tags.

Conclusion

In this article, we explored how to write Terraform configurations in YAML, convert them to JSON, and manage environment-specific differences using yisp’s patching features.

Whether this is production-ready or not is still an open question, but the idea of “absorbing environment differences after the fact”—similar to Kubernetes kustomize—opens up interesting new ways to work with Terraform.

If you’re curious, definitely try experimenting with this workflow!

What If YAML and Lisp Had a Child?: Bring Functional Power to Your Kubernetes Manifests

totegamma — Mon, 02 Jun 2025 03:28:27 +0000

So... how's your YAML life going?

If you work with tools like Ansible Playbooks, Docker Compose, or especially Kubernetes manifests, chances are you're knee-deep in YAML files every day.

In many real-world projects, we often need to generate multiple variations of Kubernetes manifests for different environments (like dev, staging, and production). Tools like Helm and Kustomize were created to manage exactly this use case.

But these tools aren't without problems. Ever wrestled with fixing invalid YAML output from a Helm template? Or struggled with the patch ordering puzzle in Kustomize? If you've felt that pain, this article introduces a solution: injecting Lisp-style functional power into your YAML.

When Helm and Kustomize Aren’t Enough

Helm

Helm is a popular templating tool for Kubernetes that uses Go's text/template to generate YAML manifests.

Strengths:

Well-suited for generating large sets of manifests.
Allows for toggling features on and off using conditional logic.

Limitations:

Templates treat YAML as raw text, not structured data.
Output can become invalid YAML if the template is miswritten.

Kustomize

Kustomize introduces a clear semantic model for manipulating Kubernetes manifests through the concepts of resources, generators, and transformers.

Strengths:

Provides a semantic, Kubernetes-aware way to apply changes to manifests.
Strong reuse capabilities thanks to clean layering and patching mechanics.

Limitations:

Can’t easily generate resources or toggle their inclusion—it's designed to modify existing bases, not build them from scratch.
Unintended use cases (e.g. patching beyond its intended scope) often result in puzzle-like configurations.
Higher learning curve compared to Helm.
Its model is tightly coupled to Kubernetes, making its concepts hard to transfer to other YAML-based tools.

So What's the Alternative?

What we really need is:

Variable injection and toggling structures on/off
Clear evaluation order
The ability to embed logic directly without leaving YAML's structure

We want a way to treat YAML as data, while also injecting code into that data. Sounds impossible?

Yes, It’s LISP

Lisp, born in 1960, is one of the oldest programming languages. You may have seen memes about "Lisp aliens", but don't let that distract you.

Lisp is still relevant—especially because of this trait:

Code and data share the same structure.

Here's a minimal Lisp example:

(+ 3 5)  ; This is both data (a list) and code (an addition)

This flexibility is exactly what we want in our YAML: to represent structured configuration and logic as one.

Injecting Lisp into YAML: Meet `yisp`

Enter yisp, a tool that lets you write Lisp-like expressions inside YAML.

Consider this example:

myaddition: !yisp
  - +
  - 3
  - 5

This will be evaluated into:

myaddition: 8

The !yisp tag marks the list as a yisp expression. Like Lisp, it's prefix notation: ['+', 3, 5] means 3 + 5.

Writing Reusable Templates

You can define reusable templates as functions:

!yisp &mkpod
- lambda
- [name, image]
- !quote
  apiVersion: v1
  kind: Pod
  metadata:
    name: *name
  spec:
    containers:
      - name: *name
        image: *image

Then invoke it like this:

!yisp
- *mkpod
- mypod1
- myimage1

Which yields:

apiVersion: v1
kind: Pod
metadata:
  name: mypod1
spec:
  containers:
    - name: mypod1
      image: myimage1

The YAML anchor (&) and alias (*) features are used here like let and variable references.

Kustomize-Like Functionality

Want to load all files from a directory and generate a ConfigMap? Sure:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data: !yisp
  - maps.from-entries
  - - lists.map
    - - lambda
      - [file]
      - !quote
        - *file.name
        - *file.body
    - - files.glob
      - ./cm-files/*

This is similar to Kustomize's configMapGenerator, but written clearly and explicitly using standard YAML and yisp's expressive power.

What About More Complex Logic?

Yes, yisp is powerful—but not everything should be written inside YAML. When logic gets too complex, you can offload it to Go and call it from yisp.

For example, you can use a Helm adapter written in Go to expand a chart:

!yisp &helm-chart
- lambda
- [props]
- - exec.go
  - pkg: github.com/totegamma/yisp-helm-adapter@v0.1.0
    args: !quote
      - *props.repo
      - *props.release
      - *props.version
    stdin:
      - yaml.marshal
      - *props.values

And then:

!yisp
- *helm-chart
- repo: "https://charts.concrnt.net/"
  release: "concrnt"
  version: "0.7.13"
  values:
    meilisearch:
      enabled: true

Conclusion: Code and Data, Together

yisp enables a new way to manage configuration:

Structured YAML
Functional logic
Native integration

And the best part? It's not just for Kubernetes. If your tool can read YAML, it can work with yisp. You get the expressive power of code, without abandoning YAML.

yisp is still under development, but it's OSS and ready for real-world use. Try it out, build something, and let us know what you think!

GitHub: https://github.com/totegamma/yisp