Slik drifter du Healthchecks selv i 2026: Cron-ping, varsler og database-sikkerhetskopier

Det blir interessant å drifte Healthchecks selv ved den første redeployen, ikke ved den første docker run. Hvis cron-jobber sender ping til en intern URL eller e-postarbeidere ikke kjører, kan Docker fortsatt rapportere en prosess som er helt frisk. Distribusjonen nedenfor er bygget rundt observerbar atferd: Send start-, suksess- og feiling-ping fra en testjobb, hopp deretter over en planlagt ping og motta varselet om den manglende jobben.

Healthchecks har én tydelig oppgave: overvåking av cron-jobber og bakgrunnsoppgaver som skal varsle når de stopper. Denne beskrivelsen forteller oss hva som må være offentlig tilgjengelig, hva som bør forbli privat, og hva en sikkerhetskopi må kunne gjenopprette.

Sikkerhetskopier tilstanden Healthchecks ikke kan gjenskape

Standard Healthchecks-containeren har ikke noe påkrevd mount for applikasjonsdata. Gjenopprettingssettet er likevel tydelig: applikasjonsdatabasen og varslingskonfigurasjonen. Ikke opprett et tomt volume bare for å få distribusjonen til å se stateful ut; bevar heller den nøyaktige image-referansen og den gjennomgåtte konfigurasjonen.

Bygg Healthchecks på nytt på en tom vert og kjør akseptansetesten. Gjenopprettingen er vellykket når checks, tidsplaner, integrasjoner og ping-nøkler er tilbake, og en bevisst manglende ping utløser det forventede varselet. Tilkoblede database- eller samhandlingstjenester følger sin egen applikasjonskonsistente plan for sikkerhetskopiering, mens den utskiftbare web-containeren opprettes fra kode. Distribusjonsveiledningen fra Git til produksjon beskriver denne reproduserbare grensen.

Bevar en checksum eller digest for det kjente, fungerende imaget, og test på nytt etter oppdateringer. For en stateless-tjeneste er en vellykket rebuild gjenopprettingstesten; for ekstern state må Healthchecks-runbooken lenke til den separate eieren og gjenopprettingsprosedyren.

Bygg en utskiftbar Healthchecks-container

Bruk en kommando som synliggjør alle viktige valg. Denne grunnkonfigurasjonen binder Healthchecks til loopback på verten, legger til de kjente datamountene og angir den første nødvendige innstillingen. Legg til de gjennomgåtte tilkoblingsinnstillingene for Postgres og fungerende e-postlevering for produksjonsvarsler; bruk private navn for private tjenester.

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

Bytt ut flytende tags med en testet versjon eller digest. Etter oppstart kan du inspisere docker logs --tail 200 healthchecks og bekrefte at prosessen lytter på 8000. Kjør deretter Healthchecks-akseptansetesten; et svar fra rotsiden kan ikke bevise at hele scenariet fungerer: Send start-, suksess- og feiling-ping fra en testjobb, hopp deretter over en planlagt ping og motta varselet om den manglende jobben.

Hva Healthchecks er avhengig av

Tegn tre grenser rundt Healthchecks: innkommende trafikk til port 8000, persistent state og støttende krav. Containeren kan byttes ut, men de to andre trenger tydelige eiere. Nettverkskontrakten for Healthchecks er Postgres og fungerende e-postlevering for produksjonsvarsler. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Healthchecks en tjenestekredential med begrenset tilgang.

Diagrammet er komplett når en ren klient kan sende start-, suksess- og feiling-ping fra en testjobb, hoppe over en planlagt ping og motta varselet om den manglende jobben. Samle inn tids- og ressursdata for antall checks, grace periods, varseldistribusjon, e-postlevering og databaseskrivinger. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert, om du bør undersøke ruting, lokal kapasitet eller en støttetjeneste.

Rute Healthchecks uten å gi et misvisende bilde av HTTPS

Velg det endelige Healthchecks-hostnavnet før brukerne lagrer callbacks eller klientinnstillinger, og sett deretter SITE_ROOT og ALLOWED_HOSTS til den eksterne HTTPS-adressen. Plattformruten bør terminere TLS én gang og peke til den private porten 8000.

Kjør akseptansetesten eksternt. Hvis klienten aldri når Healthchecks, kan du bruke sjekklisten for SSL-validering til å kontrollere DNS og sertifikatet. Hvis forespørselen når Healthchecks, men cron-jobber sender ping til en intern URL eller e-postarbeidere ikke kjører, må du slutte å endre proxy-redirects og heller undersøke den applikasjonsspesifikke grensen.

Dokumentasjon du bør samle inn før Healthchecks går i produksjon

Opprett en liten, midlertidig Healthchecks-fixture og behold den for hver release. Fixturen bør teste den faktiske arbeidsflyten: Send start-, suksess- og feiling-ping fra en testjobb, hopp deretter over en planlagt ping og motta varselet om den manglende jobben. Registrer image-digest, eksternt hostnavn, avhengighetsadresse og forventet resultat, slik at en senere operatør kan gjenta testen uten å måtte tolke denne veiledningen.

Kjør fixturen tre ganger. Først bruker du den ferske distribusjonen. Deretter bytter du ut containeren uten å endre persistent state. Til slutt gjenoppretter du sikkerhetskopien i et tomt miljø. Den tredje kjøringen er bare vellykket når checks, tidsplaner, integrasjoner og ping-nøkler er tilbake, og en bevisst manglende ping utløser det forventede varselet. Under hver kjøring måler du latenstid og ressursbruk knyttet til antall checks, grace periods, varseldistribusjon, e-postlevering og databaseskrivinger; dette blir grunnlaget for varsler i stedet for en tilfeldig CPU-prosent.

Til slutt tester du den negative banen med vilje: Blokker midlertidig testidentitetens tilgang til Postgres og fungerende e-postlevering for produksjonsvarsler. Bekreft at Healthchecks feiler synlig uten å ødelegge state, gjenopprett riktig tilstand og gjenta den vellykkede transaksjonen. En release-oppføring som inneholder disse fire resultatene, er sterkere dokumentasjon enn skjermbilder av et dashboard eller et enkelt curl-svar.

Feiløvelser for Healthchecks

Følg med på arbeidet Healthchecks utfører: antall checks, grace periods, varseldistribusjon, e-postlevering og databaseskrivinger. Sett grenser med tilstrekkelig margin for dette arbeidet, og unngå en liveness probe som konkurrerer med det. Operatørsjekken bør fortsatt forsøke å sende start-, suksess- og feiling-ping fra en testjobb, hoppe over en planlagt ping og motta varselet om den manglende jobben etter en tidsplan.

Ved oppdateringer må du huske at applikasjonsmigreringer og worker-konfigurasjon må oppgraderes samlet, slik at websiden ikke skjuler ødelagt varslingslevering. Distribuer kandidaten mot en gjenopprettet kopi og gjenta den kjente testen. Hvis cron-jobber sender ping til en intern URL eller e-postarbeidere ikke kjører, kan du bruke runtime-logger og den faktiske nettverksforespørselen til å finne ut hvilken antakelse som har endret seg.

Velg tillitsgrensen for Healthchecks

Lukk bootstrap-vinduet så snart den første administratoren du stoler på, er opprettet. Den konkrete fellen i Healthchecks er å bruke en generert secret som endres ved hver omstart; den tryggere grensen er å bruke en stabil SECRET_KEY, begrense prosjektmedlemskap og behandle ping-URL-er som credentials.

Generer SECRET_KEY én gang, hold den ute av Git og bevar den sammen med gjenopprettingsmanifestet, fordi en endring kan ugyldiggjøre kryptert eller signert applikasjonsstate. Privat nettverk bør håndtere credentials til avhengighetene, og roller i Healthchecks bør bare gi den minste nyttige tilgangen. Ikke skriv sensitive request bodies eller svar fra leverandører til vanlige logger.

En Dockup-distribusjon trenger fortsatt en akseptansetest for Healthchecks

Dockup kan eie de utskiftbare plattformdelene: rute trafikk til port 8000, utstede domenet og sertifikatet, injisere secrets, koble til persistent storage og koble Healthchecks til administrerte eller privat tilkoblede tjenester. Dette kan gjøres på Dockup-infrastruktur eller på en server du kobler til.

Akseptansearbeidet for Healthchecks må fortsatt være tydelig definert. Etter one-click-distribusjonen setter du SITE_ROOT og ALLOWED_HOSTS til den eksterne HTTPS-adressen, kobler til og tester Postgres og fungerende e-postlevering for produksjonsvarsler, og kjører dette scenariet: Send start-, suksess- og feiling-ping fra en testjobb, hopp deretter over en planlagt ping og motta varselet om den manglende jobben. Denne fordelingen er bevisst: Dockup fjerner repetitivt infrastrukturarbeid uten å late som om applikasjonsroller, credentials hos leverandører eller gjenopprettingspolicy velger seg selv.

Vanlige spørsmål

Hva trenger Healthchecks for en produksjonsdistribusjon?

Rute Healthchecks-containeren på port 8000 gjennom én HTTPS-origin. Det støttende nettverkskravet er Postgres og fungerende e-postlevering for produksjonsvarsler. Ikke kall Healthchecks klar før du kan sende start-, suksess- og feiling-ping fra en testjobb, hoppe over en planlagt ping og motta varselet om den manglende jobben.

Hvilke Healthchecks-data hører hjemme i en sikkerhetskopi?

Standard Healthchecks-imaget har ikke noe påkrevd mount for applikasjonsdata. Bevar distribusjonskonfigurasjonen og sikkerhetskopier tilkoblet state separat; gjenopprettingen er vellykket når checks, tidsplaner, integrasjoner og ping-nøkler er tilbake, og en bevisst manglende ping utløser det forventede varselet.

Krever Healthchecks HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Healthchecks-origin og behold port 8000 på den interne ruten. Konfigurer Healthchecks-innstillingen riktig: Sett SITE_ROOT og ALLOWED_HOSTS til den eksterne HTTPS-adressen. For Healthchecks beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av origin.

Hvordan bør en Healthchecks-oppgradering testes?

Gjenopprett gjeldende Healthchecks-state i en isolert distribusjon, ta i bruk kandidatversjonen og gjenta akseptansetesten. Vær spesielt oppmerksom på at applikasjonsmigreringer og worker-konfigurasjon må oppgraderes samlet, slik at websiden ikke skjuler ødelagt varslingslevering. Behold det forrige Healthchecks-imaget til grensen for datamigrering og rollback er forstått.