Sådan selvhoster du Beszel i 2026: Agenter, privat netværk og sikkerhedskopier

Den korteste Beszel-demo beviser, at en proces lytter på port 8090. Produktion kræver stærkere dokumentation. Den skal kunne gennemføre dette scenarie, selv efter at containeren er blevet udskiftet: tilmeld en agent, se CPU-, hukommelses- og diskdiagrammer, udløs en tærskelalarm, og forbind agenten igen efter en genstart af hubben.

Beszel implementeres med et klart formål: letvægtsserverovervågning i en lille container. Den mest almindelige faldgrube ved deployment er, at hubben ikke kan nå port 45876 på en agent, eller at dens SSH-nøgle er blevet ændret. Derfor skal håndtering af den offentlige URL og persistent state have samme opmærksomhed som opstart af imaget.

Afgræns Beszels runtime

Processtatus og produktstatus er to forskellige ting i Beszel. Port 8090 kan svare, selvom den brugerrettede transaktion stadig fejler. Netværkskontrakten for Beszel er en Beszel-agent på hver overvåget maskine. Hold private endpoints på intern DNS, tillad kun nødvendige udgående forbindelser, og giv Beszel en servicekonto med begrænsede rettigheder.

Brug denne readiness-øvelse efter væsentlige konfigurationsændringer: tilmeld en agent, se CPU-, hukommelses- og diskdiagrammer, udløs en tærskelalarm, og forbind agenten igen efter en genstart af hubben. Hold dyre eksterne checks ude af liveness probes, så et driftsstop hos en udbyder ikke udløser en restart-loop. Kapacitetsarbejdet bør følge antallet af agenter, metrics retention, hub-lageret og netværksforbindelsen til hver agent på dens dedikerede port. Det afspejler Beszels reelle belastning bedre end sideforespørgsler.

Gør den offentlige origin entydig

Browseren, API-klienten og Beszel skal være enige om én origin. For at sikre det skal du route hubben gennem HTTPS og holde agentportene private. Bevar den oprindelige host og protokol, og sørg samtidig for, at port 8090 ikke er tilgængelig som en konkurrerende offentlig adresse.

Guiden til fejlfinding af et site, der er nede hjælper med at skelne mellem en utilgængelig route og en applikation, der svarer. Den skelnen er vigtig her: Hubben kan ikke nå port 45876 på en agent, eller dens SSH-nøgle er blevet ændret. Kun det første problem løses med ændringer i ingress; det andet kræver inspektion af Beszel-logs, state eller workload.

Kør den første produktionslignende instans

Den første container skal være nem at slette og oprette igen. Hold data væk fra det skrivbare layer, bind kun port 8090 dér, hvor proxyen kan nå den, og send konfigurationen ind 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

Fastlås imaget efter den indledende test. Læs den tidligste startup-fejl i stedet for den sidste restart-meddelelse, verificer hvert mount med docker inspect, og følg logs, mens du tilmelder en agent, ser CPU-, hukommelses- og diskdiagrammer, udløser en tærskelalarm og forbinder agenten igen efter en genstart af hubben. Denne sekvens skelner mellem en forkert image-kommando og et problem med en afhængighed eller tilladelser.

Logs, der besvarer det næste spørgsmål

En grøn container er nødvendig, men ikke tilstrækkelig. Service-level-indikatoren er en vellykket gennemførelse af “tilmeld en agent, se CPU-, hukommelses- og diskdiagrammer, udløs en tærskelalarm, og forbind agenten igen efter en genstart af hubben”, mens de sandsynlige belastningssignaler er antallet af agenter, metrics retention, hub-lageret og netværksforbindelsen til hver agent på dens dedikerede port.

Change control er vigtigt, fordi hub- og agentversioner bør testes sammen, da protokolændringer kan ligne stille huller i overvågningen. Bevar det gamle image, test migrationer på en kopi af state, og dokumentér, om rollback understøttes, efter at schemaet er blevet ændret. Hvis hubben ikke kan nå port 45876 på en agent, eller dens SSH-nøgle er blevet ændret, skal du diagnosticere den første grænse, der adskiller sig fra det fungerende miljø.

En produktionsaccepttest for Beszel

Inden de rigtige brugere kommer til, skal du oprette et release-ark til Beszel. Det skal angive det fastlåste image, port 8090, den kanoniske origin, persistente stier og ejeren af en Beszel-agent på hver overvåget maskine. Vedhæft det forventede resultat af denne transaktion: tilmeld en agent, se CPU-, hukommelses- og diskdiagrammer, udløs en tærskelalarm, og forbind agenten igen efter en genstart af hubben.

Brug arket efter en normal udskiftning og efter en ren restore. Recovery accepteres kun, hvis systemer, historik og alarmer vender tilbage, og alle gendannede agenter igen sender aktuelle metrics. Indsaml også et kort ressource-trace, der dækker antallet af agenter, metrics retention, hub-lageret og netværksforbindelsen til hver agent på dens dedikerede port. Opbevar det sammen med releaset, så fremtidige kapacitetsændringer kan sammenlignes med den samme workload.

Inkludér én kontrolleret fejl: nægt midlertidigt testidentiteten adgang til en Beszel-agent på hver overvåget maskine. Bekræft, at Beszel rapporterer problemet ved den korrekte grænse, gendan den gyldige tilstand, og kør transaktionen igen. Det tester synligheden af fejl, ikke kun succes, og forhindrer, at en tilsyneladende sund grænseflade skjuler en defekt worker, callback eller databaseforbindelse.

Design Beszel-restore før lancering

Lav en fortegnelse over alle persistente artefakter: hub-data, brugere, systemer og alarmkonfiguration. Mount /beszel_data før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Inkludér konfiguration, der ændrer, hvordan gemte data fortolkes, ikke kun den største mappe.

Indstil retention, kopiér sikkerhedskopier væk fra hosten, og kør en restore i et rent miljø. Beszel-øvelsen er fuldført, når systemer, historik og alarmer vender tilbage, og alle gendannede agenter igen sender aktuelle metrics. Hvis snapshots indgår i planen, kan du bruge vejledningen om PITR kontra snapshots til at dokumentere, hvad hver mekanisme kan gendanne.

Luk midlertidig adgang til opsætning

Threat-model den handling, Beszel udfører, ikke kun loginformularen. Den største risiko her er at eksponere agent listeners til internettet uden netværkskontroller. Implementér denne grænse: Hold agent listeners på private netværk, og beskyt hubkontoen og enrollment keys.

Beszel har ingen obligatorisk bootstrap-secret i denne baseline. Beskyt i stedet den faktiske administratorkonto eller upstream authentication. Forsøg ikke at løse en tilladelsesfejl ved at køre containeren som root eller mounte hosten bredt. Resource limits hører også til i sikkerhedsdesignet, når brugere kan udløse belastning gennem antallet af agenter, metrics retention, hub-lageret og netværksforbindelsen til hver agent på dens dedikerede port.

Flyt det gentagelige infrastrukturarbejde til Dockup

For Beszel er Dockup mest nyttig i grænsefladen mellem et image og en persistent service. Den holder routen til 8090, TLS, secret-værdier og storage tilknyttet på tværs af containerudskiftninger, uanset om compute leveres af Dockup eller af din tilknyttede server.

Afslut med applikationsviden: Route hubben gennem HTTPS, og hold agentportene private; forbind og test en Beszel-agent på hver overvåget maskine; og kør denne verificering: tilmeld en agent, se CPU-, hukommelses- og diskdiagrammer, udløs en tærskelalarm, og forbind agenten igen efter en genstart af hubben. Gem resultatet som et deployment-check, så den næste imageopdatering vurderes ud fra adfærd i stedet for containerstatus.

Ofte stillede spørgsmål

Hvad kræver Beszel til et produktionsdeployment?

Route Beszel-containeren på port 8090 gennem én HTTPS-origin. Det understøttende netværkskrav er en Beszel-agent på hver overvåget maskine. Erklær ikke Beszel klar, før du kan tilmelde en agent, se CPU-, hukommelses- og diskdiagrammer, udløse en tærskelalarm og forbinde agenten igen efter en genstart af hubben.

Hvilke Beszel-data skal med i en sikkerhedskopi?

Gør /beszel_data persistent, og inkludér hub-data, brugere, systemer og alarmkonfiguration i det samme recovery-manifest. En ren Beszel-restore er kun vellykket, når systemer, historik og alarmer vender tilbage, og alle gendannede agenter igen sender aktuelle metrics.

Kræver Beszel HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Beszel-origin, og hold port 8090 på den interne route. Anvend Beszel-indstillingen korrekt: Route hubben gennem HTTPS, og hold agentportene private. For Beszel beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan bør en Beszel-opgradering testes?

Restore den aktuelle Beszel-state til et isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi hub- og agentversioner bør testes sammen, da protokolændringer kan ligne stille huller i overvågningen. Behold det tidligere Beszel-image, indtil grænsen for datamigration og rollback er forstået.