70 lines
4.6 KiB
Markdown
70 lines
4.6 KiB
Markdown
---
|
|
title: "Automating My Homelab: From Bare Metal to Kubernetes with Ansible"
|
|
date: 2025-07-27
|
|
author: "TuDatTr"
|
|
tags: ["Ansible", "Proxmox", "Kubernetes", "K3s", "IaC", "Homelab"]
|
|
---
|
|
|
|
## The Homelab: Repeatable, Automated, and Documented
|
|
|
|
For many tech enthusiasts, a homelab is a playground for learning, experimenting, and self-hosting services. But as the complexity grows, so does the management overhead. Manually setting up virtual machines, configuring networks, and deploying applications becomes a tedious and error-prone process. This lead me to building my homelab as Infrastructure as Code (IaC) with Ansible.
|
|
|
|
This blog post walks you through my Ansible project, which automates the entire lifecycle of my homelab—from provisioning VMs on Proxmox to deploying a production-ready K3s Kubernetes cluster.
|
|
|
|
## Why Ansible?
|
|
|
|
When I decided to automate my infrastructure, I considered several tools. I chose Ansible for its simplicity, agentless architecture, and gentle learning curve. Writing playbooks in YAML felt declarative and intuitive, and the vast collection of community-supported modules meant I wouldn't have to reinvent the wheel.
|
|
|
|
## The Architecture: A Multi-Layered Approach
|
|
|
|
My Ansible project is designed to be modular and scalable, with a clear separation of concerns. It's built around a collection of roles, each responsible for a specific component of the infrastructure.
|
|
|
|
### Layer 1: Proxmox Provisioning
|
|
|
|
The foundation of my homelab is Proxmox VE. The `proxmox` role is the first step in the automation pipeline. It handles:
|
|
|
|
- **VM and Container Creation:** Using a simple YAML definition in my `vars` files, I can specify the number of VMs and containers to create, their resources (CPU, memory, disk), and their base operating system images.
|
|
- **Cloud-Init Integration:** For VMs, I leverage Cloud-Init to perform initial setup, such as setting the hostname, creating users, and injecting SSH keys for Ansible to connect to.
|
|
- **Hardware Passthrough:** The role also configures hardware passthrough for devices like Intel Quick Sync for video transcoding in my media server.
|
|
|
|
### Layer 2: The K3s Kubernetes Cluster
|
|
|
|
With the base VMs ready, the next step is to build the Kubernetes cluster. I chose K3s for its lightweight footprint and ease of installation. The setup is divided into several roles:
|
|
|
|
- `k3s_server`: This role bootstraps the first master node and then adds additional master nodes to create a highly available control plane.
|
|
- `k3s_agent`: This role joins the worker nodes to the cluster.
|
|
- `k3s_loadbalancer`: A dedicated VM running Nginx is set up to act as a load balancer for the K3s API server, ensuring a stable endpoint for `kubectl` and other clients.
|
|
|
|
### Layer 3: Applications and Services
|
|
|
|
Once the Kubernetes cluster is up and running, it's time to deploy applications. My project includes roles for:
|
|
|
|
- `docker_host`: For services that are better suited to run in a traditional Docker environment, this role sets up and configures Docker hosts.
|
|
- `kubernetes_argocd`: I use Argo CD for GitOps-based continuous delivery. This role deploys Argo CD to the cluster and configures it to sync with my application repositories.
|
|
- `reverse_proxy`: Caddy is my reverse proxy of choice, and this role automates its installation and configuration, including obtaining SSL certificates from Let's Encrypt.
|
|
|
|
## Putting It All Together: The Power of Playbooks
|
|
|
|
The playbooks in the `playbooks/` directory tie everything together. For example, the `kubernetes_setup.yml` playbook runs all the necessary roles in the correct order to bring up the entire Kubernetes cluster from scratch.
|
|
|
|
```yaml
|
|
# playbooks/kubernetes_setup.yml
|
|
---
|
|
- name: Set up Kubernetes Cluster
|
|
hosts: all
|
|
gather_facts: true
|
|
roles:
|
|
- role: k3s_server
|
|
- role: k3s_agent
|
|
- role: k3s_loadbalancer
|
|
- role: kubernetes_argocd
|
|
```
|
|
|
|
## Final Thoughts and Future Plans
|
|
|
|
This Ansible project has transformed my homelab from a collection of manually configured machines into a fully automated and reproducible environment. I can now tear down and rebuild my entire infrastructure with a single command, which gives me the confidence to experiment without fear of breaking things.
|
|
|
|
While the project is highly tailored to my specific needs, I hope this overview provides some inspiration for your own automation journey. The principles of IaC and the power of tools like Ansible can be applied to any environment, big or small.
|
|
|
|
What's next? I plan to explore more advanced Kubernetes concepts, such as Cilium for networking and policy, and integrate more of my self-hosted services into the GitOps workflow with Argo CD. The homelab is never truly "finished," and that's what makes it so much fun.
|