
Alexander is a writer, traveler, and serial digital entrepreneur. He’s the founder of the Tushi, the Gen X personal growth newsletter Further, and offers small business advice at Unemployable.

Twitter

Linkedin

Facebook

Director and Chief Evangelist

Alexander Hipp


Anil is a content-obsessed marketer who loves driving organic traffic for outstanding companies. He is also the creator of Hack the Content, co-host of The Runner, and owner of several digital commerce sites.

Managing Partner

Anil Vugels


Monika is a writer, musician, and content strategist with a passion for language. When she isn’t helping clients, you can find her writing songs, hiking in a northern forest, or furiously journaling.

Director of Operations

Ann Monika

Programmer / Founder / Student

Tim Schupp


Every now and then, when setting up a simple staging environment, the need for a quick-setup database that retains state consistently arises. In such situations, I often lean towards MariaDB, specifically utilizing the [Bitnami Helm Chart](https://github.com/bitnami/charts/tree/main/bitnami/mariadb), with slight tweaks to achieve the following:

- An auto-set, namespace setup
- Accessibility through a single host subdomain + port
- Easy hourly backups to a specified host path
- Exposure through TCP to the cluster host

### Prerequisites

This post is operating under the assumption that you have a `microk8s` Kubernetes cluster already set up, complete with `cert-manager`, `ingress`, `dns` and an active and configured `letsencrypt-prod` cluster issuer.

> Note: To jumpstart your setup, you might find [this Blog Post on Microk8s Private Cluster Setup](/blog/microk8s-on-vps) quite helpful.

### TL;DR 

For a swift deployment of this configuration:

1. [Grab this script](https://github.com/tbscode/tims-blog-posts/blob/main/assets/create_mariadb.sh)
2. Then run it as follows:

```bash
./create_mariadb.sh \
  RELEASE_NAME="<release-name>" \
  K8_NAMESPACE="<installation-namespace>" \
  DB_USERNAME="<db-username>" \
  DB_PASSWORD="<your-super-secure-password>" \
  DB_NAME="<db-name>" \
  TARGET_PORT="<desired-port>" \
  HOST_BACKUP_PATH="<your host backup volume>"
```


> Remember to expose the desired port through your firewall with a `sudo ufw allow $TARGET_PORT` command.
  
#### Uninstallation Process:

Execute the following command: 

```
microk8s helm uninstall $RELEASE_NAME
```

#### Connecting to the Database

Use this command to establish a connection to the database:

```bash
docker run -it --rm  mysql mysql --host <your-host-domain> --port <your-port> --user <your-user> --password --protocol=TCP
```

Or use this with `--network="host"` if your testing a local server.
Remember to enter the admin password when prompted.

#### Backing up the Database

Here's a simple docker command for accomplishing this:

```bash
docker run --network="host" --rm mysql:5.7 mysqldump -h localhost -P 30004 -u <your-user> -p<your-admin-password> --protocol=TCP <your-db-name> > backup.sql
```

#### Host Backup Strategy

A straightforward example of a cron job that allows your database to be backed up regularly is created as follows:

1. First, create a secret to hold your MariaDB credentials:

```bash
microk8s kubectl create secret generic mariadb-creds --from-literal=password='$DB_PASSWORD' --from-literal=username='$DB_USER' -n $K8_NAMESPACE
```

2. Then, define a CronJob in a yaml file:

```yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          volumes:
            - name: backup-volume
              hostPath:
                path: "$HOST_BACKUP_PATH"
          containers:
            - name: backup-container
              image: mysql:5.7
              volumeMounts:
                - name: backup-volume
                  mountPath: /backup
              env:
                - name: MYSQL_PWD
                  valueFrom:
                    secretKeyRef:
                      name: mariadb-creds
                      key: password
                - name: MYSQL_USER
                  valueFrom:
                    secretKeyRef:
                      name: mariadb-creds
                      key: username
              command: ["sh", "-c", 'mysqldump -h database-host -P 30004 -u $MYSQL_USER --protocol=TCP database-name > /backup/backup-$(date +%Y%m%d-%H%M%S).sql']
          restartPolicy: OnFailure
```

With this configuration in place, you would have a CronJob that executes hourly backups of the database.



This straightforward guide will walk you through deploying and exposing a basic MariaDB database on your microk8s Kubernetes cluster.

MariaDB on Kubernetes with Backup Cron-job


> Are you tired of overpriced package registries? Rapidly deploy your own git and package registry - with [Gitea](https://about.gitea.com/) - using [their helm chart](https://gitea.com/gitea/helm-chart).

### Prerequisites

This post assumes that you have a `microk8s` cluster set up with `cert-manager`, `ingress`, and `dns` configured, and a cluster issuer `letsencrypt-prod` ready.

> To get started, feel free to follow my [Blog Post on Microk8s Private Cluster Setup](/blog/microk8s-on-vps).

## Setting it Up

> **Please note** - This is meant for a quick temporary private package. There is **no persistence intended.**

For easy installation, you can use [this simple script](https://github.com/tbscode/tims-blog-posts/blob/main/assets/install_gitea_microk8s.sh)

```bash
./install_gitea_microk8s.sh \
  K8_NAMESPACE="<installation-namespace>" \
  RELEASE_NAME="<release-name>" \
  ADMIN_USERNAME="<...>" \
  ADMIN_PASSWORD="<...>" \ 
  INGRESS_HOST="<host-url>"
```

In the above script, `$INGRESS_HOST` represents a subdomain you've configured a DNS entry for, pointing to your server, for instance: `my-git.example.com`.

### Configuration

First, to ensure that this doesn't consume too many resources, we disable the high-availability database and use the default one instead.

```bash
microk8s helm install $RELEASE_NAME gitea-charts/gitea \
    -n $K8_NAMESPACE \
    --set postgresql-ha.enabled=false \
    --set postgresql.enabled=true \
```

Next, we establish some credentials for our default admin user:

```bash
    --set gitea.admin.username="$ADMIN_USERNAME" \
    --set gitea.admin.password="$ADMIN_PASSWORD" \
```

We then enable and configure the ingress. Please note we are increasing the `proxy-body-size` to 1GB to allow us to push larger packages.
```bash
    --set ingress.enabled=true \
    --set "ingress.annotations.kubernetes\.io/ingress\.class=public" \
    --set "ingress.annotations.cert-manager\.io/cluster-issuer=letsencrypt-prod" \
    --set "ingress.annotations.nginx\.ingress\.kubernetes\.io/proxy-body-size=1g" \
    --set ingress.hosts[0].host="$INGRESS_HOST" \
    --set ingress.hosts[0].paths[0].path=/ \
    --set ingress.hosts[0].paths[0].pathType=Prefix \
    --set ingress.tls[0].secretName="git.$RELEASE_NAME-tls" \
    --set ingress.tls[0].hosts[0]="$INGRESS_HOST" \
```

> To make packages of the admin user private, sign in at `$INGRESS_HOST`, navigate to Settings > Profile > Visibility, and set it to Private.

### Uploading a Package

You can push a package to a path under your Gitea user as follows:

```bash
echo "<your-admin-password" | docker login $INGRESS_HOST -u <your-gitea-admin> --password-stdin
docker tag <image-id> $INGRESS_HOST/<your-gitea-admin>/<some-package-name>
```
### Authenticating Deployments for Pulling Images

It's essential to authorize your deployments to pull your private container images. You can create a simple image pull secret in your Helm chart as outlined below.

```yaml
kind: Secret
type: kubernetes.io/dockerconfigjson
apiVersion: v1
metadata:
  name: dockerconfigjson-github-com
  namespace: {{ .Values.rootNamespace }}
stringData:
  .dockerconfigjson: >
    {{
      (
        dict "auths"
        (
          dict "$INGRESS_HOST"
          (
            dict "auth" .Values.registryAuth.token
          )
        )
      )
      |
      toJson
    }}
{{- end }}
```

> If you're using Github packages, for instance, `$INGRESS_HOST` would be `ghcr.io`

Create a token by Base64 encoding the `user:password` string:

```bash
echo "<gitea-admin>:<gitea-admin-password" | base64
```
This will allow you to pull from your private repositories.

### Setting up gitea action runners via helm



This guide will demonstrate how you can effortlessly host Gitea on a private Kubernetes cluster and utilize it as a package registry.

Self-Hosted Git Server with Gitea on Kubernetes


> Discover the cheapest and easiest way I've found to create personal Kubernetes clusters.

This blog post provides a step-by-step guide to setting up a private Kubernetes cluster on a Virtual Private Server (VPS), with the following features ready and configured:

- VPS firewall setup to expose HTTP/HTTPS & kubeapi server
- MetalLB configured for load balancing and exposing VPS IP
- Ingress and cert-manager setup for quick & automatic TLS management
- Kubeapi server configured for restricted remote access

The **prerequisites** for this tutorial are: **A VPS with a Public IP**, **A domain with a configurable DNS**.

## Step 1: Create a base user

Connect to your VPS. In a terminal, create a user and add them to the sudoers.

```bash
adduser <user-name>
usermod -aG sudo <user-name>
```

## Step 2: Create SSH keys

On your local machine, create SSH keys to access the server.
Set a secure password for the key.

```bash
ssh-keygen -b 2048 -t rsa
chmod 600 <key-file> <key-file>.pub
```

Copy the content of `<key-name>.pub` to your VPS at `/home/<user-name>/.ssh/authorized_keys`.

Now we edit the ssh config to require the ssh key, edit `/etc/ssh/sshd_config`

```bash
PasswordAuthentication no # yes before
PubkeyAuthentication yes # no before
```

Then restart the ssh service `service ssh restart`

> Note: these are minimal ssh setup setups and depending on the environment extra steps should be taken to make ssh more robust agains outside attacks.

## Step 3: Set up and enable the firewall

Set up the firewall to allow SSH, HTTP, HTTPS connections and also expose port `16443` which will be used to access the Kubeapi server.

```bash
ufw allow ssh
ufw allow http
ufw allow https
ufw allow 16443
ufw enable
```

Now disconnect from your server and reconnect as the new user:

```bash
ssh -i "<private-server-key>" <user-name>@<server-IP>
```

## Step 4: Install and set up microk8s

```bash
sudo snap install microk8s --classic --channel=1.28
sudo microk8s enable rbac
sudo microk8s start
microk8s enable ingress dns hostpath-storage cert-manager
```

If you want to use the current user to manage microk8s; this is not recomended for production clusters

```
sudo usermod -a -G microk8s <your-user>
```

Now we create a default cluster issuer: `letsencrypt-prod`:

```bash
microk8s kubectl apply -f - <<EOF
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
spec:
 acme:
   email: <your email>
   server: https://acme-v02.api.letsencrypt.org/directory
   privateKeySecretRef:
     name: lets-encrypt-priviate-key
   solvers:
   - http01:
       ingress:
         class: public
EOF
```

We also need to enable some additional rules for the firewall ([see this github comment](https://github.com/canonical/microk8s/issues/2418#issuecomment-877350375)):

```bash
sudo ufw allow in on cali+
sudo ufw allow out on cali+
```

To check for general configration issues use `microk8s inspect`
This can give you some easy setup configuration infos and warnings such as:

To enable ip forwarding:

```
sudo iptables -P FORWARD ACCEPT
sudo apt-get install iptables-persistent
```


No to konfigure kubeserver access through the host dns, edit `/var/snap/microk8s/current/certs/csr.conf.template`:

```bash
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
DNS.6 = k8s.<your-domain>
```

Refresh the server certificate:

```bash
sudo microk8s refresh-certs --cert server.crt
```

View the updated client certificate: `microk8s config > kubeconfig.yaml`.
Open the `kubeconfig.yaml` and edit the `server:` entry.

```bash
...
- cluster:
    certificate-authority-data: XXXXXXXXCENSOREDXXXXXXX
    server: <pub-IP> <---- put k8s.<domain> here
...
```

Now you can connect to the Kubernetes cluster from your local machine:

```bash
KUBECONFIG="./kubeconfig.yaml" kubectl get pods --all-namespaces
```

## Step 5: Setting Up MetalLB

First, prepare `<your-domain>`. 
Create a specific or one wildcard DNS entry:

```bash
<your-domain> -> <vps-ip>
*.<your-domain> -> <vps-ip>
```

Enable `metallb` via `microk8s enable metallb:<your-ip>-<your-ip>`.

To make `metallb` work correctly, apply the patch described in [this GitHub comment](https://github.com/canonical/microk8s/issues/824#issuecomment-1003284063).


```bash
#!/bin/sh

command -v kubectl > /dev/null 2>&1 && KUBECTL=kubectl
command -v microk8s.kubectl > /dev/null 2>&1 && KUBECTL=microk8s.kubectl

INGTMPFILE=$(mktemp -t ingress_daemonset.XXXXXXXX)

trap "rm -f ${INGTMPFILE}" 0 1 2 3

${KUBECTL} -n ingress get daemonset nginx-ingress-microk8s-controller -o yaml | \
    sed -e 's|- --publish-status-address=.*|- --publish-service=$(POD_NAMESPACE)/ingress|' > ${INGTMPFILE}

${KUBECTL} diff -f ${INGTMPFILE}
if [ $? -eq 0 ]; then
    echo "No changes need to be made"
else
    ${KUBECTL} apply -f ${INGTMPFILE}
fi
```

You can now use LoadBalancer nodes that distribute the `<VPS-IP>`.

## Some Tips

#### Enabling tab completion for microk8s

`vim ~/.bash_aliases`

```bash
# add the fllowing
alias kubectl='microk8s kubectl'
export LC_ALL=en_US.utf-8
export LANG=en_US.utf-8
source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)  
```

#### Patching External Traffic Policies

```bash
kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
```

#### Testing the preservation of client IP adresses

```bash
kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
```

## Conclusion

You now have a Kubernetes cluster with services that can be exposed via ingress, have a load balancer, and cert manager ready. You should be able to access these services through a host domain. 

> The possibilities are endless from here ;^)

You even have the option to connect this to multiple VPSs to extend your cluster. More on that in a future blog post.


A step-by-step guide to setting up a fully configurable private Kubernetes cluster

Setting up a Private Kubernetes Cluster on Your Own VPS Using Microk8s


> UPDATE: We made 2. Place! 🥳 Checkout [the hackathon page](https://devpost.com/software/tim-s-stack-anystack).

<iframe width="560" height="315" src="https://www.youtube.com/embed/_06vvSltvvY?si=ZMTgD9l2TFNTTa_2" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

> Checkout the [full stack code](https://github.com/tbscode/tims-stack-anystack) on my repo

## Introduction

I recently participated in the Bunnyshell hackathon, where I successfully orchestrated a dynamic cross-platform web app stack. I want to share with you in detail my development process, core features, and the benefits of this stack.

This stack is primarily designed for dynamic, real-time web apps, with a specific inclination towards mobile clients. One of the prominent features is that any changes made in the backend can be directly and instantly transmitted to the clients via a WebSocket connection, thanks to Redux for smooth state management.

## Architecture

I used a Docker container-based architecture using Helm for my application. Docker simplifies the process of managing my application's lifecycle, while Helm assists in deploying my Docker images into a Kubernetes cluster.

Here is an image representation of my stack's architecture:

![stack overview](/static/assets/overview_graph.png)

## Building the Stack

The stack incorporates:

- **Django Backend**: Django is utilised for the backend due to its simplicity and rapid development capabilities. Features like Celery for task management and DRF Spectacular for API documentation are added advantages.

- **Next.js + React Frontend**: Next.js powers the frontend, providing performance benefits, SEO capabilities, and better developer experience.

- **Postgresql & Redis**: They act as primary databases for data and celery respectively.

- **Documentation**: Pdoc3 was used to generate code documentation from backend code.

## Configuring the Stack on Bunnyshell

Bunnyshell significantly simplifies cloud management and deployment automation making it a breeze to set up a Kubernetes cluster and to deploy my application there.

In addition to this, I also exemplify setting up a private Microk8s cluster. Microk8s serves as a lightweight, lean, and efficient Kubernetes distribution, enabling quick and easy deployment of Kubernetes resources even on a low-end VPS.

I hope you find this stack setup helpful and efficient for your next big project. The GitHub repository contains all the code with appropriate comments and READMEs for further exploration.

Happy Coding!

## Technologies

The following table provides a quick overview of the key technologies integrated into the stack:

| Component | Technology | Purpose |
|-----------|------------|---------|
| Frontend  | Next.js + React | Rich UI |
|           | Tailwind CSS + DaisyUI | Styling |
|           | Redux | State Management |
|           | Capacitor | Native integrations and iOS/Android PWA export |
| Backend   | Django | Application Framework |
|           | Celery | Task Management |
|           | Django REST Framework + django_rest_dataclasses | REST API Development |
|           | DRF Spectacular | API Documentation |
|           | Django Channels | Managing WebSockets |
| Documentation | Pdoc3 | Code Documentation |
| Database  | PostgreSQL | Primary Backend Database |
|           | Redis | Broker for Celery and Django Channels |
| Containerization | Docker | Container Creation and Management |
| Deployment and Orchestration | Helm + Bunnyshell | Simplified deployment, Scaling and Management |

Each of these technologies has been selected for its specific capabilities that contribute to the efficient operation of the entire web application stack.

This article showcases a high-performing web app stack I created for a recent Bunnyshell hackathon, using Docker, Kubernetes, Microk8s, Django and Next.js.

Tim's Stack: Dynamic Cross-platform Web App Stack, deployed with Bunnyshell


Art Collective Simulator is a Game Dev Story–inspired simulation for the Vibrational Network, a Hamburg-based collective of musical and visual artists. I developed the codebase, while Giaco and Togrul contributed graphics and music.

The project evolved rapidly across several months, adding systems for characters, tasks, rooms, and events, alongside a modernized dynamic UI and mobile support.

### Feature timeline

#### Up to Jan 2020

- Task section
- Stat-based score generation
- Personalizable and random characters
- First event-related states (e.g., playing instruments)
- Event guest simulations
- Multiple rooms and teleports
- Completely updated dynamic UI

![Jam session gameplay](/assets/archive/game_play_new_jamsession.gif)

#### July

- Full game-state saving and loading
- Game phases
- Phase-based task selection
- Automatic task-based score generation
- Several new game tasks
- Android and iOS compatibility

![June/July gameplay](/assets/archive/june_july.gif)

#### June

- A* pathfinding
- Character stats such as Intelligence, Speed, Creativity
- Stats-based scoring system

#### May

Started programming the simulations with a complete task system. Tasks control entities by working through task queues. Tasks are selected based on player actions and game state.

![Simulation](/assets/archive/simulation.gif)

#### April

First visual prototype: basic isometric functionality — y-sorting, 2D movement, clickable tiles, character animation, and walk cycles.

![First gameplay](/assets/archive/first_game_play.gif)

#### March

I started developing the general framework using the Godot game engine. I outlined core concepts and scoped the project. The following diagrams show interactions between scores, entities, and events — the game's main components.

![Implementation](/assets/archive/implementation.jpg)

![Event hosting](/assets/archive/event_hosting.jpg)

#### February

I began the collaboration with the Vibrational Network in Hamburg — a collective of musical and visual artists. A friend reached out about developing a game; I was motivated to build my first isometric game: a Game Dev Story–style simulation with art.




A Game Dev Story–inspired isometric simulation for the Vibrational Network with evolving features from tasks and stats to events and rooms.

Art Collective Simulator


Retro Escape is a simple but challenging puzzle game. Guide a character from the start to the end tile while navigating walls, collecting items in the right order, and using them appropriately to solve each level.

However, that's not all — programmable blocks and recursive objects unlock new puzzle concepts and level designs.

Not only can you challenge your mind by solving tricky levels, you can also use your creativity to build unique ones. The built-in level editor includes all game blocks and offers a simple script language to interface with the programmable blocks. Created levels can be saved or shared via file and QR code.

The game was developed cross-platform using the LibGDX framework. It was written in Kotlin and uses the ZXING library for QR code detection. An Android beta was released featuring 30 levels.

### Gallery

![Retro Escape banner](/assets/archive/banner_rtesc_3.png)

![Retro Escape banner](/assets/archive/banner_rtesc_4.png)

![Retro Escape banner](/assets/archive/banner_rtesc_5.png)

![Retro Escape banner](/assets/archive/banner_rtesc_6.png)

![Gameplay](/assets/archive/retro_escape_play.gif)




A simple yet challenging puzzle game with programmable blocks, a level editor, and QR-based sharing. Built with Kotlin/LibGDX and ZXing.

Latest Posts

MariaDB on Kubernetes with Backup Cron-job

Self-Hosted Git Server with Gitea on Kubernetes

Setting up a Private Kubernetes Cluster on Your Own VPS Using Microk8s

Tim's Stack: Dynamic Cross-platform Web App Stack, deployed with Bunnyshell

Art Collective Simulator

Retro Escape