Search Results

One golden image, cloned many times. Consistency first; it kills "works on that box" bugs. Bake the common, inject the unique. Shared tooling in the template; hostname/IP/credentials via cloud-init. Have an address convention. "IP = VM-ID minus 100" removes a...

Every VM in the lab gets the same small set of OS-level adjustments before it does any real work. Not a heavy "hardening framework" — just a handful of settings that make a virtual machine on virtualised, SSD-backed storage behave sensibly. The value isn't any...

The recurring adjustments, and the reasoning for each: Swap — present and small on the general VMs as a safety cushion, but off on the Kubernetes nodes (the kubelet wants it gone). The point isn't "swap good" or "swap bad" — it's matching the swap policy to t...

Tune to the role, not dogmatically. Swap off for k8s nodes, on (small) elsewhere. BBR where it faces the internet. There's no single right answer for the whole fleet. Apply it the same way everywhere. The benefit is uniformity; a baseline that's applied to 13...

Git is distributed, but teams still need a central place to push to, open pull requests, and trigger automation. You could use a SaaS forge — or you could run your own. This lab runs Gitea (GIT-Server, 10.100.100.2), a lightweight open-source Git forge. The re...

Gitea here is a straightforward binary install: the gitea service listening on port 3000, a lightweight database behind it, and its config in one file (app.ini). HAProxy at the edge publishes it as https://git.example.com. GIT-Server (10.100.100.2) gitea (s...

A forge earns its keep through its API. Gitea exposes a full REST API, authenticated with a token, and that's how the rest of the platform automates against it: creating repos, managing CI secrets, reading workflow status, even creating the registration token ...

Owning the forge closes the loop. Code → CI → registry → cluster, all in one network you control. Light is fine. A single Go binary forge is plenty for a lab (and many small teams), and it's a joy to operate. Lean on the API. It's the seam where automation pl...

A lab you can't explain is just a pile of running processes. Documentation is what turns it into a portfolio and a teaching resource — which, for this lab, is the entire point. So it gets a real home: BookStack (Docs-Server, 10.100.100.3), the wiki you're read...

BookStack is a PHP web application, so the box runs a fairly classic web stack: Docs-Server (10.100.100.3) nginx (:80) - serves the app, fronted by HAProxy -> docs.example.com PHP - the BookStack application itself MariaDB ...

BookStack's content model is just three levels, and these docs use them deliberately: Shelf "Building a Kubernetes Platform on Proxmox" Book "Kubernetes Cluster (kubeadm + Calico)" Page "Joining the workers (and the firewall that blocked them)" ...

Here's the meta bit. BookStack has a full REST API, and every shelf, book, and page in this documentation was created through it, not typed into the web editor. Covers included. POST /api/books (name, description, + a generated cover image) POST /api/shelve...

Document for the reader you were. The most valuable pages explain the why and the mistakes, because that's what you couldn't find when you started. Let the tool's structure guide you. Shelf → book → page keeps things findable; fight it and you get sprawl. One...

Logs tell you what happened; metrics tell you how things are trending. Is the host running out of memory? Is disk filling up? Is CPU pegged? Those are numbers over time, and you want them charted and alertable, not discovered by accident. The lab runs a metric...

Metrics flow in one direction, from source to dashboard: Proxmox host --(built-in metric server)--> InfluxDB --> Grafana (CPU, RAM, (10.100.100.4) dashboards disk, I/O) bucket: proxmox ...

Grafana is doing double duty in this lab, and that's deliberate. It's the dashboard front-end for metrics (from InfluxDB) and — because Grafana can query multiple data sources — the front-end for logs (from Loki; see the next book). Grafana (10.100.100.4) |...

Watch the foundation first. The Proxmox host's CPU/RAM/disk is the most important thing to graph — everything else depends on it staying healthy. Learn the universal shape: source → time-series DB → dashboards. InfluxDB or Prometheus, the pattern is the same....

With more than a couple of machines, "SSH in and grep the log" stops scaling. You don't know which box the interesting line is on, logs rotate away, and correlating across machines is hopeless. The fix is to ship every log line to one searchable place. This la...