Jak v roce 2026 provozovat Beszel ve vlastní infrastruktuře: agenti, privátní síť a zálohy

Nejkratší demo Beszelu prokáže, že proces naslouchá na portu 8090. Produkce vyžaduje přesvědčivější důkazy. Tento scénář musí projít i po nahrazení kontejneru: zaregistrovat agenta, sledovat grafy CPU, paměti a disku, vyvolat alert při překročení prahové hodnoty a znovu připojit agenta po restartu hubu.

Beszel se nasazuje z jasného důvodu: pro lightweight monitoring serveru v malém kontejneru. Nejčastější past při nasazení spočívá v tom, že hub se nemůže připojit k portu 45876 na agentovi nebo se změnil jeho SSH klíč. Proto je potřeba věnovat práci s veřejnou URL a trvalým stavem stejnou pozornost jako spuštění image.

Vymezte hranice runtime Beszelu

U Beszelu jsou health procesu a health produktu dvě odlišné věci. Port 8090 může odpovídat, i když transakce viditelná pro uživatele stále selhává. Síťový kontrakt Beszelu vyžaduje agenta Beszelu na každém monitorovaném stroji. Privátní endpointy ponechte na interním DNS, povolte pouze potřebná odchozí volání a Beszelu přidělte service credential s omezeným rozsahem oprávnění.

Toto ověření připravenosti proveďte po každé významné změně konfigurace: zaregistrujte agenta, sledujte grafy CPU, paměti a disku, vyvolejte alert při překročení prahové hodnoty a znovu připojte agenta po restartu hubu. Nákladné externí kontroly nepřidávejte do liveness probes, aby výpadek poskytovatele nevyvolal restartovací smyčku. Při plánování kapacity sledujte počet agentů, retenci metrik, úložiště hubu a dostupnost sítě ke každému agentovi na jeho dedikovaném portu. To lépe odpovídá skutečnému zatížení Beszelu než požadavky na stránky.

Zajistěte jednoznačný veřejný origin

Prohlížeč, API klient a Beszel se musí shodnout na jednom originu. Toho dosáhnete směrováním hubu přes HTTPS a ponecháním portů agentů v privátní síti. Zachovejte původní host a protokol a zároveň zajistěte, aby port 8090 nebyl dostupný jako konkurenční veřejná adresa.

Průvodce řešením problémů s nedostupným webem pomáhá rozlišit nedostupnou route od aplikace, která odpovídá. V tomto případě je rozdíl důležitý: hub se nemůže připojit k portu 45876 na agentovi nebo se změnil jeho SSH klíč. Změny na ingressu opraví pouze první problém; druhý vyžaduje kontrolu logů Beszelu, stavu nebo workloadu.

Spusťte první instanci ve tvaru odpovídajícím produkci

První kontejner by mělo být snadné odstranit a znovu vytvořit. Data uchovávejte mimo writable layer, port 8090 namapujte pouze tam, kam se dostane proxy, a konfiguraci předávejte při 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 úvodním testu image připněte na konkrétní verzi. Přečtěte si nejstarší chybu při startu, ne až poslední zprávu o restartu, každý mount ověřte pomocí docker inspect a sledujte logy během registrace agenta, sledování grafů CPU, paměti a disku, vyvolání alertu při překročení prahové hodnoty a opětovného připojení agenta po restartu hubu. Tato posloupnost odliší chybný příkaz image od problému se závislostí nebo oprávněními.

Logy, které zodpoví další otázku

Zelený kontejner je nutnou, nikoli však dostačující podmínkou. SLI na úrovni služby představuje úspěšné dokončení akce „zaregistrovat agenta, sledovat grafy CPU, paměti a disku, vyvolat alert při překročení prahové hodnoty a znovu připojit agenta po restartu hubu“. Pravděpodobnými signály zatížení jsou počet agentů, retence metrik, úložiště hubu a dostupnost sítě ke každému agentovi na jeho dedikovaném portu.

Na řízení změn záleží, protože verze hubu a agentů by se měly testovat společně. Změny protokolu mohou vypadat jako nenápadné mezery v monitoringu. Ponechte si starou image, migrace testujte na kopii stavu a zdokumentujte, zda je rollback po změně schématu podporován. Pokud se hub nemůže připojit k portu 45876 na agentovi nebo se změnil jeho SSH klíč, diagnostikujte první hranici, která se liší od funkčního prostředí.

Produkční akceptační test Beszelu

Než dorazí skuteční uživatelé, připravte pro Beszel release worksheet. Musí v něm být uvedena připnutá image, port 8090, canonical origin, persistentní cesty a vlastník agenta Beszelu na každém monitorovaném stroji. Přiložte očekávaný výsledek této transakce: zaregistrovat agenta, sledovat grafy CPU, paměti a disku, vyvolat alert při překročení prahové hodnoty a znovu připojit agenta po restartu hubu.

Worksheet použijte po běžné náhradě i po čisté obnově. Obnova je úspěšná pouze tehdy, pokud se vrátí systémy, historie i alerty a každý obnovený agent začne znovu odesílat aktuální metriky. Shromážděte také krátký resource trace zahrnující počet agentů, retenci metrik, úložiště hubu a dostupnost sítě ke každému agentovi na jeho dedikovaném portu. Uchovávejte ho u release, aby bylo možné budoucí změny kapacity porovnávat se stejným workloadem.

Zahrňte jednu řízenou poruchu: dočasně odeberte testovací identitě přístup k agentovi Beszelu na každém monitorovaném stroji. Ověřte, že Beszel ohlásí problém na správné hranici, obnovte platné podmínky a transakci spusťte znovu. Tím ověříte viditelnost chyb, nikoli pouze úspěch, a zabráníte tomu, aby zdravě vypadající rozhraní skrývalo nefunkční worker, callback nebo připojení k databázi.

Navrhněte obnovu Beszelu ještě před spuštěním

Seznamte všechny trvalé artefakty: data hubu, uživatele, systémy a konfiguraci alertů. Před bootstrapem namountujte /beszel_data, zapište neškodná testovací data a nahraďte kontejner, abyste prokázali, že je tato cesta skutečně persistentní. Zahrňte také konfiguraci, která mění způsob interpretace uložených dat, nikoli pouze největší adresář.

Nastavte retenci, kopírujte zálohy mimo hostitele a proveďte obnovu v čistém prostředí. Drill Beszelu je dokončen, když se vrátí systémy, historie i alerty a každý obnovený agent začne znovu odesílat aktuální metriky. Pokud jsou součástí plánu snapshots, použijte pokyny k PITR versus snapshotům a zdokumentujte, co lze pomocí jednotlivých mechanismů obnovit.

Zrušte dočasný přístup pro setup

Při threat modelingu se zaměřte na akci, kterou Beszel provádí, nejen na jeho přihlašovací formulář. Zde je vysoce rizikovou chybou vystavení listenerů agentů do internetu bez síťových kontrol. Nastavte tuto hranici: listenery agentů ponechte v privátních sítích a chraňte účet hubu i enrollment keys.

Beszel v této základní konfiguraci nevyžaduje povinný bootstrap secret; místo toho chraňte skutečný administrátorský účet nebo upstream authentication. Chybu oprávnění neřešte spuštěním kontejneru jako root ani širokým mountováním hostitele. Součástí bezpečnostního návrhu jsou i resource limits, protože uživatelé mohou ovlivnit počet agentů, retenci metrik, úložiště hubu a dostupnost sítě ke každému agentovi na jeho dedikovaném portu.

Přesuňte opakovatelnou infrastrukturní práci do Dockupu

U Beszelu je Dockup nejužitečnější na hranici mezi image a trvalou službou. Udržuje route na port 8090, TLS, hodnoty secretů a storage připojené i po nahrazení kontejnerů, bez ohledu na to, zda výpočetní prostředky poskytuje Dockup, nebo váš připojený server.

Dokončete nasazení znalostí aplikace: směrujte hub přes HTTPS a porty agentů ponechte v privátní síti; připojte a otestujte agenta Beszelu na každém monitorovaném stroji; a proveďte toto ověření: zaregistrujte agenta, sledujte grafy CPU, paměti a disku, vyvolejte alert při překročení prahové hodnoty a znovu připojte agenta po restartu hubu. Výsledek si uložte jako deployment check, aby se další aktualizace image posuzovala podle chování, nikoli podle stavu kontejneru.

Často kladené otázky

Co Beszel potřebuje pro produkční nasazení?

Kontejner Beszelu směrujte přes port 8090 na jediný HTTPS origin. Podmínkou pro podpůrnou síť je agent Beszelu na každém monitorovaném stroji. Beszel nepovažujte za připravený, dokud nedokážete zaregistrovat agenta, sledovat grafy CPU, paměti a disku, vyvolat alert při překročení prahové hodnoty a znovu připojit agenta po restartu hubu.

Která data Beszelu patří do zálohy?

Uchovávejte /beszel_data a do stejného recovery manifestu zahrňte data hubu, uživatele, systémy a konfiguraci alertů. Čistá obnova Beszelu je úspěšná pouze tehdy, pokud se vrátí systémy, historie i alerty a každý obnovený agent začne znovu odesílat aktuální metriky.

Vyžaduje Beszel za reverse proxy HTTPS?

Pro veřejný origin Beszelu používejte HTTPS a port 8090 ponechte na interní route. Nastavení Beszelu aplikujte správně: směrujte hub přes HTTPS a porty agentů ponechte v privátní síti. U Beszelu HTTPS chrání credentials nebo uživatelský obsah při přenosu a zajišťuje konzistentní chování klienta závislé na originu.

Jak testovat upgrade Beszelu?

Obnovte aktuální stav Beszelu v izolovaném deploymentu, aplikujte kandidátní verzi a zopakujte akceptační transakci. Zvláštní pozornost věnujte tomu, že verze hubu a agentů by se měly testovat společně, protože změny protokolu mohou vypadat jako nenápadné mezery v monitoringu. Předchozí image Beszelu si ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.