The Ultimate Home Lab Project: A Journey to High Availability Self-Hosting

Embracing the Challenge of Creating a Truly Decentralized Network

I’ve always been fascinated by the idea of self-hosting my own services, free from the shackles of internet censorship and the whims of cloud providers. It’s a hobby that’s both rewarding and frustrating, as I’ve come to realize that going distributed is hard. Really hard. But, as they say, “a guy can have a hobby,” and mine is to create the ultimate home lab project – a high availability, self-hosted network that’s truly mine.

My journey began with a simple idea: to create a network that’s decentralized, secure, and scalable. I started with six physical machines, four of which are proper servers, and two are a Raspberry Pi and a NUC. I connected them all using a Nebula overlay network, which allows them to communicate with each other as if they’re in the same LAN. It’s been a charm to set up, and I’ve even got my firewall configured to work like a LAN, with more restrictive firewalls planned for the future.

The Hard Part: Choosing the Right Architecture

Now that my devices can talk to each other, the next step is to decide on an architecture that will allow me to replicate my services across multiple nodes. I’ve got a plethora of services that I want to self-host, including Home Assistant, PiHole, Jellyfin, Wireguard, Nextcloud, and many more. The problem is, there’s no easy way to duplicate most of them and keep them synced across locations. Take something like NGINX, for instance – it’s a walk in the park to deploy multiple containers, but if you start to look at the front ends and Docker containers, your head may start spinning.

I’ve been struggling to make the switch from my old Apache + Certbot configs, and things like NGINX Proxy Manager sound extremely appealing, but I fear the day I’ll have to replicate them. Some services don’t even make sense to replicate, like Home Assistant, which is heavily integrated with local hardware. So, I’m left with a few questions: what would you replicate if you were in my shoes? Do you know of good ways to host these services in a distributed fashion? And, am I the only one who’s afraid that this may lead to the final boss – a complex, unwieldy system that’s more trouble than it’s worth?

Kubernetes: The Elephant in the Room

Ah, Kubernetes – the damnation I felt when I realized that it’s the only thing that may save me from my self-hosting woes. But, it’s also a hell to get through, especially after centering my ecosystem around Docker and finding out that Docker Swarm may be slowly dying. I’ve tried looking at Kubernetes, but it feels both overkill and like it still didn’t fully solve the issues. Synchronization of data across live nodes would still need distributed database systems, and that’s without counting all the accessory services that come with it.

The Current Architecture Idea

I’ve sketched out an idea for my architecture, which involves having several A records in the DNS, all with the same name but different values, to create a round-robin setup for load balancing on three NGINX nodes. These nodes would communicate with the underlying services using the Nebula network. The problem is, I don’t know which tools to adopt to replicate these services, especially the storage part, which is currently handled by a node running Nextcloud.

So, I’m turning to the community for help. Any advice on the architecture, specific tools, or obscure setup tutorials would be appreciated. I want to create a guide that will let anyone who wants to self-host have the chance to see themselves in a position where they can have all the ease of use of everyday applications without selling their soul to Google or having 10 years of expertise in Kubernetes.

—

Projekt Ostatecznego Laboratorium Domowego: Podróż do Wysokiej Dostępności Samo-Hostowania

Przyjmowanie Wyzwania Tworzenia Prawdziwie Decentralizowanej Sieci

Zawsze byłem fascynowany pomysłem hostowania własnych usług, wolny od ograniczeń cenzury internetowej i kaprysów dostawców chmury. To hobby, które jest zarówno nagradzające, jak i frustrujące, ponieważ zdaje sobie sprawę, że decentralizacja jest trudna. Bardzo trudna. Ale, jak mówią, “człowiek może mieć hobby”, a moim hobby jest stworzenie ostatecznego projektu laboratorium domowego – sieci o wysokiej dostępności, samo-hostowanej i prawdziwie mojej.

Moja podróż rozpoczęła się od prostej idei: stworzenia sieci, która jest zdecentralizowana, bezpieczna i skalowalna. Zacząłem od sześciu fizycznych maszyn, z których cztery są prawidłowymi serwerami, a dwie to Raspberry Pi i NUC. Połączyłem je wszystkie za pomocą sieci Nebula, która pozwala im komunikować się ze sobą, jakby były w tej samej sieci lokalnej. To było czarem, aby to ustawić, i nawet mam skonfigurowaną zapórę sieciową, aby działała jak sieć lokalna, z bardziej restrykcyjnymi zapарамi planowanymi na przyszłość.

Trudna Część: Wybór Prawidłowej Architektury

Teraz, gdy moje urządzenia mogą ze sobą rozmawiać, następny krok to zdecydowanie, jaka architektura pozwoli mi na replikację usług na wielu węzłach. Mam wiele usług, które chcę samo-hostować, w tym Asystenta Domowego, PiHole, Jellyfina, Wireguard, Nextcloud i wiele innych. Problem polega na tym, że nie ma łatwego sposobu, aby duplikować większość z nich i utrzymać je zsynchronizowane w różnych lokalizacjach. Weźmy coś takiego jak NGINX, na przykład – jest to spacer, aby wdrożyć wiele kontenerów, ale jeśli zaczniesz patrzeć na front-endy i kontenery Docker, twoja głowa może zacząć kręcić się.

Starałem się przerzucić ze swoich starych konfiguracji Apache + Certbot, a rzeczy takie jak Menedżer serwera proxy NGINX brzmią niezwykle atrakcyjnie, ale boję się dnia, w którym będę musiał je replikować. Niektóre usługi nie mają nawet sensu replikować, jak Asystent Domowy, który jest głęboko zintegrowany z lokalnym sprzętem. Więc, jestem zostawiony z kilkoma pytaniami: co byś replikował, gdybyś był na moim miejscu? Czy znasz dobre sposoby, aby hostować te usługi w sposób rozproszony? I, czy jestem jedynym, kto boi się, że to może doprowadzić do ostatecznego bossa – złożonego, niewygodnego systemu, który jest więcej kłopotu niż wartości?

Kubernetes: Słoń w Pokoju

Ah, Kubernetes – potępienie, które czułem, gdy zdałem sobie sprawę, że to jedyna rzecz, która może mnie uratować od moich problemów z samo-hostowaniem. Ale, to także piekło, przez które trzeba przejść, zwłaszcza po scentralizowaniu mojego ekosystemu wokół Docker i odkryciu, że Docker Swarm może być powoli umierający. Spróbowałem patrzeć na Kubernetes, ale wydaje się zarówno nadmiarowe, jak i jakby nie rozwiązało w pełni problemów. Synchronizacja danych w czasie rzeczywistym między węzłami nadal wymagałaby rozproszonego systemu baz danych, a to bez liczenia wszystkich usług dodatkowych, które się z tym wiążą.

Bieżąca Idea Architektury

Narysowałem pomysł na moją architekturę, który obejmuje posiadanie kilku rekordów A w systemie DNS, wszystkie z tym samym nazwą, ale różnymi wartościami, aby utworzyć rundę robin dla równoważenia obciążenia na trzech węzłach NGINX. Te węzły komunikowałyby się z podstawowymi usługami za pomocą sieci Nebula. Problem polega na tym, że nie wiem, jakie narzędzia przyjąć, aby replikować te usługi, zwłaszcza część magazynu, która jest obecnie obsługiwana przez węzeł uruchamiający Nextcloud.

Więc, zwracam się do społeczności o pomoc. Jakiekolwiek porady dotyczące architektury, konkretnych narzędzi lub nieznanych tutoriali ustalenia będą mile widziane. Chcę stworzyć przewodnik, który pozwoli każdemu, kto chce samo-hostować, zobaczyć siebie w sytuacji, w której mogą mieć wszystkie udogodnienia codziennych aplikacji bez sprzedaży swojej duszy Google lub mając 10 lat doświadczenia w Kubernetes.