Search Results

Pick storage per workload. Shared app data → NFS. Databases → local disk on their own VM. One size does not fit all. NFSv4, single port, subnet-scoped. Smallest firewall footprint, simplest mental model. A default StorageClass keeps manifests clean. Apps shou...

Ask Kubernetes for a Service of type LoadBalancer in the cloud and you get a real load balancer with a real IP, because the cloud provider has a controller watching for exactly that. On bare metal — a home lab — nobody's listening. The service just sits there ...

MetalLB has two modes: BGP (it speaks routing protocols to your network gear) and L2 (it answers ARP for the service IPs). For a flat single-subnet lab, L2 is the obvious pick — no router configuration, it just works on the local network. The config is two sma...

Once you can get an external IP, you need something to route HTTP to the right app and, ideally, to add the cross-cutting concerns every API needs — auth, rate limiting, request shaping. A plain ingress controller (like ingress-nginx) does routing well. An API...

Kong can run config-only ("DB-less") or backed by a database. I chose DB-backed, against the existing PostgreSQL server, for two reasons: it exercises the database layer the lab already has, and it's the mode that supports runtime configuration and the admin w...

Kong's Admin API is powerful — it can reconfigure the whole gateway — and the open-source edition has no built-in authentication on it (that's a paid feature). So you must not expose it casually. Two honest options: Leave it internal. The ingress controller t...

A natural instinct is to give Kong a certificate and let it serve HTTPS. I did that first — and then remembered the lab already terminates TLS at the edge (pfSense/HAProxy, with a wildcard cert). Doing it in both places is redundant and causes a redirect loop:...

A cluster runs containers; it doesn't build them. Something has to turn a git push into an image sitting in a registry, ready to deploy. That's CI/CD, and in this lab it's two pieces working together: git push -> Gitea (git.example.com) ...

Gitea ships a CI system that speaks the same workflow syntax as GitHub Actions. To actually run jobs you register a runner — and that's a dedicated VM here (GIT-Runner, 10.100.100.11). Why a separate VM rather than running builds in the cluster? Builds are bur...

Jobs run inside containers, but the jobs themselves need to build containers. The classic tangle is "Docker inside Docker." The cleaner approach used here is Docker-out-of-Docker: the runner mounts the host's Docker socket into the job container, so docker bui...

Here's a subtle thing. Those custom job images live in the private registry, which requires authentication. So how does the runner pull them? It doesn't do anything special — it asks the host's Docker engine to pull, and Docker uses the credentials in the runn...

A workflow file in a repo (.gitea/workflows/build.yml) is all it takes. Because the job image already has the tools, the workflow is short: name: build on: { push: { branches: [main] } } jobs: build: runs-on: ubuntu-24.04 steps: - uses: actions...

Give builds their own box. Bursty, disk-heavy, sometimes privileged — you don't want that sharing fate with your cluster workloads. Docker-out-of-Docker over Docker-in-Docker. Mount the socket; skip the privileged nested daemon. Bake a real job image. Tools-i...

The platform runs three relational databases — PostgreSQL (10.100.100.13), MariaDB (10.100.100.14), and MySQL (10.100.100.15) — each on its own VM, each on local disk, not on the cluster's NFS. Why three? Because real applications disagree about what they want...

A freshly installed database ships with cautious, generic defaults. On a box you've sized deliberately (4 vCPU, 4 GiB RAM, SSD-backed disk), a little tuning goes a long way. The themes are the same across all three engines: Let it use the RAM. Tell the engine...

This is a hard rule in the lab: no application ever connects as the database admin. Each app gets its own database, its own user, and its own password, scoped to just that database. # for an app 'foo', on PostgreSQL: CREATE DATABASE foo; CREATE USER foo WITH P...

The lab already had a central log store (Loki — see its book in Core Infrastructure), with a Promtail agent on every VM shipping system logs. When the cluster arrived, the job was to feed its logs in too. On the Kubernetes nodes the node-level Promtail agent w...

Match storage to the workload: databases get local disk on dedicated VMs, never NFS. Tune for the box you have: give the engine the RAM, tell it the disk is SSD, log slow queries. MariaDB ≠ MySQL: running both proved it. Check settings against your actual eng...