Healthchecksin itsehostaus vuonna 2026: cron-pingit, hälytykset ja tietokantavarmuuskopiot

Healthchecksin itsehostaus muuttuu kiinnostavaksi ensimmäisen uudelleenasennuksen yhteydessä, ei ensimmäisen docker run -komennon jälkeen. Jos cron-työt pingittävät sisäistä URL-osoitetta tai sähköpostityöntekijät eivät ole käynnissä, Docker voi silti ilmoittaa prosessin olevan täysin kunnossa. Alla kuvattu käyttöönotto perustuu havaittavaan toimintaan: lähetä testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jätä sitten ajastettu ping lähettämättä ja varmista, että saat puuttuvan työn hälytyksen.

Healthchecksin käyttötarkoitus on selkeä: cron-töiden ja taustatehtävien dead-man-monitorointi. Tämä määritelmä kertoo, minkä on oltava julkisesti saatavilla, minkä pitäisi pysyä yksityisenä ja mitä varmuuskopion on pystyttävä palauttamaan.

Varmuuskopioi tila, jota Healthchecks ei pysty luomaan uudelleen

Healthchecksin vakiokontti ei tarvitse sovellustietojen mounttausta. Palautettava kokonaisuus on silti selkeä: sovellustietokanta ja ilmoitusmääritykset. Älä luo tyhjää volumea vain saadaksesi käyttöönoton näyttämään tilalliselta, vaan säilytä tarkka image-viite ja tarkistettu konfiguraatio.

Rakenna Healthchecks uudelleen tyhjälle palvelimelle ja suorita hyväksymistesti. Palautus onnistuu, kun tarkistukset, aikataulut, integraatiot ja ping-avaimet ovat palautuneet ja tarkoituksella lähettämättä jätetty ping nostaa odotetun hälytyksen. Kaikki yhdistetyt tietokannat ja yhteistyöpalvelut noudattavat omaa sovelluksenmukaista varmuuskopiointisuunnitelmaansa, kun taas korvattava web-kontti luodaan uudelleen koodista. Gitistä tuotantoon -käyttöönotto-opas kuvaa tämän toistettavan rajapinnan.

Säilytä tunnetusti toimivan imagen tarkistussumma tai digest ja testaa se uudelleen päivitysten jälkeen. Tilattomassa palvelussa onnistunut uudelleenrakennus toimii palautustestinä; ulkoisen tilan osalta Healthchecksin runbookissa on viitattava erilliseen omistajaan ja palautusmenettelyyn.

Rakenna korvattava Healthchecks-kontti

Käytä komentoa, joka tuo kaikki tärkeät valinnat näkyviin. Tämä perusmääritys sitoo Healthchecksin isännän loopback-osoitteeseen, lisää tunnetut datamountit ja asettaa ensimmäisen pakollisen määrityksen. Lisää tuotantohälytyksiä varten tarkistetut Postgres-yhteysmääritykset ja toimiva sähköpostin toimitus; käytä yksityisille palveluille yksityisiä nimiä.

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

Vaihda liikkuvat tagit testattuun versioon tai digestiin. Käynnistyksen jälkeen tarkista docker logs --tail 200 healthchecks ja varmista, että prosessi kuuntelee porttia 8000. Suorita sen jälkeen Healthchecksin hyväksymistoiminto; juurisivun vastaus ei todista koko skenaarion onnistumista: lähetä testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jätä sitten ajastettu ping lähettämättä ja varmista, että saat puuttuvan työn hälytyksen.

Mistä Healthchecks riippuu

Piirrä Healthchecksin ympärille kolme rajaa: liikenne porttiin 8000, säilytettävä tila ja tukivaatimukset. Kontti on korvattavissa, mutta kahdella muulla rajalla on oltava selkeät omistajat. Healthchecksin verkkosopimukseen kuuluvat Postgres sekä tuotantohälytyksiä varten toimiva sähköpostin toimitus. Pidä yksityiset päätepisteet sisäisessä DNS:ssä, salli vain tarvittavat lähtevät yhteydet ja anna Healthchecksille rajattuun käyttöön tarkoitettu palvelutunnus.

Kaavio on valmis, kun puhdas asiakas voi lähettää testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jättää sitten ajastetun pingin lähettämättä ja vastaanottaa puuttuvan työn hälytyksen. Kerää ajoitus- ja resurssitiedot tarkistusten määrästä, joustoajoista, ilmoitusten jakelusta, sähköpostin toimituksesta ja tietokantakirjoituksista. Jos tapahtuma epäonnistuu, ensimmäinen dokumentoidulla tavalla toimimaton raja kertoo, pitääkö tutkia reititystä, paikallista kapasiteettia vai tukipalvelua.

Reititä Healthchecks vääristelemättä HTTPS:n toimintaa

Valitse lopullinen Healthchecksin isäntänimi ennen kuin käyttäjät tallentavat callbackit tai asiakasasetukset, ja määritä SITE_ROOT sekä ALLOWED_HOSTS ulkoiseen HTTPS-osoitteeseen. Alustan reitin tulee päättää TLS kerran ja kohdistaa liikenne yksityiseen porttiin 8000.

Suorita hyväksymistesti ulkoisesti. Jos asiakas ei koskaan saavuta Healthchecksiä, käytä SSL-validoinnin tarkistuslistaa DNS- ja sertifikaattitarkistuksiin. Jos pyyntö saavuttaa Healthchecksin, mutta cron-työt pingittävät sisäistä URL-osoitetta tai sähköpostityöntekijät eivät ole käynnissä, lopeta proxyn uudelleenohjausten muuttaminen ja tutki sen sijaan sovelluskohtaista rajaa.

Healthchecksin tuotantoonviennin yhteydessä kerättävät todisteet

Luo pieni, helposti hävitettävä Healthchecks-fixture ja säilytä se jokaista julkaisua varten. Fixturen tulee testata todellinen työnkulku: lähetä testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jätä sitten ajastettu ping lähettämättä ja varmista, että saat puuttuvan työn hälytyksen. Tallenna imagen digest, ulkoinen isäntänimi, riippuvuuden osoite ja odotettu tulos, jotta myöhempi ylläpitäjä voi toistaa testin ilman tämän oppaan tulkintaa.

Suorita fixture kolme kertaa. Käytä ensimmäisellä kerralla uutta käyttöönottoa. Toisella kerralla korvaa kontti koskematta säilytettävään tilaan. Kolmannella kerralla palauta varmuuskopio tyhjään ympäristöön. Kolmas ajo onnistuu vain, kun tarkistukset, aikataulut, integraatiot ja ping-avaimet ovat palautuneet ja tarkoituksella lähettämättä jätetty ping nostaa odotetun hälytyksen. Kerää jokaisen ajon aikana viive- ja resurssitiedot tarkistusten määrästä, joustoajoista, ilmoitusten jakelusta, sähköpostin toimituksesta ja tietokantakirjoituksista; tästä muodostuu hälytysten lähtötaso mielivaltaisen CPU-prosentin sijaan.

Testaa lopuksi kielteinen polku tarkoituksella: estä testi-identiteetiltä tilapäisesti pääsy Postgresiin ja tuotantohälytyksiä varten tarvittavaan toimivaan sähköpostin toimitukseen. Varmista, että Healthchecks epäonnistuu näkyvästi mutta ei riko tilaa, palauta oikea tila ja toista onnistunut tapahtuma. Julkaisumerkintä, joka sisältää nämä neljä tulosta, on vahvempaa näyttöä kuin hallintapaneelin kuvakaappaukset tai yksittäinen curl-vastaus.

Healthchecksin vikatilanteiden harjoittelu

Seuraa Healthchecksin tekemää työtä: tarkistusten määrää, joustoaikoja, ilmoitusten jakelua, sähköpostin toimitusta ja tietokantakirjoituksia. Aseta rajat niin, että niihin jää työmäärää varten pelivaraa, ja vältä liveness-probea, joka kilpailee saman työn kanssa. Ylläpitäjän tarkistuksen tulee edelleen yrittää lähettää testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jättää sitten ajastettu ping lähettämättä ja vastaanottaa puuttuvan työn hälytyksen ajastetusti.

Muista päivityksissä, että sovelluksen migraatiot ja työntekijöiden konfiguraatio on päivitettävä yhdessä, jotta web-sivu ei peitä rikkinäistä hälytysten toimitusta. Ota ehdokasversio käyttöön palautettua kopiota vasten ja toista tunnettu testi. Jos cron-työt pingittävät sisäistä URL-osoitetta tai sähköpostityöntekijät eivät ole käynnissä, etsi muuttunut oletus runtime-lokeista ja todellisesta verkkopyynnöstä.

Valitse Healthchecksin luottamusraja

Sulje bootstrap-ikkuna heti, kun ensimmäinen luotettu ylläpitäjä on luotu. Healthchecksin konkreettinen sudenkuoppa on jokaisella uudelleenkäynnistyksellä vaihtuva generoitu salaisuus; turvallisempi rajaus on käyttää pysyvää SECRET_KEY:tä, rajoittaa projektien jäsenyyttä ja käsitellä ping-URL-osoitteita tunnistetietoina.

Luo SECRET_KEY kerran, pidä se Gitin ulkopuolella ja säilytä se palautusmanifestin kanssa, koska sen vaihtaminen voi mitätöidä salatun tai allekirjoitetun sovellustilan. Yksityisen verkon tulee välittää riippuvuuksien tunnistetiedot, ja Healthchecksin roolien tulee sallia vain pienin tarvittava toiminto. Älä tallenna arkaluonteisia pyyntörunkoja ja palveluntarjoajien vastauksia tavallisiin lokeihin.

Dockup-käyttöönotto tarvitsee edelleen Healthchecksin hyväksymistestin

Dockup voi hallita korvattavia alustakomponentteja: reitittää liikenteen porttiin 8000, myöntää verkkotunnuksen ja sertifikaatin, välittää salaisuudet, liittää pysyvän tallennustilan ja yhdistää Healthchecksin hallittuihin tai yksityisesti liitettyihin palveluihin. Tämä voidaan tehdä Dockup-infrastruktuurissa tai liittämässäsi palvelimessa.

Healthchecksin hyväksymistyö on edelleen määriteltävä erikseen. Määritä yhden napsautuksen käyttöönoton jälkeen SITE_ROOT ja ALLOWED_HOSTS ulkoiseen HTTPS-osoitteeseen, yhdistä ja testaa Postgres sekä tuotantohälytyksiä varten toimiva sähköpostin toimitus ja suorita tämä skenaario: lähetä testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jätä sitten ajastettu ping lähettämättä ja varmista, että saat puuttuvan työn hälytyksen. Tämä jako on tarkoituksellinen: Dockup poistaa toistuvan infrastruktuurin määritystyön ilman teeskentelyä, että sovelluksen roolit, palveluntarjoajien tunnistetiedot tai palautuskäytäntö valikoituisivat itsestään.

Usein kysytyt kysymykset

Mitä Healthchecks tarvitsee tuotantokäyttöönottoon?

Reititä Healthchecksin kontti portissa 8000 yhden HTTPS-alkuperän kautta. Verkkotason tukivaatimuksia ovat Postgres ja tuotantohälytyksiä varten toimiva sähköpostin toimitus. Älä merkitse Healthchecksiä valmiiksi ennen kuin voit lähettää testi­työstä aloitus-, onnistumis- ja epäonnistumis­pingit, jättää sitten ajastetun pingin lähettämättä ja vastaanottaa puuttuvan työn hälytyksen.

Mitkä Healthchecksin tiedot kuuluvat varmuuskopioon?

Healthchecksin vakioimage ei tarvitse sovellustietojen mounttausta. Säilytä käyttöönoton konfiguraatio ja varmuuskopioi kaikki siihen yhdistetty tila erikseen; palautus onnistuu, kun tarkistukset, aikataulut, integraatiot ja ping-avaimet ovat palautuneet ja tarkoituksella lähettämättä jätetty ping nostaa odotetun hälytyksen.

Tarvitseeko Healthchecks HTTPS:n reverse proxyn takana?

Käytä julkisessa Healthchecksin alkuperässä HTTPS:ää ja pidä portti 8000 sisäisessä reitissä. Määritä Healthchecksin asetus oikein: aseta SITE_ROOT ja ALLOWED_HOSTS ulkoiseen HTTPS-osoitteeseen. Healthchecksin tapauksessa HTTPS suojaa tunnistetietoja tai käyttäjäsisältöä siirron aikana ja pitää alkuperästä riippuvan asiakaskäyttäytymisen yhdenmukaisena.

Miten Healthchecksin päivitys pitäisi testata?

Palauta nykyinen Healthchecksin tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksymistesti. Kiinnitä erityistä huomiota siihen, että sovelluksen migraatiot ja työntekijöiden konfiguraatio on päivitettävä yhdessä, jotta web-sivu ei peitä rikkinäistä hälytysten toimitusta. Säilytä edellinen Healthchecks-image, kunnes sen datamigraation ja palautuksen rajat ovat selvillä.