The homelab is where all computer services are provided to the Rachelski household.
At the time of this writing, it is composed of:
| Topic | Description |
|---|---|
| NAS (diskstation.rachelski.internal) | Network Attached Storage device |
| Hashicorp Vault (hcl-vault.rachelski.internal) | the secrets store and certificate issuer for the homelab, running on the NAS |
| net-1 (net-1.rachelski.internal) | A rackmount computer that houses most network-related services |
| Proxmox Hosts | the virtualization hosts (ranch-1, ranch-2) whose VMs make up the Kubernetes cluster |
| Kubernetes Cluster (k8s-control.rachelski.internal) | Kubernetes allows for High Availability of applications and the potential to design for zero downtime. |
Cloud Server (host-1.rachelski.net) |
hosted in the Hetzner cloud in Germany hosting things that are 100% exposed to the internet |
To give another engineer admin access, or to work on the homelab remotely, see Setting up a new administrator.
In general, I try to avoid exposing homelab applications directly to the internet unless there are clear performance reasons for doing so. I experimented with running an always-on VPN tunnel from the host-1 server and only exposing public endpoints from there. But the latency on the connection was too high for most services.
At this time, if a service in the homelab needs to be exposed to the internet, it is normally routed via the Caddy server running on the net-1 host. The only inbound connections from the internet go to that service.
The one exception to this rule is that bittorrent protocols are forwarded on the router to a dedicated Virtual IP for that protocol. This VIP is managed by MetalLB in the media-server-k8s project with qbittorrent being the torrent app that is targeted.
The overall backup strategy for the homelab (Kopia to the NAS and to the data-barn-1 storage box in Hetzner) and the list of machines being backed up are on the Backups page. In addition, the Kuberenetes cluster contains the Longhorn storage system that is capable of backing up Kubernetes persistent volumes to the NAS.
The actual plans applied to the homelab are spread over a few Git repos. This allows for modular maintenance of the cluster with a cleaner git commit history. The tree below lists the repos in dependency order. Apply the ones higher in the list first:
rachelski.internal that the cluster depends uponnfs-nas that an app can use to allocate a storage sub-directory on the NAS. In some cases, Kubernetes apps are using a none StorageClass to map out their own NFS mounts against shared folders on the NAS.host-1 server in the hetzner cloud. It is required for applications in the k8s cluster that have integrated with it for login. The cluster and its apps can be brought up without it, but no users will be able to log into the apps.media namespace. This is a collection of services that download interesting video content (movies, TV, etc) and then provides tools for serving that content (e.g. jellyfin)