Så självhostar du Healthchecks 2026: cron-pings, aviseringar och databasbackuper

Att självhosta Healthchecks blir intressant vid den första omdistributionen, inte vid den första docker run. Om cron-jobb skickar pingar till en intern URL eller om e-postarbetare inte körs kan Docker fortfarande rapportera en helt frisk process. Distributionen nedan är uppbyggd kring observerbart beteende: skicka start-, lyckade och misslyckade pingar från ett testjobb, utelämna sedan en schemalagd ping och ta emot aviseringen om det saknade jobbet.

Healthchecks har ett tydligt syfte: dead-man-övervakning av cron-jobb och bakgrundsjobb. Den beskrivningen visar vad som måste vara publikt, vad som bör förbli privat och vad en backup måste kunna återskapa.

Säkerhetskopiera det tillstånd som Healthchecks inte kan återskapa

Standardcontainern för Healthchecks har ingen obligatorisk mount för applikationsdata. Det som måste kunna återställas är ändå tydligt: applikationsdatabasen och konfigurationen för aviseringar. Skapa inte en tom volume bara för att få distributionen att se stateful ut; bevara i stället den exakta image-referensen och den granskade konfigurationen.

Bygg om Healthchecks på en tom värd och kör acceptanstestet. Återställningen är godkänd när kontroller, scheman, integrationer och ping-nycklar är tillbaka och en avsiktligt utelämnad ping utlöser den förväntade aviseringen. Alla anslutna databaser eller samarbets tjänster följer sin egen applikationskonsistenta backupplan, medan den utbytbara webbcontainern återskapas från kod. Guiden från Git till produktionsdistribution beskriver den reproducerbara gränsen.

Spara en checksumma eller digest för den kända fungerande imagen och testa igen efter uppdateringar. För en stateless-tjänst är en lyckad ombyggnad återställningstestet; för extern state måste Healthchecks-runbooken länka till den separata ägaren och återställningsproceduren.

Bygg en utbytbar Healthchecks-container

Använd ett kommando som visar alla viktiga val. Den här baslinjen binder Healthchecks till loopback på värden, lägger till de kända datamounterna och anger den första obligatoriska inställningen. Lägg till de granskade anslutningsinställningarna för Postgres och fungerande e-postleverans för produktionsaviseringar; använd privata namn för privata tjänster.

docker run -d \
  --name healthchecks \
  --restart unless-stopped \
  -p 127.0.0.1:8000:8000 \
  -e SECRET_KEY=replace-with-a-long-random-value \
  -e SITE_ROOT=https://app.example.com \
  -e ALLOWED_HOSTS=app.example.com \
  -e DB=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_NAME=healthchecks \
  -e DB_USER=healthchecks \
  -e DB_PASSWORD=replace-with-a-strong-database-password \
  healthchecks/healthchecks:latest

Ersätt flytande taggar med en testad version eller digest. Efter uppstarten granskar du docker logs --tail 200 healthchecks och bekräftar att processen lyssnar på 8000. Kör sedan Healthchecks acceptanstest; ett svar från rotsidan kan inte bevisa att hela scenariot fungerar: skicka start-, lyckade och misslyckade pingar från ett testjobb, utelämna sedan en schemalagd ping och ta emot aviseringen om det saknade jobbet.

Vad Healthchecks är beroende av

Dra tre gränser runt Healthchecks: ingress till port 8000, beständigt state och stödkrav. Containern är utbytbar, men de två andra delarna behöver tydliga ägare. Healthchecks nätverkskontrakt består av Postgres och fungerande e-postleverans för produktionsaviseringar. Behåll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Healthchecks en begränsad service credential.

Diagrammet är komplett när en ren klient kan skicka start-, lyckade och misslyckade pingar från ett testjobb, utelämna sedan en schemalagd ping och ta emot aviseringen om det saknade jobbet. Samla in tids- och resursdata för antal kontroller, grace periods, aviseringarnas fan-out, e-postleverans och databasskrivningar. Om transaktionen misslyckas visar den första gräns som inte beter sig enligt dokumentationen om du ska undersöka routing, lokal kapacitet eller en stödjande tjänst.

Routa Healthchecks utan att ge en felaktig bild av HTTPS

Välj det slutliga värdnamnet för Healthchecks innan användarna sparar callbacks eller klientinställningar, och ange sedan SITE_ROOT och ALLOWED_HOSTS till den externa HTTPS-adressen. Plattformens route bör terminera TLS en gång och rikta trafiken till den privata porten 8000.

Kör acceptanstestet externt. Om klienten aldrig når Healthchecks använder du checklistan för SSL-validering för DNS- och certifikatkontroller. Om begäran når Healthchecks men cron-jobb skickar pingar till en intern URL eller e-postarbetare inte körs ska du sluta ändra proxy-redirects och i stället granska den applikationsspecifika gränsen.

Bevis att samla in innan Healthchecks tas i drift

Skapa en liten, tillfällig Healthchecks-fixture och behåll den för varje release. Fixturen ska testa det verkliga arbetsflödet: skicka start-, lyckade och misslyckade pingar från ett testjobb, utelämna sedan en schemalagd ping och ta emot aviseringen om det saknade jobbet. Dokumentera imagens digest, externa värdnamn, beroendeadress och förväntat resultat så att en senare operatör kan upprepa testet utan att behöva tolka den här guiden.

Kör fixturen tre gånger. Använd först den nya distributionen. Ersätt sedan containern utan att röra beständigt state. Återställ till sist backupen i en tom miljö. Den tredje körningen är godkänd först när kontroller, scheman, integrationer och ping-nycklar är tillbaka och en avsiktligt utelämnad ping utlöser den förväntade aviseringen. Samla under varje körning in latens och resursanvändning för antal kontroller, grace periods, aviseringarnas fan-out, e-postleverans och databasskrivningar; detta blir baslinjen för aviseringar i stället för en godtycklig CPU-procent.

Testa slutligen den negativa vägen medvetet: neka tillfälligt testidentiteten åtkomst till Postgres och fungerande e-postleverans för produktionsaviseringar. Bekräfta att Healthchecks misslyckas synligt utan att skada state, återställ rätt förutsättning och upprepa den lyckade transaktionen. En releasepost med dessa fyra resultat är starkare bevis än skärmbilder av en dashboard eller ett engångssvar från curl.

Felövningar för Healthchecks

Observera det arbete som Healthchecks utför: antal kontroller, grace periods, aviseringarnas fan-out, e-postleverans och databasskrivningar. Sätt gränser med marginal för detta arbete och undvik en liveness probe som konkurrerar med det. Operatörskontrollen ska fortfarande försöka skicka start-, lyckade och misslyckade pingar från ett testjobb, sedan utelämna en schemalagd ping och ta emot aviseringen om det saknade jobbet enligt ett schema.

Vid uppdateringar ska du komma ihåg att applikationsmigreringar och worker-konfiguration måste uppgraderas tillsammans, så att webbsidan inte döljer trasig aviseringleverans. Distribuera kandidaten mot en återställd kopia och upprepa det kända testet. Om cron-jobb skickar pingar till en intern URL eller e-postarbetare inte körs använder du runtime-loggar och det faktiska nätverksanropet för att hitta vilket antagande som har ändrats.

Välj Healthchecks trust boundary

Stäng bootstrap-fönstret så snart den första betrodda administratören finns. Healthchecks konkreta fallgrop är att använda en genererad hemlighet som ändras vid varje omstart; den säkrare gränsen är att använda en stabil SECRET_KEY, begränsa projektmedlemskap och behandla ping-URL:er som credentials.

Generera SECRET_KEY en gång, håll den utanför Git och bevara den tillsammans med återställningsmanifestet, eftersom en ändring kan ogiltigförklara krypterat eller signerat applikationsstate. Privat nätverk ska bära credentials för beroenden, och rollerna i Healthchecks ska endast ge den minsta användbara behörigheten. Håll känsliga request bodies och svar från providers borta från rutinloggar.

En Dockup-distribution behöver fortfarande ett acceptanstest för Healthchecks

Dockup kan ansvara för de utbytbara plattformsdelarna: routa trafik till port 8000, utfärda domän och certifikat, injicera hemligheter, ansluta persistent storage och koppla Healthchecks till hanterade eller privat anslutna tjänster. Detta kan göras på Dockup-infrastruktur eller på en server som du ansluter.

Acceptansarbetet för Healthchecks är fortfarande tydligt. Efter one-click-distributionen anger du SITE_ROOT och ALLOWED_HOSTS till den externa HTTPS-adressen, ansluter och testar Postgres samt fungerande e-postleverans för produktionsaviseringar och kör följande scenario: skicka start-, lyckade och misslyckade pingar från ett testjobb, utelämna sedan en schemalagd ping och ta emot aviseringen om det saknade jobbet. Den uppdelningen är avsiktlig: Dockup tar bort repetitiv infrastrukturkonfiguration utan att låtsas att applikationsroller, provider-credentials eller återställningspolicy väljer sig själva.

Vanliga frågor

Vad behöver Healthchecks för en produktionsdistribution?

Routa Healthchecks-containern via en HTTPS-origin på port 8000. Det stödjande nätverkskravet är Postgres och fungerande e-postleverans för produktionsaviseringar. Förklara inte Healthchecks som redo förrän du kan skicka start-, lyckade och misslyckade pingar från ett testjobb, utelämna sedan en schemalagd ping och ta emot aviseringen om det saknade jobbet.

Vilka Healthchecks-data ska ingå i en backup?

Standardimagen för Healthchecks har ingen obligatorisk mount för applikationsdata. Bevara distributionskonfigurationen och säkerhetskopiera anslutet state separat; återställningen är godkänd när kontroller, scheman, integrationer och ping-nycklar är tillbaka och en avsiktligt utelämnad ping utlöser den förväntade aviseringen.

Kräver Healthchecks HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Healthchecks-origin och behåll port 8000 i den interna routen. Tillämpa Healthchecks-inställningen korrekt: ange SITE_ROOT och ALLOWED_HOSTS till den externa HTTPS-adressen. För Healthchecks skyddar HTTPS credentials eller användarinnehåll under överföring och gör klientbeteendet som beror på origin konsekvent.

Hur bör en uppgradering av Healthchecks testas?

Återställ aktuellt Healthchecks-state till en isolerad distribution, tillämpa kandidatversionen och upprepa dess acceptanstest. Var särskilt uppmärksam eftersom applikationsmigreringar och worker-konfiguration måste uppgraderas tillsammans, så att webbsidan inte döljer trasig aviseringleverans. Behåll den tidigare Healthchecks-imagen tills gränsen för datamigrering och rollback är förstådd.