Budowa niezawodnego homelabu: od Raspberry Pi do pełnowartościowego serwera
Programista z Moskwy w ciągu dwóch lat przekształcił podstawowe umiejętności Linuxa w kompletną domową infrastrukturę serwerową. Rozpoczął od Raspberry Pi 5 i udziałów SMB na SSD o pojemności 1 TB, a następnie stopniowo rozwijał system do NAS z wieloma dyskami, by w końcu przejść na procesor Intel Core i7-13700 do obsługi intensywnych obciążeń. Dzięki temu mógł samodzielnie hostować kluczowe usługi, minimalizując zależność od chmur publicznych.
Modernizacja sprzętu
Pierwsza konfiguracja oparta na Raspberry Pi 5 zawierała port SATA do czterech dysków SSD. Wady platformy — słabe przetwarzanie HEVC w 4K, niewystarczająca ilość pamięci RAM oraz niestabilność kart SD przy przechowywaniu baz danych — zmusiły do drastycznych zmian.
Nowa konfiguracja:
- Procesor: Intel Core i7-13700 (LGA1700)
- Płyta główna: Asus ROG STRIX B760-I GAMING WIFI (mini-ITX)
- Pamięć RAM: 32 GB DDR5 Kingston 5600 MHz
- Dysk SSD: Adata LEGEND 860 1 TB PCIe 4.0
- Obudowa: Jonsbo N3 z 8 gniazdami na HDD z możliwością wymiany 'na gorąco'
- Zasilacz: 750 W 80+ Platinum
System operacyjny: Fedora bez interfejsu graficznego. Automatyzacja poprzez skrypty bash, systemd-tajmer, zsh z Oh My Zsh i Powerlevel10k. Wszystkie usługi działają w kontenerach Docker zarządzanych przez Portainer.
Usługi selfhosted w architekturze
Lista wdrożonych aplikacji obejmuje kluczowe scenariusze:
- Jellyfin: strumieniowanie multimediów z transkodowaniem
- Navidrome: serwer muzyki
- filebrowser-quantum: menedżer plików (przechowalnia 14 TB)
- Immich: samodzielne hostowanie zdjęć i filmów
- mscmanager: pula do zarządzania Minecraftem i Terrarią
- Transmission: klient torrent
- Vaultwarden: menedżer haseł z obsługą kluczy SSH
- dnsmasq: lokalny DNS do nadpisywania nazw domen
- Home Assistant: zarządzanie IoT
- Termix: menedżer SSH
- WireGuard: dostęp przez VPN
- Nginx: proxy zwrotny (planowane przejście na Caddy z ACME)
Konfiguracja sieci i dostępność
Architektura sieci zapewnia nieprzerwaną dostępność lokalną i zdalną:
- Domena na Cloudflare wskazuje na statyczny IP routera (192.168.0.1).
- Przekierowanie portu 443 na wewnętrzny router (192.168.2.1, OpenWRT z Xray).
- Proxy zwrotne na serwerze (192.168.2.10) dystrybuuje ruch po subdomenach (np. immich:2283).
- Lokalny dnsmasq w Dockerze nadpisuje domeny na wewnętrzne IP, upstream: 1.1.1.1/8.8.8.8.
- DHCP routera przekazuje lokalny DNS wszystkim urządzeniom klienckim.
Zapora blokuje dostęp z zewnątrz do portów lokalnych, z wyjątkiem localhost. To rozwiązuje problem awarii dostawcy: w domu domena rozpoznaje się lokalnie.
Kopie zapasowe i odporność na awarie
Bez RAID: 5 kopii danych w 3 lokalizacjach za pomocą skryptów rsync uruchamianych przez systemd-tajmer. Skrypty monitorują zmiany w /etc i innych katalogach, w tym konfiguracje dynamiczne. Planowane jest wdrożenie integracji z Git.
Badanie koncepcji sieciowych: model OSI, VLAN, przełącznik zarządzany. LazyVim do edycji, zaawansowane polecenia CLI do zarządzania.
Co warto wiedzieć
- Skalowanie od RPi do architektury x86 rozwiązuje ograniczenia wydajności bez kompromisów.
- Docker + Portainer ułatwiają wdrażanie i monitorowanie całego stosu usług selfhosted.
- Lokalny DNS + proxy zwrotne zapewniają płynny dostęp zarówno w domu, jak i zdalnie.
- Skrypty bash i systemd automatyzują kopie zapasowe, minimalizując ryzyko utraty danych.
- Selfhosting zmniejsza zależność od zewnętrznych usług w warunkach niestabilnego internetu.
Taka infrastruktura pasuje specjalistom średnio- i wysokiego poziomu, którzy chcą mieć pełną kontrolę nad danymi i usługami.
— Editorial Team
Brak komentarzy.