DEV Community: Vuyisile Ndlovu

How to use Azure Key Vault with the Azure CLI

Vuyisile Ndlovu — Wed, 30 Jul 2025 07:36:30 +0000

Azure Key Vault is a secure secret storage service from Microsoft. You can use it to safeguard application credentials and SSH keys. In this post, I’ll show you how to create a Key Vault, and also how to add, retrieve and modify credentials in it.

Creating a Key Vault

Create a resource group if you don’t have one

az group create --name myResourceGroup --location westus2

Create an Azure Key Vault

az keyvault create --name <yourKeyVaultName> --resource-group myResourceGroup --location westus2

Replace yourKeyVaultName with your own name. Azure assigns DNS names for Key Vaults, so yourKeyVaultName must be globally unique.

Insert a Secret

To insert or set a new secret, use az keyvault secret set:

az keyvault secret set --vault-name <yourKeyVaultName> --name "MySecret" --value "SecretValue"

Retrieve a Secret

To securely retrieve a secret:

az keyvault secret show --vault-name <yourKeyVaultName> --name "MySecret"

To retrieve only the secret’s value and no other metadata:

az keyvault secret show --vault-name <yourKeyVaultName> --name "MySecret" --query value -o tsv

Update an Existing Secret

az keyvault secret set --vault-name <yourKeyVaultName> --name "MySecret" --value "NewSecretValue"

List All Secrets

To list all secrets in the Key Vault:

az keyvault secret list --vault-name <yourKeyVaultName>

Delete a Secret

To delete a secret:

az keyvault secret delete --vault-name <yourKeyVaultName> --name "MySecret"

This command performs a soft-delete that’ll keep the secret for 90 days before it is purged.

Self-Hosting Planka in Kubernetes: A Lightweight Trello Alternative

Vuyisile Ndlovu — Thu, 10 Jul 2025 10:29:11 +0000

Intro

Planka is a lightweight, open-source, kanban-style project management application similar to Trello. It’s built with React and Postgres, and its key features include a drag-and-drop interface, boards, lists, cards, notifications and markdown support.

Kanban is a simple but powerful method for visualising and managing work. You break tasks into cards and move them through columns that represent stages of progress, such as To Do, In Progress and Done. This makes it easy to see what’s happening at a glance: what’s in the backlog, what’s currently in progress and what’s done. In my case, I’m often juggling projects in my homelab, client work, personal learning goals and content creation. A Kanban board helps me stay organised and focused.

Why I chose Planka

I use and love Trello, but its software is proprietary, and their free plan has limitations on the number of boards you can create. One of my goals with my homelab is digital sovereignty — the ability to control my data, tools and infrastructure without depending on third parties. SaaS platforms are great, but they frequently change pricing, lock down features, or disappear entirely. I want the freedom to own and shape the systems I use every day.

That’s why I self-host as many tools as I can, from DNS and backups to tools like Planka. There’s no shortage of self-hostable Kanban-style tools. I chose Planka because it is Open source, uses a Postgres database, is lightweight and relatively easy to run in Kubernetes. There are some things I don’t like about it, but the pros outweigh the cons. More on that later. Self hosting Planka gives full control over it, I control access to it, its uptime, backups and how it fits into the rest of my workflow.

Kubernetes Set Up

Planka runs as a container and can be deployed to Kubernetes using its official Helm chart. In my homelab, I manage all applications with aGItOps approach using FluxCD. To deploy Planka with Flux CD, I created three manifest files:

a HelmRepository resource pointing to the official Planka Helm chart,
a HelmRelease that defines how Planka should be deployed and configured.
and an ExternalSecret manifest to securely fetch credentials from my secret storage.

Using this approach keeps my deployment reproducible, version-controlled, and easy to update.

Defining the Helm Repository

In FluxCD terminology, a HelmRepository points FluxCD to an upstream Helm chart. The Helm Repository below points Flux to the upstream source of the Planka Helm chart:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: planka
  namespace: flux-system
spec:
  interval: 60m
  url: http://plankanban.github.io/planka

The spec.interval field specifies how often Flux will check the upstream Helm repository for updates. This interval is useful for ensuring that the Planka in my cluster stays up-to-date with the latest versions of Helm charts in the repository without requiring manual intervention.

Managing Secrets with `ExternalSecrets`

To keep sensitive data like database credentials and the secret key out of Git and plain Kubernetes manifests, I created the secrets in AWS and referenced the secrets using the ExternalSecrets operator. It connects to a secure secrets vault — in my case, AWS SSM Parameter Store — fetches the values, and creates Kubernetes Secret resources automatically inside the cluster.

To create the secrets in theAWS SSM Parameter Store, I used the AWS CLI to define each key-value pair securely. For example, I created and stored the Planka PostgreSQL credentials using the following command:

export planka_db_username="planka_user"
export planka_db_name="planka_db"

aws ssm put-parameter --name "/K8s/Clusters/Prod/Planka/planka-postgres" \
\ --type "SecureString" \
\ --value "{\"username\": \"$planka_db_username\", \"password\": \"$(openssl rand -base64 16)\", \"database\": \"$planka_db_name\"}"

This parameter name or secret is namespaced under “Planka” in AWS to keep things organised. Secrets are encrypted at rest using AWS KMS and are only accessible to the IAM role or user associated with the External Secrets provider. Once created and stored, the External Secrets Operator fetches the secrets and injects them into Kubernetes as native Secret resources, making them available to the Planka Helm release without ever exposing the raw values in the Git Repo. Pretty cool!

To make the secrets available inside Kubernetes, I created an ExternalSecret resource that maps each AWS SSM parameter to a corresponding key in a Kubernetes Secret. Here’s an example of the manifest I used:

---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: planka-secret
  namespace: default
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-parameter-store
    kind: ClusterSecretStore
  target:
    name: planka-secret
    creationPolicy: Owner
  data:
    - secretKey: secretkey
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-secretkey
        property: SECRET_KEY
    - secretKey: planka-db-username
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-postgres
        property: username
    - secretKey: planka-db-password
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-postgres
        property: password
    - secretKey: planka-db-name
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-postgres
        property: database
    - secretKey: planka-admin-email
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-admin
        property: admin_email
    - secretKey: planka-admin-password
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-admin
        property: admin_password
    - secretKey: planka-admin-username
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-admin
        property: admin_username
    - secretKey: planka-admin-adminname
      remoteRef:
        key: /K8s/Clusters/Prod/Planka/planka-admin
        property: admin_name

The manifest tells the External Secrets Operator to:

Pull secrets from a ClusterSecretStore named aws-parameter-store
Fetch parameters such as SECRET_KEY and planka-db-password from SSM
Map each SSM parameter to a corresponding key in the resulting Secret

The Planka Helm Release(defined in the next section) then references this Secret to inject the values as environment variables into the container at run time, keeping the credentials secure and fully managed through GitOps.

Creating the Helm Release

A HelmRelease configures and deploys applications via Helm in a cluster. I used the release below to deploy Planka to my cluster.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: planka
  namespace: default
spec:
  interval: 5m
  chart:
    spec:
      chart: planka
      version: "1.0.3"
      sourceRef:
        kind: HelmRepository
        name: planka
        namespace: flux-system
      interval: 60m
  valuesFrom:
    - kind: Secret
      name: planka-secret
      valuesKey: secretkey
      targetPath: secretkey

    - kind: Secret
      name: planka-secret
      valuesKey: planka-db-username
      targetPath: postgresql.auth.username

    - kind: Secret
      name: planka-secret
      valuesKey: planka-db-password
      targetPath: postgresql.auth.password

    - kind: Secret
      name: planka-secret
      valuesKey: planka-db-name
      targetPath: postgresql.auth.database

  values:
    base:
      baseUrl: "https://planka.ndlovucloud.co.zw"
    ingress:
      enabled: true
      className: nginx
      annotations:
        cert-manager.io/cluster-issuer: letsencrypt-prod
      hosts:
        - host: planka.ndlovucloud.co.zw
          paths:
            - path: /
              pathType: Prefix
      tls:
        - hosts:
            - planka.ndlovucloud.co.zw
          secretName: planka-tls

    # Values from planka-secret
    postgresql:
      enabled: true
    redis:
      enabled: true

This Helm Release references the Planka external secret from the previous section, pulls in the credentials and injects them into the Planka container at runtime.

How I use Planka

I haven’t started using Planka heavily yet, as I just finished setting it up, but I plan to use it a a central board for managing my personal growth, homelab activities and client projects.

For personal projects, I’ll track blog posts, conference talks, and books I’m reading to stay on top of my goals. I’ll create a dedicated board for infrastructure tasks to log homelab issues, upgrades and experiments. Finally, I’ll use Planka to manage client tasks. Using kanban for this will keep my work organised and deadlines clear.

Here’s a screenshot showing the board I’m using to track work I’m doing for a client:

![Planka board set against an image background of a scenic European town. The board is categorised into five columns. From left to right, the columns are

Backlog, Doing, Documentation and Complete](https://vuyisile.com/wp-content/uploads/2025/07/planka-screenshot.png)

What I don’t like about Planka

I appreciate the work the developers put into Planka, but there are a few areas where I think it falls short.

First, customising parts of the UI isn’t straightforward. Unlike Trello, where you can tweak the look and feel easily, Planka requires you to fork the codebase and edit the CSS to make visual changes to the UI. I’m technically capable of doing that, but I’d prefer an easier way to personalise the interface without maintaining a fork.

Secondly, there’s no built-in search for cards –at least as of the version I’m using. That makes it hard to find specific cards. That’s not a problem for me now because my boards are still small, but as my boards grow, it might be an inconvenience.

Finally, I haven’t found an easy way to export your data in JSON or other portable formats. This is something I’d like to see supported, both for backup and interoperability reasons. These aren’t deal breakers, but they are small annoyances worth noting.

Conclusion

Planka isn’t the most feature-packed project management tool out there, but it’s simple and easy to self-host, perfect for someone like me who wants full control over their data without unnecessary complexity. I’m happy to have a private, minimal Kanban system that fits into my workflow. As my boards grow and usage continues, I may post more about it and how I use it.

Rollbacks in ArgoCD

Vuyisile Ndlovu — Tue, 01 Jul 2025 12:26:59 +0000

ArgoCD is a GitOps-based continuous delivery tool for Kubernetes that keeps applications in sync with their declared state in Git. I wrote about ArgoCD a few days ago, explaining what it is and how to set it up. In a GitOps workflow, Git is the single source of truth for your Kubernetes infrastructure. ArgoCD continually syncs and reconciles what’s defined in your Git repository with your cluster.

Deployments don’t always go according to plan, and changes can break the application. In this post, I’ll discuss how to perform a rollback using ArgoCD.

The GitOps Philosophy

The idea behind GitOps is that your cluster should always reflect what’s defined in Git. Rather than making manual changes to deployed resources, you define the desired state of your application in code, and a tool like ArgoCD applies it to your cluster automatically. This approach has some advantages:

– You can audit changes with Git history

– You always know exactly what’s running

– Rolling back bad deployments is straight forward. You run a git revert or an ArgoCD rollback command.

Rollback in ArgoCD

A rollback in ArgoCD means ArgoCD syncs a previous version of an application to the cluster using its Git commit. It checks out the last good commit and reapplies it to the cluster.

In some instances, it may be a good idea to disable auto syncing when troubleshooting failed deployments. To do this, run

argocd app set <app-name> --sync-policy none

To inspect the deployment history, run

argocd app history <app_name>

replacing <app_name> with the name of your application. This command shows a list of numbered revisions. To rollback, take note of the number of the good revision and run

argocd app rollback <app_name> <revision_number>

replacing app_name and revision_number with the correct values for your application.

This will reapply the good version and bring the cluster back up. To clean up the broken state in Git, you can undo the changes using git revert:

git revert <bad-commit-sha>
git push

This ensures that your Git history accurately reflects the fix. If you had disabled auto sync, re-enable it:

argocd app set <app-name> --sync-policy automated

Conclusion

ArgoCD makes rollbacks simple — but only if your Git repo is well-maintained. To make rollbacks easy, ensure your Git commits are small and intentional.

Setting Up a Remote Backend for Terraform Using Azure Storage

Vuyisile Ndlovu — Thu, 26 Jun 2025 09:36:47 +0000

Terraform Remote State Using Azure Storage

Recently, I needed to set up a shared Terraform workflow where state could be safely stored and accessed by a team. I figured out how to use Azure Blob Storage as a remote backend for Terraform. Storing your Terraform state in a remote backend ensures consistency across teams and machines. This post walks you through setting up Azure Blob Storage as the backend.

1. Create Storage Account and Container

Run the following in your terminal. Adjust variables as needed.

# Set variables
RESOURCE_GROUP="tf-aks-rg"
STORAGE_ACCOUNT_NAME="tfstatestore$(openssl rand -hex 3)" # must be globally unique
CONTAINER_NAME="tfstate"
LOCATION="westus2"

# Create the storage account
az storage account create \
  --resource-group $RESOURCE_GROUP \
  --name $STORAGE_ACCOUNT_NAME \
  --sku Standard_LRS \
  --encryption-services blob \
  --kind StorageV2 \
  --location $LOCATION

# Get the storage account key
ACCOUNT_KEY=$(az storage account keys list \
  --resource-group $RESOURCE_GROUP \
  --account-name $STORAGE_ACCOUNT_NAME \
  --query '[0].value' -o tsv)

# Create the container
az storage container create \
  --name $CONTAINER_NAME \
  --account-name $STORAGE_ACCOUNT_NAME \
  --account-key $ACCOUNT_KEY

2. Configure Terraform to Use the Remote Backend

Create a file called backend.tf:

terraform {
  backend "azurerm" {
    resource_group_name = "tf-aks-rg"
    storage_account_name = "<your-storage-account-name>"
    container_name = "tfstate"
    key = "terraform.tfstate"
  }
}

Replace <your-storage-account-name> with the actual name.

3. Initialize Terraform

terraform init

You’ll be prompted:

Do you want to copy the existing state to the new backend? [yes]

Answer yes to migrate your local state to Azure.

4. Verify

Confirm that terraform.tfstate exists in the Azure container.
Your local state file (terraform.tfstate) should no longer be present or should be empty.

Next Step: Team Access

Make sure your team members have:

Read/write access to the storage account
Correct backend config in their Terraform project

Conclusion

This was my first time setting up a remote backend with Azure, and it turned out to be more straightforward than I expected. If you’re using Azure and want to avoid local state headaches, this set up works well.

GitOps with ArgoCD

Vuyisile Ndlovu — Fri, 13 Jun 2025 19:48:30 +0000

I’m learning a set of new tools to make my skills more well-rounded. These include Azure, Terraform and ArgoCD. ArgoCD is a GitOps continuous delivery tool for Kubernetes that’s similar to Flux CD, which I used in my Kubernetes homelab. Like Flux CD, it syncs your cluster with configuration data stored in Git. The way it works is that you push changes to Git and Argo CD picks them up and applies them to the cluster. Git becomes the single source of truth. If the cluster drifts from what’s in Git, Argo CD can either alert you or automatically sync to fix it.

Installing Argo CD

I installed Argo CD using Helm:

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

kubectl create namespace argocd
helm install argocd argo/argo-cd --namespace argocd

Accessing the UI

Unlike Flux CD which is CLI-first, Argo CD is a UI-first application. After installing it in the cluster, I accessed the argocd-server by port forwarding using this command:

kubectl port-forward svc/argocd-server -n argocd 8080:443

This command lets me tunnel securely into the Argo CD pod from my local machine without setting up an ingress or load balancer. This is a screenshot from the Argo CD UI:

Getting the Default Admin Password

Before I could login to the UI, I had to get the default admin password from the secret that was created during installation:

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

Key Concept: The Application Object

So far, I’ve learned that the heart of Argo CD is the Application object. It defines a

Source : A Git repo with source files (Helm charts, Kustomize files or plain YAML manifests)
Destination: The target Kubernetes cluster and namespace
Sync Policy: Whether or not this application should be manually or automatically synced to the cluster.

Below is an example of an ArgoCD Application to deploy Nginx via Helm:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-helm
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://charts.bitnami.com/bitnami
    chart: nginx
    targetRevision: 15.3.2
    helm:
      values: |
        service:
          type: LoadBalancer
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

This config tells Argo CD to watch the Bitnami Nginx chart and auto-deploy changes.

Thoughts so far

Argo CD was quick to install–I had it up and running in a few minutes. The UI is clean and easy to use. I haven’t explored the CLI yet, but I’ll test it as I deploy more applications. So far, it feels straightforward and promising.

An intro to Helm

Vuyisile Ndlovu — Thu, 12 Jun 2025 12:23:16 +0000

I’m currently learning Helm to improve how I deploy and manage Kubernetes applications. This post is a quick summary of what I’ve learned so far.

Helm is a package manager for Kubernetes. It simplifies deploying and managing Kubernetes resources by bundling them into reusable packages called charts. If you’ve used apt for Debian-based systems, Helm serves a similar role, except for Kubernetes.

Installing Helm

I installed Helm on Linux using Snap:

sudo snap install helm --classic

Key Concepts

Chart : A collection of YAML manifests that define a Kubernetes application (e.g Prometheus or a monitoring stack).
Release: A running instance of a chart, versioned and deployed into a cluster
Values: Configurable parameters used to customise chart behavior during deployment.

Why Use Helm

Faster Installs: Deploy applications like Prometheus and Grafana in seconds
Rollbacks: Easily revert to a previous release if something breaks
Customisation: Tweak values without editing raw YAML files
GitOps-friendly: Helm charts integrate well into GitOps workflows

What I’m Doing Next

I’m starting with simple charts, then I’ll work my way up to deploying complex stacks and applications such as ArgoCD with Helm. I’ll be sharing what I learn as I go in short blog posts like this one.

From HDD to SSD: How I fixed an I/O Bottleneck in a Kubernetes Node

Vuyisile Ndlovu — Fri, 30 May 2025 11:34:38 +0000

Diagnosing and Fixing an I/O Bottleneck in My Kubernetes Node

I’ve been experiencing some issues with my homelab servers. One was that the media server (Mac Mini hardware running Ubuntu) kept freezing and locking up, requiring a manual restart. This caused the Kubernetes containers running on it to fail. Kubernetes, in response, would move the failed apps to another node(HP laptop) and slightly overload it. I suspected the issue was I/O related since this machine used a hard drive with a spinning disk, which is quite slow compared to a Solid State Drive(SSD). The media server has significantly less memory than the HP, but it has a better processor, and its RAM never got maxed out, so CPU and RAM weren’t the issue. Before setting up Kubernetes on it, its performance was acceptable, so I figured the slowness was caused by the impact of Kubernetes components like logs, image pulls, and metrics hammering the disk heavily, causing it to slow down.

I fixed the problem by cloning the system from an HDD to a new SSD drive and swapping the drives. In this post, I’ll walk you through how I did that with minimal downtime.

The Problem

Node froze often, especially during heavy disk usage.
It had a decent CPU but less RAM than my HP635 node.
Disk I/O seemed to be the bottleneck.

The Plan

Clone the HDD to a new SSD.
Swap drives
Boot from the SSD.

Steps I Took

I drained the node of all Kubernetes applications running on it. The apps moved to the HP node.
Next, I connected the new SSD to the server using a USB-SATA connector.
Checked the drive names with lsblk:
- sda: 149.1GB (old HDD)
- sdb: 238.5GB (new SSD)
The new SSD was larger than the HDD, which made cloning much easier since I didn’t need to resize the contents of the source disk. I ensured that the SSD was connected but not mounted.
Next, I estimated how long it would take to copy random data from the hard drive to itself using this command and the formula below:

sudo dd if=/dev/sda of=/dev/null bs=1M count=256 status=progress

Running the command above gave me a rough estimate of the disk’s speed. I then divided the disk size by the speed to get how long it’d take to copy the entire disk. (Formula: disk size (MB) ÷ speed (MB/s) = ETA)
I knew that it would take longer to copy data from the HDD to the SSD through a USB cable, but running the test above allowed me to get a reasonable estimate of the time it’d take. My initial thought was that it’d take about 40 minutes to an hour to clone the drive.
1. The server wasn’t connected to a screen, and setting up a screen for it would have been inconvenient, so I cloned the drive over SSH.
2. To prevent losing progress if the SSH connection dropped during the clone process, I started atmux session to keep the job running in the background:

tmux new -s clone_disk

Next, I cloned the disk using dd :

sudo dd if=/dev/sda of=/dev/sdb bs=1M status=progress conv=noerror,sync

where if is the input device, of is the output device, bs is the block size, status=progress displays a progress bar and conv=noerror,sync tells dd not to stop even if it encounters a read error in the input device. If it encounters any read errors, it should pad input blocks with zeroes to keep the output file properly aligned, block by block
Cloning the drive took twice as long as I had initially thought — the process completed after 2 hours.
1. Once the disk was cloned, I ran a check on the cloned disk :

sudo fdisk -l /dev/sdb

The check was mostly okay except for this warning: "The backup GPT table is not on the end of the device." This meant that the GPT (GUID Partition Table) wasn’t located at the physical end of the disk, which is where it’s supposed to be. Since the HDD was smaller than the SSD, dd copied the main GPT header and partition table at the beginning of the disk and the backup GPT at the same position it was on the smaller disk(at the end). But since the SSD is bigger, the backup GPT wasn’t at the end of the new disk. I took note of the warning and moved on.
1. After swapping the drives, I booted from the SSD. The server booted up without errors and quicker than it had previously.
2. Next, I fixed the GPT warning using gdisk :

sudo gdisk /dev/sda

Entered v to verify
And w to write the fix
1. I tried to resize the new drive’s volume by running :

sudo pvresize /dev/sda2

Checking the volume sizes using the commands below showed no change in the size of the drive; it was still showing up as a hundred and something GB drive :

sudo vgdisplaysudo lvdisplay

To resolve this, I installed cloud-guest-utils, grew the partition to take up the extra space, resized the physical volume and extended the logical volume to take up the extra space:
- Installed the required tool:

sudo apt install cloud-guest-utils

Grew the partition:

sudo growpart /dev/sda2sudo pvresize /dev/sda2sudo lvextend -l +100%FREE /dev/ubuntu-vg/rootsudo resize2fs /dev/ubuntu-vg/root

After that, I confirmed that everything was the way it should have been by running:

lsblk /dev/sda

Everything looked good, the drive and its partitions were using up all available space.

Replacing the drives

After verifying that the new drive looked good and that all the data from the old drive was copied successfully, I popped the Mac Mini open, removed the HDD and replaced it with the SSD before closing it back up.

Copied data to the SSD first

Mac Mini before disassembly

Case removed

Disassembled

HDD removed

HDD replaced with SSD

The Result

The Media Server now runs on a Solid State Drive, it’s faster and more stable now. To test it, I drained all Kubernetes applications from the HP control node to the Mac Mini and ran them for a few days. They ran beautifully, the CPU didn’t take a huge hit, and it didn’t lock up from the heavy I/O from the apps. One slight problem I have now with the server is that its CPU fan is much louder. When replacing the hard drive, I forgot to reinstall a temperature sensor in the Mac Mini that regulates how fast the fan runs. Now it probably thinks the sensor is damaged, so it runs at full throttle all the time, and it’s quite loud. Other than that, the server works perfectly.

Takeaway

I need to be more careful when opening Apple devices, it’s easy to miss replacing an important component. If you’re running a server on an old HDD and it keeps constantly freezing, locking up or running slow, consider swapping it out for an SSD. Clone your data between drives before replacing them with dd, fix any GPT issues with gdisk, and resize your volumes.

May AWS Tech Meet at FlexiWork

Vuyisile Ndlovu — Mon, 26 May 2025 13:53:59 +0000

On Saturday, May 24, I attended an AWS meetup at FlexiWork. The meetup was three hours long, we networked and listed to talks with hands-on tips for AWS practitioners.

Here’s how it went down.

The venue: FlexiWork, a relaxed, coworking space

The event was hosted at FlexiWork, a beautiful co-working space in Bulawayo with secure parking, art along the hallways and a quiet garden just outside. Around 20 people attended the meetup, ranging from bootcamp students to working professionals.

Tiffany, the FlexiWork Operations Manager, started us off with a quick tour of the venue and an icebreaker session to introduce ourselves. FlexiWork offered doughnuts, coffee and other treats. We settled in with Wi-Fi and got ready for the talks at around 11AM.

Hildah Machando — AWS Fundamentals: Your Guide to Certification, Cloud Building, and Security

Hildah, a 3x AWS and CISA certified security specialist opened the session with a beginner-friendly introduction to AWS. She covered:

Certification paths and AWS job prospects
Tips on passing certification exams, including costs and resources to prep for them
How to set up your first AWS account. This included steps on creating groups, roles and IAM policies.
She broke down how EC2 works; covering the different types of instances, and strategies for using the free tier wisely e.g stopping and terminating instances after completing learning sessions to avoid incurring high bills.
An explanation of Shared Responsibility, including
- What AWS manages for you (instance patching, licensing)
- What you’re responsible for (security configurations, updates etc)

The talk was practical and gave new users a clear path to start experimenting with AWS.

My Talk — Cloud Skills, No Cloud Required

I gave a talk titled “Cloud Skills, No Cloud Required”, where I shared how I built my own “cloud” using local hardware combined with AWS services. You can find the slides from my presentation on speakerdeck.

I walked through:

Why I started a homelab — to learn by doing, keep costs low and to prove that it’s possible
What software powers it: containers (Kubernetes), backups, monitoring, declarative tools like Ansible and CloudFormation
AWS services I use within the homelab:
- S3 for backups
- Route 53 for DNS and subdomains
- SSM Parameter Store for secure credentials storage
- IAM for access control and policy enforcement
- SES to send alerts when backups fail

I also mentioned the cloud-native principles I follow, even in a homelab such as:

Rebuildability : everything is declarative in YAML and version controlled in git
Security-first : credentials aren’t hardcoded and backups are stored securely
*Monitoring and alerts: * so I know when things go wrong
*Low cost: * I use low cost hardware and low-cost/free services from AWS

I recommend a hybrid approach like this if you’re learning AWS, cloud engineering or DevOps but can’t afford to run full workloads in the cloud, it’s helped me gain real-world experience without the real-world bill.

Conversations I Had

One of the highlights of the day was connecting with students from the Uncommon bootcamp. Their enthusiasm for learning how code works, from variables to full applications reminded me of myself many years ago when I was a bootcamp student at Muzinda Hub.

I shared advice with them on breaking into tech via open source. We talked about programs like Google Summer of Code, Outreachy, Summer of Docs and other internship opportunities.

Another great moment was chatting with Tapiwa Kanda from the AWS Zimbabwe community. We kicked around the idea of launching an AWS User group in Bulawayo. The group would be a place for local builders to collaborate, share and grow together. I’m looking forward to see where that leads.

Takeaways

I few things that stuck with me during the event:

Email is deceptively hard to self-host. Somone asked why I don’t run my own mail server. We discussed the challenges; IP reputation problems, getting emails marked as spam, setting DNS records up and keeping the server secure. It sounds like a pain, but now I want to try it. I’m thinking of it as an interesting technical puzzle.
There’s a hunger for tech. Whether it’s bootcamp students or hobbyists, people are eager to learn more, build real things and use tech to its full potential.

What’s Next

After the event, and thinking about the discussions I had, I plan to experiment with self-hosted email to see how far I can push it. I also want to follow up with Tapiwa about starting an AWS User Group in Bulawayo.

If you’re interested in homelabs, AWS or setting up cloud-native systems on a budget, reach out to me to ask questions. And if you’ve never been to a tech event, go. You’ll meet interesting new people, make lasting connections and leave with more than just knowledge.

How A Bad Firewall Rule Broke My Network

Vuyisile Ndlovu — Wed, 14 May 2025 09:19:32 +0000

While tightening up and securing the firewall rules in my network with UFW, I ran into a problem that completely broke DHCP. My goal was simple: to allow DHCP requests from devices in my LAN. So I added the following rule:

On paper, it looked right. DHCP traffic should only be coming from devices in that subnet, but as soon as I applied it, clients stopped getting IP addresses and I only realised this a day later after some devices rebooted or tried to renew their IP addresses. Static IPs worked fine, but DHCP wasn’t working.

DHCP Protocol — Where I got it wrong

DCHP is unique in that it uses broadcast IP addresses to communicate. When clients join a new network, they send a message requesting an IP address to 255.255.255.255. This is the equivalent of entering a room and shouting to get everyone’s attention. Since I had created a rule to only allow DHCP traffic on a specific subnet that isn’t 255.255.255.255, the rule didn’t match, and UFW silently dropped it and didn’t allow the messages to reach the DHCP server. In other words, my rule was too restrictive, and DHCP couldn’t allocate IP addresses to network devices.

The fix

When I saw the problem on one of the devices in my network, I first thought the network cable was damaged, so I swapped the cable with one from another device that worked, but the problem didn’t go away, so I knew it had to be something else. I checked the network settings and noticed that the device didn’t have an IP address, which meant there was something wrong with DHCP. I logged into the DHCP server, ran a few troubleshooting commands and realised that the problem wasn’t on the server itself, so it had to be clients failing to reach the server.

Whenever I encounter a problem in code or in my network, the first question I ask myself is, “What changed recently?”. I remembered modifying the firewall rules the day before, and when I looked at them it hit me, I had configured the firewall to only allow DHCP traffic on the subnet and not on the broadcast address.

To fix it, I simply deleted the rule and added another without the subnet:

This accepts DHCP traffic from any address. The rule feels like a security hole, which is why I changed it in the first place, but it isn’t because of the way DHCP works. To get IP addresses via DHCP, devices have to already be in the same network; devices outside the network can’t send DHCP requests to the server, so I’m only opening up traffic that’s already on the network. If a malicious person is already there, then I have bigger problems.

Conclusion

The lesson for me here is to spend more time thinking about the underlying protocols I want to implement firewall rules for before applying the firewall rules.

Why my ingress-nginx failed after reboot, and how I fixed it with static IPs in MetalLB

Vuyisile Ndlovu — Tue, 06 May 2025 08:39:38 +0000

The problem

As you know, I run a self-hosted Kubernetes Homelab. Recently, I had a problem where I couldn’t reach some services running in the cluster after restarting the Kubernetes servers. The problem didn’t happen every time I restarted the servers, but whenever it did occur, it was always after a server restart. Ingress-nginx is the service that got affected specifically. I have it configured to request a specific IP address, but sometimes after the server restarts, it fails to get the IP address from MetalLB, the tool I use to manage and allocate IP addresses to the different services running in the cluster. When I first set up the cluster, I configured MetalLB with a pool of IPs it could assign to services. There were enough IP addresses for all the services and more to spare, so this wasn’t an IP address exhaustion problem. A service might grab a previously assigned IP because of the way MetalLB assigns IPs; it allocates IPs from a shared pool, and on reboot, services might start in a different order, leading to another service taking ingress-nginx’s IP.

Solution

To debug the problem, the first thing I did was to check if the cluster was healthy. All server nodes were up and running, deployments were running okay, and application and pod logs looked fine. I ran kubectl get svc to check on the network services and realised that the ingress nginx controller’s IP address column was stuck in “pending” state. This meant that it had failed to get its reserved IP address because another service had taken the IP address it wanted. As a quick fix, I stopped the service that had taken up the ingress-nginx’s IP and the IP address was immediately assigned to ingress-nginx. This worked until the server restarted again, so I needed a permanent solution.

To resolve this IP address allocation race condition, I created IP addresses for each load balancer in the cluster instead of having the load balancer get its IPs from a shared IP pool. This way, the load balancers have reliable IP addresses that survive server restarts. Here’s how I created a static IP for ingress-nginx in MetalLB:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ingress-nginx
  namespace: metallb-system
spec:
  addresses:
    - 10.0.0.8/32

---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2-advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
  - ingress-nginx

When adding individual IPs and not an IP range to a pool like what I did above, MetalLB requires the IP to have a CIDR. 10.0.0.8/32 represents a single IP.

Next, I updated the ingress-nginx deployment to request that specific IP address:

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.12.1
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    metallb.universe.tf/address-pool: ingress-nginx

Adding the metallb.universe.tf/address-pool: ingress-nginx annotation to the service makes it request the 10.0.0.8 IP address from MetalLB

Takeaways

Dynamic IPs can cause race conditions. Relying on dynamically assigned IP addresses can lead to service conflicts after reboots due to the non-deterministic order in which services come online.
Static IPs increase reliability. Assigning static IPs to critical services like ingress controllers ensures predictable behavior and avoids conflicts on server or network reboot.
MetalLB is a joy to work with. MetalLB supports both shared IP pools and dedicated IP configurations, making it easy to set up and adjust to meet my needs.
Self-hosting is hard. Unlike managed cloud services, self-hosting requires handling networking, IP management, hardware, power issues and fault tolerance. Thinking about and solving these issues deepens my understanding of system admin in general and Kubernetes internals specifically.

S3 Lifecycle Rules for WordPress Backups: Deleting files older than 90 days

Vuyisile Ndlovu — Sat, 03 May 2025 19:00:58 +0000

Since I started my self-hosted homelab, I’ve been thinking of ways to back up all my data. The first thing I chose to back up automatically is this blog using a script I wrote. The script creates a weekly backup of the WordPress database and the media files into compressed archives and uploads them to AWS S3. At the time of this post, the backup files are approximately 1GB each, and S3 charges $0.02/GB, which is a good deal to me.

To keep S3 costs low, I set up the bucket to automatically delete backup files more than 90 days old using AWS S3’s Lifecycle Management Rules. This way, even if the size of my backup files increases, I won’t have multiple old backups wasting space and raising storage costs in S3. I’ll show you how I set this all up in this post.

Enable Lifecycle Management

In the AWS console, navigate to your S3 bucket and click on the Management Ta b.

Under Lifecycle configuration, click “ Create lifecycle rule ” to create a new lifecycle rule. Lifecycle rules are actions you want AWS S3 to take on your files during their lifetime, such as moving them between storage classes or deleting them after a while.

Next, give the lifecycle rule a descriptive name, and specify whether you want the rule to apply to the entire bucket or specific objects. If you choose to apply the rule to all bucket objects, click the check box that is presented and move on to the Lifecycle rule actions.

Check the “Expire current versions of objects” box to make AWS delete or expire the files after some time. In versioned buckets, expiring an object adds a delete marker to the object, similar to a soft delete. In buckets without versioning enabled, expiring an object deletes it from the bucket. In my case, the bucket isn’t versioned, so this option is good for me. In the next section, set the days to wait before expiring objects. In the image below, I chose 90, this means that files older than 90 days will be automatically deleted.

Conclusion

Deleting old backups using lifecycle management in S3 is cost-effective and simple to set up. I’ll probably use some version of this approach for future backups. For example, I could use lifecycle rules to automatically transition older backups to cheaper storage classes before expiring them. How do you rotate backups? Let me know in the comments.

The History of Virtual Machines and Containers

Vuyisile Ndlovu — Tue, 22 Apr 2025 10:00:24 +0000

Introduction

Virtual Machines(VMs) and containers are at the heart of modern computing, powering everything from cloud infrastructure to local development environments. The concepts we now know as VMs and containers have been around since the early days of computing and were shaped by decades of research, hardware constraints and industry needs.

This post is my attempt to provide a brief history or timeline that covers the evolution of VMs and containers, their common origins and how they developed into the modern tools we use today.

Key Concepts and Terminology

VMs and containers were designed to enable multitenancy — running multiple workloads on the same machine by abstracting the underlying host. They achieve this using different approaches:

Kernel : The Operating System’s main component that interacts with the hardware. It manages system resources like CPU, RAM and connected devices. If an Operating System is a car, the kernel is its engine.

Virtual Machines : Emulate physical machines and real hardware using control software called hypervisors.

Containers : Share the host kernel but isolate applications at the process level.

Hypervisor : Software used to manage virtual machines in a host

Virtual Machine Monitor : Another name for a hypervisor, software that allows running multiple virtual operating systems on the same physical hardware.

x86 : A popular family of CPU architectures used in personal computers and servers.

Paravirtualization : A virtualization technique where the guest OS is modified to make it aware of the virtualization layer, allowing it to make explicit calls to the Hypervisor for some instructions.

POSIX — Portable Operating System Interface, A set of standards for UNIX-based systems to ensure compatibility between operating systems.

Namespaces — An isolation feature that allow processes to have their view of certain system resources such as filesystems, network interfaces and processes without being affected by other processes.

Early Foundations (1960s-1980s)

In the early computing days, software was written for a particular hardware architecture. When the hardware changed, software had to be re-written and needless to say, this was unsustainable. To address this problem, researchers proposed keeping the kernel simple, stable and managed by a few experts. This would allow the kernel to handle hardware interactions while minimising what programmers needed to know.

During this time, key developments included:

Improved memory isolation in hardware.
Early timesharing systems that emphasized isolation
Rise of Personal Computers led to the decline in VM research

The Decline and Revival of Virtual Machines (1990s-2000s)

Although VMs existed in the 1980s and 1990s, interest waned during this period. The term “virtual machine” was even repurposed by Java and Smalltalk, something that was indicative of how dead the original concept of a VM was in this period. However, the late 1990s saw renewed interest due to research projects that sought to make Operating Systems more portable.

The Disco Project (1997)

A Stanford University project that explored using Virtual Machines as a way to run operating systems on different types of hardware without extensive modifications. The project prioritised portability over security or performance.

VMWare (1999)

The team behind the Disco Project started VMWare a year later and in 1999 released a workstation product and two server products (VMWare GSX Server and VMWare ESX).

The VMWare team faced a challenge virtualising the x86 architecture of the time because x86 processors (from Intel and AMD) weren’t built for virtualization.

Normally, a Virtual Machine Monitor(VMM) or Hypervisor relies on a method called trap-and-execute to control how guest operating systems interact with hardware. VMWare couldn’t trap all the instructions because some could bypass their VMM.

The x86 architecture had a problem:

some instructions it processed were sensitive but not privileged
Privileged instructions such as changing memory settings trigger an error ( a trap ) when run in user mode. When this happens, the VMM catches the error and safely handles it( execute ).
Sensitive instructions have potential system stability and security issues. These instructions don’t always trigger a trap, so they could be run without the VMM noticing, introducing potential security issues.

VMware’s solution:

Trap-and-Execute where possible. For privileged instructions that triggered traps, VMware would handle them using traditional virtualization techniques.
Dynamic Binary Translation. For sensitive and tricky instructions that didn’t always trap, VMware rewrote the instructions on the fly before execution. Doing this allowed guest operating systems to run more efficiently, without realising they were virtualized.
This approach allowed running guest operating systems unmodified and was a breakthrough at the time. Later, Intel and AMD created processor extensions in their x86 CPUs to provide hardware support for virtualization making VMWare’s workarounds unnecessary.

Denali (2002)

A University of Washington project that introduced paravirtualization, a technique that modified a guest OS to work more efficiently with a hypervisor. Since x86 hardware lacked native virtualization support at the time, paravirtualization offered a workaround by modifying CPU instructions. By making the guest OS aware of the virtulization layer,it could communicate more efficiently with the hypervisor. Instead of attempting to execute restricted instructions directly, the modified guest OS would make explicit calls to the hypervisor, allowing it to handle operations that required hardware-level execution.

Xen (2003)

A University of Cambridge project that used paravirtualization techniques with an emphasis on keeping user applications unmodified. Unsafe or privileged calls were replaced with its own hyper calls. Xen introduced features that allowed tracking the resource usage of each guest, something that directly led to the creation of AWS EC2 a few years later.

x86 Hardware Virtualization Extensions (2004/2005)

Due to the rise in the popularity of virtual machines and the complexity associated with running them on x86 hardware, AMD and Intel introduced (independently of each other) extensions to their processorsin the mid 2000s enabling hardware support for virtualization. These extensions allowed running VM code directly and trapped any sensitive instructions making paravirtualization or binary translation unnecessary.

AMD-V – the virtualization extension added to AMD processors around 2005. AMD-V debuted with AMD Athlon 64, Opteron and Turion 64 processors. It aimed to eliminate the need for binary translation.

Intel VT-x – the virtualization extension first introduced to Intel processors in 2005 in Pentium 4. It allowed running hypervisors like VMware and KVM efficiently without using complex workarounds like Binary Translation. VT-x allowed guest OSes to run in kernel mode safely and introduced features that intercepted and emulated privileged system calls.

Hyper-V (2008)

In 2008, Microsoft released Hyper-V; their own Hypervisor that took advantage of the x86 virtualization extensions created by Intel and AMD.

Decline of VMs and the Rise of Modern Containers

By the late 2000s, container-based solutions started gaining traction, reducing the reliance on hypervisors like QEMU+KVM, VMWare, Hyper-V and Xen.

The Rise of Modern Containers (1982-2013)

Containers evolved from multiple isolation technologies that were developed around the same time as VMs, including chroot, FreeBSD Jails , resource controls, namespaces and zones.

POSIX Capabilities (1990s)

In the 1990s, thePOSIX Group proposed the POSIX.1e standard to add capabilities to the traditional UNIX security permissions. Capabilities allowed users to start processes or perform tasks using a subset of root privileges. The goal of the standard was to split root permissions into units or subsets that could be managed easily and assigned selectively to processes.

The proposal was never accepted and later abandoned. Despite this, the Linux kernel introduced capabilities in version 2.2 in 1999. The Linux implementation wasn’t an exact match to the POSIX.1e proposal but it retained the core principle of splitting root privileges into smaller units or capabilities. Linux is the only major OS to implement in a form similar to POSIX.1e. It expanded them over time to make them more useful to modern security models.

Early Isolation Techniques

Chroot and FreeBSD Jails (1982-2000)

UNIX v7 introduced Chroot, a program that allowed creating virtual filesystems by changing the root directory for running processes. Chroot limits a process to a specific directory, effectively changing the process’ world view and limits the process and its children to that new directory and its subdirectories.

In 2000, FreeBSD 4.0 introduced Jails, enhancements to chroot that extended chroot to isolate not just the file system, but also network interfaces, process visibility and user credentials. Each jail could have its own root user with full permissions inside the jail and no permissions outside the jail.

Linux VServer and Virtuozzo (Early 2000s)

Linux-VServer and Virtuozzo were early container-like virtualization technologies that introduced process isolation and resource control mechanisms. Linux-VServer was a lightweight virtualization project that enabled multiple isolated environments to run on a single Linux Kernel. Virtuozzo, developed by Parallels was a commercial container-based virtualization platform focused on resource sharing in hosting environments. They introduced mechanisms to set limits on resources such as CPU, RAM, Disk, and other resources.

For example, the projects introduced the following isolation mechanisms:

Memory Isolation – Implemented control systems that prevented containers from accessing each other’s memory.
Process Isolation – Ensured that a process in one container could not see, interact or interfere with processes from other containers or the host.
Network Isolation – Enabled isolation of network addresses, allowing processes (or containers) to have their own sets of IP addresses and network interfaces.

This isolation work laid the groundwork for modern containers.

File System Mount Namespaces (2002)

Linux introduced its first namespace, the mount namespace in 2002. Mount namespaces enabled creating isolated file system environments where processes could mount and unmount file systems without affecting the host system or other processes. The ability to isolate filesystems this way enabled processes to have different views of the filesystem, a crucial step toward isolating container environments from one another.

Class Based Kernel Resource Management (2003)

An early framework that introduced the idea of classifying processes into groups or classes and assigning resources to each class as opposed to per-process resource limit. This concept played a significant role towards modern containers by influencing kernel features like cgroups, and namespaces which form the foundation of containers today.

Solaris Zones (AKA Solaris Containers) (2004)

At around the same time as the developments in Linux, Solaris, a UNIX operating system introduced Zones, also known as Solaris Containers that isolated processes into groups that could only interact with processes within the same group.

Process Containers (2006/2007)

Google used a system called Borg(precursor to Kubernetes) to manage its massive infrastructure. Borg, developed in the early 2000s allowed Google to run many tasks across thousands of machines in isolated containers. They needed an efficient way to manage, control and isolate resources, so around 2006, Google engineers began developing process containers , an early implementation of resource isolation and control for running workloads efficiently on shared infrastructure.

This work on process containers evolved and was later renamed cgroups( Control Groups) when it became a part of the Linux kernel in 2007. cgroups allowed fine-grained control over CPU, memory, I/O and other resources at the group level. This “class-based” or group-based management approach ensured that resources in one group did not starve resources in another group or class. Cgroups became the foundation for Docker, Kubernetes and modern container runtimes like containerd and CRI-O.

Additional Linux Kernel Namespaces (2006-2013)

Between 2006 and 2013, the Linux kernel introduced additional namespaces that allowed isolation in process IDs, inter-process communication, network stacks and user IDs. User namespaces were the last namespace to be added. They allow unprivileged users to create a namespace or isolated environment that allows running privileged processes within the namespace while disallowing running them outside the environment. This enables a process to have root-like privileges within its own namespace without actually having those privileges outside of it in the host.

The Modern Container Ecosystem (2008-Present)

LXC (2008) – One of the first Linux container implementations, providing a userspace interface for managing containers.
Docker (2013) – Popularised container usage with an easy-to-use interface, standardized images and an ecosystem that simplified deployment.
Container Orchestration (2014-2015)
- Docker Swarm (2014) – Docker began work on Swarm, an orchestration tool for managing containerised applications
- Kubernetes (2015) – Google built and open-sourced Kubernetes in 2015, it is now the de facto standard for orchestrating large-scale containerised applications.
- LXD (2016) – Developed by Canonical, LXD extended LXC by introducing a more powerful container management interface with better security and networking features.

Security Concerns

Despite their advantages, VMs and containers are not immune to vulnerabilities. In 2018, critical flaws like Spectre and Meltdown exposed security risks in both technologies, emphasizing the need for ongoing improvements.

Conclusion

I enjoyed looking into the history of VMs and containers and learning how the technology behind them developed at the same time. Let me know in the comments how you use containers or virtual machines. Thanks for reading.

Resources

If you’re interested in learning more about the history of VMs and contaiers, consider looking at the resources listed below:

DEV Community: Vuyisile Ndlovu

How to use Azure Key Vault with the Azure CLI

Creating a Key Vault

Insert a Secret

Retrieve a Secret

Update an Existing Secret

List All Secrets

Delete a Secret

Self-Hosting Planka in Kubernetes: A Lightweight Trello Alternative

Intro

Why I chose Planka

Kubernetes Set Up

Defining the Helm Repository

Managing Secrets with ExternalSecrets

Creating the Helm Release

How I use Planka

What I don’t like about Planka

Conclusion

Rollbacks in ArgoCD

The GitOps Philosophy

Rollback in ArgoCD

Conclusion

Setting Up a Remote Backend for Terraform Using Azure Storage

Terraform Remote State Using Azure Storage

1. Create Storage Account and Container

2. Configure Terraform to Use the Remote Backend

3. Initialize Terraform

4. Verify

Next Step: Team Access

Conclusion

GitOps with ArgoCD

Installing Argo CD

Accessing the UI

Getting the Default Admin Password

Key Concept: The Application Object

Thoughts so far

An intro to Helm

Installing Helm

Key Concepts

Why Use Helm

What I’m Doing Next

From HDD to SSD: How I fixed an I/O Bottleneck in a Kubernetes Node

Diagnosing and Fixing an I/O Bottleneck in My Kubernetes Node

The Problem

The Plan

Steps I Took

Replacing the drives

The Result

Takeaway

May AWS Tech Meet at FlexiWork

The venue: FlexiWork, a relaxed, coworking space

Hildah Machando — AWS Fundamentals: Your Guide to Certification, Cloud Building, and Security

My Talk — Cloud Skills, No Cloud Required

Conversations I Had

Takeaways

What’s Next

How A Bad Firewall Rule Broke My Network

DHCP Protocol — Where I got it wrong

The fix

Conclusion

Why my ingress-nginx failed after reboot, and how I fixed it with static IPs in MetalLB

The problem

Solution

Takeaways

S3 Lifecycle Rules for WordPress Backups: Deleting files older than 90 days

Enable Lifecycle Management

Conclusion

The History of Virtual Machines and Containers

Introduction

Key Concepts and Terminology

Early Foundations (1960s-1980s)

The Decline and Revival of Virtual Machines (1990s-2000s)

The Disco Project (1997)

VMWare (1999)

Denali (2002)

Xen (2003)

x86 Hardware Virtualization Extensions (2004/2005)

Hyper-V (2008)

Decline of VMs and the Rise of Modern Containers

The Rise of Modern Containers (1982-2013)

Managing Secrets with `ExternalSecrets`