A Beszel saját üzemeltetése 2026-ban: agentek, privát hálózat és biztonsági mentések

A legrövidebb Beszel-demó azt bizonyítja, hogy egy process figyel a 8090-es porton. Production környezetben ennél erősebb bizonyítékra van szükség. A rendszernek ezt a forgatókönyvet akkor is teljesítenie kell, ha a containert lecseréltük: regisztrálj egy agentet, figyeld a CPU-, memória- és lemezgrafikonokat, válts ki egy küszöbérték-riasztást, majd hub-újraindítás után csatlakoztasd újra az agentet.

A Beszelt egyértelmű célra telepítik: könnyűsúlyú szervermonitorozásra egy kisebb containerben. A leggyakoribb deployment-csapda, hogy a hub nem éri el az agent 45876-os portját, vagy megváltozott az SSH-kulcsa, ezért a publikus URL kezelésére és a tartós állapotra ugyanannyi figyelmet kell fordítani, mint az image indulására.

A Beszel futtatási határainak feltérképezése

A process állapota és a termék állapota két külön dolog a Beszelnél. A 8090-es port válaszolhat úgy is, hogy a felhasználó által indított tranzakció mégis meghiúsul. A Beszel hálózati szerződésének része, hogy minden monitorozott gépen fusson egy Beszel agent. A privát endpointokat tartsd belső DNS-en, csak a szükséges kimenő kapcsolatokat engedélyezd, és adj a Beszelnek korlátozott hatókörű service credentialt.

Ezt a readiness-ellenőrzést minden érdemi konfigurációmódosítás után futtasd le: regisztrálj egy agentet, figyeld a CPU-, memória- és lemezgrafikonokat, válts ki egy küszöbérték-riasztást, majd hub-újraindítás után csatlakoztasd újra az agentet. A költséges külső ellenőrzéseket hagyd ki a liveness probe-okból, hogy egy provider kiesése ne indítson el restart loopot. A kapacitástervezésnek az agentek számát, a metrikák megőrzési idejét, a hub tárhelyigényét és az egyes agentek dedikált portján elérhető hálózati kapcsolatot kell követnie, mert ezek jobban tükrözik a Beszel valós terhelését, mint az oldalbetöltések.

A publikus origin egyértelművé tétele

A böngészőnek, az API kliensnek és a Beszelnek ugyanabban az originben kell megegyeznie. Ehhez a hubot HTTPS-en keresztül irányítsd, az agentportokat pedig tartsd privátan. Őrizd meg az eredeti hostot és protokollt, miközben a 8090-es portot ne tedd elérhetővé konkurens publikus címként.

A webhely elérhetetlenségének elhárításáról szóló útmutató segít megkülönböztetni az elérhetetlen route-ot a válaszoló alkalmazástól. Ez itt fontos különbség: a hub nem éri el az agent 45876-os portját, vagy megváltozott az SSH-kulcsa. Ingress-módosítás csak az előbbi problémát oldja meg; az utóbbihoz Beszel-logok, state vagy a workload vizsgálata szükséges.

Az első production jellegű példány futtatása

Az első containert könnyű legyen törölni és újra létrehozni. Az adatokat tartsd a writable layeren kívül, a 8090-es portot csak azon a hálózati felületen publikáld, amelyet a proxy elér, a konfigurációt pedig runtime-ban add át.

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

Az első teszt után pineld az imaget. A legkorábbi startup hibát olvasd el, ne a végső restart üzenetből indulj ki, minden mountot ellenőrizz a docker inspect használatával, és kövesd a logokat, miközben regisztrálsz egy agentet, figyeled a CPU-, memória- és lemezgrafikonokat, küszöbérték-riasztást váltasz ki, majd hub-újraindítás után újracsatlakoztatod az agentet. Ez a sorrend megkülönbözteti a hibás image commandot a dependency- vagy jogosultsági problémától.

A következő kérdésre választ adó logok

A zöld container szükséges, de önmagában nem elég. A service-level indicator a „regisztrálj egy agentet, figyeld a CPU-, memória- és lemezgrafikonokat, válts ki egy küszöbérték-riasztást, majd hub-újraindítás után csatlakoztasd újra az agentet” műveletsor sikeres végrehajtása, a várható terhelési jelek pedig az agentek száma, a metrikák megőrzési ideje, a hub tárhelyigénye és az egyes agentek dedikált portján elérhető hálózati kapcsolat.

A change control azért fontos, mert a hub és az agent verzióit együtt kell tesztelni: a protocolváltozások észrevétlen monitorozási hiányosságoknak tűnhetnek. Őrizd meg a régi imaget, a migrationöket másolt state-en teszteld, és dokumentáld, hogy támogatott-e a rollback a séma módosítása után. Ha a hub nem éri el az agent 45876-os portját, vagy megváltozott az SSH-kulcsa, akkor azt az első határt vizsgáld meg, amely eltér a működő környezettől.

Production acceptance run a Beszelhez

Mielőtt a valódi felhasználók megérkeznek, készíts release worksheetet a Beszelhez. Nevezze meg a pinelt imaget, a 8090-es portot, a canonical origint, a perzisztens útvonalakat és a minden monitorozott gépen futó Beszel agent felelősét. Csatold hozzá ennek a tranzakciónak az elvárt eredményét: regisztrálj egy agentet, figyeld a CPU-, memória- és lemezgrafikonokat, válts ki egy küszöbérték-riasztást, majd hub-újraindítás után csatlakoztasd újra az agentet.

A worksheetet egy normál replacement és egy tiszta restore után is használd. A helyreállítás csak akkor fogadható el, ha a rendszerek, az előzmények és a riasztások visszaállnak, és minden helyreállított agent ismét aktuális metrikákat küld. Gyűjts egy rövid resource trace-t is, amely lefedi az agentek számát, a metrikák megőrzési idejét, a hub tárhelyigényét és az egyes agentek dedikált portján elérhető hálózati kapcsolatot; ezt tartsd a release mellett, hogy a jövőbeli kapacitásváltozásokat azonos workload mellett lehessen összehasonlítani.

Vegyél fel egy kontrollált hibát is: ideiglenesen vond meg a tesztidentitás hozzáférését egy Beszel agenthez minden monitorozott gépen. Ellenőrizd, hogy a Beszel a megfelelő határon jelzi a problémát, állítsd vissza az érvényes állapotot, majd futtasd újra a tranzakciót. Ez nem csupán a sikert, hanem a hibák láthatóságát is ellenőrzi, és megakadályozza, hogy egy egészségesnek tűnő felület elfedjen egy hibás workert, callbacket vagy adatbázis-kapcsolatot.

A Beszel restore megtervezése az indulás előtt

Vedd számba az összes tartós artifactot: a hub adatait, a felhasználókat, a rendszereket és a riasztási konfigurációt. A bootstrap előtt csatold fel a /beszel_data útvonalat, írj bele ártalmatlan mintaadatokat, majd cseréld le a containert annak bizonyítására, hogy az útvonal valóban perzisztens. Olyan konfigurációt is vegyél fel, amely megváltoztatja a tárolt adatok értelmezését, ne csak a legnagyobb könyvtárat.

Állítsd be a retentiont, másold a backupokat a hoston kívülre, és futtass clean-room restore-t. A Beszel-helyreállítás akkor teljes, ha a rendszerek, az előzmények és a riasztások visszatérnek, és minden helyreállított agent ismét aktuális metrikákat küld. Ha a terv részei a snapshotok, használd a PITR és a snapshotok összehasonlításáról szóló útmutatót, és dokumentáld, hogy az egyes mechanizmusok mit képesek helyreállítani.

Az ideiglenes setup-hozzáférés lezárása

A Beszel által végrehajtott műveletet threat modellezd, ne csak a login formot. Itt az a nagy kockázatú hiba, ha hálózati kontrollok nélkül publikálod az agent listenereket az internetre. Alakítsd ki ezt a határt: az agent listenerei maradjanak privát hálózatokon, a hub accountját és az enrollment keyket pedig védd.

Ebben a baseline-ban a Beszel nem igényel kötelező bootstrap secretet; helyette a tényleges administrator accountot vagy az upstream authenticationt védd. Jogosultsági hibát ne úgy oldj meg, hogy rootként futtatod a containert, vagy széles körben felcsatolod a hostot. A resource limitek szintén a security design részét képezik, mivel a felhasználók által kiváltott terhelés érintheti az agentek számát, a metrikák megőrzési idejét, a hub tárhelyigényét és az egyes agentek dedikált portján elérhető hálózati kapcsolatot.

A megismételhető infrastruktúramunkák áthelyezése a Dockupra

A Beszel esetében a Dockup ott a leghasznosabb, ahol az image-ből tartós service lesz. A 8090-es route-ot, a TLS-t, a secret értékeket és a storage-ot a containercserék során is együtt tartja, függetlenül attól, hogy a compute a Dockuphoz vagy a csatlakoztatott szerveredhez tartozik.

A lezáráshoz alkalmazásszintű ismeretekre van szükség: a hubot HTTPS-en keresztül irányítsd, az agentportokat pedig tartsd privátan; csatlakoztass és tesztelj egy Beszel agentet minden monitorozott gépen; majd futtasd le ezt az ellenőrzést: regisztrálj egy agentet, figyeld a CPU-, memória- és lemezgrafikonokat, válts ki egy küszöbérték-riasztást, majd hub-újraindítás után csatlakoztasd újra az agentet. Az eredményt deployment checkként őrizd meg, hogy a következő image-frissítés megítélése a működésen, ne pusztán a container státuszán alapuljon.

Gyakran ismételt kérdések

Mire van szüksége a Beszelnek production deploymenthez?

A Beszel containert a 8090-es porton keresztül, egyetlen HTTPS originen tedd elérhetővé. A kapcsolódó hálózati követelmény az, hogy minden monitorozott gépen fusson egy Beszel agent. Ne tekintsd késznek a Beszelt addig, amíg nem tudsz regisztrálni egy agentet, megfigyelni a CPU-, memória- és lemezgrafikonokat, kiváltani egy küszöbérték-riasztást, majd hub-újraindítás után újracsatlakoztatni az agentet.

Mely Beszel-adatok tartoznak a backupba?

Tartsd perzisztensen a /beszel_data útvonalat, és a hub adatait, a felhasználókat, a rendszereket, valamint a riasztási konfigurációt ugyanabba a recovery manifestbe vedd fel. A clean Beszel restore csak akkor sikeres, ha a rendszerek, az előzmények és a riasztások visszatérnek, és minden helyreállított agent ismét aktuális metrikákat küld.

Szüksége van a Beszelnek HTTPS-re reverse proxy mögött?

A publikus Beszel originhez használj HTTPS-t, a 8090-es portot pedig tartsd a belső route-on. A Beszel beállítását helyesen alkalmazd: a hubot HTTPS-en keresztül irányítsd, az agentportokat pedig tartsd privátan. A Beszel esetében a HTTPS védi a credentialeket és a felhasználói tartalmakat átvitel közben, valamint egységessé teszi az originérzékeny kliensviselkedést.

Hogyan kell tesztelni egy Beszel-frissítést?

A jelenlegi Beszel-state-et állítsd vissza egy izolált deploymentbe, alkalmazd a jelölt verziót, majd ismételd meg az acceptance tranzakciót. Különösen figyelj arra, hogy a hub és az agent verzióit együtt kell tesztelni, mert a protocolváltozások észrevétlen monitorozási hiányosságoknak tűnhetnek. A korábbi Beszel-imaget addig őrizd meg, amíg nem érted az adatmigration és a rollback határát.