Jak przeniosłem serwer domowy z Dockhanda i Nginx Proxy Managera na Stackmoor

Mój domowy serwer przez długi czas działał na zestawie narzędzi, które same w sobie były w porządku, ale razem tworzyły coraz większy bałagan. Dockhand do stacków, Nginx Proxy Manager do lokalnych adresów, kilka własnych skryptów do pilnowania serwera i osobne pomysły na kopie zapasowe. W końcu postanowiłem to uprościć. Skończyło się na tym, że napisałem własny panel, Stackmoor, i przeniosłem na niego cały serwer.

W tym wpisie opisuję, dlaczego to zrobiłem, jak wyglądała przeprowadzka i na jakie problemy trafiłem po drodze.

Jak wygląda mój homelab

Krótko, żeby było wiadomo, o czym mowa:

• domowy serwer z Linuxem, na którym stoją aplikacje w Dockerze. Działa cały czas i sam się włącza, gdy po przerwie wróci prąd,
• osobny serwer Unraid z kontenerami, do tego NAS-y i KVM. Te urządzenia nie muszą chodzić non stop, więc budzę je, kiedy są potrzebne,
• kilka VPS-ów u różnych dostawców,
• dostęp z zewnątrz wyłącznie przez VPN UniFi (z telefonu lub laptopa przez aplikację WiFiman). Nic z domu nie jest wystawione do internetu.

Ten zawsze włączony serwer pełni więc ważną rolę: to od niego zaczyna się wszystko inne. Działa na nim UpSnap, czyli aplikacja do Wake-on-LAN. Gdy jestem poza domem, łączę się przez WiFiman z VPN-em UniFi, otwieram UpSnapa i jednym kliknięciem budzę Unraida czy NAS-a. Po przerwie w dostawie prądu nie muszę nikogo prosić, żeby poszedł i wcisnął przycisk.

Aplikacje mają lokalne adresy w stylu aplikacja.dom.example.com. Wskazują one na prywatne IP w sieci domowej (np. 192.168.1.10), a certyfikaty Let's Encrypt wydaję przez DNS, bo serwer i tak nie jest dostępny z internetu.

Jak było wcześniej

• Dockhand zarządzał stackami docker compose.
• Nginx Proxy Manager obsługiwał lokalne adresy z certyfikatami, także dla innych urządzeń w sieci: NAS-ów, Unraida, KVM.
• Własne skrypty pilnowały serwera. Jeden z nich co 10 minut wysyłał powiadomienie na Pushovera, czyli w praktyce zwykły spam, który przestałem czytać.
• Kopie zapasowe i domeny ogarniałem osobnymi narzędziami.

Dlaczego zmiana

Dockhand był dla mnie za skomplikowany na co dzień

Przy każdym stacku ręcznie ustawiałem wolumeny i sieci w compose. Brakowało mi prostoty Dockge, gdzie foldery na dane po prostu tworzą się same obok pliku compose.

Bałem się o dane

Bezpośrednim impulsem był Termix, czyli webowy klient SSH, przez który łączę się z VPS-ami. Uświadomiłem sobie, że jeśli stracę jego dane, stracę całą konfigurację połączeń.

Panele do Dockera zwykle zostawiają kopie zapasowe zewnętrznym aplikacjom. A większość narzędzi do kopii po prostu kopiuje pliki, także pliki działającej bazy danych. Taka kopia może się nie nadawać do przywrócenia, bo baza była w trakcie zapisu. Poprawnie robi się to przez zrzut bazy, a tego mi brakowało.

Za dużo osobnych narzędzi

Panel, proxy, skrypty, kopie. Każde trzeba osobno konfigurować, aktualizować i pilnować. Im więcej elementów, tym większa szansa, że o którymś zapomnę.

Zmienny adres IP w domu

Zapory na VPS-ach wpuszczają SSH tylko ze stałego adresu mojego tunelu WireGuard. Domowe IP się zmienia, więc Termix musi łączyć się z VPS-ami przez ten tunel. Nie chciałem jednak puszczać przez VPN całego serwera, tylko tę jedną aplikację.

Powiadomienia, które coś znaczą

Zamiast spamu co 10 minut chciałem dostawać wiadomość tylko wtedy, gdy naprawdę coś się dzieje: kopia się nie udała, aktualizacja się wywaliła, stack przestał działać.

Porządek i bezpieczeństwo

Automatyczne łatki systemu, aktualizacje aplikacji z możliwością cofnięcia i jedno miejsce, w którym widać stan wszystkiego.

Dlaczego własne narzędzie

Szukałem panelu, który łączy to wszystko w prostym interfejsie, i nie znalazłem. Były świetne narzędzia do pojedynczych rzeczy, ale nic, co obejmowałoby stacki, kopie z bazami, domeny i VPN dla wybranych aplikacji naraz.

Napisałem więc Stackmoor. Jest otwarty (licencja AGPL-3.0), darmowy i instaluje się jednym poleceniem.

Uczciwie: kod powstaje z pomocą AI (Claude). Ja decyduję, co i jak ma działać, sprawdzam kod, testuję go na własnych serwerach i używam Stackmoora na co dzień. Piszę o tym wprost także w README projektu.

Co potrafi

• Stacki docker compose z automatycznymi wolumenami w ./data, tak jak w Dockge.
• Kopie zapasowe na S3/B2 przez restic: szyfrowane, z sumami kontrolnymi, z retencją i przywracaniem. Bazy danych (PostgreSQL, MySQL/MariaDB, SQLite i inne) są zrzucane poprawnie, a nie kopiowane jako pliki.
• Lokalne domeny z certyfikatem wildcard wydawanym przez API dostawcy DNS. Rekord DNS tworzy się sam.
• Proxy dla innych urządzeń w sieci (NAS, Unraid, KVM), czyli to, do czego używałem Nginx Proxy Managera.
• VPN (WireGuard) tylko dla wybranych aplikacji, z kill switchem: jeśli tunel padnie, aplikacja nie wyjdzie do internetu bokiem.
• Automatyczne aktualizacje stacków z kopią przed aktualizacją i powrotem do poprzedniej wersji, jeśli nowa się nie uruchomi.
• Restart serwera z panelu i według harmonogramu, automatyczne łatki systemu (Debian/Ubuntu). Po restarcie panel sam podnosi stacki.
• Powiadomienia: e-mail, Telegram, ntfy, Pushover i webhooki.

Najnowsza funkcja to publiczne adresy przez Pangolina, z logowaniem przed aplikacją. Jest świeża i wciąż ją testuję, więc na razie traktuję ją jako nowość, a nie coś sprawdzonego.

Jak wyglądała przeprowadzka

Od zera, bez importu

Nie przenosiłem starych konfiguracji. Usunąłem Dockhanda i Nginx Proxy Managera razem z danymi, a aplikacje postawiłem na nowo. Czysty start okazał się prostszy niż przepisywanie konfiguracji, z których część pamiętała jeszcze dawne eksperymenty.

Instalacja

Instalacja to jedno polecenie (aktualne znajdziesz w dokumentacji), a potem kreator pierwszego uruchomienia: domena, dostawca DNS i certyfikat. Po kilku minutach panel działał pod lokalnym adresem z ważnym certyfikatem.

Co przeniosłem

• Termix: działa przez VPN, więc łączy się z VPS-ami ze stałego adresu tunelu.
• UpSnap do budzenia urządzeń przez Wake-on-LAN, o którym pisałem wyżej. To dla mnie kluczowa aplikacja, więc musiała działać od pierwszego dnia. Pakiety WoL muszą trafić do całej sieci lokalnej, dlatego ten stack działa z network_mode: host. Stackmoor po starcie serwera sam podnosi stacki, więc po powrocie prądu UpSnap jest gotowy bez mojej pomocy.
• EasyCopy, mój własny archiwizator stron.
• NAS-y, Unraid i KVM dodałem jako „Proxy”, więc mają lokalne adresy z certyfikatem, tak jak wcześniej w NPM.

Przykładowy stack UpSnapa wygląda tak:

services:
  upsnap:
    image: ghcr.io/seriousm4x/upsnap:5
    network_mode: host
    restart: unless-stopped
    volumes:
      - ./data:/app/pb_data

Folder ./data tworzy się sam, a Stackmoor obejmuje go kopią zapasową.

Problemy po drodze

Unraid przez proxy: biały ekran

Po dodaniu Unraida jako proxy dostawałem biały ekran, a potem przeglądarka przeskakiwała na adres IP z portem, np. http://192.168.1.20:8080. Przyczyna: Unraid przekierowuje na swój pełny adres. Nginx Proxy Manager po cichu poprawiał takie przekierowania, Caddy (na którym stoi proxy w Stackmoorze) nie.

Poprawiłem to w wersji 0.9.2: przekierowania na adres serwera są teraz zamieniane z powrotem na domenę, więc Unraid działa normalnie pod unraid.dom.example.com.

Stary skrypt dalej spamował

Po przeprowadzce Pushover nadal co 10 minut dostawał powiadomienia. Okazało się, że stary skrypt monitorujący wciąż siedział w cronie. Trzeba go było znaleźć i usunąć. Jego rolę przejęły wbudowane powiadomienia Stackmoora, które odzywają się tylko wtedy, gdy coś jest nie tak.

Ruch do sieci domowej szedł przez VPN

Na początku aplikacje puszczone przez WireGuard wysyłały przez tunel także ruch do sieci lokalnej, więc nie widziały np. NAS-a. Poprawiłem to: sieci prywatne (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) idą zwykłą drogą, a przez VPN tylko reszta.

Co zyskałem

• Jedno miejsce zamiast kilku narzędzi: stacki, kopie, domeny, proxy, VPN, aktualizacje i powiadomienia.
• Spokój o dane: kopie razem z bazami, sprawdzane sumami kontrolnymi, z przywracaniem jednym kliknięciem.
• Mniej ręcznej roboty: certyfikaty, DNS, aktualizacje i restarty dzieją się same.
• Powiadomienia, które czytam, bo przychodzą tylko wtedy, gdy coś jest nie tak.

Linki

• Strona projektu: stackmoor.dev
• Dokumentacja (PL i EN): docs.stackmoor.dev
• Kod źródłowy: github.com/gadziunet/stackmoor

Jeśli wypróbujesz Stackmoora u siebie, daj znać, co działa, a co nie. Zgłoszenia na GitHubie są mile widziane.