Slik self-hoster du Beszel i 2026: agenter, privat nettverk og sikkerhetskopier

Den korteste Beszel-demoen viser at en prosess lytter på port 8090. Produksjon krever sterkere bevis. Dette scenariet må fungere selv etter at containeren er erstattet: registrer en agent, overvåk CPU-, minne- og diskgrafer, utløse et terskelvarsel og koble agenten til på nytt etter en omstart av huben.

Beszel tas i bruk for et tydelig formål: lettvekts serverovervåking i en liten container. Den vanligste feilen i utrullingen er at huben ikke får kontakt med port 45876 på en agent, eller at SSH-nøkkelen er endret. Derfor må håndtering av offentlig URL og persistent state få like mye oppmerksomhet som oppstart av imaget.

Tegn runtime-grensen for Beszel

Prosesshelse og produkthelse er to forskjellige ting i Beszel. Port 8090 kan svare selv om transaksjonen sett fra brukerens side fortsatt mislykkes. Nettverkskontrakten for Beszel er en Beszel-agent på hver maskin som overvåkes. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Beszel en avgrenset service credential.

Bruk denne readiness-øvelsen etter vesentlige konfigurasjonsendringer: registrer en agent, overvåk CPU-, minne- og diskgrafer, utløse et terskelvarsel og koble agenten til på nytt etter en omstart av huben. Hold kostbare eksterne sjekker utenfor liveness probes, slik at et tjenesteavbrudd hos en leverandør ikke fører til en restart loop. Kapasitetsarbeidet bør følge med på antall agenter, metrics retention, hub-lagring og nettverkstilgjengelighet til hver agent på den dedikerte porten. Dette gjenspeiler Beszels reelle belastning bedre enn sideforespørsler.

Gjør den offentlige origin entydig

Nettleseren, API-klienten og Beszel må være enige om én origin. For å oppnå dette må du rute huben gjennom HTTPS og holde agentportene private. Bevar den opprinnelige hosten og protokollen, samtidig som port 8090 ikke er tilgjengelig som en konkurrerende offentlig adresse.

Veiledningen for feilsøking når nettstedet er nede hjelper deg med å skille mellom en utilgjengelig route og en applikasjon som svarer. Dette skillet er viktig her: huben får ikke kontakt med port 45876 på en agent, eller SSH-nøkkelen er endret. Bare det første løses ved å endre ingress; det andre krever inspeksjon av Beszel-logger, state eller workload.

Kjør den første produksjonsnære instansen

Den første containeren bør være enkel å slette og opprette på nytt. Hold data utenfor det skrivbare laget, bind port 8090 bare der proxien kan nå den, og send inn konfigurasjon ved runtime.

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

Lås imaget etter den første testen. Les den tidligste oppstartsfeilen i stedet for den siste restart-meldingen, verifiser hver mount med docker inspect, og følg loggene mens du registrerer en agent, overvåker CPU-, minne- og diskgrafer, utløser et terskelvarsel og kobler agenten til på nytt etter en omstart av huben. Denne sekvensen skiller en feilaktig image-kommando fra et problem med en dependency eller tillatelser.

Logger som besvarer det neste spørsmålet

En grønn container er nødvendig, men ikke tilstrekkelig. Service-level-indikatoren er vellykket gjennomføring av «registrer en agent, overvåk CPU-, minne- og diskgrafer, utløse et terskelvarsel og koble agenten til på nytt etter en omstart av huben». De sannsynlige belastningssignalene er antall agenter, metrics retention, hub-lagring og nettverkstilgjengelighet til hver agent på den dedikerte porten.

Endringskontroll er viktig fordi hub- og agentversjoner bør testes sammen. Protokollendringer kan se ut som stille hull i overvåkingen. Ta vare på det gamle imaget, test migreringer på en kopi av state, og dokumenter om rollback støttes etter at schemaet er endret. Hvis huben ikke får kontakt med port 45876 på en agent, eller SSH-nøkkelen er endret, må du diagnostisere den første grensen som skiller seg fra miljøet der alt fungerer.

En produksjonsklar akseptansetest for Beszel

Før de faktiske brukerne kommer, bør du lage et release-ark for Beszel. Det må angi pinned image, port 8090, canonical origin, persistente paths og hvem som har ansvar for en Beszel-agent på hver maskin som overvåkes. Legg ved forventet resultat for denne transaksjonen: registrer en agent, overvåk CPU-, minne- og diskgrafer, utløse et terskelvarsel og koble agenten til på nytt etter en omstart av huben.

Bruk arket etter en normal utskifting og etter en ren gjenoppretting. Recovery godkjennes bare hvis systemer, historikk og varsler kommer tilbake, og alle gjenopprettede agenter fortsetter å sende aktuelle metrics. Samle også inn en kort ressursmåling som dekker antall agenter, metrics retention, hub-lagring og nettverkstilgjengelighet til hver agent på den dedikerte porten. Oppbevar den sammen med releasen, slik at fremtidige kapasitetsendringer kan sammenlignes med samme workload.

Ta med én kontrollert feil: nekt midlertidig testidentiteten tilgang til en Beszel-agent på hver maskin som overvåkes. Bekreft at Beszel rapporterer problemet ved riktig grense, gjenopprett den gyldige tilstanden og kjør transaksjonen på nytt. Dette tester synligheten av feil, ikke bare suksess, og hindrer at et grensesnitt som ser friskt ut skjuler en ødelagt worker, callback eller databaseforbindelse.

Utform gjenoppretting av Beszel før lansering

Kartlegg alle persistente artefakter: hub-data, brukere, systemer og varslingskonfigurasjon. Mount /beszel_data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at denne banen faktisk er persistent. Ta med konfigurasjon som endrer hvordan lagrede data tolkes, ikke bare den største katalogen.

Definer retention, kopier sikkerhetskopier utenfor hosten og gjennomfør en clean-room restore. Beszel-øvelsen er fullført når systemer, historikk og varsler kommer tilbake, og alle gjenopprettede agenter fortsetter å sende aktuelle metrics. Hvis snapshots er en del av planen, kan du bruke veiledningen om PITR versus snapshot til å dokumentere hva hver mekanisme kan gjenopprette.

Lukk midlertidig tilgang brukt under oppsettet

Lag en threat model for handlingen Beszel utfører, ikke bare for innloggingsskjemaet. Den mest risikable feilen her er å eksponere agent listeners mot internett uten nettverkskontroller. Implementer denne grensen: hold agent listeners på private nettverk og beskytt hub-kontoen og enrollment keys.

Beszel har ingen obligatorisk bootstrap secret i denne grunnkonfigurasjonen. Beskytt i stedet den faktiske administratorkontoen eller upstream-autentiseringen. Ikke løs en permission error ved å kjøre containeren som root eller mounte hosten bredt. Resource limits hører også hjemme i sikkerhetsdesignet når brukere kan utløse belastning gjennom antall agenter, metrics retention, hub-lagring og nettverkstilgjengelighet til hver agent på den dedikerte porten.

Flytt det repeterbare infrastrukButarbeidet til Dockup

For Beszel er Dockup mest nyttig i grensen mellom et image og en persistent tjeneste. Det holder routen til 8090, TLS, secret values og lagring samlet gjennom utskiftinger av containere, uavhengig av om compute-ressursene tilhører Dockup eller den tilkoblede serveren din.

Avslutt med applikasjonskunnskap: rute huben gjennom HTTPS og hold agentportene private; koble til og test en Beszel-agent på hver maskin som overvåkes; og kjør denne verifiseringen: registrer en agent, overvåk CPU-, minne- og diskgrafer, utløse et terskelvarsel og koble agenten til på nytt etter en omstart av huben. Lagre resultatet som en deployment check, slik at neste image-oppdatering vurderes etter faktisk funksjon og ikke bare containerstatus.

Vanlige spørsmål

Hva trenger Beszel for en produksjonsutrulling?

Rute Beszel-containeren på port 8090 gjennom én HTTPS-origin. Det tilhørende nettverkskravet er en Beszel-agent på hver maskin som overvåkes. Ikke erklær Beszel som klar før du kan registrere en agent, overvåke CPU-, minne- og diskgrafer, utløse et terskelvarsel og koble agenten til på nytt etter en omstart av huben.

Hvilke Beszel-data bør inngå i en sikkerhetskopi?

Gjør /beszel_data persistent, og ta med hub-data, brukere, systemer og varslingskonfigurasjon i det samme recovery-manifestet. En ren Beszel-gjenoppretting er bare vellykket når systemer, historikk og varsler kommer tilbake, og alle gjenopprettede agenter fortsetter å sende aktuelle metrics.

Krever Beszel HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Beszel-originen, og hold port 8090 på den interne routen. Bruk Beszel-innstillingen riktig: rute huben gjennom HTTPS og hold agentportene private. For Beszel beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som avhenger av origin.

Hvordan bør en Beszel-oppgradering testes?

Gjenopprett gjeldende Beszel-state i en isolert utrulling, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at hub- og agentversjoner bør testes sammen, fordi protokollendringer kan se ut som stille hull i overvåkingen. Behold det forrige Beszel-imaget til grensene for datamigrering og rollback er forstått.