DEV Community: Daniel Pepuho

AWS EKS: Running Your First Workload Using AWS CDK

Daniel Pepuho — Fri, 06 Feb 2026 05:55:38 +0000

TL;DR

- Created an EKS cluster and deployed a workload using AWS CDK

- Separated stack between infrastructure and application

- Defined Kubernetes resources (ConfigMap, Deployment, Service) in code

- Learned why cdk deploy --all is often required to apply updates

Now that we have a running EKS cluster created with AWS CDK, it’s time to deploy our first workload. In this post, we’ll define Kubernetes resources using AWS CDK, deploy a simple web workload to the cluster, and expose it so it can be accessed externally.

This will give us a practical foundation before moving on to ingress, scaling, and Karpenter in later posts.

Defining Kubernetes manifests in CDK

By default, Kubernetes workloads are defined using YAML manifests and applied manually using kubectl. While this approach works, it often leads to duplicated configuration, limited reusability, and infrastructure logic being scattered across multiple files.

With AWS CDK, we can define Kubernetes resources directly in code and let CDK handle applying them to the cluster. Under the hood, CDK still talks to the Kubernetes API, but we gain the benefits of using a real programming language—such as structure, composition, and version control.

BTW, our project structure should be like this:

running-first-workloads/
├── app.py
├── cdk.json
├── requirements.txt
├── eks
│   ├── __init__.py
│   └── eks_stack.py # 1. Create EKS cluster 
├── workloads
│   ├── __init__.py
│   └── running_first_workloads_stack.py # 2. Running workload
└── tests

- eks/eks_stack.py

Defines the core EKS infrastructure, including the VPC, EKS control plane, managed node group, and IAM access configuration. This stack is responsible only for the cluster itself.

- workloads/running_first_workloads_stack.py

Defines Kubernetes resources that run on top of the existing cluster. In this post, this includes the ConfigMap, Deployment, and Service for the Caddy web server.

- app.py

Acts as the entry point that wires the two stacks together. The EKS cluster created in eks_stack.py is passed into the workload stack, allowing workloads to be deployed without recreating the cluster.

Now let’s do some work and start defining our first Kubernetes workload using AWS CDK inside running_first_workloads_stack.py.

Stack Definition and Constructor

We start by defining a new CDK stack class that accepts an existing EKS cluster as a parameter.

class RunningFirstWorkloadsStack(Stack):

    def __init__(
        self,
        scope: Construct,
        construct_id: str,
        cluster: eks.Cluster,
        **kwargs
    ) -> None:
        super().__init__(scope, construct_id, **kwargs)

Unlike the cluster stack, this stack does not create any AWS infrastructure. Instead, it receives a reference to an already running EKS cluster. This reference allows CDK to know where Kubernetes resources should be applied.

For our first workload, we’ll deploy Caddy, a lightweight and modern web server. Caddy is a good fit for this example because it behaves like a real-world application component while remaining simple enough to focus on Kubernetes and CDK concepts rather than application logic.

Image Source: Caddy Community

A ConfigMap to store the Caddy configuration
A Deployment to run the Caddy containers
A Service to expose the application externally

All of these resources are defined using cluster.add_manifest() in the workload stack. CDK takes care of applying the manifests to the cluster in the correct order, allowing us to focus on how the workload is structured rather than how it is manually deployed.

Next, we’ll start by defining a ConfigMap to store the Caddy configuration.

ConfigMap: Storing the Caddy Config

Before running any containers, we need to define how Caddy should behave. Instead of embedding configuration directly into the container image, we store the configuration in a ConfigMap. This is a common Kubernetes pattern that keeps application configuration separate from the runtime environment.

For this example, the configuration is intentionally minimal. We configure Caddy to listen on port 80 and return a simple HTTP response. This keeps the focus on how the workload is deployed, not on application logic. This ConfigMap will create an object named caddy-config that contains a Caddyfile. Caddy automatically reads its configuration from this file when it starts.

        # ConfigMap for Caddyfile
        cluster.add_manifest(
            "CaddyConfig",
            {
                "apiVersion": "v1",
                "kind": "ConfigMap",
                "metadata": {
                    "name": "caddy-config"
                },
                "data": {
                    "Caddyfile": """
:80 {
    respond "Hello from Caddy v1"
}
"""
                }
            }
        )

Deployment: Running the Containers

The next step is to run the application containers. In Kubernetes, this is done using a Deployment, which manages how pods are created, updated, and kept running.

In this example, the Deployment is responsible for:

- Running the Caddy container image

- Mounting the ConfigMap as a volume

- Managing multiple replicas for availability

        # Caddy Deployment
        cluster.add_manifest(
            "CaddyDeployment",
            {
                "apiVersion": "apps/v1",
                "kind": "Deployment",
                "metadata": {
                    "name": "caddy"
                },
                "spec": {
                    "replicas": 2,
                    "selector": {
                        "matchLabels": {
                            "app": "caddy"
                        }
                    },
                    "template": {
                    "metadata": {
                        "labels": { "app": "caddy" },
                        "annotations": {
                            "configmap-reload-ts": str(int(time.time()))
                        }
                    },
                        "spec": {
                            "containers": [
                                {
                                    "name": "caddy",
                                    "image": "caddy:2",
                                    "ports": [
                                        {
                                            "containerPort": 80
                                        }
                                    ],
                                    "volumeMounts": [
                                        {
                                            "name": "caddy-config",
                                            "mountPath": "/etc/caddy"
                                        }
                                    ]
                                }
                            ],
                            "volumes": [
                                {
                                    "name": "caddy-config",
                                    "configMap": {
                                        "name": "caddy-config"
                                    }
                                }
                            ]
                        }
                    }
                }
            }
        )

Let’s do some break down:

- replicas: 2: Runs two instances of the Caddy container, providing basic availability and allowing us to observe how Kubernetes distributes traffic.

- container image: Uses the official caddy:2 image

- volumeMounts and volumes: The ConfigMap created earlier is mounted into the container at /etc/caddy, which is where Caddy expects its configuration file by default.

Service: Exposing the Application

At this point, the Caddy pods are running perfectly fine inside the cluster—buuut from the outside world, they might as well not exist. You can kubectl get pods all day long, but your browser still won’t load anything.

To make the application actually usable, we define a Service, which gives our pods a stable identity and a proper way to receive traffic.

In this example, we use a Service of type LoadBalancer, which is the simplest way to expose an application externally on AWS.

        # Service to expose Caddy
        cluster.add_manifest(
            "CaddyService",
            {
                "apiVersion": "v1",
                "kind": "Service",
                "metadata": {
                    "name": "caddy-service"
                },
                "spec": {
                    "type": "LoadBalancer",
                    "selector": {
                        "app": "caddy"
                    },
                    "ports": [
                        {
                            "port": 80,
                            "targetPort": 80
                        }
                    ]
                }
            }
        )

Once the Service is created, Kubernetes and AWS work together to expose the application. After a short delay, the Service will receive an external IP or DNS name that can be used to access Caddy from a browser or via curl

Deploying the Stack (EKS Stack and Workload Stack)

Before we dive deeper, here is the full code for eks_stack.py

from aws_cdk import (
Stack,
aws_eks as eks,
aws_ec2 as ec2,
)

from aws_cdk.lambda_layer_kubectl_v32 import KubectlV32Layer

from aws_cdk import aws_iam as iam

from constructs import Construct

class CdkEksStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        kubectl_layer = KubectlV32Layer(self, "KubectlLayer")

        vpc = ec2.Vpc(
            self,
            "EksVpc",
            max_azs=2 # AZ
        )

        self.cluster = eks.Cluster(
            self,
            "EksCluster",
            version=eks.KubernetesVersion.V1_32,
            vpc=vpc,
            default_capacity=0,
            kubectl_layer=kubectl_layer
        )

        self.cluster.add_nodegroup_capacity(
            "ManagedNodeGroup",
            desired_size=2,
            min_size=1,
            max_size=3,
            instance_types=[ec2.InstanceType("t3.medium")], # 2vcpu/4gi
        )

        self.cluster.aws_auth.add_user_mapping(
            iam.User.from_user_name(
            self,
            "AdminUser",
            "<YOUR_IAM>"
            ),
            groups=["system:masters"],
        )

Also, the running_first_workloads_stack.py

from aws_cdk import (
Stack,
aws_eks as eks,
)

from constructs import Construct

import time 

class RunningFirstWorkloadsStack(Stack):

    def __init__(
        self,
        scope: Construct,
        construct_id: str,
        cluster: eks.Cluster,
        **kwargs
    ) -> None:
        super().__init__(scope, construct_id, **kwargs)

class RunningFirstWorkloadsStack(Stack):

    def __init__(
        self,
        scope: Construct,
        construct_id: str,
        cluster: eks.Cluster,
        **kwargs
    ) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # ConfigMap for Caddyfile
        cluster.add_manifest(
            "CaddyConfig",
            {
                "apiVersion": "v1",
                "kind": "ConfigMap",
                "metadata": {
                    "name": "caddy-config"
                },
                "data": {
                    "Caddyfile": """
:80 {
    respond "Hello from Caddy v2"
}
"""
                }
            }
        )

        # Caddy Deployment
        cluster.add_manifest(
            "CaddyDeployment",
            {
                "apiVersion": "apps/v1",
                "kind": "Deployment",
                "metadata": {
                    "name": "caddy"
                },
                "spec": {
                    "replicas": 2,
                    "selector": {
                        "matchLabels": {
                            "app": "caddy"
                        }
                    },
                    "template": {
                    "metadata": {
                        "labels": { "app": "caddy" },
                        "annotations": {
                            "configmap-reload-ts": str(int(time.time()))
                        }
                    },
                        "spec": {
                            "containers": [
                                {
                                    "name": "caddy",
                                    "image": "caddy:2",
                                    "ports": [
                                        {
                                            "containerPort": 80
                                        }
                                    ],
                                    "volumeMounts": [
                                        {
                                            "name": "caddy-config",
                                            "mountPath": "/etc/caddy"
                                        }
                                    ]
                                }
                            ],
                            "volumes": [
                                {
                                    "name": "caddy-config",
                                    "configMap": {
                                        "name": "caddy-config"
                                    }
                                }
                            ]
                        }
                    }
                }
            }
        )

        # Service to expose Caddy
        cluster.add_manifest(
            "CaddyService",
            {
                "apiVersion": "v1",
                "kind": "Service",
                "metadata": {
                    "name": "caddy-service"
                },
                "spec": {
                    "type": "LoadBalancer",
                    "selector": {
                        "app": "caddy"
                    },
                    "ports": [
                        {
                            "port": 80,
                            "targetPort": 80
                        }
                    ]
                }
            }
        )

And the last one, app.py:

#!/usr/bin/env python3
import aws_cdk as cdk

from eks.eks_stack import CdkEksStack
from workloads.running_first_workloads_stack import RunningFirstWorkloadsStack

app = cdk.App()

# 1. Create EKS cluster stack
eks_stack = CdkEksStack(
    app,
    "EksStack",
)

# 2. Deploy workloads on top of the cluster
RunningFirstWorkloadsStack(
    app,
    "RunningFirstWorkloadsStack",
    cluster=eks_stack.cluster,
)

app.synth()

Listing Available Stacks

Before deploying, it’s often useful to see which stacks are defined in the application. You can list them using:

$ cdk list

Deploying All Stacks

Since the workload stack depends on the EKS stack, the simplest approach is to deploy all stacks at once:

$ cdk deploy --all

CDK will:

- Deploy the EKS infrastructure first

- Wait for the cluster to become available

- Apply the Kubernetes manifests defined in the workload stack

Deploying a Single Stack

If you want to deploy only a specific stack, you can target it by name:

$ cdk deploy EksStack

or 

$ cdk deploy RunningFirstWorkloadsStack

Verify Deployment

Once the deployment is complete, let's see that the workload is running correctly using Kubernetes commands.

First, let’s check the pods:

$ kubectl get pods

Both pods are in the Running state and ready, which means the Caddy containers started successfully and are using the configuration provided via the ConfigMap.

Next, let’s check the Service:

$ kubectl get svc

Here we can see that the caddy-service has been assigned an external endpoint by AWS. This means the load balancer is ready and traffic can now reach the application from outside the cluster.

Accessing the Application

Copy the value from the EXTERNAL-IP column and open it in your browser, or use curl:

At this point, the workload is fully deployed and accessible.

Make Changes

To see how changes are applied, let’s update the Caddy configuration. We’ll modify the response in the Caddyfile from v1 to v2:

respond "Hello from Caddy v1" -> respond "Hello from Caddy v2"

First, try deploying only the workload stack:

$ cdk deploy RunningFirstWorkloadsStack

At first glance, this looks like the correct approach—after all, only the workload code has changed. However, after the deployment completes, nothing appears to have changed:

- The running pods are still the same

- No rolling update is triggered

- The application response still returns Hello from Caddy v1

In other words, from the cluster’s point of view, the workload has not been updated.

Why Didn’t This Work?

Although the ConfigMap content changed in code, Kubernetes manifests defined using cluster.add_manifest() are applied through a custom resource backed by the EKS stack. When deploying only the workload stack, CDK may determine that there are no CloudFormation-level changes that require reapplying the manifests.

As a result, the Kubernetes provider is not re-invoked, and the updated configuration is never applied to the cluster.

Next, we deploy all stacks together:

$ cdk deploy --all

This time, the behavior is different:

- The EKS stack is re-evaluated

- The Kubernetes provider is refreshed

- The updated manifests are applied to the cluster

- A rolling update is triggered on the Deployment

- New pods are created with the updated configuration

After the rollout completes, the application now responds with:

What’s next

At this point, we’ve successfully deployed a workload to EKS using AWS CDK. We defined Kubernetes resources in code, deployed them through CDK, exposed the application externally, and verified that updates can be rolled out predictably.

This setup it’s still just the beginning.

In the next posts, we’ll continue building on top of this foundation by exploring more production-oriented patterns, including:

- CDK for more
- Ingress
- Autoscaling with Karpenter

Each of these topics will build directly on the cluster and workload we’ve created, moving the setup closer to a production-ready environment.

Aight, thanks for taking the time read this post. Here is the full code of this post:

danielcristho/that-i-write/running-first-workloads

AWS EKS: Create Your First Cluster Using AWS CDK

Daniel Pepuho — Wed, 28 Jan 2026 08:33:53 +0000

TL;DR

- Create an EKS cluster using AWS CDK Python

- Provision infrastructure via AWS CloudFormation

- The setup includes a VPC, EKS control plane, and a managed EC2 node group

- Configure IAM access to use kubectl

- Verify the cluster and clean up resources when done

Introduction

About 2 years ago, I’ve been using AWS CDK to manage infrastructure, mostly for smaller workloads like deploying APIs on AWS Lambda. You can see the repo here: cdk-go-simple-restapi. This year, I want to take it a step further by using AWS CDK to create and manage an AWS EKS cluster.

I’ll be writing a short series of posts around this topic, starting with the basics. In this first post we’ll focus on building a minimal EKS cluster using AWS CDK as the foundation for the next parts of the series.

Why AWS CDK for EKS?

Amazon EKS already provides multiple ways to create and manage clusters, from the AWS Console to CloudFormation and Terraform. However, when infrastructure starts to grow in complexity, the way it’s defined and maintained becomes just as important as the resources themselves.

CDK allows you to define infrastructure using familiar programming languages. Instead of managing large YAML or JSON templates, you work with code—loops, conditions, and abstractions included. This makes infrastructure easier to reason about, review, and evolve over time. According to the documentation, AWS CDK supports multiple languages such as Python, Go, TypeScript, JavaScript, and C#

For EKS specifically, the kit provides higher-level constructs that abstract away a lot of the boilerplate required to get a cluster running. Networking, IAM roles, and node groups can be defined in a few lines of code while still allowing you to customize the parts that matter.

How AWS CDK Works with Amazon EKS

The diagram above shows us how CDK interacts with AWS services when creating an Amazon EKS cluster.

Everything starts from your CDK application (stack), where infrastructure is defined using a programming language such as Go, TypeScript, or Python. At this stage, no AWS resources are created yet. When you run cdk synth, AWS CDK translates your code into a standard AWS CloudFormation template.

This CloudFormation template is then deployed using cdk deploy. At this point, AWS CloudFormation becomes responsible for provisioning the infrastructure. It creates all required AWS resources, including the VPC, IAM roles, the EKS control plane, and the managed node group. AWS CDK itself does not bypass CloudFormation, it simply acts as a higher-level abstraction on top of it.

Once CloudFormation finishes, the Amazon EKS cluster is fully provisioned and exposes a Kubernetes control plane backed by AWS-managed infrastructure. From this point forward, the cluster behaves like a standard Kubernetes cluster.

Optionally, the CDK can also interact with the Kubernetes API to manage workloads, such as applying Kubernetes manifests or deploying Helm charts. This step usually happens after the cluster is ready and is covered in later parts of this series.

Setup

In this series, all AWS CDK examples will be written in Python.
While AWS CDK supports multiple languages such as TypeScript and Go, the underlying concepts and constructs remain the same regardless of the language used.

Prerequisites

AWS account and configured AWS CLI

An active AWS account with permissions to create EKS, VPC, IAM, and CloudFormation resources. Installed and configured with valid credentials (aws configure).
Python 3.10+

Used for writing the AWS CDK application in this series.
AWS CDK installed

Installed globally via npm:
```
$ npm install -g aws-cdk
```
kubectl installed

Used to interact with the EKS cluster once it is created.

Notes

This post focuses on creating the EKS cluster. No Kubernetes workloads are deployed yet.
Make sure your AWS credentials have sufficient permissions before running cdk deploy, as EKS provisioning may take several minutes.

Project Initialization

We’ll start by creating a new AWS CDK project using Python. AWS CDK provides a project template that sets up the basic structure, dependencies, and configuration needed to get started.

First, create a new directory and initialize a CDK app:

$ mkdir cdk-eks
$ cd cdk-eks
$ cdk init app --language python

This command generates a basic project structure for a Python-based CDK application. The output after you run cdk init

Applying project template app for python

# Welcome to your CDK Python project!

This is a blank project for CDK development with Python.

The `cdk.json` file tells the CDK Toolkit how to execute your app.

...

Enjoy!

Executing Creating virtualenv...
Executing Installing dependencies...
✅ All done!

After initialization, you should see a structure similar to this:

.
├── app.py
├── cdk_eks
│   ├── cdk_eks_stack.py
│   └── __init__.py
├── cdk.json
├── README.md
├── requirements-dev.txt
├── requirements.txt
├── source.bat
└── tests
    ├── __init__.py
    └── unit

- app.py

The entry point of the CDK application. This is where the stack is instantiated.

- cdk_eks_stack.py

Contains the definition of the CDK stack where we’ll define the EKS cluster.

- requirements.txt

Python dependencies for the CDK app.

- cdk.json

CDK configuration file, including the command used to run the app.

- tests/

A placeholder for unit tests, which we’ll use in a later post.

1. Install Dependencies

Before writing any code, activate the Python virtual environment and install the dependencies. BTW, you need add this one to your requirements.txt: aws-cdk.lambda-layer-kubectl-v34.

$ source .venv/bin/activate
$ pip install -r requirements.txt

Keeping dependencies isolated using a virtual environment helps avoid version conflicts and keeps the project reproducible.

2. Run Bootsrap

If this is your first time using AWS CDK in the selected AWS account and region, you’ll need to bootstrap the environment:

$ cdk bootstrap

This command creates the necessary resources in your AWS account that CDK requires to deploy stacks.

At this point, the project is ready, and we can start defining the EKS cluster using AWS CDK.

Creating the EKS Cluster

In this section, we’ll define a minimal EKS cluster using AWS CDK. The goal is not to build a production-ready cluster yet, but to create a foundation that we can extend in later posts.

All changes will be made inside the CDK stack file

1. Import Required Modules

Open cdk_eks/cdk_eks_stack.py and start by importing the required CDK modules:

from aws_cdk import (
Stack,
aws_eks as eks,
aws_ec2 as ec2,
)

from aws_cdk.lambda_layer_kubectl_v32 import KubectlV32Layer

from aws_cdk import aws_iam as iam

from constructs import Construct

We’ll use:

ec2 for networking (VPC)
eks for creating the EKS cluster and its node groups

2. Define the VPC

EKS requires a VPC. For simplicity, we’ll let CDK create one for us:

class CdkEksStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        kubectl_layer = KubectlV32Layer(self, "KubectlLayer")

        vpc = ec2.Vpc(
            self,
            "EksVpc",
            max_azs=2 # AZ
        )

This creates a basic VPC across two Availability Zones, which is sufficient for a minimal cluster.

3. Create the EKS Cluster

Next, we define the EKS cluster itself:

cluster = eks.Cluster(
    self,
    "EksCluster",
    version=eks.KubernetesVersion.V1_32,
    vpc=vpc,
    default_capacity=0,
    kubectl_layer=kubectl_layer
)

A few important points:

Kubernetes version is explicitly set to avoid unexpected upgrades.
default_capacity=0 disables the default node group so we can define our own.

4. Add a Managed Node Group

Now we add a managed node group to run workloads:

cluster.add_nodegroup_capacity(
    "ManagedNodeGroup",
    desired_size=2,
    min_size=1,
    max_size=3,
    instance_types=[ec2.InstanceType("t3.medium")],
)

This creates:

A managed EC2-based node group
Autoscaling between 1 and 3 nodes
Instance type for testing

5. Add IAM

By default, creating an EKS cluster with AWS CDK does not automatically grant Kubernetes access to the IAM identity used to deploy the stack. While the control plane and node group roles are configured, additional IAM-to-Kubernetes RBAC mapping is required to access the cluster using kubectl.

cluster.aws_auth.add_user_mapping(
    iam.User.from_user_name(
    self,
    "AdminUser",
    "<REPLACE_WITH_YOUR_IAM>"
    ),
    groups=["system:masters"],
)

Or using Role

cluster.aws_auth.add_role_mapping(
    iam.Role.from_role_name(
    self,
    "EksAdminRole",
    "<REPLACE_WITH_YOUR_ROLE>"
    ),
    groups=["system:masters"],
)

Here is the full code:

from aws_cdk import (
Stack,
aws_eks as eks,
aws_ec2 as ec2,
)

from aws_cdk.lambda_layer_kubectl_v32 import KubectlV32Layer

from aws_cdk import aws_iam as iam

from constructs import Construct

class CdkEksStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        kubectl_layer = KubectlV32Layer(self, "KubectlLayer")

        vpc = ec2.Vpc(
            self,
            "EksVpc",
            max_azs=2
        )

        cluster = eks.Cluster(
            self,
            "EksCluster",
            version=eks.KubernetesVersion.V1_32,
            vpc=vpc,
            default_capacity=0,
            kubectl_layer=kubectl_layer
        )

        cluster.add_nodegroup_capacity(
            "ManagedNodeGroup",
            desired_size=2,
            min_size=1,
            max_size=3,
            instance_types=[ec2.InstanceType("t3.medium")],
        )

        cluster.aws_auth.add_user_mapping(
            iam.User.from_user_name(
            self,
            "AdminUser",
            "<YOUR_IAM>"
            ),
            groups=["system:masters"],
        )

At this point, our CDK stack defines:

A VPC
An EKS control plane
A managed node group for worker nodes

All of this is defined as code and will be provisioned via CloudFormation.

5 Synthesize the Stack

Before deploying, it’s a good idea to check what CDK will generate:

$ cdk synth

cdk synth 2>&1 | head -50

Resources:
  KubectlLayer600207B5:
    Type: AWS::Lambda::LayerVersion
    Properties:
      Content:
        S3Bucket:
          Fn::Sub: cdk-hnb659fds-assets-${AWS::AccountId}-${AWS::Region}
        S3Key: cc5bb5a423d0f1ccbfa20b3016434049b477f393e38ad2be0e8cba029f2a2373.zip
      Description: /opt/kubectl/kubectl 1.32.3; /opt/helm/helm 3.17.2
      LicenseInfo: Apache-2.0

...

This command outputs the CloudFormation template that will be used to create the EKS cluster.

Deploying the Stack

With the stack definition in place, we can now deploy the EKS cluster using AWS CDK. This step will trigger AWS CloudFormation to provision all required resources.

1. Deploy the Stack

Run the following command from the project root:

$ cdk deploy

During deployment, CDK will:

Package and upload assets (if any)
Create or update the CloudFormation stack
Provision AWS resources such as the VPC, IAM roles, EKS control plane, and managed node group

You’ll be prompted to confirm the deployment, as the stack creates IAM roles and other security-related resources. Review the changes and approve the deployment when prompted.

Verifying the Cluster

After the deployment completes, the next step is to verify that the EKS cluster has been created successfully and is in a healthy state.

At this point, you should see a CloudFormation stack created by AWS CDK in the AWS Console.
This stack represents all resources defined in the CDK application, including the VPC, IAM roles, EKS control plane, and the managed node group.

The stack status should be CREATE_COMPLETE, indicating that all resources were provisioned without errors. This also reinforces that AWS CDK relies on CloudFormation as the underlying provisioning engine.

Next, navigate to the Amazon EKS console. You should see the newly created cluster listed and marked as Active.

1. Accessing the Cluster with kubectl

To interact with the cluster, update your kubeconfig:

$ aws eks update-kubeconfig --name <cluster-name> --region <region>

Once configured, verify that the nodes are registered:

$ kubectl get nodes

Cleaning Up Resources

This command deletes the CloudFormation stack and all resources created by AWS CDK, including the EKS cluster, node groups, and networking components.
Since EKS is not covered by the AWS free tier, it’s recommended to clean up resources when they are no longer needed.

$ cdk destroy

What’s Next?

At this point, we have a fully functional Amazon EKS cluster created and managed using AWS CDK. The cluster is accessible via kubectl, the node group is running, and IAM access has been configured correctly. This gives us a foundation, but so far, the cluster is still empty.

In the next post, we’ll move beyond infrastructure and start running actual workloads on this cluster. Instead of applying raw Kubernetes YAML files manually, we’ll use AWS CDK to deploy workloads in a more structured and repeatable way.

Aight, thanks for taking the time read this post. Here is the full code of this post:

danielcristho/that-i-write/create-kube-cluster

Exploring Logging in Caddy

Daniel Pepuho — Wed, 17 Dec 2025 18:45:40 +0000

At some point, I realized that ‘it works’ is not enough. I need to know how it works too.”

When something slows down or fails, the question is no longer “is the service running?” but:

- Which component handled this request?

- How long did it take?

- Did the proxy retry or switch upstreams?

Without clear answers, even a simple issue can turn into a long time debugging😆. This is where logging stops being a checkbox feature and starts becoming a core part of system design.

Why Default Logs Are Not Enough?

By default, Caddy already gives you access logs. They show incoming requests, response status codes, and basic metadata. For simple setups, that might be sufficient.

But once a system grows even slightly those logs start to fall short.

The first issue is noise. Default logs tend to mix everything together: health checks, internal probes, real user traffic. Important signals get buried under routine requests.

The second issue is missing context. When a request goes through a reverse proxy with load balancing, the most interesting part is often not the request itself, but what happens behind the scenes:

- How long did the upstream take to respond?

- Was there a retry or a fallback?

Without this information, debugging becomes guesswork. A 502 response tells you that something failed, but not where or why.

This post explores how to make Caddy logs actually useful especially in a Dockerized setup with reverse proxying and load-balanced Go APIs.

Understanding Caddy Logging Model

Like most web servers, Caddy separates access logs from error logs. Access logs tell you what happened to a request. Error logs tell you why something went wrong.

1. Access Logs

Access logs describe the lifecycle of an incoming request:

- who made the request

- what was requested

- how the server responded

- how long it took

This is where most operational insights come from. When properly configured, access logs can tell you:

- which upstream handled a request

- how traffic is distributed

- where latency is introduced

2. Error Logs

Error logs focus on failures and exceptional cases:

- upstream connection errors

- timeouts

- TLS or protocol issues

These logs are usually quieter, but they become critical when things break. They complement access logs by explaining why a request failed, not just that it failed.

Enabling JSON Access Logs

For this setup, I’m using a simple Go application as the backend worker. Each instance responds with its hostname, making it easy to see how requests are distributed by the load balancer.

func handler(w http.ResponseWriter, r *http.Request) {
    hostname, _ := os.Hostname()
    fmt.Fprintf(w, "Hello from %s\n", hostname)
}

The full load-balancing setup, Caddy in front of three Go workers running in Docker has already been covered in a previous post.
If you need the full context, you can refer to here:

https://danielcristho.site/blog/go-caddy-load-balancer#the-project-setup

Logging in a Docker-Based Load Balancer

When running Caddy inside Docker, the most practical logging strategy is to write logs to stdout and let Docker handle log collection.

When you first run the stack:

$ docker compose up -d --build 

$ docker logs load_balancer

You’ll mostly see logs like:

{"level":"info","ts":1765883971.5864136,"msg":"maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined"}
{"level":"info","ts":1765883971.586685,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":16911289958,"previous":9223372036854775807}
{"level":"info","ts":1765883971.586744,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1765883971.5883265,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"warn","ts":1765883971.5883417,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1765883971.5897346,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
{"level":"warn","ts":1765883971.5899262,"logger":"http.auto_https","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv0","http_port":80}
{"level":"warn","ts":1765883971.5901978,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"warn","ts":1765883971.590206,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"}
{"level":"info","ts":1765883971.5902092,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"info","ts":1765883971.5905173,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00070c200"}
{"level":"info","ts":1765883971.5906706,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1765883971.591785,"msg":"serving initial configuration"}
{"level":"info","ts":1765883971.5926607,"logger":"tls","msg":"cleaning storage unit","storage":"FileStorage:/data/caddy"}
{"level":"info","ts":1765883971.5949264,"logger":"tls","msg":"finished cleaning storage units"}

These are startup and internal runtime logs, not HTTP access logs. Access logs only appear after real HTTP traffic flows through Caddy.

To make access logs enable JSON logging globally in the Caddyfile you can put output stdout like this.

{
    log {
        level INFO
        format json
    }
}

:80 {
    log {
        output stdout
        format json
    }

    reverse_proxy worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy random
        health_uri /
        health_interval 3s
    }
}

At this point:

- logs are emitted to stdout

- Docker captures them automatically

Once the stack is running, send a few requests:

curl http://localhost:8082
curl http://localhost:8082
curl http://localhost:8082

You should see responses like:

Hello from worker_1
Hello from worker_2
Hello from worker_3

Now check the logs again:

{"level":"info","ts":1765884414.2170205,"logger":"tls","msg":"cleaning storage unit","storage":"FileStorage:/data/caddy"}
{"level":"info","ts":1765884414.2187994,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1765884423.2440372,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"51346","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"Sec-Fetch-Mode":["navigate"],"Sec-Gpc":["1"],"Connection":["keep-alive"],"Priority":["u=0, i"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Site":["none"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0"],"Sec-Fetch-User":["?1"],"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Upgrade-Insecure-Requests":["1"]}},"bytes_read":0,"user_id":"","duration":0.000733253,"size":20,"status":200,"resp_headers":{"Content-Length":["20"],"Via":["1.1 Caddy"],"Content-Type":["text/plain; charset=utf-8"],"Date":["Tue, 16 Dec 2025 11:27:03 GMT"]}}
{"level":"info","ts":1765884423.7748682,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"51346","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0"],"Sec-Fetch-User":["?1"],"Sec-Gpc":["1"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Site":["none"],"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Priority":["u=0, i"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Connection":["keep-alive"],"Sec-Fetch-Mode":["navigate"]}},"bytes_read":0,"user_id":"","duration":0.000783659,"size":20,"status":200,"resp_headers":{"Via":["1.1 Caddy"],"Date":["Tue, 16 Dec 2025 11:27:03 GMT"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"]}}
{"level":"info","ts":1765884424.1060758,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"51346","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Site":["none"],"Accept-Language":["en-US,en;q=0.5"],"Sec-Gpc":["1"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-User":["?1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-Mode":["navigate"],"Priority":["u=0, i"],"Connection":["keep-alive"]}},"bytes_read":0,"user_id":"","duration":0.002117571,"size":20,"status":200,"resp_headers":{"Via":["1.1 Caddy"],"Date":["Tue, 16 Dec 2025 11:27:04 GMT"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"]}}
{"level":"info","ts":1765884424.456112,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"51346","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"Connection":["keep-alive"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Priority":["u=0, i"],"Accept-Language":["en-US,en;q=0.5"],"Sec-Fetch-Mode":["navigate"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-Dest":["document"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0"],"Sec-Gpc":["1"]}},"bytes_read":0,"user_id":"","duration":0.000959646,"size":20,"status":200,"resp_headers":{"Content-Type":["text/plain; charset=utf-8"],"Via":["1.1 Caddy"],"Date":["Tue, 16 Dec 2025 11:27:04 GMT"],"Content-Length":["20"]}}
{"level":"info","ts":1765884440.3606126,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"49074","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"User-Agent":["curl/7.81.0"],"Accept":["*/*"]}},"bytes_read":0,"user_id":"","duration":0.000425884,"size":20,"status":200,"resp_headers":{"Date":["Tue, 16 Dec 2025 11:27:20 GMT"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"],"Via":["1.1 Caddy"]}}
{"level":"info","ts":1765884442.148407,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"49090","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"Accept":["*/*"],"User-Agent":["curl/7.81.0"]}},"bytes_read":0,"user_id":"","duration":0.000592974,"size":20,"status":200,"resp_headers":{"Via":["1.1 Caddy"],"Date":["Tue, 16 Dec 2025 11:27:22 GMT"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"]}}
{"level":"info","ts":1765884442.6677225,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"49102","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"User-Agent":["curl/7.81.0"],"Accept":["*/*"]}},"bytes_read":0,"user_id":"","duration":0.000432397,"size":20,"status":200,"resp_headers":{"Via":["1.1 Caddy"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"],"Date":["Tue, 16 Dec 2025 11:27:22 GMT"]}}
{"level":"info","ts":1765884443.2411807,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"49106","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"Accept":["*/*"],"User-Agent":["curl/7.81.0"]}},"bytes_read":0,"user_id":"","duration":0.000496529,"size":20,"status":200,"resp_headers":{"Content-Type":["text/plain; charset=utf-8"],"Date":["Tue, 16 Dec 2025 11:27:23 GMT"],"Via":["1.1 Caddy"],"Content-Length":["20"]}}

To make the logs more readable you can use jq:

docker logs -f load_balancer 2>&1 | jq -R 'fromjson? | {level, logger, msg, request: {method: .request.method, uri: .request.uri}, status, duration}'

...

{
  "level": "info",
  "logger": "tls",
  "msg": "finished cleaning storage units",
  "request": {
    "method": null,
    "uri": null
  },
  "status": null,
  "duration": null
}
{
  "level": "info",
  "logger": "http.log.access.log0",
  "msg": "handled request",
  "request": {
    "method": "GET",
    "uri": "/"
  },
  "status": 200,
  "duration": 0.000733253
}

...

Which Upstream Handled This Request?

Using Debug Logs to Expose Load Balancer Decisions

Earlier, we saw that standard access logs don’t explicitly show which backend handled a request. Caddy can expose upstream selection details, just not in access logs. The information lives in debug-level logs, specifically inside the reverse proxy handler.

By enabling debug mode, Caddy reveals how routing decisions are made internally.

{
    log {
        level DEBUG
        format json
    }
}

In this mode, a single request produces logs like this, you can see which upstream that handled request "dial":"worker_3:8081":

{"level":"debug","logger":"http.handlers.reverse_proxy","msg":"selected upstream","dial":"worker_3:8081","total_upstreams":3}

Simulating Failure (Error Logs)

So far, everything looks fine. Requests succees and access logs show no anomalies.

Real systems rarely fail all at once. They fail partially one backend goes down, a health check starts failing, or a connection becomes unstable. In this setup, stopping one worker is enough:

$ docker stop worker_2

Try to hit the URL again:

$ curl http://localhost:8082

Hello from worker_3
Hello from worker_1
Hello from worker_3

From the client’s perspective, nothing breaks. Requests are still served, and responses keep coming back from the remaining healthy workers. This is exactly what we expect from a load balancer.

Now if you see the logs again, there is an unhealthy upstream:

{: dial tcp: lookup worker_2 on 127.0.0.11:53: no such host"}
{"level":"info","ts":1765992098.8407533,"logger":"http.handlers.reverse_proxy.health_checker.active","msg":"HTTP request failed","host":"worker_2:8081","error":"Get \"http://worker_2:8081/\": dial tcp: lookup worker_2 on 127.0.0.11:53: no such host"}
{"level":"info","ts":1765992101.6597724,"logger":"http.handlers.reverse_proxy.health_checker.active","msg":"HTTP request failed","host":"worker_2:8081","error":"Get \"http://worker_2:8081/\": dial tcp: lookup worker_2 on 127.0.0.11:53: no such host"}
{"level":"info","ts":1765992104.640808,"logger":"http.handlers.reverse_proxy.health_checker.active","msg":"HTTP request failed","host":"worker_2:8081","error":"Get \"http://worker_2:8081/\": dial tcp: lookup worker_2 on 127.0.0.11:53: no such host"}

This message is emitted by Caddy’s active health checker. It indicates that:

- worker_2 is no longer reachable

- the failure happens during health check probes

Customizing Log Output

Up to this point, all examples use JSON access logs. They are structured, machine-friendly, and easy to filter.

Caddy allows you to control how logs are encoded, not just what gets logged. This is useful when the goal shifts from processing logs to reading them.

Console Logs

Besides json, Caddy also provides a console encoder. It formats logs in a more friendly way while still preserving structure.

{
    log {
        level INFO
        format json
    }
}

:80 {
    log {
        output stdout
        format console
    }

    reverse_proxy worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy random
        health_uri /
        health_interval 3s
    }
}

$ docker restart load_balancer

After restarting the container, access logs will look like this:

$ docker logs load_balancer

2025/12/17 17:31:44.788 INFO    http.log.access.log0    handled request {"request": {"remote_ip": "172.21.0.1", "remote_port": "36598", "client_ip": "172.21.0.1", "proto": "HTTP/1.1", "method": "GET", "host": "localhost:8082", "uri": "/", "headers": {"User-Agent": ["curl/7.81.0"], "Accept": ["*/*"]}}, "bytes_read": 0, "user_id": "", "duration": 0.001321876, "size": 20, "status": 200, "resp_headers": {"Date": ["Wed, 17 Dec 2025 17:31:44 GMT"], "Content-Length": ["20"], "Content-Type": ["text/plain; charset=utf-8"], "Via": ["1.1 Caddy"]}}

Choosing the Right Format

There is no universally “correct” log format.

- JSON works best when logs are consumed by tools or pipelines.

- Console works better when you are actively watching logs and debugging in real time.

Shaping Logs Without Changing Their Meaning

Caddy also allows fine-grained control over how log fields are named and formatted. This is not about adding new information, but about making existing information easier to work with.

For example, you can:

- rename common fields

- control timestamp formats

- standardize duration units

- normalize log levels

... 
{
    log {
        output stdout
        format json {
            time_format     "2006-01-02 15:04:05 MST"
            time_local
            duration_format "ms"
            level_format    "upper"
        }
    }
}

Here’s the updated access log after applying the custom JSON format:

{sp_headers":{"Via":["1.1 Caddy"],"Content-Type":["text/plain; charset=utf-8"],"Date":["Wed, 17 Dec 2025 17:36:47 GMT"],"Content-Length":["20"]}}
{"level":"debug","ts":1765993007.632117,"logger":"http.handlers.reverse_proxy","msg":"selected upstream","dial":"worker_1:8081","total_upstreams":3}
{"level":"debug","ts":1765993007.6339025,"logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"worker_1:8081","duration":0.001633852,"request":{"remote_ip":"172.21.0.1","remote_port":"36378","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"X-Forwarded-For":["172.21.0.1"],"X-Forwarded-Proto":["http"],"X-Forwarded-Host":["localhost:8082"],"Via":["1.1 Caddy"],"User-Agent":["curl/7.81.0"],"Accept":["*/*"]}},"headers":{"Date":["Wed, 17 Dec 2025 17:36:47 GMT"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"]},"status":200}
{"level":"INFO","ts":"2025-12-17 17:36:47 UTC","logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"36378","client_ip":"172.21.0.1","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"User-Agent":["curl/7.81.0"],"Accept":["*/*"]}},"bytes_read":0,"user_id":"","duration":2,"size":20,"status":200,"resp_headers":{"Via":["1.1 Caddy"],"Date":["Wed, 17 Dec 2025 17:36:47 GMT"],"Content-Length":["20"],"Content-Type":["text/plain; charset=utf-8"]}}

What Changed?

The structure of the log is still JSON, but key fields are now normalized:

- level is uppercase (INFO)

- readable timestamps and localized

- duration is expressed in milliseconds instead of fractional seconds

This makes the log easier to read during debugging.

Reducing Noise and Risk in Logs

Once logs are readable and structured, the next concern is volume and exposure. Not every field in an access log is equally useful, and some of them are better left out entirely.

Caddy allows selective filtering at the log level, making it possible to reduce noise without changing how requests are handled.

Reducing Noise by Removing Fields

Access logs often include fields that are technically correct but not relevant, like request headers.

If headers are not part of your debugging workflow, you can remove them:

...
log {
    format filter {
        request delete
        wrap json
    }
}

With the request field removed entirely, access logs become significantly smaller:

{"level":"info","msg":"handled request","duration":0.001026852,"size":20,"status":200}

In other cases, it’s enough to remove only specific nested fields:

...
log {
    format filter {
        request>headers>Authorization delete
        resp_headers>Server delete
        wrap json
    }
}

Instead of deleting the entire request, selectively removing fields gives a better balance.

"headers": {"User-Agent": ["curl/7.81.0"], "Accept": ["*/*"]}

Obscuring Sensitive Information

Some fields should not be stored in plain text at all. Rather than relying on downstream redaction, Caddy can obscure sensitive data at the source:

log {
    format filter {
        request>client_ip ip_mask {
            ipv4 24
            ipv6 56
        }
        wrap json
    }
}

With IP masking enabled, the change is subtle but important:

{"level":"info","ts":1765994419.4105134,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"172.21.0.1","remote_port":"58562","client_ip":"172.21.0.0","proto":"HTTP/1.1","method":"GET","host":"localhost:8082","uri":"/","headers":{"Accept":["*/*"],"User-Agent":["curl/7.81.0"]}},"bytes_read":0,"user_id":"","duration":0.00146917,"size":20,"status":200,"resp_headers":{"Content-Type":["text/plain; charset=utf-8"],"Date":["Wed, 17 Dec 2025 18:00:19 GMT"],"Via":["1.1 Caddy"],"Content-Length":["20"]}}

"client_ip": "172.21.0.0"

The request remains traceable across logs, but the exact client address is no longer exposed.

Filtering is not about producing minimal logs. It’s about producing intentional logs.

I only apply filters after understanding:

- which fields I actually use

- which ones are never read

TL;DR

- Enabling logs is easy. Making them useful takes effort.

- Access logs show what happened to a request.

- Debug logs show how requests are routed.

- Error logs show what fails behind the scenes.

- Filtering and formatting reduce noise without hiding behavior.

Aight, that's all. Thank you for taking your time to read this post.

Feel free to give me feedback, tips, or a different perspective. I’d love to hear yours and continue the discussion.

Happy logging!🧐

References:

- Caddy Documentation: log

- Caddy Documentation: How Logging Works

Docker Image Compression: gzip vs zstd

Daniel Pepuho — Tue, 02 Dec 2025 15:15:35 +0000

Docker images are already compressed when you push them to registries like Docker Hub, GHCR, AWS ECR, etc.

So why would anyone compress an image again by using gzip or zstd?

Because in the real world, engineers often need to:

- move images between servers (air-gapped networks),

- migrates registries,

- backup image to object,

- load or save images repeatedly in Continuous Integration (CI) pipelines.

In these cases, docker save produces a raw .tar file often huge.
Compressing that tarball can cut transfer and storage time by 50-80%.

But what’s the best compression tool? So we will test gzip vs zstd.

🤔 When Do We Need Image Compression?

Like I said before, you need to compress your image to:

- transfer image between SSH or local network (LAN),

- work with offline or air-gapped servers,

- backup images to object storage,

- migrate to new registry.

Skip compression when images are pushed directly to registry like DockerHub, registries are handled that.

Test Up

To get a realistic number, we will test three images:

- alpine:latest -> ~8MB

- maridb:10.6.18 -> ~396MB

- Custom Jupyterlab image -> ~5.4GB

Environment

1. Local Computer

- CPU: 4 cores / 8 threads

- Storage: NVMe SSD

- OS: Ubuntu 22.04

- Docker Version: 27x

- Tools: gzip, zstd, time, scp

2. VPS

- CPU: 4 cores / 8 threads

- Storage: VirtIO-backed SSD

- OS: Ubuntu 22.04

- Docker Version: 27x

- Tools: gzip, zstd, time

Command used

Below are the commands used to save, compress, transfer, decompress, and load the Docker images during testing.

1. Save the image (local machine)

docker pull <image_name>
docker save <image_name> -o <image_name>.tar

$ docker pull alpine:latest

latest: Pulling from library/alpine
Digest: sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412
...

$ docker save alpine:latest -o alpine_latest.tar

$ docker save mariadb:10.6.18 -o mariadb_10.tar

$ docker save danielcristh0/datascience-notebook:python-3.10.11 -o jupyter_notebook.tar


$ ls -lh

total 5,6G
-rw------- 1 user group 8,3M Nov 28 19:51 alpine_latest.tar
-rw------- 1 user group 5,2G Nov 28 20:18 jupyter_notebook.tar
-rw------- 1 user group 384M Nov 28 20:14 mariadb_10.tar

2. Compress the image (local machine)

- gzip

time gzip -k <image>.tar

$ time gzip -k alpine_latest.tar

gzip -k alpine_latest.tar  0,44s user 0,01s system 99% cpu 0,452 total

$ time gzip -k mariadb_10.tar

gzip -k mariadb_10.tar  17,21s user 0,62s system 99% cpu 17,979 total

$ time gzip -k jupyter_notebook.tar

gzip -k jupyter_notebook.tar  238,83s user 3,56s system 99% cpu 4:03,16 total

-k → keep original file

gzip uses a single CPU thread at its default level (≈ level 6)

- zstd

time zstd -T0 -19 <image>.tar

$  time zstd -T0 -19 alpine_latest.tar

alpine_latest.tar    : 37.01%   (8617984 => 3189867 bytes, alpine_latest.tar.zst)
zstd -T0 -19 alpine_latest.tar  3,64s user 0,10s system 100% cpu 3,734 total

$  time zstd -T0 -19 mariadb_10.tar

mariadb_10.tar       : 16.95%   (402636288 => 68258055 bytes, mariadb_10.tar.zst)
zstd -T0 -19 mariadb_10.tar  172,89s user 0,66s system 191% cpu 1:30,81 total

$  time zstd -T0 -22 jupyter_notebook.tar
Warning : compression level higher than max, reduced to 19
zstd: jupyter_notebook.tar.zst already exists; overwrite (y/n) ? y

jupyter_notebook.tar : 24.79%   (5560227328 => 1378450873 bytes, jupyter_notebook.tar.zst)
zstd -T0 -22 jupyter_notebook.tar  4759,54s user 19,32s system 188% cpu 42:11,68 total

-T0 → use all CPU threads

-22 → request maximum compression (automatically reduced to -19 by zstd)

3. Transfer to VPS

- gzip

time scp <image_name>.tar.gz user@vps:/tmp/

$ time scp alpine_latest.tar.gz onomi@myserver:/tmp
alpine_latest.tar.gz    100% 3588KB 174.8KB/s   00:20

scp alpine_latest.tar.gz onomi@myserver:/tmp  0,11s user 0,29s system 1% cpu 23,208 total


$ time scp mariadb_10.tar.gz onomi@myserver:/tmp/
mariadb_10.tar.gz   100%  114MB   2.2MB/s   00:50

scp mariadb_10.tar.gz onomi@myserver:/tmp/  0,46s user 0,84s system 2% cpu 52,457 total


$ time scp jupyter_notebook.tar.gz onomi@myserver:/tmp/
jupyter_notebook.tar.gz  100% 1765MB   3.4MB/s   08:35

scp jupyter_notebook.tar.gz onomi@myserver:/tmp/  5,03s user 10,42s system 2% cpu 8:38,50 total

- zstd

time scp <image_name>.tar.zst user@vps:/tmp/

$ time scp alpine_latest.tar.zst onomi@myserver:/tmp
alpine_latest.tar.zst   100% 3115KB 343.4KB/s   00:09

scp alpine_latest.tar.zst onomi@myserver:/tmp  0,10s user 0,18s system 1% cpu 22,728 total


$ time scp mariadb_10.tar.zst onomi@myserver:/tmp/
mariadb_10.tar.zst  100%   65MB   3.0MB/s   00:21

scp mariadb_10.tar.zst onomi@myserver:/tmp/  0,29s user 0,59s system 3% cpu 23,285 total


$ time scp jupyter_notebook.tar.zst onomi@myserver:/tmp/
jupyter_notebook.tar.zst    100% 1315MB   2.3MB/s   09:44

scp jupyter_notebook.tar.zst onomi@myserver:/tmp/  3,94s user 7,64s system 1% cpu 9:46,33 total

4. Load the Image on the Server (VPS)

Now the compressed images are transferred to the VPS, the next step is to decompress them and load the Docker image into the remote server.

- gzip

time gzip -dk <image>.tar.gz

$ time gzip -dk alpine_latest.tar.gz

real    0m0.189s
user    0m0.116s
sys     0m0.039s


$ time gzip -dk mariadb_10.tar.gz


real    0m5.108s
user    0m3.813s
sys     0m1.129s

$ time gzip -dk jupyter_notebook.tar.gz

real    1m8.344s
user    0m48.466s
sys     0m13.408s

- zstd

time zstd -d <image>.tar.zst

$ time zstd -d alpine_latest.tar.zst
alpine_latest.tar.zst: 8617984 bytes

real    0m4.121s
user    0m0.041s
sys     0m0.043s

$ time zstd -d mariadb_10.tar.zst
mariadb_10.tar.zst  : 402636288 bytes

real    0m3.455s
user    0m0.983s
sys     0m0.927s

$ time zstd -d jupyter_notebook.tar.zst

jupyter_notebook.tar.zst: 5560227328 bytes

real    0m31.810s
user    0m14.599s
sys     0m13.600s

Decompression in zstdis extremely fast, 5-10x faster than compression, even for large files.

5. Loading the Image Into Docker

Once decompressed, load the .tar file:

docker load -i <image>.tar

$ docker load -i jupyter_notebook.tar

Loaded image: danielcristh0/datascience-notebook:python-3.10.11

$ docker images

IMAGE                                               ID             DISK USAGE   CONTENT SIZE   EXTRA
danielcristh0/datascience-notebook:python-3.10.11   9b38bf7c570f       11.4GB         5.56GB

6. Analysis: gzip vs zstd

After running all compression, transfer, decompression, and loading tests across three different Docker images, let's compare gzip and zstd.

Size Comparison

zstd consistently produces much smaller output files than gzip, especially on medium and large images.

Image	Actual Size	gzip Size	zstd Size	Reduction (gzip)	Reduction (zstd)
alpine:latest	8.3 MB	3.5 MB	3.1 MB	~57%	~62%
mariadb:10.6.18	384 MB	114 MB	65 MB	~70%	~83%
jupyter-notebook	5.2 GB	1.7 GB	1.3 GB	~67%	~75%

zstd gives around 20-50% better compression than gzip.

Speed

gzipis faster than zstd at compression.

Image	gzip (time)	zstd (time)	Notes
alpine	0.45 s	3.7 s	8x slower
mariadb	17.9 s	90.8 s	5x slower
jupyter-notebook	243 s	42 minutes	10x slower

zstd gives better compression but requires significantly more CPU.

Transfer Speed (via SCP)

Because zstd produces smaller files, transfer times are 2x faster. But on larger files, zstd can still lose to gzip depending on CPU and disk performance.

Image	gzip Transfer	zstd Transfer
alpine	20 s	9 s
mariadb	50 s	21 s
jupyter-notebook	8m 35s	9m 44s

When Should You Use gzip or zstd?

Use zstd when you want

- The smallest compressed Docker images

- Fast decompression

- Faster transfers across networks

- Long-term backups

Use gzip when you want:

- Fast compression

- Low CPU usage

- Simple, predictable behavior

- Occasional small image transfers

Conclusion

If you need to compress Docker images, here’s the quick answer:

Use zstd when you want:

- Smaller archive sizes (around 20-50% smaller than gzip)

- Faster decompression

- Faster network transfers

Use gzip when you want:

- Fast compression

- Low CPU usage

- Simplicity

Aight, that's all. Thank you for taking your time to read this post.

Feel free to give me feedback, tips, or different benchmarks. I’d love to hear your feedback and continue the discussion.

Happy containerization! 🐳

Running Firefox in Docker? Yes, with a GUI and noVNC!

Daniel Pepuho — Fri, 21 Nov 2025 15:02:15 +0000

Docker isn’t just for serve your code, appliactions. you can actually run a full desktop app inside it. In this project, I containerized Firefox with a virtual desktop and made it accessible through a browser using noVNC.

What this project does?

It creates a lightweight container that:

- Runs a minimal desktop environment (Fluxbox)
- Launches Firefox
- Serves a VNC display using x11vnc
- Exposes that desktop through noVNC (so you can open it in your web browser)

You can literally open Firefox running inside Docker, from your browser tab.
All using a single docker compose up.

How it works?

Here’s a quick breakdown of what happens inside the container:

Everything runs headlessly, there’s no physical display, but the combo of Xvfb + Fluxbox gives Firefox a virtual desktop.

🐋 Dockerfile Overview

FROM alpine:edge

RUN apk add --no-cache \
    faenza-icon-theme \
    firefox \
    fluxbox \
    xfce4 \
    xvfb \
    x11vnc \
    novnc \
    supervisor \
    bash \
    net-tools

# Install noVNC & websockify from source code
RUN apk add --no-cache git python3 py3-pip \
    && rm -rf /usr/share/novnc \
    && git clone https://github.com/novnc/noVNC.git /usr/share/novnc \
    && git clone https://github.com/novnc/websockify.git /usr/share/novnc/utils/websockify \
    && ln -sf /usr/share/novnc/vnc.html /usr/share/novnc/index.html

ENV DISPLAY=:1
ENV RESOLUTION=1920x1080x24

# Set vnc password
ARG VNC_PASS=dummypass

# Create vnc password file
RUN mkdir -p /root/.vnc && \
    x11vnc -storepasswd "$VNC_PASS" /root/.vnc/passwd

COPY supervisord.conf /etc/supervisord.conf

EXPOSE 5900 6080

CMD ["supervisord", "-c", "/etc/supervisord.conf", "-n"]

📦 Docker Compose Setup

version: '3.8'
services:
  vnc_firefox:
    build: .
    container_name: vnc_firefox
    ports:
      - "5901:5900" # VNC
      - "6080:6080" # noVNC web UI
     healthcheck:
      test: ["CMD-SHELL", "netstat -tln | grep -q 6080 || exit 1"]
      interval: 1m30s
      timeout: 30s
      retries: 5
      start_period: 30s

Under the Hood (process supervision)

Everything is managed by supervisord, which runs:

Xvfb - virtual framebuffer display

x11vnc - provides VNC access

fluxbox - lightweight window manager (WM)

firefox - your GUI browser

novnc_proxy - web socket bridge

Example supervisord.conf:

# Supervisor main config
[supervisord]
nodaemon=true
logfile=/var/log/supervisord.log
pidfile=/var/run/supervisord.pid
childlogdir=/var/log

# XVirtual Framebuffer (Xvfb)
# Creates a virtual display environment (:1)
[program:xvfb]
command=/usr/bin/Xvfb :1 -screen 0 1920x1080x24
autostart=true
autorestart=true
priority=10

# x11vnc, VNC server
[program:x11vnc]
command=/usr/bin/x11vnc -display :1 -rfbauth /root/.vnc/passwd -forever -shared -rfbport 5900
autostart=true
autorestart=true
priority=20

# fluxbox, lightweight window manager
[program:fluxbox]
command=/usr/bin/fluxbox
environment=DISPLAY=":1"
autostart=true
autorestart=true
priority=30

# Runs firefox inside the Xvfb + Fluxbox environment
[program:firefox]
command=/usr/bin/firefox
environment=DISPLAY=":1"
autostart=true
autorestart=true
priority=40

# noVNC, WebSocket VNC Proxy
# Bridges VNC (port 5900) to a web interface (port 6080)
[program:novnc]
command=/usr/share/novnc/utils/novnc_proxy --vnc localhost:5900 --listen 6080
autostart=true
autorestart=true
priority=50

Our project structure should look likes this:

.
├── docker-compose.yml
├── Dockerfile
└── supervisord.conf

How to Run It?

1. Build & start the container:

$ docker compose up --build -d

2 Access it by using your browser or VNC client. Using dummypass as password:

- Using noVNC Web: http://localhost:6080

- Open any VNC viewer (e.g., RealVNC, TigerVNC, Remmina), then connect to: localhost:5901

What’s Next?

While this is mostly a fun experiment, it can be used for:

- Headless browser testing environments

- Remote browsing (isolated Firefox)

- Demonstrating GUI automation setups

NB: 😎 This post is part of my “Container Stuffs” open-source project on GitHub. Upcoming labs include:

- PostgreSQL master–replica setup

- Redis Sentinel cluster

- Multi-node Docker Swarm simulations

- and more to come!

danielcristho/container-stuffs

Conclusion

Docker is more than backend services you can literally containerize entire user experiences.

Projects like this prove that containers aren’t limited to APIs, databases, and background workers. With a bit of creativity, you can run full desktops, interactive UIs, browsers, automation toolchains, and even full development environments inside isolated, reproducible containers.

Running Firefox inside Docker with noVNC shows how:

- system-level components (Xvfb, window managers, VNC)

- web technologies (WebSockets, noVNC)

- and container orchestration (Docker + Compose) can blend together to create something both useful and fun.

Cheers, feel free to give me a feedback, and happy containerizing! 🐳

My First Experience as a Speaker at AWS Community Day

Daniel Pepuho — Tue, 04 Nov 2025 01:02:13 +0000

Hello everyone! 👋

Last weekend, I had the amazing opportunity to be a speaker at AWS Community Day Indonesia 2025.
It was one of the most rewarding and eye-opening experiences in my tech journey and in this post, I’d love to share what the day was like, what I learned, and why it meant so much to me. BTW, I shared about “Building a Multi-Tenant Machine Learning Platform on AWS EKS with Ray and JupyterHub”.

Before the Event: Preparation

A few days before the event, to be honest, I felt a mix of excitement and nervousness.
Even though I’ve presented in smaller settings before, speaking at a community event like this felt special and a bit more serious!

Here’s what I did to prepare:

- Finalized my presentation topic, making sure the content was practical and relevant for developers and cloud enthusiast
- Practiced my talk several times out loud to get comfortable with the flow
- Set my mindset: I’m not just here to present. I’m here to connect, share, and learn from others.

That mindset shift really helped me calm down before stepping on stage.

During the Event: On Stage and Beyond

When the day finally came, the atmosphere was incredible buzzing with conversations, excitement, and passion for AWS and cloud technologies.

Some of my favorite moments were:
- Meeting so many people from the AWS community, many of whom I had only interacted with online before.
- Taking the stage to deliver my session “Building a Multi-Tenant Machine Learning Platform on AWS EKS with Ray and JupyterHub”.
- Even though I was nervous at first, once I started talking, everything clicked. It didn’t feel like a “presentation” anymore it felt like a conversation with friends who shared the same curiosity and enthusiasm.

Key Takeaways & Reflections

Looking back, here are a few lessons that really stuck with me:

- Community is everything. Behind every technology, it’s always about people learning, sharing, and growing together.
- Preparation builds confidence. The more I practiced, the more natural it felt on stage.
- Sharing is a two-way process. I came to give a talk, but I left with more insights from the audience than I expected
- Stay adaptable. Every crowd is different. Reading the room and adjusting how you explain something is an important skill.
- Keep growing. This experience reminded me that growth doesn’t just happen behind the keyboard it happens when you step out, speak, and share what you’ve learned.

What's Next?

To be honest, there are still many aspects I haven’t fully covered in my presentation. After this event, I plan to expand this talk into a deeper technical series exploring the end-to-end ML lifecycle using Ray on AWS.

While this session mainly focused on the infrastructure layer, there’s so much more to uncover about how Ray can power the entire machine learning pipeline from data preprocessing and distributed training with Ray Train, to hyperparameter tuning with Ray Tune, and serving models in production with Ray Serve.

You can see my deck here: Deck

Exploring Load Balancing in Caddy Using Docker

Daniel Pepuho — Wed, 27 Aug 2025 15:55:33 +0000

Hello there! In this post, we'll dive into the world of Caddy, a modern and powerful web server. Built using Go, Caddy offers a range of built-in features, including reverse proxy and load balancing.

By the way, in this project, I'll use Caddy 2, the latest version, which comes with a completely rewritten architecture and enhanced features. To make our setup and testing as smooth as possible, we'll leverage Docker. Docker allows us to create a reproducible environment with all the necessary components easily.

The main focus of this post will be on understanding and experimenting with Caddy's load balancing algorithms. We'll explore how Caddy intelligently distributes incoming traffic, the different strategies it offers (such as Round Robin, Least Connection, Random, and more), and how you can configure the for various use cases.

By using Docker, we'll quickly spin up multiple backend services (which are called "workers") and route requests through a single Caddy instance acting as our load balancer.

The Project Setup

To get started, let's look at the project structure. Our setup is straightforward, allowing us to focus on the core concepts of load balancing.

Here's the project structure:

├── caddy
│   └── Caddyfile
├── docker-compose.yml
└── src
    ├── Dockerfile
    ├── go.mod
    └── main.go

Our setup is composes of three main parts:

1. Backend Workers (src): These are simple Go applications the will handle the requests. Each worker will simply return a "Hello form [hostname]" message, allowing us to sess which server is handling the request. This is the perfect way to visualize how Caddy distributes the load.

2. Caddy Load Balancer (caddy): Our Caddy instance will act as the reverse proxy, forwarding requests to the worker services. We'll use the Caddyfile to define our load balancing rules.

3. Docker Compose (docker.compose.yml): This file orchestrates everything, defining and running our multi-container application with a single-command.

Understanding the Components

Let's break down the files in our project.

src/main.go

This is a simple Go HTTP server. It listens on port 8081 and responds to any request by printing its hostname. This is our primary tool for observing the load balancing behavior.

package main

import (
    "fmt"
    "net/http"
    "os"
)

func handler(w http.ResponseWriter, r *http.Request) {
    hostname, _ := os.Hostname()
    fmt.Fprintf(w, "Hello from %s\n", hostname)
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8081", nil)
}

src/Dockerfile

This Dockerfile builds our Go application into a lightweight, self-contained Docker image.

FROM golang:1.24 AS builder

WORKDIR /go/src/app

COPY . .

RUN go mod download

RUN CGO_ENABLED=0 go build -o /go/bin/app

FROM golang:1.24-alpine

COPY --from=builder /go/bin/app /

EXPOSE 8081
ENV PORT 8081

CMD ["/app"]

docker-compose.yml

This file ties everything together. We define a service for our Caddy load balancer and three worker services.

version: "3.8"

services:
  load_balancer:
    image: caddy:2.10-alpine
    container_name: load_balancer
    ports:
      - "8082:80"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile

  worker_1:
    build: ./src
    container_name: worker_1
    hostname: worker_1
    expose:
      - "8081"

  worker_2:
    build: ./src
    container_name: worker_2
    hostname: worker_2
    expose:
      - "8081"

  worker_3:
    build: ./src
    container_name: worker_3
    hostname: worker_3
    expose:
      - "8081"

caddy/Caddyfile

This is where the magic happens! The Caddyfile is Caddy's configuration file. We'll define a reverse proxy that routes to our workers. The lb_policy directive is where we'll specify our load balancing algorithms.

:80 {
    reverse_proxy worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy round_robin
        health_uri /
        health_interval 3s
    }
}

Experimenting with Load Balancing Algorithms

Now that our project is set up, we can start experimenting. To run the project, simply execute docker-compose up in your terminal. You can then send requests to http://127.0.0.1:8082 and observe which worker responds.

1. Round Robin (lb_policy round_robin)

This is the most common and simplest load balancing algorithm. Caddy distributes incoming requests to the backend servers in a sequential, rotating manner. It's a fair and predictable method, assuming all servers are equally capable of handling the load.

How to Configure:

Modify your caddy/Caddyfile to use the round_robin policy.

:80 {
    reverse_proxy worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy round_robin
        health_uri /
        health_interval 3s
    }
}

How to Test:

After running docker-compose up -d --build, open your terminal and send a few requests using curl. You should see that Caddy distributes the traffic evenly among the three workers.

$ curl http://127.0.0.1:8082
# Output: Hello from worker_1

$ curl http://127.0.0.1:8082
# Output: Hello from worker_2

$ curl http://127.0.0.1:8082
# Output: Hello from worker_3

$ curl http://127.0.0.1:8082
# Output: Hello from worker_1

Now, let's test Caddy's fault tolerance. In a real-world scenario, a server might crash or become unresponsive. We'll simulate this by manually stopping one of the workers.

Run the following command in your terminal to stop worker_1:

$ docker stop worker_1

After a few moments (the health_interval you set, e.g., 3 seconds), Caddy will perform its next health check, detect that worker_1 is unresponsive, and automatically mark it as unhealthy.

Now, send a few more requests. What do you expect to happen? With worker_1 down, Caddy should intelligently stop routing traffic to it and redirect all requests to the remaining healthy servers (worker_2 and worker_3).

2. Weighted Round Robin (lb_policy weighted_round_robin)

This algorithm is a more advanced version of Round Robin. It allows you to assign a "weight" to each backend server, which determines its share of the requests. Servers with a higher weight will receive more traffic than those with a lower weight. This is ideal when you have servers with varying capacities, for example, a new, more powerful server and an older, less powerful one.

You can also use this policy to gradually drain traffic from an old server or ramp up traffic to a new one during deployments, making it a very useful strategy.

How to Configure:

To use this policy, you need to add the weight to each server's address in the Caddyfile. For our example, let's give worker_1 a higher weight of 3, while worker_2 and worker_3 each have a weight of 1. This means worker_1 should handle three out of every five requests.

:80 {
    reverse_proxy  worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy weighted_round_robin 3 1 1
        health_uri /
        health_interval 3s
    }
}

After updating the Caddyfile, make sure to reload or restart your Caddy container to apply the changes. You can do this with docker-compose up -d --build.

How to Test:

Now, let's send a few requests to our load balancer and see how Caddy distributes the traffic according to the assigned weights. Send a few requests using curl and observe the responses.

$ curl http://127.0.0.1:8082
# Output: Hello from worker_1

$ curl http://127.0.0.1:8082
# Output: Hello from worker_1

$ curl http://127.0.0.1:8082
# Output: Hello from worker_2

$ curl http://127.0.0.1:8082
# Output: Hello from worker_3

$ curl http://127.0.0.1:8082
# Output: Hello from worker_1

3. Least Connection (lb_policy ip_hash)

Aight, let's dive into Least Connection. Unlike Round Robin, which is a simple, sequential algorithm, Least Connection is a dynamic and more intelligent load balancing policy. It chooses the backend server with the fewest number of currently active requests. This policy is excellent for situations where your requests have a highly variable processing time.

For example, if one of your servers gets a handful of complex, long-running requests while the others are handling many small, quick ones, this algorithm will automatically route new traffic to the servers that are less burdened, preventing a single server from becoming a bottleneck. If there's a tie, meaning two or more servers have the same lowest number of connections, Caddy will randomly choose one of them.

How to Configure:

Configuring this policy is simple. You just need to change the lb_policy directive in your Caddyfile.

:80 {
    reverse_proxy worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy least_conn
        health_uri /
        health_interval 3s
    }
}

After updating your Caddyfile, make sure to restart your Caddy container with docker-compose up -d --build to apply the changes.

How to Test:

To demonstrate the Least Connection algorithm, you'll need to modify your Go code to simulate a long-running request. This will allow you to see how Caddy intelligently routes traffic away from the busy worker.

- Update Your Go Code

Open your src/main.go file and add a new handler that will simulate a task with a significant delay. This will act as our "long-running request."

package main

import (
    "fmt"
    "net/http"
    "os"
    "time"
)

func handler(w http.ResponseWriter, r *http.Request) {
    hostname, _ := os.Hostname()
    fmt.Fprintf(w, "Hello from %s\n", hostname)
}

func longHandler(w http.ResponseWriter, r *http.Request) {
    hostname, _ := os.Hostname()
    time.Sleep(10 * time.Second)
    fmt.Fprintf(w, "Hello! long running request finished from %s\n", hostname)
}

func main() {
    http.HandleFunc("/", handler)
    http.HandleFunc("/long", longHandler)
    http.ListenAndServe(":8081", nil)
}

- Rebuild and Run Docker Compose

After updating your code, you must rebuild and run your containers to apply the changes.

$ docker-compose up -d --build

- Test the Scenario

Now, you can test the Least Connection algorithm using two separate terminals.

Terminal 1 (Long-Running Request):

Start a request to the /long endpoint. This will open a connection to one of the workers and hold it for 10 seconds. Caddy will detect that this worker has an active, ongoing connection.

$ curl http://127.0.0.1:8082/long

Terminal 2 (Normal Requests):

Immediately after running the command in Terminal 1, switch to Terminal 2 and send several quick requests to the root endpoint (/).


$ curl http://127.0.0.1:8082/
# Output: Hello from worker_2

$ curl http://127.0.0.1:8082/
# Output: Hello from worker_3

$ curl http://127.0.0.1:8082/
# Output: Hello from worker_2

You will observe that Caddy will not send requests to the worker that is currently busy with the long-running request. Instead, all new requests will be routed to the other two workers, demonstrating how the least_conn algorithm effectively balances load dynamically. Once the long-running request is complete, that worker will once again be available to handle new requests.

4. IP Hash (lb_policy ip_hash)

The IP Hash load balancing algorithm is different from the previous ones because it's focused on session persistence. Instead of distributing requests based on a sequential or random order, it creates a hash from the client's IP address and uses that hash to consistently route all requests from that same client to the same backend server.

How to Configure:

Configuring the IP Hash policy is straightforward. You simply need to replace the lb_policy directive in your Caddyfile with ip_hash.

:80 {
    reverse_proxy  worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy ip_hash
        health_uri /
        health_interval 3s
    }
}

After updating your Caddyfile, make sure to restart your Caddy container with docker-compose up -d --build to apply the changes.

How to Test:

To test this algorithm, you'll need to send requests from different "clients" (i.e., different IP addresses) and observe where they are routed. The easiest way to simulate this is by sending requests from your local machine and then using a proxy or a different network to see if the requests are routed to a different server.

No matter how many times you run curl from the same machine, the requests will always be routed to the same worker. This is because Caddy is hashing your local IP address (127.0.0.1 or the container's internal IP) and consistently mapping it to that specific worker.

This demonstrates how IP Hash ensures session stickiness without needing to share session data across all servers. It’s a powerful tool for maintaining a consistent user experience.

5. Random (lb_policy random)

The Random load balancing policy is the simplest and most unpredictable of all the algorithms. As its name suggests, it selects a backend server at random for each new request. There is no sequential pattern or special logic; every request has an equal chance of being routed to any of the available servers.

While it may seem less sophisticated than other algorithms, the Random policy is surprisingly effective in many scenarios. It's fast, has a very low overhead, and can be a great choice for distributing traffic evenly across a large pool of homogenous servers. It naturally avoids the "thundering herd" problem that can sometimes occur with Round Robin on first-come-first-served requests, as it prevents all clients from hitting the same server at the same time.

How to Configure:

Configuring this policy is the easiest. Simply replace the lb_policy directive in your Caddyfile with random.

:80 {
    reverse_proxy  worker_1:8081 worker_2:8081 worker_3:8081 {
        lb_policy random
        health_uri /
        health_interval 3s
    }
}

After updating your Caddyfile, make sure to restart your Caddy container with docker-compose up -d --build to apply the changes.

How to Test:

To test the Random policy, send a series of quick requests and observe the output. Unlike the predictable pattern of Round Robin or the consistent output of IP Hash, the responses will come from different workers in an unpredictable order.

curl http://127.0.0.1:8082
# Output: Hello from worker_3

curl http://127.0.0.1:8082
# Output: Hello from worker_1

curl http://127.0.0.1:8082
# Output: Hello from worker_2

curl http://127.0.0.1:8082
# Output: Hello from worker_1

Conclusion

Throughout this post, we've explored the core capabilities of Caddy as a powerful web server and a flexible load balancer. Using a simple Docker setup, we were able to quickly demonstrate five different load balancing algorithms, each with its own unique advantages:

- Round Robin: The classic, simple approach for evenly distributing traffic in a predictable sequence.

- Weighted Round Robin: A smarter version of Round Robin that allows you to prioritize traffic to more powerful servers.

- Least Connection: A dynamic algorithm that routes traffic based on real-time load, preventing a single server from becoming a bottleneck.

- IP Hash: The ideal choice for session stickiness, ensuring a consistent user experience by always routing a client to the same backend server.

- Random: A straightforward and fast algorithm for scattering traffic across servers, effective for a large pool of homogenous workers.

This hands-on experience proved that Caddy is not just a simple web server but a robust tool for building scalable and reliable applications. Caddy's elegant syntax and powerful features make it an excellent choice for anyone looking to simplify their server configurations without sacrificing control or performance. Whether you're a seasoned developer or just starting, Caddy offers a smooth and intuitive experience that can handle everything from a single website to a complex, distributed application.

References:

- Caddy Documentation: Reverse Proxy

- Caddy Community Wiki

Dockerizing Go API and Caddy

Daniel Pepuho — Mon, 18 Aug 2025 02:24:50 +0000

Hello! In this post I'll walk through how to use Caddy as a reverse proxy and Docker for containerization to deploy a simple Go API. This method offers a quick and modern to getting your Go API up and running.

Before we dive into the deployment steps, let's briefly discuss why Docker and Caddy are an excellent combination.

Docker is a containerization platform that packages your app and all its dependecies into an isolated unit. This guarantess that your app runs consistenly everywhere, eliminating the classic "it works on my machine" problem.

Dockerile is the blueprint that defines how your Docker image is built. It specifies the base image, the steps to compile your application, and how the container should run.
Docker Compose is a tool for defining and running multi-container Docker applications. Instead of starting each container manually, we can describe the entire stack in a single YAML file.
Caddy is a modern reverse proxy and web server built using Go. Caddy is renowned for its ease of use, especially its automatic HTTPS feature. Its simple configuration makes it an ideal choice for serving our API.

Requirements

Before we start, you'll need to install Go, Docker and Docker Compose on your system.

1. Go

Make sure Go is installed. You can check your version with:

$ go version

go version go1.24.0 linux/amd6

If it's not installed, you can download it from the official site.

2. Docker & Docker Compose

Make sure Docker & Docker Compose are installed. You can check your docker version with:

$ docker --version

Docker version 27.5.1, build 9f9e405

$ docker compose version

Docker Compose version v2.3.3

Follow the official guides to install Docker and Docker Compose for your operating system if you haven't installed them before. The official site.

Setting Up the Project

Step 1: Create and Run a Simple Go API

First, create a new directory for the project and initialize a Go module:

$ mkdir go-api && cd go-api

$ go mod init example.com/go-api

This command creates a Go module (go.mod) named example.com/go-api, which helps manage dependencies and makes the project reproducible.

Next, create a new file main.go and define a simple HTTP server using Chi as the router.

The server exposes two routes:

Root path / -> return an ASCII banner generated with the go-figure package.

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    asciiArt := figure.NewFigure("Go API - Caddy", "", true).String()
    fmt.Fprintln(w, asciiArt)
}

/api/hello -> returns a simple JSON response.

func apiHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    fmt.Fprintf(w, `{"message":"Hello, World!"}`)
}

In the main function, we:

Initialize the Chi router and register both routes.

Configure an HTTP server to listen on port 8081.

Run the server in a goroutine and listen for shutdown signals (SIGINT, SIGTERM).

Gracefully shut down the server with a 5-second timeout when a termination signal is received.

func main() {

    r := chi.NewRouter()

    // API Route
    r.Get("/", handler)
    r.Get("/api/hello", apiHandler)

    srv := &http.Server{
        Addr:    ":8081",
        Handler: r,
    }

    stop := make(chan os.Signal, 1)
    signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)

    go func() {
        fmt.Println("Server started at :8081")
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            fmt.Printf("Could not listen on port 8081: %v\n", err)
        }
    }()

    <-stop

    fmt.Println("Shutting down server...")

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    if err := srv.Shutdown(ctx); err != nil {
        fmt.Printf("Server shutdown failed: %v\n", err)
    }
}

Here is the full code:

package main

import (
    "context"
    "fmt"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"

    "github.com/common-nighthawk/go-figure"
    "github.com/go-chi/chi/v5"
)

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    asciiArt := figure.NewFigure("Go API - Caddy", "", true).String()
    fmt.Fprintln(w, asciiArt)
}

func apiHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    fmt.Fprintf(w, `{"message":"Hello, World!"}`)
}

func main() {

    r := chi.NewRouter()

    // API Route
    r.Get("/", handler)
    r.Get("/api/hello", apiHandler)

    srv := &http.Server{
        Addr:    ":8081",
        Handler: r,
    }

    stop := make(chan os.Signal, 1)
    signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)

    go func() {
        fmt.Println("Server started at :8081")
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            fmt.Printf("Could not listen on port 8081: %v\n", err)
        }
    }()

    <-stop

    fmt.Println("Shutting down server...")

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    if err := srv.Shutdown(ctx); err != nil {
        fmt.Printf("Server shutdown failed: %v\n", err)
    }
}

Then, try run the main.go using go run:

$ go run main.go

After that, you should see this message in the terminal:

Server started at :8081

Finally, you can test the API using curl or access from the browser on http://127.0.0.1:8081:

$ curl 127.0.0.1:8081

   ____                _      ____    ___                ____               _       _
  / ___|   ___        / \    |  _ \  |_ _|              / ___|   __ _    __| |   __| |  _   _
 | |  _   / _ \      / _ \   | |_) |  | |     _____    | |      / _` |  / _` |  / _` | | | | |
 | |_| | | (_) |    / ___ \  |  __/   | |    |_____|   | |___  | (_| | | (_| | | (_| | | |_| |
  \____|  \___/    /_/   \_\ |_|     |___|              \____|  \__,_|  \__,_|  \__,_|  \__, |
                                                                                        |___/

$ curl 127.0.0.1:8081/api/hello

{"message":"Hello, World!"}

Step 2: The Dockerfile

We'll use a multi-stage build to create a minimal and secure Docker image. This process compiles our Go application in one stage and then copies only the final binary to a much smaller final image. This keeps our final image size low.

Create a Dockerfile in your project directory and add the following code:

# First stage: builder
FROM golang:1.24 AS builder

WORKDIR /go/src/app

COPY . .

RUN go mod download

RUN CGO_ENABLED=0 go build -o /go/bin/app

In the builder stage, we use the official Go image to compile our code.
We copy the entire project into the container and run go mod download to fetch dependencies.
Then we build the binary with CGO_ENABLED=0 to ensure it’s statically compiled and portable. The binary is placed in /go/bin/app.

# Second stage: final image
FROM golang:1.24-alpine

# Copy only the compiled binary from builder stage
COPY --from=builder /go/bin/app /

EXPOSE 8081

ENV PORT 8081

CMD ["/app"]

In the final stage, only the compiled binary is copied over from the builder stage. This keeps the image small because source code, dependencies, and build tools are excluded.
We expose port 8081 so Docker knows which port the app listens on.
CMD ["/app"] runs the binary as the container’s main process.

Here is the full code:

FROM golang:1.24 AS builder

WORKDIR /go/src/app

COPY . .

RUN go mod download

RUN CGO_ENABLED=0 go build -o /go/bin/app

FROM golang:1.24-alpine

COPY --from=builder /go/bin/app /

EXPOSE 8081

ENV PORT 8081

CMD ["/app"]

Step 3: Configure Caddy

Caddy will act as a reverse proxy that forwards incoming requests to the Go API container. This allows us to:

Tells Caddy to listen on port 80 (HTTP).
Forwards requests to the Go API container, using the Docker service name go-api and port 8081.

Create a file named Caddyfile in your project directory:

:80 {
    reverse_proxy go-api:8081
}

💡 If you later have a domain (e.g., api.example.com), you can replace :80 with your domain

api.example.com {
    reverse_proxy go-api:8081
}

Step 4: Configure Docker Compose

Create a file named docker-compose.yml in your project directory:

version: "3.8"

services:
  go-api:
    build: .
    container_name: go-api
    expose:
      - "8081"                 # Expose port internally (only visible to other services in this network)
    restart: unless-stopped

  caddy:
    image: caddy:2.10-alpine
    container_name: caddy
    ports:
      - "8082:80"              # Map host port 8082 -> container port 80
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    restart: unless-stopped
    depends_on: 
      - go-api

Explanation

go-api service

Built from your local Dockerfile.
Uses expose instead of ports → this means the Go API is reachable inside the Docker network but not directly exposed to the host machine.
The Go API will listen on :8081, but only Caddy can access it.

caddy service

Uses the official lightweight caddy:2.10-alpine image.
ports: "8082:80" -> exposes port 80 from the container to port 8082 on your host machine. So when you open http://127.0.0.1:8082, requests are routed through Caddy.
The Caddyfile is mounted so you can configure reverse proxy behavior.
depends_on ensures Caddy waits for the Go API container to start.

Step 5: Test the Setup

Once all files are ready (main.go, Dockerfile, Caddyfile, docker-compose.yml), run the stack using the docker compose up command:

.
├── Caddyfile
├── docker-compose.yml
├── Dockerfile
├── go.mod
├── go.sum
└── main.go

$ docker compose up -d --build

Make sure the containers are running using docker ps command:

$ docker ps

CONTAINER ID   IMAGE                          COMMAND                  CREATED         STATUS         PORTS
                                                      NAMES
6b6b35487d77   caddy:2.10-alpine              "caddy run --config …"   9 minutes ago   Up 9 minutes   443/tcp, 2019/tcp, 443/udp, 0.0.0.0:8082->80/tcp, [::]:8082->80/tcp   caddy
20cbb2209fe7   docker-go-api-caddy_go-api     "/app"                   9 minutes ago   Up 9 minutes   0.0.0.0:32770->8081/tcp, [::]:32770->8081/tcp

Now, test the endpoints through Caddy (reverse proxy):

$ curl http://127.0.0.1:8082

Expected output: the ASCII art rendered by go-figure.

$ curl http://127.0.0.1:8082/api/hello

Expected output:

{"message":"Hello, World!"}

Conclusion

In this guide, we successfully deployed a simple Go API containerized approach. By leveraging Docker, we created an isolated and reproducible environment for our application. We used a multi-stage build in our Dockerfile to keep the final image lightweight and secure, and Docker Compose to easily manage both our Go API and Caddy services with a single command.

Feel free to explore further by adding more features to your API or by setting up a domain with Caddy’s automatic HTTPS. Happy deployment!🚀

References:

Deploying a Simple Flask API Using Gunicorn, Supervisor & Nginx

Daniel Pepuho — Wed, 30 Apr 2025 15:21:10 +0000

Intro

Hi there! Flask is great for building APIs quickly. But turning your local project into a publicly accessible web service involves a few extra steps that aren’t always obvious.

In this guide, I'll show you how to deploy a Flask API using Gunicorn as the WSGI server, Supervisor to manage the process, and Nginx as a reverse proxy.

Overview

Flask: The Python microframework we’ll use to build the API.
Gunicorn: A Python WSGI HTTP server for running Flask in production.
Supervisor: A process control system to ensure the Gunicorn server stays alive.
Nginx: A reverse proxy to handle client requests and route them to Gunicorn.

Flask API Deployment Flow

The diagram below illustrates the flow of a request and response when using Flask, Gunicorn, Supervisor, and Nginx.

When a user sends an HTTP request, it first reaches the Nginx reverse proxy. Nginx forwards the request to Gunicorn, which serves the Flask application via the WSGI protocol. Supervisor ensures that Gunicorn keeps running and automatically restarts it if needed. The response follows the same path back to the user.

Requirements

Before starting, make sure you have the following installed on your system:

Python 3 and Virtualenv

Check if Python is installed:

$ python3 --version

Python 3.10.14

If not installed, install it:

Ubuntu/Debian:

$ sudo apt update
$ sudo apt install python3 python3-venv -y

CentOS/RHEL:

$ sudo yum install python3 python3-venv -y

Homebrew (macOS):

$ brew install python

Nginx

Ubuntu/Debian:

$ sudo apt install nginx -y

CentOS/RHEL:

$ sudo yum install nginx -y

Homebrew (macOS):

$ brew install nginx

After installation, check if Nginx is running:

$ sudo systemctl status nginx

If it’s not running, start and enable it:

$ sudo systemctl start nginx
$ sudo systemctl enable nginx

Supervisor

Ubuntu/Debian:

$ sudo apt update
$ sudo apt install supervisor -y

CentOS/RHEL:

$ sudo yum install supervisor -y

Homebrew (macOS):

$ brew install supervisor

After installation, check if Supervisor is running:

$ sudo systemctl status supervisor

If it’s not running, start and enable it:

$ sudo systemctl start supervisor
$ sudo systemctl enable supervisor

Setting Up the Flask Project

First, create a project directory and set up a virtual environment:

$ mkdir flask-api && cd flask-api

$ python3 -m venv venv
$ source venv/bin/activate

With the virtual environment activated, install Flask and Gunicorn:

$ pip install flask gunicorn

You can verify the installation:

$ flask --version
$ gunicorn --version

Next, you need to create a file called app.py inside your project directory. You can use any text editor you prefer, such as nano, vim, or others:

$ vim app.py

from flask import Flask

app = Flask(__name__)

@app.route("/api/hello")
def hello():
    return {"message": "Hello from Flask API!"}

Then, try to run your Flask app using Gunicorn command:

$ gunicorn app:app

[2025-04-30 20:37:49 +0700] [1085004] [INFO] Starting gunicorn 23.0.0
[2025-04-30 20:37:49 +0700] [1085004] [INFO] Listening at: http://127.0.0.1:8000 (1085004)
[2025-04-30 20:37:49 +0700] [1085004] [INFO] Using worker: sync
[2025-04-30 20:37:49 +0700] [1085005] [INFO] Booting worker with pid: 1085005
[2025-04-30 20:38:58 +0700] [1085004] [INFO] Handling signal: winch

To try your app, just open another terminal session or window. You can use a tool like curl:

$ curl http://127.0.0.1:8000/api/hello

{"message":"Hello from Flask API!"}

Running with Multiple Workers

You can run Gunicorn with multiple worker processes using the -w option. For example, to run your app with 3 workers:

$ gunicorn -w 3 app:app

[2025-04-30 20:49:13 +0700] [1085759] [INFO] Starting gunicorn 23.0.0
[2025-04-30 20:49:13 +0700] [1085759] [INFO] Listening at: http://127.0.0.1:8000 (1085759)
[2025-04-30 20:49:13 +0700] [1085759] [INFO] Using worker: sync
[2025-04-30 20:49:13 +0700] [1085760] [INFO] Booting worker with pid: 1085759
[2025-04-30 20:49:13 +0700] [1085761] [INFO] Booting worker with pid: 1085760
[2025-04-30 20:49:13 +0700] [1085762] [INFO] Booting worker with pid: 1085761

To confirm that Gunicorn is running with multiple workers, you can use tools like top or htop.

Install htop (optional but nicer to read):

$ sudo apt install htop -y

Then run:

$ htop

To bind it to a different port (e.g., 8081) and listen on all interfaces:

$ gunicorn -b 0.0.0.0:8081 app:app

[2025-04-30 21:14:29 +0700] [1085847] [INFO] Starting gunicorn 23.0.0
[2025-04-30 21:14:29 +0700] [1085847] [INFO] Listening at: http://0.0.0.0:8081 (1085847)
[2025-04-30 21:14:29 +0700] [1085847] [INFO] Using worker: sync
[2025-04-30 21:14:29 +0700] [1085848] [INFO] Booting worker with pid: 1085848

Adding Supervisor and Nginx Configuration

Supervisor Setup

To make sure Gunicorn runs in the background and restarts automatically if it crashes, you'll want to use Supervisor. Here's how to set it up:

Create a configuration file for your app:

$ sudo vim /etc/supervisor/conf.d/flask-api.conf

Insert this configuration (adjust paths as needed):

[program:flask-api]
directory=/home/youruser/flask-api
command=/home/youruser/flask-api/venv/bin/gunicorn -w 3 -b 127.0.0.1:8000 app:app
autostart=true
autorestart=true
user=www-data
stdout_logfile=/var/log/flask-api.out.log
stderr_logfile=/var/log/flask-api.err.log
environment=PATH="/home/youruser/flask-api/venv/bin"

directory=/home/youruser/flask-api → The working directory where your Flask project is located.

command=/home/youruser/flask-api/venv/bin/gunicorn -w 3 -b 127.0.0.1:8000 app:app → Runs the Gunicorn server with 3 workers, binding to localhost on port 8000.

autostart=true → Automatically starts the app when Supervisor starts (e.g., on boot).

autorestart=true → Restarts the app automatically if it crashes.

user=www-data → Runs the process as the www-data user (you can change this to your own user if needed).

stdout_logfile=/var/log/api/flask-api.out.log → File where standard output (including errors) is logged.

stderr_logfile=/var/log/api/flask-api.err.log → (Optional if using redirect_stderr) File for capturing standard error output.

environment=PATH="..." → Ensures Supervisor uses the correct Python virtual environment for Gunicorn.

Then reload Supervisor to pick up the new config:

$ sudo supervisorctl reread
$ sudo supervisorctl update
$ sudo supervisorctl status

If the API is not running, check the logs:

$ cat /var/log/flask-api.out.log
$ cat /var/log/flask-api.err.log

Or use Supervisor’s built-in log viewer:

$ tail -f flask-api

==> Press Ctrl-C to exit <==

Nginx Configuration

Now that Gunicorn is running your Flask app on port 8000, you’ll want Nginx to act as a reverse proxy.

Create a new Nginx config file:

$ sudo vim /etc/nginx/sites-available/flask-api

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable the site and test:

$ sudo ln -s /etc/nginx/sites-available/flask-api /etc/nginx/sites-enabled
$ sudo nginx -t
$ sudo systemctl restart nginx

Finally, ff everything is set up correctly, you should now be able to access your Flask API at http://YOUR_SERVER_IP/api/hello if you're using a public server or VPS.

Optional: Project Structure & Requirements

To easily reinstall dependencies later:

$ pip freeze > requirements.txt

However, it’s better to specify only the packages you need manually:

$ sudo vim requirements.txt

flask
gunicorn

To install all requirements, just run pip install:

$ pip install -r requirements.txt

Your project structure should look like this:

flask-api/
├── app.py
├── venv/
└── requirements.txt

Common Issues

Here are a few quick troubleshooting tips:

502 Bad Gateway: Usually means Gunicorn isn't running or the Nginx config has the wrong port.

Supervisor status shows STOPPED: Check your config file paths and the logs:
sudo tail -f /var/log/flask-api.err.log

Permission errors: Ensure all paths used by Supervisor and Gunicorn are accessible by the appropriate user.

Conclusion

In this guide, we deployed a Flask API using Gunicorn as the WSGI server, Supervisor to keep the app running reliably, and Nginx as a reverse proxy to handle incoming requests. With this setup, your Flask app is ready to serve real traffic efficiently and automatically recover from crashes. Thanks for reading — and good luck with your deployment! 🚀

Project Reference:

Rahul Nayak: Deploy flask app with nginx using gunicorn and supervisor

Deploying a Simple Go API with Supervisor and Nginx

Daniel Pepuho — Thu, 20 Mar 2025 06:02:30 +0000

Intro

Hi! In this post, I'll show you how to deploy a simple Go API using Supervisor to manage the process and Nginx as a web server to serve it.

Before we dive into the deployment steps, let's briefly discuss why we're using Supervisor and Nginx.

Supervisor is a process control system that helps manage and monitor applications running in the background. It ensures that your Go API stays up and automatically restarts it if it crashes. See the full documentation
Nginx is a high-performance web server that can also function as a reverse proxy, making it ideal for serving our Go API to the internet. See the full documentation

🤔 Why Choose Supervisor Over Other Options?

You might wonder why we use Supervisor instead of alternatives like Systemd, PM2, or containerized solutions like Docker. Here’s a quick comparison:

Tools	Pros	Cons
Supervisor	Simple setup, great for managing multiple processes, easy log management	Requires manual config
Systemd	Native to Linux, faster startup	More complex setup, harder to debug
PM2	Built for Node.js, supports process monitoring	Not ideal for Go applications
Docker	Isolated environment, easy deployment, scalable	More setup overhead, requires container knowledge

When Should You Use Supervisor?

Use Supervisor when you want a simple, non-containerized way to manage a Go service, with features like auto-restart and log management, without dealing with systemd’s complexity or Docker’s extra overhead.

Setup and Run a Simple Go API

Requirements

Before starting, make sure you have the following installed on your system:

Go
```
$ go version

go version go1.24.0 linux/amd64
```
If not installed, download it from the official site.
Supervisor

Ubuntu/Debian

$ sudo apt update
$ sudo apt install supervisor -y

CentOS/RHEL
```
$ sudo yum install supervisor -y
```

Homebrew (macOS)

$ brew install supervisor

After installation, check if Supervisor is running:

$ sudo systemctl status supervisor

If it’s not running, start and enable it:

$ sudo systemctl start supervisor
$ sudo systemctl enable supervisor

Nginx
Ubuntu/Debian
```
$ sudo apt install nginx -y
```
CentOS/RHEL
```
$ sudo yum install nginx -y
```

Homebrew (macOS)

$ brew install nginx

After installation, check if Nginx is running:

$ sudo systemctl status nginx

If it’s not running, start and enable it:

$ sudo systemctl start nginx
$ sudo systemctl enable nginx

Initialize a New Go Project

First, create a new directory for the project and initialize a Go module:

$ cd /var/www/
$ mkdir go-api && cd go-api

$ go mod init example.com/go-api

This command creates a Go module named example.com/go-api, which helps manage dependencies.

Create a Simple API

Now, create a new file main.go and add the following code:

$ vim main.go

package main

import (
        "fmt"
        "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/plain")
        fmt.Fprintln(w, "Simple Go API")
}

func main() {
        http.HandleFunc("/", handler)
        fmt.Println("Server started at :8080")
        http.ListenAndServe(":8080", nil)
}

Compile and run the Go server:

$ go run main.go

If successful, you should see this message in the terminal:

Server started at :8080

Now test the API using curl:

$ curl localhost:8080


Simple Go API

Create a Simple API with ASCII Text Response (Optional)

First, install the go-figure package:

$ go get github.com/common-nighthawk/go-figure

Now, modify main.go to generate an ASCII text response dynamically:

package main

import (
    "fmt"
    "net/http"

    "github.com/common-nighthawk/go-figure"
)

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    asciiArt := figure.NewFigure("Simple Go API", "", true).String()
    fmt.Fprintln(w, asciiArt)
}

func main() {
    http.HandleFunc("/", handler)
    fmt.Println("Server started at :8080")
    http.ListenAndServe(":8080", nil)
}

$ curl localhost:8080

  ____    _                       _             ____                _      ____    ___
 / ___|  (_)  _ __ ___    _ __   | |   ___     / ___|   ___        / \    |  _ \  |_ _|
 \___ \  | | | '_ ` _ \  | '_ \  | |  / _ \   | |  _   / _ \      / _ \   | |_) |  | |
  ___) | | | | | | | | | | |_) | | | |  __/   | |_| | | (_) |    / ___ \  |  __/   | |
 |____/  |_| |_| |_| |_| | .__/  |_|  \___|    \____|  \___/    /_/   \_\ |_|     |___|
                         |_|

Running the API as a Background Service with Supervisor

Create a Supervisor Configuration for the Go API

Create a new Supervisor config file:

$ sudo vim /etc/supervisor/conf.d/go-api.conf

Add the following configuration:

[program:go-api]
process_name=%(program_name)s_%(process_num)02d
directory=/var/www/go-api
command=bash -c 'cd /var/www/go-api && ./main'
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stderr_logfile=/var/log/go-api.err.log
stdout_logfile=/var/log/go-api.out.log

Explanation:

directory=/var/www/go-api → The working directory of the Go API.
command=bash -c 'cd /var/www/go-api && ./main' → Runs the API.
autostart=true → Starts automatically on system boot.
autorestart=true → Restarts if the process crashes.
user=www-data → Runs as the www-data user (adjust as needed).
redirect_stderr=true → Redirects error logs to stdout.
stdout_logfile=/var/log/go-api.out.log → Standard output log file.
stderr_logfile=/var/log/go-api.err.log → Error log file.

Now, we need build the Go API:

$ go build -o main .

Ensure the directory and binary have the correct permissions:

$ sudo chown -R www-data:www-data /var/www/go-api
$ sudo chmod 775 /var/www/go-api/main

Apply the Supervisor Configuration

Reload Supervisor and start the service:

$ sudo supervisorctl reread
$ sudo supervisorctl update
$ sudo supervisorctl start go-api:*

Check the service status:

$ sudo supervisorctl avail

go-api:go-api_00                 in use    auto      999:999

$ sudo supervisorctl status go-api:*

go-api:go-api_00                 RUNNING   pid 198867, uptime 0:01:52

Check Logs and Debugging

If the API is not running, check the logs:

$ sudo cat /var/log/go-api.out.log
$ sudo cat /var/log/go-api.err.log

Or use Supervisor’s built-in log viewer:

$ sudo supervisorctl tail -f go-api:go-api_00

==> Press Ctrl-C to exit <==
Server started at :8080

Setting Up Nginx as a Reverse Proxy for the API

Create a new configuration file:

$ sudo vim /etc/nginx/sites-available/go-api

server {
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
    }

    error_log /var/log/nginx/go-api_error.log;
    access_log /var/log/nginx/go-api_access.log;
}

Create a symbolic link to enable the site:

$ sudo ln -s /etc/nginx/sites-available/go-api /etc/nginx/sites-enabled/

Test the configuration:

$ sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If the test is successful, restart Nginx:

$ sudo systemctl restart nginx

Now, you can access your Go API using:

Localhost (if running locally)

$ curl http://localhost

  ____    _                       _             ____                _      ____    ___
 / ___|  (_)  _ __ ___    _ __   | |   ___     / ___|   ___        / \    |  _ \  |_ _|
 \___ \  | | | '_ ` _ \  | '_ \  | |  / _ \   | |  _   / _ \      / _ \   | |_) |  | |
  ___) | | | | | | | | | | |_) | | | |  __/   | |_| | | (_) |    / ___ \  |  __/   | |
 |____/  |_| |_| |_| |_| | .__/  |_|  \___|    \____|  \___/    /_/   \_\ |_|     |___|
                         |_|

Server’s Public IP (if running on a VPS or remote server)

$ curl http://YOUR_SERVER_IP

Note: If you want to access your Go API using a custom domain instead of an IP address, you need to purchase a domain, configure its DNS to point to your server’s IP, and update your Nginx configuration accordingly. For better security, it's recommended to set up HTTPS using Let's Encrypt.

Conclusion

In this guide, we deployed a simple Go API using Supervisor to manage the process ensuring automatic restarts and efficient request handling also Nginx as a reverse proxy. Thank you for reading, and good luck with your deployment! 🚀

Kubernetes 105: Create Kubernetes Cluster

Daniel Pepuho — Sat, 01 Feb 2025 14:21:01 +0000

Let's start again. Now we will do some practices.

In this part of the Kubernetes series, we will explore how to create a Kubernetes cluster in different environments. Whether you're running Kubernetes locally or in the cloud, understanding how to set up a cluster is fundamental to deploying and managing containerized applications efficiently.

We will cover three different ways to create a Kubernetes cluster:

Kind (Kubernetes in Docker) - A lightweight way to run Kubernetes clusters locally for testing and development.
K3D (K3S in Docker) - A more lightweight Kubernetes distribution, optimized for local development and CI/CD workflows.
EKS (Amazon Elastic Kubernetes Service) - A managed Kubernetes service provided by AWS for running Kubernetes workloads in the cloud.

Each approach has its own use cases, advantages, and trade-offs. Let's dive into each one and see how to set up a cluster.

Setting Up a Kubernetes Cluster with Kind

Kind (Kubernetes in Docker) is one of the simplest ways to spin up a Kubernetes cluster for local development and testing. It runs Kubernetes clusters inside Docker containers and is widely used for CI/CD and development workflows.

Prerequisites

Docker installed on your machine. (installation guide)
KIND CLI installed. (installation guide)
Kubectl CLI installed. (installation guide)

Create a Cluster with Kind

Create a new Kind cluster:

$  kind create cluster --name kind-cluster

Creating cluster "kind-cluster" ...
 ✓ Ensuring node image (kindest/node:v1.31.0) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind-cluster"
You can now use your cluster with:

kubectl cluster-info --context kind-kind-cluster

Thanks for using kind! 😊

Check the cluster:

$   kubectl cluster-info --context kind-kind-cluster

Kubernetes control plane is running at https://127.0.0.1:43417
CoreDNS is running at https://127.0.0.1:43417/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

List available nodes:

$ kubectl get nodes

NAME                         STATUS   ROLES           AGE   VERSION
kind-cluster-control-plane   Ready    control-plane   75s   v1.31.0

Create Simple Deployment

Use the kubectl create deployment command to define and start a deployment:

$  kubectl create deployment nginx --image=nginx

deployment.apps/nginx created

Check deployment status using kubectl get deployment command:

$ kubectl get deployment

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   0/1     1            0           29s

Expose the deployment:

$ kubectl expose deployment nginx --port=80 --type=LoadBalancer

service/nginx exposed

Verify the Pod status and then try to access Nginx using your browser:

$ kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
nginx-676b6c5bbc-wd87x   1/1     Running   0          12m

Delete the cluster when no longer needed

$ kind delete cluster --name kind-cluster

Deleting cluster "kind-cluster" ...
Deleted nodes: ["kind-cluster-control-plane"]

Setting Up a Kubernetes Cluster with K3D

K3D is a tool that allows you to run lightweight Kubernetes clusters using K3S inside Docker. It is a great choice for fast, local Kubernetes development.

Prerequisites

Docker installed on your machine. (installation guide)
K3D CLI installed. (installation guide)
Kubectl CLI installed. (installation guide)

Create a Cluster with K3D

Create a new K3D cluster:

$ k3d cluster create my-k3d-cluster

INFO[0000] Prep: Network
INFO[0000] Created network 'k3d-my-k3d-cluster'
INFO[0000] Created image volume k3d-my-k3d-cluster-images
INFO[0000] Starting new tools node...
INFO[0000] Starting node 'k3d-my-k3d-cluster-tools'
INFO[0001] Creating node 'k3d-my-k3d-cluster-server-0'
INFO[0001] Creating LoadBalancer 'k3d-my-k3d-cluster-serverlb'
INFO[0001] Using the k3d-tools node to gather environment information
INFO[0001] HostIP: using network gateway 172.20.0.1 address
INFO[0001] Starting cluster 'my-k3d-cluster'
INFO[0001] Starting servers...
INFO[0001] Starting node 'k3d-my-k3d-cluster-server-0'
INFO[0008] All agents already running.
INFO[0008] Starting helpers...
INFO[0008] Starting node 'k3d-my-k3d-cluster-serverlb'
INFO[0016] Injecting records for hostAliases (incl. host.k3d.internal) and for 2 network members into CoreDNS configma
p...
INFO[0018] Cluster 'my-k3d-cluster' created successfully!
INFO[0018] You can now use it like this:
kubectl cluster-info

Check the cluster status:

$ kubectl cluster-info

Kubernetes control plane is running at https://0.0.0.0:46503
CoreDNS is running at https://0.0.0.0:46503/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://0.0.0.0:46503/api/v1/namespaces/kube-system/services/https:metrics-server:https/p
roxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

List available nodes:

$ kubectl get nodes

NAME                          STATUS   ROLES                  AGE     VERSION
k3d-my-k3d-cluster-server-0   Ready    control-plane,master   2m33s   v1.30.4+k3s1

Create Simple Deployment

Use the kubectl create deployment command to define and start a deployment:

$ kubectl create deployment httpd --image=httpd

Check deployment status using kubectl get deployment command:

$ kubectl get deployment

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
httpd   0/1     1            0           45s

Verify the Pod status:

$  kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
httpd-56f946b8c8-84ww8   1/1     Running   0          9m11s

Expose the deployment:

$ kubectl expose deployment httpd --port=80 --type=LoadBalancer

Try to access using browser:

Delete the cluster when no longer needed:

$ k3d cluster delete my-k3d-cluster

INFO[0000] Deleting cluster 'my-k3d-cluster'
INFO[0001] Deleting cluster network 'k3d-my-k3d-cluster'
INFO[0001] Deleting 1 attached volumes...
INFO[0001] Removing cluster details from default kubeconfig...
INFO[0001] Removing standalone kubeconfig file (if there is one)...
INFO[0001] Successfully deleted cluster my-k3d-cluster!

Setting Up a Kubernetes Cluster on AWS EKS

Amazon Elastic Kubernetes Service (EKS) is a fully managed Kubernetes service on AWS, designed for running production workloads.

Prerequisites

AWS CLI installed and configured. (installation guide)
EKSCTL CLI installed. (installation guide)
Kubectl CLI installed. (installation guide)

Create a cluster on EKS

To create a Kubernetes cluster in AWS, you can use the AWS Console (dashboard) or the eksctl CLI. For this guide, we will use eksctl.

We will provisions an EKS cluster with two t4g.small nodes in the us-east-1 region, making it ready for running Kubernetes workloads.

$ eksctl create cluster  \
--name cluster-1  \
--region us-east-1 \
--node-type t4g.small \
--nodes 2 \
--nodegroup-name node-group-1

2025-02-01 19:52:35 [ℹ]  eksctl version 0.202.0
2025-02-01 19:52:35 [ℹ]  using region us-east-1
2025-02-01 19:52:37 [ℹ]  setting availability zones to [us-east-1c us-east-1f]

...

2025-02-01 20:02:04 [ℹ]  creating addon
2025-02-01 20:02:04 [ℹ]  successfully created addon
2025-02-01 20:02:05 [ℹ]  creating addon
2025-02-01 20:02:06 [ℹ]  successfully created addon
2025-02-01 20:02:07 [ℹ]  creating addon
2025-02-01 20:02:07 [ℹ]  successfully created addon
"us-east-1" region is ready

Access AWS console, navigate to the EKS service and you can see the cluster is successfully created.

List available nodes:

kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
ip-192-168-xx-yy.ec2.internal   Ready    <none>   17m   v1.30.8-eks-aeac579
ip-192-168-xx-yy.ec2.internal   Ready    <none>   17m   v1.30.8-eks-aeac57

Create Simple Deployment

Use the kubectl create deployment command to define and start a deployment:

$ kubectl create deployment nginx --image=nginx

deployment.apps/nginx create

Check deployment status using kubectl get deployment command:

$  kubectl get deployment

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
nginx    1/1     1            1           23s

Verify the Pod status:

$ kubectl get pods

NAME                     READY   STATUS         RESTARTS   AGE
nginx-bf5d5cf98-9dld5    1/1     Running        0          43s

Expose the service:

$ kubectl expose deployment nginx --type=LoadBalancer --port=80 --name=nginx-service

Try to access using the browser:

Delete the cluster when no longer needed:

$  eksctl delete cluster --name cluster-1 --region us-east-1

2025-02-01 20:51:59 [ℹ]  deleting EKS cluster "cluster-1"
2025-02-01 20:52:02 [ℹ]  will drain 0 unmanaged nodegroup(s) in cluster "cluster-1"
2025-02-01 20:52:02 [ℹ]  starting parallel draining, max in-flight of 1
2025-02-01 20:52:04 [ℹ]  deleted 0 Fargate profile(s)
2025-02-01 20:52:13 [✔]  kubeconfig has been updated
2025-02-01 20:52:13 [ℹ]  cleaning up AWS load balancers created by Kubernetes objects of Kind Service or Ingress
2025-02-01 20:52:56 [ℹ]
...

2025-02-01 21:02:00 [ℹ]  waiting for CloudFormation stack "eksctl-cluster-1-nodegroup-node-group-1"
2025-02-01 21:02:01 [ℹ]  will delete stack "eksctl-cluster-1-cluster"
2025-02-01 21:02:04 [✔]  all cluster resources were deleted

Conclusion

Setting up a Kubernetes cluster is the first step in running containerized applications at scale. In this guide, we've explored three different ways to create a Kubernetes cluster and do a simple deployment: using Kind and K3D for local development and using EKS for cloud-based deployments. Each method has its own advantages depending on your use case.

Thanks for reading this post. Stay tuned!

References:

KUBERNETES UNTUK PEMULA. https://github.com/ngoprek-kubernetes/buku-kubernetes-pemula.
How do I install AWS EKS CLI (eksctl)?. https://learn.arm.com/install-guides/eksctl

Kubernetes 104: Controllers

Daniel Pepuho — Wed, 22 Jan 2025 09:13:36 +0000

Let's start again. Now I'm going to talk about Controllers in Kubernetes. In Kubernetes, a Controller is like a cluster's brain, constantly working to ensure the system maintains its desired state. By monitoring objects such as Pods, Deployments, or DaemonSets, Controllers automate tasks and handle changes dynamically. Understanding Controllers is key to grasping how Kubernetes orchestrates and manages workloads seamlessly.

Common Kubernetes Controllers

Here are some of the most commonly used Controllers in Kubernetes:

1. Deployment

Deployments manage updates to Pods and ReplicaSets declaratively by transitioning the current state to the desired state step-by-step. They can create new ReplicaSets, adopt existing resources, or remove old Deployments.

Common uses for Deployments include:

a. Releasing a ReplicaSet and monitoring its status.
b. Updating Pod specifications to declare a new desired state.
c. Scaling up to handle increased load.
d. Rolling back to a previous version if the current state is unstable.
e. Cleaning up unused ReplicaSets.

2. ReplicaSet

ReplicaSets (RS) function as controllers in Kubernetes, responsible for maintaining a consistent number of running Pods for a specific workload. Acting as the mechanism behind the scenes, the ReplicaSet controller continuously monitors the state of the Pods and ensures the desired replica count is maintained. If a Pod crashes, is evicted, or fails for any reason, the ReplicaSet controller swiftly creates new Pods to restore the desired state, ensuring resilience and uninterrupted service.

In practical use, ReplicaSets are not typically managed directly by users. Instead, they are controlled through Deployments, which leverage the ReplicaSet controller while providing additional features such as rolling updates, rollbacks, and declarative workload management. This abstraction allows users to benefit from the reliability and scalability of ReplicaSet controllers without dealing with their complexities directly.

3. DaemonSet

DaemonSet (DS) ensures that every or specific nodes in a cluster run a copy of a particular Pod. When a new node is added, DaemonSet automatically creates a Pod on that node. Conversely, when a node is removed, the associated Pod is deleted by the garbage collector. Deleting the DaemonSet removes all Pods it created.

Common uses of DaemonSet:

Running storage daemons across nodes, such as Glusterd or Ceph.
Running log collection daemons across nodes, such as Fluentd or LogStash.
Running node monitoring daemons, such as Prometheus Node Exporter, Flowmill, or New Relic Agent.

DaemonSet is ideal for tasks that require processes to run on every node, such as log collection, monitoring, or providing local volumes.

4. StatefulSet

A StatefulSet is a Kubernetes controller used for managing stateful applications. Unlike Deployments, which focus on stateless workloads, StatefulSet is designed for applications that require persistent identity and stable storage. It ensures that each Pod it manages has a unique, stable network identity and maintains a strict order during creation, scaling, or deletion.

Key Features of StatefulSet:

Stable Network Identity: Each Pod gets a unique and persistent DNS name (e.g., pod-0, pod-1), which remains consistent even after rescheduling.
Ordered Pod Deployment and Scaling: Pods are created and scaled in a sequential order. For example, pod-0 must be created before pod-1, and the same applies during deletion.
Persistent Storage: StatefulSet works closely with PersistentVolumeClaim (PVC). Each Pod gets a dedicated PersistentVolume that remains intact even after the Pod is deleted or rescheduled.

Common Use Cases:

Databases like MySQL, PostgreSQL, and MongoDB, where stable storage and network identity are critical.
Distributed Systems like Cassandra, Kafka, or ZooKeeper, where maintaining order and state is essential.
Caching Systems like Redis, requiring predictable storage and replication across nodes.

5. Job

A Job is a Kubernetes controller designed to manage tasks that run to completion. Unlike Deployments or StatefulSets, which manage long-running or stateful applications, Jobs are used for short-lived workloads that need to be executed only once or a specific number of times.

Key Features of a Job:

Ensures Completion: A Job creates one or more Pods to perform a task and ensures that the task is completed successfully. If a Pod fails, the Job controller automatically creates a replacement until the task succeeds.
Parallelism: Jobs support parallel execution, allowing multiple Pods to run concurrently, controlled by the parallelism and completions parameters.
Retries: Jobs retry failed Pods until the task is successful or a specified backoff limit is reached.

Common Use Cases:

Batch Processing: Data transformation, ETL pipelines, or video encoding.
Database Operations: Running migrations, backups, or clean-up scripts.
One-Time Tasks: Performing diagnostics, generating reports, or initializing configurations.

Thank you for reading this post.😀

References:

KUBERNETES UNTUK PEMULA. https://github.com/ngoprek-kubernetes/buku-kubernetes-pemula.
Kubernetes Documentation: Jobs. https://kubernetes.io/docs/concepts/workloads/controllers/job.
Kubernetes Controllers. https://www.uffizzi.com/kubernetes-multi-tenancy/kubernetes-controllers.
Kubernetes: DaemonSet. https://opstree.com/blog/2021/12/07/kubernetes-daemonset.
Kubernetes StatefulSet vs Kubernetes Deployment. https://devtron.ai/blog/deployment-vs-statefulset.