← All projects

Homelab Infra

Make the setup repeatable

What a checked-in server recipe tells you, and what it cannot tell you about a running lab.

Three nodes, kept in sync with Git.

k3s / Argo CD / Ansible

Write-up ↗
Notes & checks

Two ThinkCentres and a gaming PC with an RTX 3070 for Ollama. Ansible sets up the nodes; Argo CD keeps the cluster synced with Git. Tailscale for remote access.

MinIO runs on the cluster. TrueNAS/ZFS handles persistent storage, photos, and videos.

The problem

A home server is easy to configure through one-off commands and hard to rebuild from memory. The public homelab repository records an Ansible recipe for bootstrapping an RKE2 server. Ansible runs setup tasks; RKE2 is a Kubernetes distribution for running containerized applications.

How it works

  1. PlaybookSetup recipe
  2. Ansible roleInstall + configure
  3. RKE2 serverCluster control plane
The checked-in bootstrap path, rather than a live topology map.
  1. Choose the target machines

    The playbook targets a control-plane inventory group, the machines listed for cluster management. It selects the server role and uses elevated permissions for installation. The inventory lists specific machines, so it is not a portable demo command.

  2. Run setup as named tasks

    The role separates preflight checks, installation, storage-client packages, and server configuration. The installation task pins the RKE2 version and skips its installer when the rke2 binary already exists.

  3. Describe an application in Git

    A checked-in Argo CD application points at the hello-world manifests and requests automated sync and self-healing. Argo CD compares Git files with a cluster. The manifest expresses the requested behavior; its presence alone does not establish that a live cluster has applied it.

Decisions & tradeoffs

Keep recovery services independent

The README describes TrueNAS separately from the Kubernetes node so DNS and remote access can survive a cluster failure. That separation matters when the broken system is the one you need to reach.

A recipe is evidence of code

The portfolio's hardware notes describe a k3s setup. This article follows the public repository's RKE2 recipe instead. Neither a photograph nor a YAML file verifies current node health or deployed storage, so this note makes no such claim.

Try it yourself

Start by reading the playbook and following its task imports. No server changes are needed.

Compare the RKE2 role with the hello-world Argo CD manifest. Ask which file installs software and which asks a running cluster to host an app. Avoid running the bootstrap against a machine you have not deliberately set aside for the lab.

Sources & scope

Limited coverage: no local homelab checkout was available. Public source was read directly. Runtime deployment and the older portfolio topology were not independently verified.