
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

Mastodon

Github

Programmer / Founder / Student

Tim Schupp


Since launching [Msgmate.io](https://msgmate.io) at the end of March, we've seen a lot of activity and received a myriad of feedback regarding its services and development.

However, the development of the direct Msgmate feature has been quite restricted. As a result, the updates that are visible to the public have also been very limited. Therefore, I am writing this article to shed some light on what's in store for Msgmate's future.

Please note that this article is somewhat technical in nature!

### Statistics

<div style="
    display: flex;
    flex-wrap: wrap;
    justify-content: space-around;
">
    <div style="
        background-color: #2C333A;
        padding: 20px;
        border-radius: 10px;
        width: 20%;
        text-align: center;
        min-width: 320px;
    ">
        <h2 style="color: #E88388; font-size: 24px;">
            <strong>Registered Users:</strong>
        </h2>
        <p>300</p>
    </div>
    <div style="
        background-color: #2C333A;
        padding: 20px;
        border-radius: 10px;
        width: 20%;
        text-align: center;
        min-width: 320px;
    ">
        <h2 style="color: #E88388; font-size: 24px;">
            <strong>Messages Exchanged:</strong>
        </h2>
        <p>6,331</p>
    </div>
    <div style="
        background-color: #2C333A;
        padding: 20px;
        border-radius: 10px;
        width: 20%;
        text-align: center;
        min-width: 320px;
    ">
        <h2 style="color: #E88388; font-size: 24px;">
            <strong>Tokens Used:</strong>
        </h2>
        <p>579,807+</p>
    </div>
    <div style="
        background-color: #2C333A;
        padding: 20px;
        border-radius: 10px;
        width: 20%;
        text-align: center;
        min-width: 320px;
        margin-bottom: 0 !important;
    ">
        <h2 style="color: #E88388; font-size: 24px;">
            <strong>Images Generated:</strong>
        </h2>
        <p>192</p>
    </div>
</div>

Since the alpha launch in March, we've had 300 users register. A total of 6,331 messages have been exchanged, using over 579,807+ tokens for prompts and completions. Furthermore, a total of 192 images have been generated.

> I've received feedback indicating interest in such a service.
> However, there were also critical comments concerning the current reliability and limited range of features available.

Rest assured, I am taking all feedback seriously and am actively working to bring you a better and enhanced user experience.

<strong style="color: red;">For now we limited msgmate.io alpha registrations untill we scaled our bot service to handle more chats in paralel</strong>


### Development in the Software Stack

My interest in large language models and their immediate applications in everyday life led me to initiate Msgmate as an experiment. Having considerable experience in development operations and infrastructure, I've managed to evolve my stack through several iterations based on the backend + infrastructure definitions I've developed over the years.

**Here's a look at the evolution of the stack:**

|Iteration|Link|Description|
|--|--|--|
|1|[Django Clean Slate](https://github.com/tbscode/django-clean-slate)|First stack iteration which involved Django + Webpack + React.|
|2|[Django NextJS Setup](https://github.com/tbscode/django_nextjssetup)|First experimental combination of Django + NextJS + React.|
|3|[Tiny Django](https://github.com/tbscode/tiny-django)|Evolution into the first version of 'Tim's Stack' initially dubbed 'tiny-django'.|
|4|[AnySearch Stack](https://github.com/tbscode/anysearch-stack)|First Live application using the stack for a submission to the tum.ai hackathon. The stack proved to be instantly viable for rapid development and easy deployment to microk8s Kubernetes clusters.|
|5|[Tim's Stack Anystack](https://github.com/tbscode/tims-stack-anystack)|Clean re-write of the stack, adding automation documentation, and more. During the Bunnyshell Jamstack Hackathon, I had the unique opportunity to|
|6|[Tim's Stack V2](https://github.com/tbscode/tims-stack-v2)|Dawn of a new age ;) Finalization work on the stack has started with the objective of making it out-of-the-box ready, usable state.|

All these updated work towards shaping the backend that msgmate.io uses and making it more robust and scalable! The bigger beta update planned for msgmate will be using the update Tims Stack V2 and there are plans for launching an android and ios app along side the new backend and interface.

### The Stack Won 2. Place!

As mentioned in the Above list [I've participated in a Hackathon using my Stack](https://blog.t1m.me/blog/tims-stack). 

> 🥳 Checkout [the hackathon page](https://devpost.com/software/tim-s-stack-anystack).

My efforts in the Bunnyshell hackathon didn't go to waste, as we managed to secure second place and win `$4000`, which I'll be reinvesting in the development of Msgmate.io!

### Msgmate.io Vision

I envision msgmate.io as the premier platform for innovators and casual users a like - who wish to engage with large language models - automated agents - and seamlessly incorporate them into their applications and everyday life. 
Msgmate should provide user-friendly developer APIs, websockets, and client applications. Fundamentally, interaction with language models and agents should be as straightforward as possible. Yet beneath the surface, the platform should offer abundant interfaces and configuration options.

### Development in the Team

Given my commitments to other projects, the time I can invest in Msgmate development is limited.
So, to advance this service further, I need more development power!

Using the prize money from the hackathon, I've already hired a NextJS + React developer to help me revamp the Msgmate interface. 

**However, I still need more developers motivated to work on LLm tooling and software.**

> I am looking for motivated (self) taught developers or students who have experience working on their own projects.
> You need to be a fast learner. Having knowledge of Docker, NextJS, React, Django would be advantageous but not a requirement.
> If you are interested in collaborating with us, get in touch at tim.timschupp@gmail.com

### Want to Stay Updated? Have Feedback or Issues to Report?

We've set up a simple form over at [`msgmate.io/newsletter`](https://msgmate.io/newsletter/). By signing up, you'll receive the next update straight to your inbox.

Feel free to add a comment to the signup request for any feedback or bugs. You can fill out the newsletter request as often as you like! Happy messaging with Msgmate.io!


A progress and state update on the development of my msgmate.io plattform

Msgmate.io Development Update Oct 2023


Different command I've used over the year to quickly create pdfs from local note files.

## Raw Pandoc

```bash
pandoc -V geometry:margin=1cm <mardown-file> -o <pdf-file>
```

## Pandoc + `wkhtmltopdf`-engine

- html support, e.g.: tables etc
- dynmaic margin

```bash
pandoc --pdf-engine=wkhtmltopdf -V papersize=a4 -V margin-top=0.1 -V margin-left=0.1 -V margin-right=0.1 -V margin-bottom=0.1 --from markdown-markdown_in_html_blocks+raw_html <markdown-file> -o <pdf-file>
```

## Quick TXT file to dense readable pdf

```bash
pandoc --wrap=preserve $1 -V geometry:margin=1cm -V fontsize=8pt -o $1.pdf -f markdown+hard_line_breaks
```

## Github markdown using `grip`

```bash
sudo snap install grip
grip <markdown-file>
```

then visit the browser page and export the page as pdf.
Or `curl -X <page> > rendered.html`.

## HTML to pdf with

```bash
pandoc --pdf-engine=wkhtmltopdf rendered.html -o <pdf-file>
```

## TXT to pdf with `enscript` and `ps2pdf`

```bash
find . -type f -name $1 | while read ONELINE; do enscript "$ONELINE" -p "$(echo "$ONELINE" | sed 's/.txt/.ps/g')"; done
find . -type f -name "$(echo "$1" | sed 's/.txt/.ps/g')" | while read ONELINE; do ps2pdf "$ONELINE" "$(echo "$ONELINE" | sed 's/.ps/.pdf/g')"; done
```

A collection of strategies to quickly produce pdf's from markdown files

PDF's from markdown, pandoc and more


Simulate a webcam even in your deveice doesn't have one!
The video input can even work to simulate video inputs on remote development devices.

You'll need to install and anable `v4l2loopback`.

```bash
sudo apt install v4l2loopback-dkms
sudo modprobe v4l2loopback
```

## Live video from screen

```bash
sudo ffmpeg -f x11grab -r 15 -s 1280x720 -i :1 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video2
```

## From Video File


```bash
ffmpeg -re -i <some-video>.mp4 -map 0:v -f v4l2 /dev/video2
```

> Where to go from here? Loop a video of you listen patiently in your zoom meetings? ;)

How to use `ffmpeg` to funnel screen or video data as video input.

Simulate secondary webcam on linux


This guide illustrates the steps required to build, push, and deploy a Next.js app on Kubernetes using docker files for defining development and production Next.js images. These docker compose files allow for the building and pushing of images, with a Next.js config able to export static files. A simple helm chart will create deployment, service, and ingress for exposing our app.

> Template repo containing all the required code and configs can be [found on my github](https://github.com/tbscode/nextjs-helm-template).

### Prerequisites

This tutorial can also be adapted to work with any managed cluster as I've been using similar setups to quickly deploy Next.js apps for a while.

For your cluster you'll need:

- `cert-manger` cluster issuer with name `letsencrypt-prod` setup.
- `nginx-ingress` installed.
- `helm` installed.
- Public IP and Host Url connected.

Further, a private container registry is required.

> If you don't have a Kubernetes cluster ready follow [My Blog Post on Microk8s Private Cluster Setup](/blog/microk8s-on-vps).

### 1. Start a Next.js App

Begin by creating a simple Next.js app:

```
npx create-next-app@latest
What is your project named?  frontend
Would you like to use TypeScript? Yes
Would you like to use ESLint?  Yes
Would you like to use Tailwind CSS?  Yes
Would you like to use `src/` directory?  No
Would you like to use App Router? (recommended)  Yes
Would you like to customize the default import alias (@/*)?  No
```

We named the app `./frontend` so the respective folder is created.

### 2. Dockerize the Application

Two docker files can be created:

1. [`./frontend/Dockerfile`](https://github.com/tbscode/nextjs-helm-template/blob/main/frontend/Dockerfile): A development docker file that mounts frontend `./frontend` into the container for hot-reload.
2. [`./frontend/pro.dockerfile`](https://github.com/tbscode/nextjs-helm-template/blob/main/frontend/prod.dockerfile): A production docker file that statically builds the entire application and Next.js in a container.

The development docker file is straightforward:

```Dockerfile
FROM node:16-alpine

WORKDIR /frontend
COPY ./package.json .

RUN apk add curl

RUN npm i --save-dev

ENTRYPOINT ["npm", "run", "dev"]
```

Here, we execute `npm i` and then `npm run dev`. When mounted to the host, the `./node_modules` directory will also be present on the host.

The production docker file, which is based on the Next.js example docker file, can be found [here.](https://nextjs.org/docs/pages/building-your-application/deploying#docker-image)

```dockerfile
FROM node:16-alpine AS deps
RUN apk add --no-cache libc6-compat curl
WORKDIR /app

COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN \
    if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
    elif [ -f package-lock.json ]; then npm i; \
    elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i --frozen-lockfile; \
    else echo "Lockfile not found." && exit 1; \
    fi

FROM node:16-alpine AS builder
WORKDIR /app
COPY . .
RUN apk add --no-cache curl
RUN npm i
RUN npm install --unsafe-perm -g sharp

ENV NEXT_TELEMETRY_DISABLED 1

RUN yarn build

FROM node:16-alpine AS runner
WORKDIR /app

ENV NODE_ENV production
ENV NEXT_TELEMETRY_DISABLED 1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/styles ./styles
COPY --from=builder /app/public ./public

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000

ENV PORT 3000

CMD ["node", "server.js"]
```

### 3. Compose Files for Development

Creating two compose files can pave the way for convenience:

1. [`docker-compose.yaml`](https://github.com/tbscode/nextjs-helm-template/blob/main/docker-compose.yaml): A development compose file.
2. [`docker-compose.pro.yaml`](https://github.com/tbscode/nextjs-helm-template/blob/main/docker-compose.pro.yaml): A production/ Local Infrastructure compose file.

Development is now always as straightforward as executing `docker-compose up`.

### 4. Creating a Helm Chart

To effectively manage the deployments and services we require, we prefer to create a simple Helm chart that can easily be adapted, installed, and updated. Our Helm chart will need the following components:

1. Frontend Deployment
2. Registry Image Pull Secrets
3. Frontend Service
4. Ingress

```
microk8s helm create ./helm
cd ./helm/template && rm -rf *
```

Everything will be deployed to a `rootNamespace`.

We have reset the template and created a simple setup for now [`./helm/template/frontend.yaml`](https://github.com/tbscode/nextjs-helm-template/blob/main/helm/templates/frontend.yaml).

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

We've created a simple flag `.Values.registryAuth.use` to check if registry authentication should be used (as we wouldn't need it for local microk8s deployment).
We use `.Values.registryAuth.use` to define the registry that should be used.

Now we define a simple deployment for our nextjs backend:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-container
  namespace: {{ .Values.rootNamespace }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: frontend-container
  template:
    metadata:
      labels:
        app: frontend-container
    spec:
      containers:
        - name: frontend-container
          image: {{ .Values.frontend.imageURL }}
          ports:
            - containerPort: 8000
          envFrom:
            - secretRef:
                name: frontend-secrets
      {{- if .Values.registryAuth.use }}
      imagePullSecrets:
        - name: dockerconfigjson-github-com
      {{- end }}
```

Note that we inject the `imageURL` and the registry pull secret if required. We go on to expose the port `3000` to the cluster through a simple service.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
  namespace: {{ .Values.rootNamespace }}
  labels:
    app: frontend-container
spec:
  type: ClusterIP
  ports:
    - port: 3000
      targetPort: 3000
  selector:
    app: frontend-container

```

It's also advisable to create a secret that injects some general environment variables listed in `values.yaml:frontend.env.*`

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: frontend-secrets
  namespace: {{ .Values.rootNamespace }}
type: Opaque
data:
{{- range $key, $value := .Values.frontend.env }}
  {{ $key }}: {{ $value | b64enc }}
{{- end }}
```

Finally, we set up an ingress:

```yaml
{{- if .Values.ingress.use }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend-ingress
  namespace: {{ .Values.rootNamespace }}
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: '3600'
    nginx.ingress.kubernetes.io/proxy-read-timeout: '3600'
    nginx.ingress.kubernetes.io/proxy-send-timeout: '3600'
    nginx.ingress.kubernetes.io/server-snippets: |
      location /ws/ {
        proxy_http_version 1.1;
        proxy_redirect off;
        proxy_buffering off;
      } 
    {{- if .Values.ingress.certManager }}
    cert-manager.io/cluster-issuer: letsencrypt-prod
    {{- end }}
    kubernetes.io/ingress.class: public
spec:
  {{- if .Values.ingress.certManager }}
  tls:
    - hosts:
      - {{ .Values.ingress.host }}
    secretName: frontend-ingress-tls
  {{- end }}
  rules:
  - host: {{ .Values.ingress.host }}
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 3000
{{- end }}
```

We've introduced some flags to set up `tls` if required and some annotations to facilitate websocket forwards.

#### Configuration via `Values.yaml`

Finally, to tie this all together, we create some default [`values.yaml`](https://github.com/tbscode/nextjs-helm-template/blob/main/helm/values.yaml)

```yaml
rootNamespace: "default"
registryAuth:
  registry: "localhost:32000"
  use: false
  token: ""
ingress:
  use: true
  certManager: false
  host: "localhost"
frontend:
  imageURL: "localhost:32000/frontend:registry"
  env:
    HOSTNAME: "localhost"
```

This can be used to control all the configuration options we just created.

### 5. Testing on Local Microk8s

It's always good to ensure that we can also deploy the entire infrastructure locally. For this, we can use a simple local `microk8s` installation.

```
microk8s enable ingress dns registry
docker-compose -f docker-compose.pro.yaml build
docker-compose -f docker-compose.pro.yaml push
```

Since we set up the template `.env` earlier, we're already configured to push and pull the image from `localhost:32000/frontend:registry`.
So now, all we need to do is install our newly created chart:

```
microk8s helm install next-js-frontend ./helm/ --set rootNamespace="nextjsfront"
```

Since we also set up `$ROOT_URL="http://localhost"`, the ingress will be configured to route to `http://localhost`. Now let's check the browser:

![Next page on localhost via microk8s](/static/assets/nextjs-page.jpg)

### 6. Deploy to Private Cluster

For the capability to deploy to a private cluster, you'll need a package registry available.

> If you quickly want a cheap registry, you can [check out my blog post](/blog/microk8s-gittea) on deploying Gitea in a private k8s cluster.

#### Modify Environment for Production

Firstly, we need to modify the environment to push to our private registry with a modified tag.

```bash
rm .env
echo "FRONTEND_IMAGE=\"<your-frontend-image-url>\"" >> .env
echo "ROOT_URL=\"<your-host-url>\"" >> .env
```

An example of an image URL is `my-gitea.example.com/gitea-private-user/package:latest`.
A `ROOT_URL` could be something like `nextjs.example.com`.

Note that you can restore the old default `.env` at any time using `git checkout .env`.

We also need to encode access credentials to our registry so we can inject them into our secret.

```bash
echo "<your-registry-user>:<your-registry-password>" | base64
```

```bash
docker-compose -f docker-compose.pro.yaml build
docker-compose -f docker-compose.pro.yaml push
KUBECONFIG="./kubeconfig.yaml" microk8s helm install next-js-frontend ./helm/ \
  --set rootNamespace="nextjsfront" \
  --set ingress.use=true \
  --set frontend.imageURL="<your-frontend-image-url>" \
  --set certManager.use=true \
  --set registryAuth.use=true \
  --set registryAuth.registry="<your-registry-host>" \
  --set registryAuth.token="<base64-encoded-token>"
```

> It works perfectly! In fact, this blog was deployed using this exact technique. 

### 7. Repository Automations

Now, we have a simple process to deploy the repository using GitHub Actions. 
These actions can also run on your own runners using Gitea Actions.

We create one simple workflow [`.github/workflow/deploy.yaml`](https://github.com/tbscode/nextjs-helm-template/blob/main/.github/workflow/deploy.yaml)

```yaml
name: Deploy NextJs App
    
on:
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy NextJS App
    steps:
      - uses: actions/checkout@master
        with:
          token: ${{ secrets.BOT_PAT }}
          submodules: recursive
          ref: ${{ github.event.pull_request.head.sha }}
      - name: Setup Kubeconfig
        id: setup_kubeconfig
        run: |
          touch .env; rm .env
          echo "${{ secrets.KUBE_CONFIG_BASE64 }}" | base64 -d > kubeconfig.yaml
      - name: Setup Environment
        id: setup_env
        run: |
          touch .env; rm .env; touch .env
          RANDOM_STRING="$( openssl rand -hex 3 )"
          FRONTEND_IMAGE="${{ secrets.CONTAINER_REGISTRY }}/${{ secrets.GITTEA_USER }}/nextjs-app:build-$RANDOM_STRING"
          echo "FRONTEND_IMAGE=\"$FRONTEND_IMAGE\"" >> .env
          echo "frontend_image=$FRONTEND_IMAGE" >> $GITHUB_OUTPUT
      - name: Build And Push Image
        run: |
          echo ${{ secrets.GITTEA_PASSWORD }} | docker login ${{ secrets.CONTAINER_REGISTRY }} -u ${{ secrets.GITTEA_USER }} --password-stdin
          DOCKER_BUILDKIT=1 docker-compose -f docker-compose.pro.yaml build
          DOCKER_BUILDKIT=1 docker-compose -f docker-compose.pro.yaml push
      - uses: azure/setup-helm@v3
        with:
           version: 'latest'
           token: ${{ secrets.BOT_PAT }}
        id: install-helm
      - uses: azure/setup-kubectl@v3
        with:
           version: 'latest'
        id: install-kubectl
      - name: Setup Cluster Connection
        id: cluster_connection
        run: |
          echo "Test"
          REGISTRY_AUTH=$(echo -n "${{ secrets.GITTEA_USER }}:${{ secrets.GITTEA_PASSWORD }}" | base64)
          KUBECONFIG=./kubeconfig.yaml kubectl create namespace nextjsnamespace || true
          cat << EOF | while read eval_command; do yq -i eval "$eval_command" ./helm/values.yaml; done
            .rootNamespace = "nextjsnamespace"
            .ingress.host = "${{ secrets.BOT_PAT }}"
            .frontend.imageURL = "${{ steps.setup_env.outputs.frontend_image }}"
            .ingress.certManager = true
            .registryAuth.token = "$REGISTRY_AUTH"
            .registryAuth.use = true
          EOF
          KUBECONFIG=./kubeconfig.yaml helm upgrade next-js-app ./helm/ --set rootNamespace="nextjsnamespace" --install
```

Using the following secrets configured in your GitHub account:

- `BOT_PAT`: GitHub bot access token
- `GITTEA_USER`: Private registry user
- `GITTEA_PASSWORD`: Private registry password or auth token
- `CONTAINER_REGISTRY`: Container registry host address
- `KUBE_CONFIG_BASE64`: Base64 encoded kubeconfig to connect to the k8s cluster

#### Automation Steps

1. Clone the repo and its sub-repos using `actions/checkout@master`.
2. Setup the `.env` with a random image tag
3. Build and push the production image using the generated tag
4. Setup Helm and kubectl using the Azure actions `azure/setup-helm@v3`, `azure/setup-kubectl@v3`
5. Modify `values.yaml` with our new configuration and update the Helm installation

> Opportunities from here are limitless; you can easily have any pull to the main deploy a feature environment or connect a backend to your Next.js app.

Simple steps to build, push, and deploy a Next.js app on Kubernetes

Quickly Deploy Any Next Js App On Kubernetes


Deploying Postgres on Kubernetes need not be complex. With automation in place, you can deploy a secure and isolated instance of PostgreSQL within your Microk8s cluster using Bitnami's Helm chart. The updated script covers everything from provisioning TLS certificates to configuring the database for secure connections.

### Preparing the Environment

The process starts with some initial setup tasks. We create a Kubernetes namespace for the PostgreSQL instance and establish the baseline for our commands:

```bash
#!/bin/bash

KUBECMD_PREFIX="${KUBECMD_PREFIX:=microk8s}"
CERT_MANAGER_NAMESPACE="cert-manager"

$KUBECMD_PREFIX kubectl create namespace $K8_NAMESPACE || true
```

### Configuring SSL/TLS Encryption

With cert-manager installed in our cluster, we can automatically provision and manage TLS certificates. This is a crucial step in ensuring that our database communication is encrypted:

```bash
cat <<EOF | $KUBECMD_PREFIX kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: $RELEASE_NAME-postgresql-tls
  namespace: $K8_NAMESPACE
spec:
  secretName: $RELEASE_NAME-postgresql-tls
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt-prod
  dnsNames:
  - $DB_HOSTNAME
EOF
```

It's imperative to wait for the certificate to become ready. This script assures that by incorporating a timeout for the process:

```bash
$KUBECMD_PREFIX kubectl -n $K8_NAMESPACE wait --for=condition=ready certificate $RELEASE_NAME-postgresql-tls --timeout=300s
```

### Installing PostgreSQL with Helm

Having confirmed that the TLS certificate is in place, we proceed with the Helm chart installation:

```bash
$KUBECMD_PREFIX helm install $RELEASE_NAME oci://registry-1.docker.io/bitnamicharts/postgresql \
    -n $K8_NAMESPACE \
    --set global.postgresql.auth.username="$DB_USERNAME" \
    --set global.postgresql.auth.password="$DB_PASSWORD" \
    ...
    --set tls.certificatesSecret="$RELEASE_NAME-postgresql-tls" \
    --set tls.certFilename="tls.crt" \
    --set tls.certKeyFilename="tls.key"
```

The script passes the appropriate values to Helm, signaling it to deploy Postgres with TLS enabled.

### Networking Configuration

The `ConfigMap` and `Service` definitions are applied to route external traffic to the Postgres instance:

```bash
read -r -d '' INGRESS_CONFIG << EOM
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: ingress
  name: nginx-ingress-tcp-microk8s-conf
data:
  5432: "$K8_NAMESPACE/$RELEASE_NAME-postgresql:5432"
---
apiVersion: v1
kind: Service
metadata:
  name: $RELEASE_NAME-nodeport
  namespace: $K8_NAMESPACE
spec:
  type: NodePort
  ...
  nodePort: $TARGET_PORT
  ...
EOM

$KUBECMD_PREFIX kubectl apply -f - <<< "$INGRESS_CONFIG"
```

### Testing the Database Connection

Once deployed, verify the secure connection using Python and the `psycopg2` library. The script aims to establish a connection, execute a command, and then gracefully terminate the connection:

```python
import psycopg2

conn = None
try:
    conn = psycopg2.connect(
        dbname='...',
        user='...',
        password='...',
        host='...',
        port='...',
        sslmode='require'
    )

    print("Success: Connected to the database!")
    cur = conn.cursor()
    cur.execute("SELECT version();")
    record = cur.fetchone()
    print("You are connected to - ", record, "\n")
    cur.close()
except (Exception, psycopg2.DatabaseError) as error:
    print("Error: ", error)
finally:
    if conn is not None:
        conn.close()
        print("Database connection closed.")
```

By requiring `sslmode='require'`, the script confirms that the connection is not only secure but also compliant with best practices.

### Wrapping Up

The combination of Microk8s's simplicity and Helm's power simplifies the deployment of a robust PostgreSQL database. TLS encryption, managed by cert-manager, makes sure the data remains secure in transit. For developers and administrators looking to setup PostgreSQL on Kubernetes, the process is now streamlined, automated, and immeasurably more secure than before.

Do check out the full deployment script and accompanying resources on the [GitHub repository](https://github.com/tbscode/tims-blog-posts/blob/main/assets/postgress_create_dynamic_k8s.sh) and ensure your databases are secure from setup to daily operations.

This guide provides a step-by-step approach to installing a PostgreSQL database using Bitnami's Helm chart on a Microk8s cluster, including TLS configuration for enhanced security.

Setting Up a Secure Bitnami PostgreSQL Instance on Microk8s


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.

Latest Posts

Msgmate.io Development Update Oct 2023

PDF's from markdown, pandoc and more

Simulate secondary webcam on linux

Quickly Deploy Any Next Js App On Kubernetes

Setting Up a Secure Bitnami PostgreSQL Instance on Microk8s

MariaDB on Kubernetes with Backup Cron-job