Så självhostar du Beszel 2026: agenter, privat nätverk och säkerhetskopior

Den kortaste Beszel-demonstrationen visar att en process lyssnar på port 8090. Produktion kräver starkare bevis. Följande scenario måste fungera även efter att containern har ersatts: registrera en agent, visa diagram för CPU, minne och disk, utlösa en tröskelbaserad avisering och ansluta agenten igen efter en omstart av hubben.

Beszel distribueras för ett tydligt syfte: lättviktsövervakning av servrar i en liten container. Den vanligaste fallgropen i distributionen är att hubben inte kan nå port 45876 på en agent eller att dess SSH-nyckel har ändrats. Därför måste hantering av publika URL:er och beständig state få samma uppmärksamhet som när imagen startas.

Definiera Beszels runtimegräns

Processens hälsa och produktens hälsa är separata i Beszel. Port 8090 kan svara samtidigt som den användarvända transaktionen fortfarande misslyckas. Nätverkskontraktet för Beszel innebär att det finns en Beszel-agent på varje övervakad maskin. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Beszel en service credential med begränsad behörighet.

Använd detta readiness-test efter betydande konfigurationsändringar: registrera en agent, visa diagram för CPU, minne och disk, utlösa en tröskelbaserad avisering och ansluta agenten igen efter en omstart av hubben. Håll kostsamma externa kontroller utanför liveness-prober, så att ett avbrott hos en leverantör inte orsakar en omstartsloop. Kapacitetsarbetet bör följa antalet agenter, hur länge metrics sparas, hubbens lagring och nätverksåtkomsten till varje agent på dess dedikerade port. Det speglar Beszels verkliga belastning bättre än sidförfrågningar.

Gör den publika origin entydig

Webbläsaren, API-klienten och Beszel måste vara överens om en och samma origin. För att säkerställa det ska hubben exponeras via HTTPS och agentportarna hållas privata. Bevara det ursprungliga hostnamnet och protokollet, samtidigt som port 8090 inte är tillgänglig som en konkurrerande publik adress.

Guiden för felsökning när webbplatsen ligger nere hjälper dig att skilja mellan en oåtkomlig route och en applikation som svarar. Den skillnaden är viktig här: hubben kan inte nå port 45876 på en agent eller så har dess SSH-nyckel ändrats. Endast det första problemet löses genom ändringar i ingressen; det andra kräver inspektion av Beszel-loggar, state eller workload.

Kör den första produktionsliknande instansen

Den första containern ska vara enkel att ta bort och återskapa. Håll data borta från det skrivbara lagret, bind port 8090 endast där proxyn kan nå den och skicka konfiguration vid runtime.

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

Pinna imagen efter det första testet. Läs det tidigaste startfelet i stället för det sista omstartsmeddelandet, verifiera varje mount med docker inspect och följ loggarna medan du registrerar en agent, visar diagram för CPU, minne och disk, utlöser en tröskelbaserad avisering och ansluter agenten igen efter en omstart av hubben. Den sekvensen skiljer ett felaktigt image-kommando från ett problem med beroenden eller behörigheter.

Loggar som besvarar nästa fråga

En grön container är nödvändig men inte tillräcklig. Service-level-indikatorn är att “registrera en agent, visa diagram för CPU, minne och disk, utlösa en tröskelbaserad avisering och ansluta agenten igen efter en omstart av hubben” slutförs utan fel. De sannolika belastningssignalerna är antalet agenter, hur länge metrics sparas, hubbens lagring och nätverksåtkomsten till varje agent på dess dedikerade port.

Ändringshantering är viktig eftersom hubb- och agentversioner bör testas tillsammans, eftersom protokolländringar kan se ut som tysta luckor i övervakningen. Bevara den gamla imagen, testa migreringar på en kopia av state och dokumentera om rollback stöds efter att schemat har flyttats. Om hubben inte kan nå port 45876 på en agent eller om dess SSH-nyckel har ändrats ska du felsöka den första gräns som skiljer sig från den fungerande miljön.

Ett produktionsgodkännande för Beszel

Innan riktiga användare ansluter bör du skapa ett releaseformulär för Beszel. Det ska ange den pinnade imagen, port 8090, den kanoniska origin, beständiga sökvägar och vem som ansvarar för en Beszel-agent på varje övervakad maskin. Bifoga det förväntade resultatet av denna transaktion: registrera en agent, visa diagram för CPU, minne och disk, utlösa en tröskelbaserad avisering och ansluta agenten igen efter en omstart av hubben.

Använd formuläret efter ett normalt utbyte och efter en ren återställning. Återställningen är godkänd först när system, historik och aviseringar är tillbaka och varje återställd agent återupptar sändningen av aktuella metrics. Samla även in ett kort resursunderlag som täcker antalet agenter, hur länge metrics sparas, hubbens lagring och nätverksåtkomsten till varje agent på dess dedikerade port. Spara det tillsammans med releasen, så att framtida kapacitetsförändringar jämförs med samma workload.

Inkludera ett kontrollerat fel: neka tillfälligt testidentiteten åtkomst till en Beszel-agent på varje övervakad maskin. Bekräfta att Beszel rapporterar problemet vid rätt gräns, återställ det giltiga tillståndet och kör transaktionen igen. Det testar felens synlighet, inte bara framgång, och hindrar ett gränssnitt som ser friskt ut från att dölja en trasig worker, callback eller databasanslutning.

Utforma återställningen av Beszel före lansering

Inventera alla beständiga artefakter: hubbdata, användare, system och aviseringskonfiguration. Montera /beszel_data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. Inkludera även konfiguration som ändrar hur lagrad data tolkas, inte bara den största katalogen.

Ange retention, kopiera säkerhetskopior till en annan värd och genomför en återställning i en ren miljö. Beszel-övningen är klar när system, historik och aviseringar är tillbaka och varje återställd agent återupptar sändningen av aktuella metrics. Om snapshots ingår i planen kan du använda vägledningen om PITR jämfört med snapshots för att dokumentera vad varje mekanism kan återställa.

Stäng tillfällig åtkomst för installation

Gör en threat model av den åtgärd som Beszel utför, inte bara av inloggningsformuläret. Det allvarligaste misstaget här är att publicera agentens listeners på internet utan nätverkskontroller. Implementera denna gräns: håll agentens listeners på privata nätverk och skydda hubbkontot och registreringsnycklarna.

Beszel har ingen obligatorisk bootstrap-hemlighet i denna baslinje. Skydda i stället det faktiska administratörskontot eller autentiseringen uppströms. Lös inte ett behörighetsfel genom att köra containern som root eller montera värdsystemet brett. Resursbegränsningar hör också hemma i säkerhetsdesignen när användare kan påverka antalet agenter, hur länge metrics sparas, hubbens lagring och nätverksåtkomsten till varje agent på dess dedikerade port.

Flytta det repeterbara infrastrukturarbetet till Dockup

För Beszel är Dockup mest användbart i gränsen mellan en image och en beständig tjänst. Det håller routen till 8090, TLS, hemliga värden och lagring kopplade även när containrar ersätts, oavsett om beräkningsresurserna tillhör Dockup eller din anslutna server.

Avsluta med applikationskunskap: exponera hubben via HTTPS och håll agentportarna privata; anslut och testa en Beszel-agent på varje övervakad maskin; och kör denna verifiering: registrera en agent, visa diagram för CPU, minne och disk, utlösa en tröskelbaserad avisering och ansluta agenten igen efter en omstart av hubben. Spara resultatet som en deployment-kontroll, så att nästa imageuppdatering bedöms utifrån beteende och inte containerstatus.

Vanliga frågor

Vad behöver Beszel för en produktionsdistribution?

Routa Beszel-containern på port 8090 genom en enda HTTPS-origin. Det stödjande nätverkskravet är en Beszel-agent på varje övervakad maskin. Markera inte Beszel som klart förrän du kan registrera en agent, visa diagram för CPU, minne och disk, utlösa en tröskelbaserad avisering och ansluta agenten igen efter en omstart av hubben.

Vilken Beszel-data ska ingå i en säkerhetskopia?

Spara /beszel_data och inkludera hubbdata, användare, system och aviseringskonfiguration i samma återställningsmanifest. En ren återställning av Beszel är godkänd först när system, historik och aviseringar är tillbaka och varje återställd agent återupptar sändningen av aktuella metrics.

Kräver Beszel HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Beszel-originen och håll port 8090 på den interna routen. Tillämpa Beszel-inställningen korrekt: exponera hubben via HTTPS och håll agentportarna privata. För Beszel skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och gör klientbeteendet som är känsligt för origin konsekvent.

Hur ska en uppgradering av Beszel testas?

Återställ aktuell Beszel-state i en isolerad deployment, tillämpa kandidatversionen och upprepa dess godkännandetransaktion. Var särskilt uppmärksam eftersom hubb- och agentversioner bör testas tillsammans, eftersom protokolländringar kan se ut som tysta luckor i övervakningen. Behåll den tidigare Beszel-imagen tills gränserna för datamigrering och rollback är förstådda.