Jak hostować Beszel samodzielnie w 2026 roku: agenty, prywatna sieć i backupy

Najkrótsza demonstracja Beszel dowodzi, że proces nasłuchuje na porcie 8090. Środowisko produkcyjne wymaga mocniejszych dowodów. Musi przejść ten scenariusz nawet po zastąpieniu kontenera: zarejestrować agenta, wyświetlić wykresy CPU, pamięci i dysku, uruchomić alert progowy oraz ponownie połączyć agenta po restarcie huba.

Beszel jest wdrażany w konkretnym celu: lekkiego monitorowania serwerów w małym kontenerze. Najczęstsza pułapka wdrożeniowa polega na tym, że hub nie może połączyć się z portem 45876 agenta albo zmienił się jego klucz SSH, dlatego obsługa publicznego URL-a i trwały stan wymagają takiej samej uwagi jak uruchomienie obrazu.

Wyznacz granicę środowiska uruchomieniowego Beszel

W przypadku Beszel zdrowie procesu i zdrowie produktu to dwie różne kwestie. Port 8090 może odpowiadać, podczas gdy transakcja widoczna dla użytkownika nadal kończy się niepowodzeniem. Kontrakt sieciowy Beszel zakłada obecność agenta Beszel na każdej monitorowanej maszynie. Trzymaj prywatne endpointy w wewnętrznym DNS, zezwalaj wyłącznie na wymagane połączenia wychodzące i nadaj Beszel ograniczone uprawnienia service credential.

Użyj tego ćwiczenia gotowości po każdej istotnej zmianie konfiguracji: zarejestruj agenta, wyświetl wykresy CPU, pamięci i dysku, uruchom alert progowy oraz ponownie połącz agenta po restarcie huba. Nie umieszczaj kosztownych zewnętrznych kontroli w liveness probes, aby awaria dostawcy nie powodowała pętli restartów. Prace nad pojemnością powinny uwzględniać liczbę agentów, retencję metryk, storage huba oraz osiągalność sieciową każdego agenta na jego dedykowanym porcie — to lepiej odzwierciedla rzeczywiste obciążenie Beszel niż żądania stron.

Jednoznacznie określ publiczny origin

Przeglądarka, klient API i Beszel muszą korzystać z tego samego originu. Aby to osiągnąć, kieruj hub przez HTTPS i pozostaw porty agentów prywatne. Zachowaj oryginalny host i protokół, jednocześnie uniemożliwiając dostęp do portu 8090 jako konkurencyjnego publicznego adresu.

Poradnik rozwiązywania problemów z niedostępną witryną pomaga odróżnić nieosiągalną trasę od odpowiadającej aplikacji. To rozróżnienie ma tutaj znaczenie: hub nie może połączyć się z portem 45876 agenta albo zmienił się jego klucz SSH. Tylko pierwszy problem można naprawić zmianami w ingressie; drugi wymaga sprawdzenia logów Beszel, stanu lub workloadu.

Uruchom pierwszą instancję zbliżoną do produkcyjnej

Pierwszy kontener powinien dać się łatwo usunąć i odtworzyć. Trzymaj dane poza writable layer, zbindować port 8090 tylko tam, gdzie może dotrzeć proxy, i przekazuj konfigurację w runtime.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Po pierwszym teście przypnij wersję obrazu. Odczytaj najwcześniejszy błąd uruchamiania zamiast końcowego komunikatu o restarcie, zweryfikuj każdy mount za pomocą docker inspect i śledź logi podczas rejestrowania agenta, obserwowania wykresów CPU, pamięci i dysku, uruchamiania alertu progowego oraz ponownego łączenia agenta po restarcie huba. Ta sekwencja pozwala odróżnić nieprawidłową komendę obrazu od problemu z zależnością lub uprawnieniami.

Logi, które odpowiadają na kolejne pytanie

Zielony kontener jest konieczny, ale niewystarczający. Wskaźnikiem na poziomie usługi jest pomyślne wykonanie operacji „zarejestruj agenta, wyświetl wykresy CPU, pamięci i dysku, uruchom alert progowy oraz ponownie połącz agenta po restarcie huba”, a prawdopodobne sygnały przeciążenia to liczba agentów, retencja metryk, storage huba oraz osiągalność sieciowa każdego agenta na jego dedykowanym porcie.

Zarządzanie zmianą ma znaczenie, ponieważ wersje huba i agenta należy testować razem — zmiany w protokole mogą wyglądać jak ciche luki w monitoringu. Zachowaj poprzedni obraz, testuj migracje na skopiowanym stanie i udokumentuj, czy rollback jest obsługiwany po zmianie schematu. Jeśli hub nie może połączyć się z portem 45876 agenta albo zmienił się jego klucz SSH, zdiagnozuj pierwszą granicę, która różni się od działającego środowiska.

Produkcyjny test akceptacyjny Beszel

Zanim pojawią się prawdziwi użytkownicy, przygotuj arkusz wydania dla Beszel. Musi on zawierać przypięty obraz, port 8090, canonical origin, ścieżki trwałych danych oraz właściciela agenta Beszel na każdej monitorowanej maszynie. Dołącz oczekiwany wynik tej transakcji: zarejestrowanie agenta, wyświetlenie wykresów CPU, pamięci i dysku, uruchomienie alertu progowego oraz ponowne połączenie agenta po restarcie huba.

Użyj arkusza po standardowym zastąpieniu kontenera oraz po czystym odtworzeniu. Odzyskiwanie można uznać za zakończone tylko wtedy, gdy wrócą systemy, historia i alerty, a każdy odtworzony agent wznowi wysyłanie bieżących metryk. Zbierz także krótki ślad zasobów obejmujący liczbę agentów, retencję metryk, storage huba oraz osiągalność sieciową każdego agenta na jego dedykowanym porcie; przechowuj go obok wydania, aby przyszłe zmiany pojemności porównywać przy tym samym workloadzie.

Uwzględnij jedno kontrolowane uszkodzenie: tymczasowo odbierz testowej tożsamości dostęp do agenta Beszel na każdej monitorowanej maszynie. Potwierdź, że Beszel zgłasza problem na właściwej granicy, przywróć prawidłowy stan i ponownie wykonaj transakcję. Sprawdza to widoczność błędów, a nie tylko sukces, i zapobiega sytuacji, w której zdrowo wyglądający interfejs ukrywa uszkodzonego workera, callback lub połączenie z bazą danych.

Zaprojektuj odtwarzanie Beszel przed uruchomieniem

Zainwentaryzuj każdy trwały artefakt: dane huba, użytkowników, systemy i konfigurację alertów. Zamontuj /beszel_data przed bootstrapem, zapisz nieszkodliwe przykładowe dane i zastąp kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Uwzględnij konfigurację zmieniającą sposób interpretacji przechowywanych danych, a nie tylko największy katalog.

Ustaw retencję, kopiuj backupy poza hosta i wykonaj odtwarzanie w clean roomie. Ćwiczenie odtwarzania Beszel jest zakończone, gdy wrócą systemy, historia i alerty, a każdy odtworzony agent wznowi wysyłanie bieżących metryk. Jeśli plan obejmuje snapshoty, użyj wskazówek dotyczących PITR i snapshotów, aby udokumentować, co można odzyskać za pomocą każdego mechanizmu.

Zamknij tymczasowy dostęp konfiguracyjny

Przeprowadź threat modeling działania wykonywanego przez Beszel, a nie tylko jego formularza logowania. Najpoważniejszym błędem jest tutaj publikowanie listenerów agentów w internecie bez kontroli sieciowej. Wprowadź następującą granicę: trzymaj listenery agentów w prywatnych sieciach oraz chroń konto huba i klucze rejestracji.

W tej konfiguracji bazowej Beszel nie wymaga obowiązkowego sekretu bootstrapowego; chroń jego rzeczywiste konto administratora albo uwierzytelnianie po stronie upstreamu. Nie rozwiązuj błędu uprawnień, uruchamiając kontener jako root lub szeroko montując hosta. Limity zasobów również należą do projektu bezpieczeństwa, ponieważ użytkownicy mogą wpływać na liczbę agentów, retencję metryk, storage huba oraz osiągalność sieciową każdego agenta na jego dedykowanym porcie.

Przenieś powtarzalną pracę infrastrukturalną do Dockup

W przypadku Beszel Dockup jest najbardziej przydatny na granicy między obrazem a trwałą usługą. Utrzymuje trasę do portu 8090, TLS, wartości sekretów i storage podczas zastępowania kontenerów, niezależnie od tego, czy compute należy do Dockup, czy do podłączonego serwera.

Zakończ pracę, uwzględniając wiedzę o aplikacji: kieruj hub przez HTTPS i pozostaw porty agentów prywatne; połącz i przetestuj agenta Beszel na każdej monitorowanej maszynie; a następnie wykonaj tę weryfikację: zarejestruj agenta, wyświetl wykresy CPU, pamięci i dysku, uruchom alert progowy oraz ponownie połącz agenta po restarcie huba. Zachowaj wynik jako kontrolę wdrożenia, aby kolejną aktualizację obrazu oceniać na podstawie działania, a nie statusu kontenera.

Najczęściej zadawane pytania

Czego Beszel potrzebuje do wdrożenia produkcyjnego?

Kieruj kontener Beszel na porcie 8090 przez jeden origin HTTPS. Wymaganiem pomocniczym po stronie sieci jest agent Beszel na każdej monitorowanej maszynie. Nie uznawaj Beszel za gotowy, dopóki nie możesz zarejestrować agenta, wyświetlić wykresów CPU, pamięci i dysku, uruchomić alertu progowego oraz ponownie połączyć agenta po restarcie huba.

Które dane Beszel powinny znaleźć się w backupie?

Utrwal /beszel_data i uwzględnij dane huba, użytkowników, systemy oraz konfigurację alertów w tym samym manifeście odtwarzania. Czyste odtworzenie Beszel kończy się powodzeniem tylko wtedy, gdy wrócą systemy, historia i alerty, a każdy odtworzony agent wznowi wysyłanie bieżących metryk.

Czy Beszel wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Beszel i pozostaw port 8090 na trasie wewnętrznej. Zastosuj prawidłową konfigurację Beszel: kieruj hub przez HTTPS i pozostaw porty agentów prywatne. W przypadku Beszel HTTPS chroni przesyłane dane uwierzytelniające lub treści użytkowników oraz zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Beszel?

Odtwórz bieżący stan Beszel w odizolowanym wdrożeniu, zastosuj wersję kandydującą i ponownie wykonaj transakcję akceptacyjną. Zwróć szczególną uwagę na to, że wersje huba i agenta należy testować razem — zmiany w protokole mogą wyglądać jak ciche luki w monitoringu. Zachowaj poprzedni obraz Beszel do czasu poznania granic migracji danych i rollbacku.