1. Terraform Core Workflow

Core Commands

terraform init       # Initialize providers & backend
terraform plan       # Preview execution plan
terraform apply      # Apply changes
terraform destroy    # Destroy resources

Typical Workflow

1. Write .tf files

2. terraform init

3. terraform plan

4. terraform apply

2. Terraform Configuration Basics

Blocks

resource "aws_instance" "example" {}

3. Providers

Provider Types

• Official

• Partner

• Community

Provider Configuration

provider "aws" {
  region = "us-east-1"
}

Version Constraints

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Version rules:

• >= 1.2.0

• <= 2.0.0

• ~> 1.2 → >=1.2,<2.0

• != 1.4.0

4. Variables

Declare Variables

variable "filename" {
  type        = string
  description = "File name"
  default     = "/tmp/file.txt"
}

Types

• string

• number

• bool

• list(type)

• map(type)

• object({})

• tuple([])

Variable Precedence (High → Low)

1. CLI var

2. .tfvars or var-file

3. Environment (TF_VAR_name)

4. Default

5. Resource Attributes & References

${resource_type.resource_name.attribute}

Example:

aws_instance.web.public_ip

6. Dependencies

Implicit

instance_id = aws_instance.web.id

Explicit

depends_on = [aws_instance.web]

7. Output Values

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

Commands:

terraform output
terraform output public_ip

8. Terraform State

Purpose

• Maps config → real infrastructure

• Tracks metadata & dependencies

State Storage

• Local (default)

• Remote (recommended):

  • S3

  • Terraform Cloud

  • GCS

  • Consul

Remote state locking is available, depending on whether the backend supports

Remote Backend (S3 Example)

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

9. Terraform State Commands

terraform state list
terraform state show <resource>
terraform state mv
terraform state rm
terraform state pull

10. Lifecycle Rules

lifecycle {
  create_before_destroy = true
  prevent_destroy       = true
  ignore_changes        = [tags]
}

11. Meta-Arguments

https://developer.hashicorp.com/terraform/language/meta-arguments

count vs for_each

• count → indexed list

• for_each → map or set

12. Data Sources

Used to read existing resources:

data "aws_ami" "amazon_linux" {
  most_recent = true
}

13. Provisioners (Use Sparingly)

Local Exec

provisioner "local-exec" {
  command = "echo Hello"
}

Remote Exec

Requires SSH access.

⚠️ Not recommended for production

14. Terraform Import

terraform import aws_instance.web i-123456

⚠️ Does NOT generate .tf code. Only updates the state file.

15. Terraform Workspaces

terraform workspace new dev
terraform workspace list
terraform workspace select dev

Each workspace has separate state.

16. Terraform Functions (Important)

https://developer.hashicorp.com/terraform/language/functions

Numeric

• max()

• min()

• ceil()

• floor()

String

• lower()

• upper()

• split()

• join()

• substr()

Collection

• length()

• contains()

• element()

• lookup()

17. Terraform Console

terraform console

Used for testing expressions.

18. Debugging

export TF_LOG=TRACE
export TF_LOG_PATH=/tmp/terraform.log

Levels:

• TRACE

• DEBUG

• INFO

• WARN

• ERROR

19. Terraform Modules

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
}

Commands:

terraform get

20. Security Best Practices

• Never commit terraform.tfstate

• Use .gitignore

• Encrypt remote state

• Use least privilege

21. Quick Commands Summary

terraform init
terraform plan
terraform apply
terraform destroy
terraform fmt
terraform validate
terraform providers
terraform output
terraform graph
terraform workspace list

22. HCP Terraform

The HashiCorp Cloud Platform — https://developer.hashicorp.com/terraform/cloud-docs

In my experience in this exam, you have to know what they are; there is no need to dig deep, so briefly review these topics, and let me know your experience:

• Users

• Teams

• Organizations

• Permissions

• Stacks & Workspaces

• Integration with VCS (Version Control Systems)

• Private registry

• Automatic health checks

• Run triggers

Why Host Your Own DNS?

1. Network-Wide Ad Blocking

By running my own DNS server, I can block ads, malicious sites, and unwanted tracking across the entire network—without installing ad blockers on each individual device.

This is especially useful in a household with kids. They tend to download lots of apps, many of which come with annoying ads and sometimes questionable network requests. With DNS-level blocking, all of that can be filtered automatically at the network level.

2. Local DNS Rewriting for Homelab Services

The second major reason was the ability to use local domain names for my homelab services.

For example:

With these rewrites in place, I can expose services using Traefik or NGINX Proxy Manager and access them via friendly URLs.

Instead of visiting something like http://192.168.1.234:9090
I can simply use: http://linkding.homelab.lan
Much cleaner and easier to remember.

Setup

While researching open-source DNS solutions, I came across AdGuard Home and Pi-hole. Both have excellent features, strong communities, and web-based dashboards.

I chose AdGuard Home because of its simplicity and clean, user-friendly dashboard.

Kubernetes Deployment

I created a Kubernetes manifest to deploy AdGuard Home. You can find it here:

👉 Gist: https://gist.github.com/devsteppe9/bf2ec5e81fa2f559c49f94e34b3064e0

⚠️ Tip:
I recommend creating the Kubernetes Service at the very end. When I exposed DNS too early, it changed the local DNS resolver on the node, which caused issues resolving docker.io while pulling images. There are probably cleaner ways to handle this, but I wanted to keep the setup simple.

Initial Configuration

Once installed, AdGuard Home binds to:

• UDP 53 / TCP 53 – DNS

• Port 3000 – Admin dashboard

You can access the web interface at: http://<your-server-ip>:3000

You’ll be prompted to:

• Create an admin user

• Configure upstream DNS servers

Router Configuration

After AdGuard is running, you need to tell your router to use it as the DNS server.

Every router is different. In my case (Starlink), I configured this through the mobile app:

• Enabled Custom DNS

• Set my AdGuard server IP as Primary DNS

• Added Google DNS as a fallback in case my server goes down

Results

With AdGuard in place, I immediately started seeing blocked ads and tracking requests. I was also surprised to discover that some devices—like TVs and even appliances—were constantly sending analytics data to the internet.

AdGuard made it easy to block all of this traffic. You can also customize blocklists further in the settings, but for my use case, the default AdGuard lists were more than sufficient.

Summary

In this post, I shared how I set up my own DNS server using AdGuard Home on a Kubernetes homelab. The benefits have been huge:

• Network-wide ad and tracker blocking

• Improved privacy

• Friendly local domain names for homelab services

• No need to remember IPs or ports

I hope this gives you some inspiration for your own homelab setup. See you in the next one!

Problem

In our household, we have multiple Android and iPhone devices filled with photos and videos. Since we don’t want to pay for cloud services like iCloud or Google Photos, our media library has always been at risk. If a device breaks or gets lost, years of memories disappear with it.

Now that I have a powerful home Kubernetes cluster running, I decided to finally solve this problem.

Solution

Immich for Photo & Video Backup

After researching self-hosting options, I discovered an amazing open-source project called Immich.

I chose Immich because:

• It has official mobile apps and a web interface

• Supports facial recognition, OCR, and multi-user features

• Has a strong community (over 86k GitHub stars)

• Easy enough that non-technical family members can use it

We installed the Immich app on our phones and connected it to the Immich server running inside our private network.

(Optional) External Backup to AWS S3 Using Restic

There was still one more risk:
If our home server or NAS disk failed, all our backups would be gone.

To protect against that, I set up an additional off-site backup to AWS S3 using an open-source tool called Restic.

Restic tracks backup folders and database dumps, then incrementally uploads them to S3. Since I store everything in S3 Glacier Flexible Retrieval, the cost is extremely low.

• S3 Glacier (us-east-1): $0.0036 per GB

• That’s $3.60/month for 1 TB of data — super affordable.

Deployment

Immich requires PostgreSQL, Redis, and its machine-learning services. I also added Restic backup Jobs/CronJobs.

I prepared a full Kubernetes manifest for this setup:

👉 YAML file:
https://gist.github.com/devsteppe9/17b83f51ca05c5012632d32c5e42cea5

Before applying it, update the following depending on your environment:

• PersistentVolume paths (if using local storage or NAS)

• External Postgres/Redis URLs (if you already run those separately)

Then simply apply:

kubectl apply -f FILENAME.yaml

Once deployed, Immich is ready to use. The first user to register will be the admin user. The admin user will be able to add other users to the application.

To register for the admin user, access the web application at http://< ip-address>:2283 and click on the Getting Started button.

The mobile app can be downloaded from the following places:

• Obtainium: You can get your Obtainium config link from the Utilities page of your Immich server.

• Google Play Store

• Apple App Store

• F-Droid

• GitHub Releases (apk)On the mobile app, just enter your Immich URL, username, and password — and start backing up!

After uploading our media to Immich, we ended up with approximately 160GB of data. With the Kubernetes configuration mentioned above, Restic initializes and uploads the data to AWS S3, and I can confirm that it has been successfully transferred

➜  ~ kubectl logs restic-init-4trwh
Initializing restic repository...
open repository
no parent snapshot found, will read all files
load index files
start scan on [/data]
start backup on [/data]
scan finished in 2.639s: 17108 files, 157.909 GiB

Files:       17108 new,     0 changed,     0 unmodified
Dirs:        16615 new,     0 changed,     0 unmodified
Data Blobs:      0 new
Tree Blobs:      0 new
Added to the repository: 0 B   (0 B   stored)

processed 17108 files, 157.909 GiB in 21:04
snapshot 560b0e01 saved

And let’s confirm from AWS S3:

Like this, relic tracks my filesystem and uploads any new or changed files to S3 every day

Summary

By self-hosting Immich on my home Kubernetes cluster and optionally backing up everything to AWS S3, we now have:

• A safe private photo/video library

• Control of our own data

• Off-site backups in case the home server dies

I hope this setup inspires you! If you have your own self-hosting solution or ideas, feel free to share them

Outline

1. Prerequisites

2. Why Monitor Spring Boot with Prometheus

3. How It Works

4. Configure Spring Boot App

5. Configure Prometheus

6. Configure the Grafana Dashboard

7. Summary & Resources

Prerequisites

Before you start, make sure you have the following:

• A running Kubernetes cluster

• Prometheus installed

• Grafana installed

• ArgoCD (optional) — I used ArgoCD to update Prometheus config, but you can also configure it manually

Why Monitor Spring Boot with Prometheus?

You might wonder: If Prometheus is already monitoring my Kubernetes cluster, why do I need to monitor the Spring Boot app?

Cluster-level metrics only show infrastructure health. App-level metrics give you insights into how your application is behaving internally.

For example:

• Request count and latency (http_server_requests_seconds_count)

• Active threads and thread pool usage

• JVM memory and GC pauses

• HikariCP connection pool metrics

• Custom business metrics (e.g., number of logins, votes, etc.)

How It Works

1. Spring Boot exposes an endpoint /actuator/prometheus that provides metrics.

2. Prometheus scrapes this endpoint at regular intervals.

3. Grafana visualizes these metrics using dashboards.

Configure Spring Boot App

1. Add Dependencies

Update your pom.xml with the following:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

• Actuator provides built-in endpoints to display performance information of your application, such as health, metrics, and more.

• Micrometer then makes these built-in metrics in a Prometheus understandable format

2. Configure application.properties

This ensures our application is an exposed /actuator/prometheus endpoint, so that later steps, Prometheus can scrape it.

management.endpoints.web.exposure.include=*
management.endpoint.health.show-details=always

⚠️ Exposing all actuator endpoints (management.endpoints.web.exposure.include=*) is okay for development, but in production, limit it to only what's necessary. See the Spring Actuator docs.

Start your app and visit:

• /actuator to see available endpoints

  

• /actuator/prometheus to see Prometheus-readable metrics

  

That’s it! Your app is now ready to be scraped by Prometheus.

Configure Prometheus

We need to configure Prometheus to scrape metrics from our Spring Boot application. If you installed Prometheus on your own way add the following to your Prometheus config (e.g., prometheus.yml):

- job_name: 'vote-spring-app'
    metrics_path: '/actuator/prometheus'
    scrape_interval: '10s'
    static_configs:
        - targets: ['vote.vote-app.svc.cluster.local:8080']

Replace vote.vote-app.svc.cluster.local:8080 with your app's actual address (e.g., localhost:8080).

In my case, I’ve addedthe above config on the ArgoCD UI by:

1. Navigate to Application → kuber-prometheus-stack → Details → Parameters.

2. Edit the Values field with the config above.

After deployment, verify your Spring Boot app appears in Prometheus targets and is in the UP state:

Explore metrics like:

• http_server_requests_seconds_count

• http_server_requests_seconds_max

Configure Grafana Dashboard

While this step is optional, dashboards in Grafana make it easier to view all metrics in one place. And looking into every metric one by one by querying in Prometheus is a repetitive task. So let’s configure the Grafana dashboard.

You can create a Grafana dashboard on your own, but in this blog, I am going to use a pre-configured dashboard from Grafana Dashboards, which is the place you can find lots of great dashboards from the Grafana community. And I chose this Spring Boot 2.1 System Monitor dashboard.

Steps:

1. Visit your Grafana website

2. Use dashboard ID 11378 (Spring Boot 2.1 System Monitor)

3. Go to Grafana → Import Dashboard

4. Enter the ID and select Prometheus as the data source

And voilà — your Spring Boot metrics dashboard is ready!

Summary

By integrating Spring Boot metrics into your Prometheus and Grafana stack:

• You gain insights into your application’s performance and health

• It complements your cluster-level observability

• Dashboards give you real-time visibility

Resources

• Spring Boot + Prometheus Guide (Baeldung)

• Simform Blog on Monitoring Spring Boot

• Spring Actuator Endpoints

• Kubernetes DNS Docs

This setup assumes you already have a Kubernetes cluster and ArgoCD installed. If not, check the installation section of my previous blog.

Outline

• What is Observability

• Prometheus and Grafana

• kube-prometheus-stack

• Setting up kube-prometheus-stack

Prerequisites

• Kubernetes Cluster

• ArgoCD (see my previous blog for setup instructions)

Observability

Observability is the ability to understand the internal state of a system by examining the data it produces—logs, metrics, and traces. Highly observable systems make it easier to detect and diagnose complex issues.

It's not just about bugs and outages but also about understanding the impact of changes in your code.

Three Pillars of Observability

1. Logs: Time-stamped records of events that are often unstructured and verbose.

2. Traces: Visualize the lifecycle of a request across services. Useful for understanding latency and bottlenecks, especially in distributed systems.

3. Metrics: Numeric data that represent the behavior of your system (e.g., CPU usage, request count).

For this blog, we’ll focus on the metrics pillar.

Prometheus and Grafana

Prometheus

Prometheus is a CNCF-hosted monitoring and alerting toolkit. It scrapes metrics using a pull-based approach and stores them in a time-series database. It supports dynamic target discovery via Kubernetes service discovery.

Grafana

Grafana is an open-source observability platform. Although Prometheus provides a UI for querying metrics, Grafana makes it easier to visualize those metrics using beautiful dashboards.

kube-prometheus-stack

We’ll use the kube-prometheus-stack Helm chart, which bundles all components required for Kubernetes monitoring:

• Prometheus: Scrapes, stores, and exposes metrics.

• Node Exporter: Collects node-level metrics. And Prometheus scrapes data prepared by this exporter.

• Kube-State-Metrics: This one is another exporter. Exposes information about Kubernetes objects, such as Pods and containers.

• Grafana: Dashboards and visualizations.

• Alertmanager: Sends notifications based on alerts.

For more details, check this Spacelift tutorial.

Setup kube-prometheus-stack

1. In ArgoCD UI, go to Applications → New App → Edit as YAML.

2. Paste the following YAML:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: 'kube-prometheus-stack'
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    targetRevision: 73.2.0
    helm:
      values: |
        grafana:
          service:
            type: NodePort
            nodePort: 31006
        prometheus:
          service:
            type: NodePort
            nodePort: 31005
    chart: kube-prometheus-stack
  destination:
    server: <https://kubernetes.default.svc>
    namespace: kube-prometheus-stack
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: false
      selfHeal: false

I’ve changed the default ClusterIP services to NodePort so we can access Prometheus and Grafana from the browser.

3. Click Save, then Create.

4. After creation, the stack will appear in your ArgoCD dashboard:

Try Prometheus

Access Prometheus at http://YOUR_NODE_IP:31005/

Type a query in the Enter expression field you can type queries in PromQL syntax. E.g. typing node_memory_Active_bytes to see memory utilization.

Click Execute to view memory usage per node. Use the Table tab for raw data and the Graph tab for visualization.

Visualize Metrics Using Grafana

Access Grafana at http://YOUR_NODE_IP:31006/

Login with:

• Username: admin

• Password: prom-operator

After logging in, you see this Grafana welcome page:

Click Dashboards in the sidebar. Explore pre-built dashboards such as:

• Kubernetes / Compute Resources / Cluster – Overview of your cluster’s resource usage.

• Kubernetes / Compute Resources / Namespace (Pods) – View resource usage by namespace. Select vote-app from the dropdown to see pod-specific metrics. By doing this I can see how my vote-app utilizing resources in this Kubernetes cluster.

Recap

In this post, we set up the popular Prometheus and Grafana monitoring stack in our Kubernetes cluster using only the ArgoCD GUI—no CLI required. We explored how to view resource metrics like memory, CPU, and network usage for our vote-app via Grafana dashboards.

To further analyze our application, we could implement custom application metrics (e.g., total votes, requests/sec) in vote-app by creating exporters, and configure Prometheus to scrape them.

References

• Github: kube-prometheus-stack

• Argo CD - Declarative GitOps CD for Kubernetes

• Prometheus Monitoring for Kubernetes Cluster [Tutorial]

• Observability: the present and future, with Charity Majors

• Prometheus & Cloud Native Observability 101

In this post, I’ll walk you through everything step by step—from setting up a simple Kubernetes cluster to configuring a CI/CD pipeline with ArgoCD and GitHub Actions.

Outline

• Spin up a new K3s cluster on AWS EC2

• Kubernetes specification files for the project

• Install ArgoCD on the cluster

• Configure GitHub Actions

• Test the CI/CD pipeline

Project Overview: CI/CD Setup

Below is the application we want to deploy. It's a simple distributed voting application orchestrated with Docker containers. You can find the source code here:
🔗 https://github.com/devsteppe9/voting_app

Here’s a visual overview of the directory structure:

├── .github               # GitHub Actions workflow files
│   └── workflows
│       ├── build-result.yaml
│       ├── build-vote-session.yaml
│       ├── build-vote.yaml
│       └── build-worker.yaml
├── docker-compose.yml    # Local development
├── k8s-specifications    # Kubernetes manifests
├── result                # Node.js web app for real-time results
├── vote                  # Spring Boot/Thymeleaf vote submission app
├── vote-session          # Spring Boot REST API to manage sessions
└── worker                # Spring Boot service to persist votes

Spin Up a New K3s Cluster on AWS EC2

If you already have a Kubernetes cluster running, feel free to skip this section.

I launched a t4g.medium Ubuntu EC2 instance and saved the .pem key for later SSH access. If you're not familiar, K3s is a lightweight, production-ready Kubernetes distribution developed by Rancher Labs. If you noticed, I also launched ARM based Ubuntu instance because I am using ARM based MacBook at home and it was comfortable to push images directly from my laptop when I needed to quickly launch Docker images from my laptop.

Make sure to open these ports on your EC2 Security Group:

• 8080: ArgoCD UI

• 22: SSH access

• 6443: Kubernetes API

• 31000–31002: Application ports

To bootstrap the K3s cluster, I used cool tool k3sup (said 'ketchup'), built by Alex Ellis. From your laptop:

curl -sLS https://get.k3sup.dev | sh
sudo install k3sup /usr/local/bin/
k3sup --help

Now install K3s to your EC2 instance:

💡 Replace $IP and key path with your own. $HOME/controlplanekeypair.pem is a private key path on my laptop, I saved in this path while I launched an EC2 instance.

export IP=54.90.96.48
k3sup install --ip $IP --user ec2-user \
  --ssh-key $HOME/controlplanekeypair.pem

It might take couple of minutes and if you don’t see any errors from command output above voila! Your kubernetes cluster ready to run and your kubeconfig file is located in your local machine.

Verify:

export KUBECONFIG=`pwd`/kubeconfig
kubectl config use-context default
kubectl get node -o wide

# -------- Output ------- #
NAME                           STATUS   ROLES                  AGE    VERSION
ip-172-31-85-66.ec2.internal   Ready    control-plane,master   7m4s   v1.32.5+k3s1

Kubernetes Specification Files

These are the deployment and service specs I created to deploy the app. ArgoCD watches these files and updates deployments when GitHub Actions push new images to DockerHub:

├── k8s-specifications
│   ├── kafka-deployment.yaml
│   ├── kafka-service.yaml
│   ├── result-deployment.yaml
│   ├── result-service.yaml
│   ├── vote-db-deployment.yaml
│   ├── vote-db-service.yaml
│   ├── vote-deployment.yaml
│   ├── vote-service.yaml
│   ├── vote-session-deployment.yaml
│   ├── vote-session-service.yaml
│   └── worker-deployment.yaml

More details here: k8s-specifications

Photo by Jack Japar 😉

Install ArgoCD on Kubernetes

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# -------- Output ------- #
NAME                                                READY   STATUS    RESTARTS    AGE
argocd-application-controller-0                     1/1     Running   0           90s
argocd-applicationset-controller-777d5b5dc7-w8blz   1/1     Running   0           90s
argocd-dex-server-7d8fcd845-lg9hr                   1/1     Running   0           90s
argocd-notifications-controller-655df7c996-q2vp4    1/1     Running   0           90s
argocd-redis-574484f6db-ssf2c                       1/1     Running   0           90s
argocd-repo-server-57449f957c-cdjc5                 1/1     Running   0           90s
argocd-server-7dd4c8cf5f-6x68f                      1/1     Running   0           90s

Expose ArgoCD on NodePort:

cat <<EOF > argocd-server-service.yml
apiVersion: v1
kind: Service
metadata:
  name: argocd-server-nodeport
  labels:
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: argocd
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 8080
      nodePort: 31002
      protocol: TCP
  selector:
    app.kubernetes.io/name: argocd-server
EOF

kubectl create -f argocd-server-service.yml -n argocd

The service above exposes the ArgoCD GUI on port 31002

Access http://YOUR_IP:31002 in your browser:

Get the admin password:

kubectl get secret argocd-initial-admin-secret -n argocd \
  -o jsonpath={.data.password} | base64 -d

To log in ArgoCD dashboard, usethe password you got from above command and use admin as a username.

Create ArgoCD App

1. Go to Applications → New App → Edit as YAML

   

2. Paste:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: vote-app
spec:
  destination:
    namespace: vote-app
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/devsteppe9/voting_app
    path: k8s-specifications
    targetRevision: main
  project: default
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

3. Then click Create

   

   

GitHub Actions Setup

I prepared 4 workflow files under the .github/workflows directory. Each of them detects code changes under result, vote-session, vote and worker subdirectories respectively.

├── .github               # Github Actions workflow files
│   └── workflows
│       ├── build-result.yaml       # workflow for result app
│       ├── build-vote-session.yaml # workflow for vote-session app
│       ├── build-vote.yaml         # workflow for vote app
│       └── build-worker.yaml       # workflow for worker app

The workflow file below is for vote service, which is one of the 4 workflows above. The remaining 3 workflows are similar, the only difference is the Docker image name tags and on.push.paths field values.

name: Integrate vote app

on:
  push:
    branches:
      - main
    paths:
      - 'vote/**'
env:
  DOCKERHUB_USERNAME: ${{ secrets.DOCKERHUB_USERNAME }}
  DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }}

permissions:
  contents: write

jobs:
  build-vote-app:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKERHUB_USERNAME }}
          password: ${{ env.DOCKERHUB_TOKEN }}

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build and push Docker image
        uses: docker/build-push-action@v6
        with:
          context: ./vote
          platforms: linux/amd64,linux/arm64
          push: true
          tags: |
            ${{ env.DOCKERHUB_USERNAME }}/voting_app-vote:${{ github.sha }}
            ${{ env.DOCKERHUB_USERNAME }}/voting_app-vote:latest
          build-args: |
            KAFKA_BOOTSTRAP_SERVERS=kafka:9092
            SESSION_API_URL=http://vote-session:8080/sessions
      - name: Update Kubernetes deployment
        # Replace image tag in deployment.yaml with new Docker image tagged by commit SHA
        run: |
          sed -i "s|image: ${{ env.DOCKERHUB_USERNAME }}/voting_app-vote:.*|image: ${{ env.DOCKERHUB_USERNAME }}/voting_app-vote:${{ github.sha }}|g" k8s-specifications/vote-deployment.yaml
          echo "Updated image in k8s-specifications/vote-deployment.yaml"

      - name: Commit and push changes
        run: |
          git config --local user.name "github-actions[bot]"
          git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add k8s-specifications/vote-deployment.yaml
          git commit -m "Update vote deployment image to ${{ env.DOCKERHUB_USERNAME }}/voting_app-vote:${{ github.sha }}"
          git pull origin main --rebase || false
          git push origin main

The workflow builds Docker images for linux/amd64 and linux/arm64 architectures, pushes to DockerHub, and updates the corresponding vote-deployment.yaml with the new tag.

You need to set up DockerHub secrets on your GitHub Repository. Below is the guideline on how to set up secrets in your GitHub repository: Using secrets in GitHub Actions

Test the Deployment

As shown in the ArgoCD dashboard, the application has successfully synced changes. I’ve experimented with adding and removing some code on result service, then pushed it into main branch of the repository. As you see, there are 7 more revisions created for the result service, and the latest one is serving, running as a pod.

Test your application:

• Vote App: http://YOUR_IP:31000/votes/1

• Result App: http://YOUR_IP:31001/results/1

Recap

GitHub Actions

• Builds and pushes Docker images

• Update Kubernetes deployment files

ArgoCD

• Monitors k8s-specifications/ directory

• Auto-syncs updated manifests into the K8s cluster

In conclusion, deploying a distributed voting application using Kubernetes, ArgoCD, and GitHub Actions provides a robust and automated CI/CD pipeline. Additionally, you can extend your workflow by adding Docker image scanning and Linting stages, which check the syntax of your source code, among other features. But these are not covered in this blog post. By integrating these technologies, developers can efficiently manage application deployments, monitor changes, and ultimately enhance the overall development and deployment process.

The process involves four key steps:

• Setting up security groups with essential ports
• Launching and configuring an EC2 instance with K3s using user-data script
• Verifying the cluster’s functionality
• Optional: Setting up local machine access

Prerequisites

• An AWS console account with permissions to create EC2 instances and security groups

Step 1: Create Security group

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation pane, choose Security Groups.
3. Choose Create security group.
4. Enter a descriptive name and brief description for the security group. You can’t change the name and description of a security group after it is created.
5. For VPC, choose the VPC in which you’ll run your Amazon EC2 instances.
6. For inbound rules, choose Inbound rules. For each rule, choose Add rule and specify the protocol, port, and source. I’ve configured Port 22 for SSH access and Port 6443 to expose the Kubernetes API. While I’ve currently opened these ports to all IP addresses (0.0.0.0/0), this isn’t secure — you should restrict access to your specific IP address.
7. To add outbound rules, choose Outbound rules. For each rule, choose Add rule and specify the protocol, port, and destination. Otherwise, you can keep the default rule, which allows all outbound traffic.
8. Choose Create security group.

Screen shot of security group

Step 2: Launch instance

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation bar at the top of the screen, the current AWS Region is displayed (for example, US East (Ohio)). If needed, select a different Region in which to launch the instance.
3. From the Amazon EC2 console dashboard, choose Launch instance.
4. (Optional) Under Name and tags, for Name, enter a descriptive name for your instance.
5. Under Application and OS Images (Amazon Machine Image), choose Quick Start, and then choose the operating system (OS) for your instance. I chose Amazon Linux, t2.micro instance type.
6. Under Key pair (login), for Key pair name, choose an existing key pair or create a new one.
7. Expand the Advanced details toggle menu and paste the following script into the user data field. I added comments on below script for the details. You can change configuration variables depending on your use case. This script installs K3s, sets up NGINX Ingress, exposes the Kubernetes API using the instance’s public IP, and verifies the installation by creating a sample deployment.

#!/bin/bash

# === CONFIGURATION VARIABLES ===
install_nginx_ingress=true # set to true or false
expose_kubeapi=true # set to true or false
k3s_version="v1.31.6+k3s1" # set to "latest" or specific version like "v1.28.5+k3s1"
k3s_token="REPLACE_WITH_YOUR_RANDOM_TOKEN" # No special characters
nginx_ingress_release="v1.12.0" # if nginx ingress is enabled

# === FUNCTION DEFINITIONS ===

check_os() {
name=$(grep ^NAME= /etc/os-release | sed 's/"//g')
clean_name=${name#*=}

version=$(grep ^VERSION_ID= /etc/os-release | sed 's/"//g')
clean_version=${version#*=}
major=${clean_version%.*}
minor=${clean_version#*.}

if [[ "$clean_name" == "Ubuntu" ]]; then
operating_system="ubuntu"
elif [[ "$clean_name" == "Amazon Linux" ]]; then
operating_system="amazonlinux"
else
operating_system="undef"
fi

echo "K3S install process running on: "
echo "OS: $operating_system"
echo "OS Major Release: $major"
echo "OS Minor Release: $minor"
}

# === MAIN EXECUTION ===

check_os
AWS_IMDS_TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Install dependencies
if [[ "$operating_system" == "ubuntu" ]]; then
apt-get update
apt-get install -y software-properties-common unzip git nfs-common jq
DEBIAN_FRONTEND=noninteractive apt-get upgrade -y
curl -s "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip -q awscliv2.zip
sudo ./aws/install
rm -rf aws awscliv2.zip
elif [[ "$operating_system" == "amazonlinux" ]]; then
yum install -y --skip-broken unzip curl jq git
else
echo "Unsupported OS: $operating_system"
exit 1
fi

# Prepare K3s install params
k3s_install_params=()

if [[ "$install_nginx_ingress" == true ]]; then
k3s_install_params+=("--disable" "traefik")
fi

if [[ "$expose_kubeapi" == true ]]; then
provider_public_ip="$(curl -s -H "X-aws-ec2-metadata-token: $AWS_IMDS_TOKEN" \
http://169.254.169.254/latest/meta-data/public-ipv4)"
k3s_install_params+=("--tls-san" "${provider_public_ip}")
fi

INSTALL_PARAMS="${k3s_install_params[*]}"
echo "INSTALL_PARAMS: $INSTALL_PARAMS"

# Get K3s version
if [[ "$k3s_version" == "latest" ]]; then
K3S_VERSION=$(curl -s https://api.github.com/repos/k3s-io/k3s/releases/latest | jq -r '.name')
else
K3S_VERSION="$k3s_version"
fi

# Install K3s with retries
until (curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=$K3S_VERSION K3S_TOKEN=$k3s_token sh -s - --cluster-init $INSTALL_PARAMS); do
echo 'k3s did not install correctly'
exit 1
sleep 2
done

# Wait for k3s to become ready
until kubectl get pods -A 2>/dev/null | grep 'Running'; do
echo 'Waiting for k3s startup'
sleep 5
done

# Configure kubectl alias
echo 'alias k=kubectl' >>~/.bashrc
source ~/.bashrc

# Optionally install nginx ingress
if [[ "$install_nginx_ingress" == true ]]; then
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-${nginx_ingress_release}/deploy/static/provider/cloud/deploy.yaml
kubectl create deployment demo --image=httpd --port=80

until kubectl get pods --namespace=ingress-nginx 2>/dev/null | grep 'Running'; do
echo 'Waiting for nginx ingress controller to start'
sleep 5
done
fi

8. In the Summary panel, choose Launch instance. Below is the snapshot of before I click Launch Instance.

Step 3: Confirm Kubernetes Cluster

Access to your instance through SSH and check Kubernetes working correct

[ec2-user@ip-172-31-30-75 ~]$ sudo su # user-data installed kubernetes with root user
[root@ip-172-31-30-75 ec2-user]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-172-31-30-75.ec2.internal Ready control-plane,etcd,master 58m v1.31.6+k3s1
[root@ip-172-31-30-75 ec2-user]#

If you cannot see that your Kubernetes is not working, you can checkthe initial user-data log on your EC2 instance by:

tail -n 100 /var/log/cloud-init-output.log

That’s it! Your K3s Kubernetes cluster is now ready to use. Note that additional security configurations are recommended, though we won’t cover those in this post.

Step 4 (Optional): Access to your Kubernetes API from your local machine

As you can see in the above, we exposed Kubernetes API while installing K3s and exposed 6443 on our security group configuration. Which enables us to access our Kubernetes cluster from our local machine. To access, you need steps below

1. Install `kubectl` command-command line tool into your local machine using this official Kubernetes guide, depending on your machine: https://kubernetes.io/docs/tasks/tools/#kubectl.
   I simply installed it on my Mac by: brew install kubectlIf you installed kubectl properly, you can use with below command

kubectl version --client

2. Transfer kubeconfig file from the EC2 instance to your local machine

scp -i mykeypair.pem root@remote-host:/etc/rancher/k3s/k3s.yaml ~/.kube/my-ec2-remote-k3s.yaml

3. Update server address:
Replace https://127.0.0.1:6443 with the public IP or DNS of your remote host. Example:

server: http://:6443

4. Set KUBECONFIG locally

export KUBECONFIG=~/.kube/remote-k3s.yaml

5. Finally, check your Kubernetes cluster on your EC2 accessible from your local machine. This shows you list of nodes you are connected with:

kubectl get nodes

If you see your EC2 node listed in the output, it means the connection is successful — you can now interact with your Kubernetes cluster from your local machine using kubectl.

Summary

Setting up a Kubernetes cluster with k3s doesn’t have to be complicated. This guide walks through creating a lightweight Kubernetes cluster using K3s on AWS EC2.

However, before diving in, consider these crucial points about Kubernetes adoption:

• Evaluate your scaling needs — Kubernetes is ideal for rapid scaling scenarios, as migration later can be challenging
• Ensure you have qualified personnel — Kubernetes requires expertise for proper management, as it’s not secure by default
• Consider managed services — Rather than building your own cluster, it’s recommended to use managed Kubernetes services that handle the complex operational aspects

Reference:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html
https://github.com/devsteppe9/k3s-aws-cdk/blob/main/scripts/k3s-master-install.sh
https://docs.k3s.io/
https://docs.k3s.io/cluster-access

What is the CAP Theorem?

The CAP theorem states that in any distributed system, you can guarantee only two out of three desired characteristics:

• Consistency (C): Every client sees the same data at the same time, no matter which node they connect to.
• Availability (A): Every request receives a response — even if some of the nodes are down.
• Partition Tolerance (P): The system continues to operate despite network partitions or communication failures between nodes.

Since network partitions can (and eventually will) happen in any distributed system, Partition Tolerance is non-negotiable. Thus, distributed databases must prioritize between Consistency and Availability when a partition occurs.

Types of Distributed Databases Based on CAP

• CA databases: All nodes remain consistent and available as long as there’s no partition.
  However, if a network partition happens, the system may crash.
  Examples: PostgreSQL, MariaDB
• CP databases: Prioritizes consistency even during partitions — meaning some nodes may become unavailable until the partition is resolved.
  Examples: MongoDB
• AP databases: Prioritizes availability at the cost of consistency.
  During a partition, nodes may continue serving potentially outdated data to ensure availability.
  Examples: Couchbase, DynamoDB

Reflection:
Learning about CAP helped me better appreciate the trade-offs that engineers must consider when designing distributed systems. It’s all about understanding your system’s priorities — consistency, availability, or how you handle network failures.

#DistributedSystems #CAPTheorem #DatabaseDesign #TodayILearned #SoftwareEngineering

I enrolled in Stephane Maarek’s Udemy course. Completed it within 2 weeks with daily study. I previously took Stephane’s SAA course so it helped me to progress faster. I took detailed notes while taking the course.

For the practice purchased exams from Tutorials Dojo and Stephane’s question sets. While working with sets, I saw some deprecated services such as OpsWorks, CodeCommit, etc. still in the questions, so I suggest you check deprecated services from the AWS documentation. Also, I realized some EKS topics were not covered with Stephane’s course, especially Pod Identity and IAM Roles for Service Accounts (IRSA). Basically, below is the strategy I followed

• Tackled 25 questions per session
• Reviewed incorrect answers immediately
• Note unfamiliar service features from the options
• After finishing each set, review the above noted features from the AWS Documentation and do small experiments on the AWS console
• After finishing 3 sets, I sit with 75 questions in one sit and check how I can solve the previous 3 sets

After tackling about 200 questions, I scheduled my exam. My exam is scheduled at 13:30 and I checked in from 13:00. The check-in process was pretty quick. Proctor tried to connect with voice connection with my MacBook, but I could not hear the proctor’s voice, so we decided to communicate with chat instead. Finished exam around 16:40, total spending 3:40 minutes, and it was the longest exam I've ever had.

Surprisingly, I received my exam result around 21:00 after 4 hours. I first received the Credly badge email, then got an email from AWS telling me congrats! That was a belief I did not want to sit that long exam again! The previous 2 certifications, AWS Developer — Associate and AWS Cloud Practitioner, are extended by 3 years automatically. And AWS Solution Architect did not extend.

This is the experience I had, as a summary, it was a pretty hard exam to prepare. I spent my weeks reading paragraphs of questions, options, it required pretty consistency and energy, I am pretty happy to pass!

In my next post, I am going to put my real raw notes I took while studying for this exam. Hopefully it helps whoever is preparing for the exam. And stay focused!

Та бүхэн нэртэй алдартнуудыг надаар хэлүүлэлтгүй мэдэж байгаа байх. Тэд бүгд өөрсдийн салбартаа амжилтад хүрсэн хүмүүс. Гэхдээ тэдний ард үргэлж дагаж мөрддөг нэгэн нийтлэг зуршил байдаг нь — насан туршдаа тасралтгүй суралцсаар байдаг явдал юм.

Тэд хэзээ ч шинэ зүйл сурахаа зогсоогоогүй. Амжилтад хүрэхэд олон чанар хэрэгтэй байдаг ч, суралцах чадвар хамгийн гол түлхэц нь болж чаддагт би итгэлтэй байна.
Бид суралцах тусам амжилтад хүрэх магадлал маань улам нэмэгдсээр байдаг.

Гэхдээ хэрхэн үр дүнтэй сурах вэ?

Бид суралцахдаа унших, үзэх, сонсох буюу ном унших, бичлэг үзэх, подкаст сонсох гэх мэт аргаар олон оролт-ыг тархиндаа хийдэг. Гэхдээ хүмүүс оролтондоо л их анхаарал тавиад байдаг. Үүний үр дүнд:

• Орж буй мэдээлэл их
• Гэхдээ гаралт байхгүй
• Ингээд гүехэн сурах (Shallow Learning) байдал үүсдэг.

Харин бидний хүсэж буй зүйл бол:
Гүн сурах (Deep Learning) юм.

Гэвч яаж вэ…

Бид сайн сурахын тулд оролтоос илүү гаралтанд анхаарах хэрэгтэй.
Гаралт гэдэг нь сурсан зүйлээ хэрэглэх, бодитоор ашиглах гэсэн үг.

Сурсан зүйлээ ашигла эсвэл алд!

За тэгээд энэхүү илтгэгч маань амжилттай, хурдан сурах нэгэн томъёог загварчилж өгч

1. Оролтын чанар

Хамгийн түрүүнд тархиндаа оруулж байгаа оролтынхоо ЧАНАРдаа өндөр анхаарал хандуул. Тархиндаа оролт оруулах явцдаа буюу сурч байхдаа тухайн зүйлдээ гүн анхаарал хандуулах хэрэгтэй. Сурч байх хооронд хүнтэй ярих, утасныхаа мэдэгдэлийг шалгах гэх мэтчлэн анхаарал саатааруулсан олон зорилтот (multitasking) зүйлүүдээс ангижрах хэрэгтэй. Юмыг уншиж, сурч, ойлгож сууж байлаа гэж бодоё. Гар утсандаа нэгэн мэдэгдэл ирлээ. Энэ үед яадаг билээ… Мэдээж шалгана. Ингээд мэдэгдэлийг шалгаж байх хооронд тэрхүү ойлгож байсан сурч байсан тэрхүү чармайл (effort)-ыг, тэрхүү оролтын чанарыг шууд алж байна гэсэн үг.Оролтын чанарыг алдаж байна гэдэг нь дараа нь тэр мэдлэгийг санах явцаа алдаж байна. Тэгэхээр оролт оруулах явцдаа тэрхүү зүйлд 100% анхаарал хандуулах, олон зүйл (multitasking) хийхгүй байх. Нэг агшинд нэг л зүйлийг анхаарах.

2. Эргэцүүлэн бодох

Ямар нэгэн зүйлийг сурч дуусаад.Сурсан зүйлдээ эргэж хараад өөрөөсөө дараах хэдэн асуултыг асуух

• Энэ мэдлэгээс авчихаар зүйл юу байсан вэ?
• Энэхүү мэдлэгийг би юунд ашиглах вэ?
• Амьдралдаа яаж ашиглаж болох вэ?
• Ажилдаа, гэр бүлдээ яаж ашиглавал болох вэ?

Энэхүү асуултуудыг өөрөөсөө асууснаар сурсан зүйлээ өөртөө бэхжүүлж үлдээж чадаж байгаа юм.

3. Хэрэгжүүлэх

Сурсан зүйлээ хэрэгжүүлж сурах. Бид ямар нэгэн зүйлийг сурах үед сурч дуусчихсан мэт мэдрэмж төрдөг бөгөөд дараагийн зүйлээ сураад явдаг. Хэрэгжүүлээгүйгээс хий мэдлэг хуримтлуулдаг — тэрхүү зүйлийг сурсан ашиглах гэхээр чадахгүй байдаг. Сурсан зүйлээ төлөвлөөд ямар нэгэн үйлдэл хийх хэрэгтэй. Ямар нэгэн үйлдэл хийх нь юу ч хийгээгүйгээс илүү тул.

4. Хуваалцах

Сүүлийнх нь бол хуваалцах. Мэдээж бид бүгд сонсож байсан байх. Хамгийн сайн сурах арга бол заах. Зүгээр сурсан зүйлээ бусад хүмүүстэй хуваалц, заа, хэлэлц. Өөр хүмүүст хуваалцах явцдаа бидний тархи тэрхүү мэдлэгт маш сайн анхаарал хандуулдаг байна.

Тэгэхээр хэн ч зөвхөн оролтондоо анхаарал хандуулсанаар төгс эзэмшигч байж чадахгүй юм байна. Төгс эзэмшигч - орсон оролтоосоо илүү их гаралт гаргадаг.

Ингээд таниас нэг асуулт асууяа. Ямар нэгэн шинэ зүйл сурахдаа, сурахад хэр их цаг зарцуулж байсан вэ? Бас эргэцүүлэн бодох, хэрэгжүүлэх, хуваалцахдаа хэр их цаг зарцуулж байсан вэ?

Хэрэв та гаралтаас илүү оролтонд их цаг зарцуулж байсан бол энэ бол зөв зүйл биш юм.

За ингээд бидний амьдралд маш чухал зүйл болох зогсолтгүй суралцах, сурах үедээ хэрхэн үр дүнтэй хурдан сурах талаар орууллаа. Энэхүү илтгэлийн бичлэгийг доор оруулсан бөгөөд орж сонирхож үзээрэй. Бас алдаатай засчимаар байгаа зүйл олдвол коммент хэсэгт үлдээгээрэй.

2020.03.02 Japan, Osaka