A Fathom Lite saját üzemeltetése 2026-ban: tracking script, SQLite és adatvédelem

A „Fathom Lite futtatásának” két szintje van: létezik egy container, vagy a service ténylegesen elvégzi a feladatát. Csak a második számít. Ennek bizonyítéka, hogy hozzáadsz egy site-ot, betöltöd a tracking scriptet egy tesztoldalon, látogatásokat generálsz, majd ellenőrzöd, hogy a dashboard cookie-k nélkül rögzíti-e azokat.

A Fathom Lite erre való: cookie-k nélküli, saját üzemeltetésű page-view analytics. A deploymentnek meg kell őriznie az e működés mögött álló elemeket; egy port, egy volume és egy certificate csak bemenet, nem maga az eredmény.

Credentialök, szerepkörök és kitett felületek

A Fathom Lite esetében az értékes támadási felület nem feltétlenül a landing page. A leggyakoribb hiba egy példaértékű secret újrahasználata vagy az admin login TLS nélküli kitétele. Ezt tudatosan előzd meg: védd az analytics loginját, tartsd stabilan az application secretet, és a scriptet csak a várt HTTPS hostról tedd közzé.

A FATHOM_SECRET értékét a Fathom Lite-ban betöltött szerepe szerint kezeld: a sensitive értékeket tartsd távol a Gittől, dokumentáld a rotation hatásait, és productionben soha ne használj publikus példát. Használj unprivileged container usert, ha az image támogatja, és ne mountolj oda nem tartozó credentialöket. Az ingressnél alkalmazz rate- vagy size limiteket ott, ahol a nem megbízható forgalom page-view write rate-et, database indexeket, retentiont vagy a látogatók böngészőitől érkező network pathot terhelheti.

Válaszd külön a Fathom Lite-ot és a függőségeit

A legkisebb felelős Fathom Lite-topológia egyetlen, 8080-as private listenert, egy ingress route-ot és egy dokumentált state boundaryt tartalmaz. A Fathom Lite network contractja SQLite vagy egy támogatott external database, valamint a client-site script megfelelő elhelyezése. A private endpointokat tartsd internal DNS-en, csak a szükséges outbound hívásokat engedélyezd, és adj a Fathom Lite-nak korlátozott hatókörű service credentialt.

A topológiát úgy validáld, hogy egy tiszta clienttel hozzáadsz egy site-ot, betöltöd a tracking scriptet egy tesztoldalon, látogatásokat generálsz, majd ellenőrzöd, hogy a dashboard cookie-k nélkül rögzíti-e azokat. Működés közben figyeld a page-view write rate-et, a database indexeket, a retentiont és a látogatók böngészőitől érkező network pathot. Az eredmény megmutatja, hogy a következő fejlesztésnek a memoryt, a storage-ot, a networkinget vagy egy külön workert kell-e érintenie, ahelyett hogy tetszőleges container sizingra ösztönözne.

Docker-alap a Fathom Lite-hoz

Egy minimális parancs akkor hasznos, ha megmutatja, mit fog később kezelni a platform.

docker run -d \
  --name fathom-lite \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v fathom-lite-data:/app \
  -e FATHOM_SECRET=replace-with-a-long-random-value \
  -e FATHOM_SERVER_ADDR=:8080 \
  -e FATHOM_DATABASE_DRIVER=sqlite3 \
  -e FATHOM_DATABASE_NAME=/app/fathom.db \
  usefathom/fathom:latest

Itt a 8080-as port host-private marad, és minden szükséges path explicit módon szerepel. Add hozzá az SQLite-hoz vagy egy támogatott external database-hez áttekintett connection settingseket, valamint a client-site script megfelelő elhelyezését; a private service-ekhez használj private neveket. Az indulást a logokkal és az application-specific bizonyítékkal is ellenőrizd: adj hozzá egy site-ot, töltsd be a tracking scriptet egy tesztoldalon, generálj látogatásokat, majd ellenőrizd, hogy a dashboard cookie-k nélkül rögzíti-e azokat. A validálás után rögzítsd az image verzióját, hogy egy rutinszerű replacement ne változtassa meg észrevétlenül a működést.

Ellenőrizd a Fathom Lite deploymentet end to end

Hozz létre egy kicsi, eldobható Fathom Lite-fixture-t, és tartsd meg minden release-hez. A fixturenek a valódi workflow-t kell lefednie: site hozzáadása, a tracking script betöltése egy tesztoldalon, látogatások generálása, valamint annak ellenőrzése, hogy a dashboard cookie-k nélkül rögzíti-e azokat. Rögzítsd az image digestet, az external hostname-t, a dependency address-t és az elvárt eredményt, hogy egy későbbi operator ennek az útmutatónak az értelmezése nélkül is megismételhesse a tesztet.

Futtasd le a fixturet háromszor. Először használd a friss deploymentet. Másodszor cseréld le a containert a durable state módosítása nélkül. Harmadszor állítsd vissza a backupot egy üres környezetbe. A harmadik futás csak akkor sikeres, ha a site-ok, a userek és a korábbi page view-k visszatérnek, és a recovery után egy új tesztlátogatás is megjelenik. Minden futás közben rögzítsd a page-view write rate, a database indexek, a retention és a látogatók böngészőitől érkező network path körüli latencyt és erőforrás-használatot; ez lesz az alerting alapja egy tetszőleges CPU-százalék helyett.

Végül szándékosan teszteld a hibás útvonalat is: ideiglenesen vond meg a teszt identity hozzáférését az SQLite-hoz vagy egy támogatott external database-hez, illetve a client-site script megfelelő elhelyezéséhez. Ellenőrizd, hogy a Fathom Lite láthatóan hibázik-e anélkül, hogy corruptálná a state-et, majd állítsd vissza a helyes feltételt és ismételd meg a sikeres tranzakciót. A négy eredményt tartalmazó release record erősebb bizonyíték, mint egy dashboardról készült screenshot vagy egy egyszer lefuttatott curl válasz.

Tartsd külön a belső és külső URL-eket

A Fathom Lite public boundary-jének egyetlen canonical hostname-ből, automatikus TLS-ből és egy 8080-as internal targetből kell állnia. Állítsd be a server addresst és a tracking script által használt public HTTPS endpointot úgy, hogy a kliensek olyan címre térjenek vissza, amelyet a service felismer.

Ha az acceptance transaction sikertelen, sorold be az első hibát. A DNS-, certificate- és 502-problémák a TLS validation checklist hatókörébe tartoznak. Az az állapot, amikor „a tracking script rossz hostname-re mutat, vagy a database path ephemeral”, az application oldalához tartozik, miután a request sikeresen elérte a Fathom Lite-ot.

Hibagyakorlatok a Fathom Lite-hoz

A capacity teszteknek a page-view write rate-et, a database indexeket, a retentiont és a látogatók böngészőitől érkező network pathot kell terhelniük, nem pedig ismételten a / végpontra küldött kéréseket. Futtasd reális concurrency mellett ezt a scenariót: „adj hozzá egy site-ot, töltsd be a tracking scriptet egy tesztoldalon, generálj látogatásokat, majd ellenőrizd, hogy a dashboard cookie-k nélkül rögzíti-e azokat”, és rögzítsd a latencyt, az error rate-et, valamint a storage növekedését.

Az upgrade tervezésénél ezt a kockázatot is figyelembe kell venni: a Fathom adatbázis-sémáját és tracking scriptjét együtt kell tesztelni, hogy elkerüld az események észrevétlen elvesztését. Teszteld az új release-t reprezentatív inputtal, majd ismételd meg az acceptance transactiont és hasonlítsd össze az eredményt. Ha a tracking script rossz hostname-re mutat, vagy a database path ephemeral, rögzítsd a hibás tranzakciót, és vizsgáld meg az első érintett boundaryt ahelyett, hogy automatikusan az ingresst tennéd felelőssé.

Ellenőrizd, hogy a Fathom Lite túléli-e a cserét

Egy container image újra letölthető; az analytics database, a site-konfiguráció és az administrator state nem. A bootstrap előtt mountold az /app pathot, írj bele ártalmatlan mintaadatokat, majd cseréld le a containert annak bizonyítására, hogy a path valóban perzisztens. Az effective mountot vizsgáld, ne egy Compose-fájlnévben bízz, és ellenőrizd, hogy a runtime user írhat-e oda, ahol a Fathom Lite ezt elvárja.

Válassz retentiont és off-host destinationt, majd gyakorold a recoveryt a production érintése nélkül. A drill csak akkor sikeres, ha a site-ok, a userek és a korábbi page view-k visszatérnek, és a recovery után egy új tesztlátogatás is megjelenik. Database-backed state esetén a storage snapshotokat párosítsd application-consistent exportokkal a point-in-time recovery versus snapshots leírása szerint.

Illeszd a Fathom Lite-ot a Dockup életciklusába

A Dockup one-click Fathom Lite deploymentjének biztonságossá kell tennie a replacementet: a route továbbra is a 8080-as portra mutat, a secretek nem kerülnek bele az image-be, és a persistent pathok visszatérnek az új containerben. Ugyanez a deployment futhat Dockup compute-on vagy egy csatlakoztatott gépen.

Végezd el az app-specifikus lépéseket az SQLite vagy egy támogatott external database, valamint a client-site script megfelelő elhelyezésének beállításával és tesztelésével, alkalmazd a canonical public addresst, majd futtasd le ezt az acceptance checket: adj hozzá egy site-ot, töltsd be a tracking scriptet egy tesztoldalon, generálj látogatásokat, és ellenőrizd, hogy a dashboard cookie-k nélkül rögzíti-e azokat. A valódi userek érkezése előtt add hozzá a restore eredményét a runbookhoz.

Gyakran ismételt kérdések

Mire van szüksége a Fathom Lite-nak production deployment esetén?

A Fathom Lite containert a 8080-as porton keresztül, egyetlen HTTPS originen át route-old. A supporting network requirement az SQLite vagy egy támogatott external database, valamint a client-site script megfelelő elhelyezése. Ne tekintsd késznek a Fathom Lite-ot addig, amíg nem tudsz hozzáadni egy site-ot, betölteni a tracking scriptet egy tesztoldalon, látogatásokat generálni, és ellenőrizni, hogy a dashboard cookie-k nélkül rögzíti-e azokat.

Mely Fathom Lite-adatoknak kell szerepelniük a backupban?

Tedd perzisztenssé az /app pathot, és az analytics database-t, a site-konfigurációt, valamint az administrator state-et ugyanabba a recovery manifestbe foglald bele. Egy tiszta Fathom Lite-restore csak akkor sikeres, ha a site-ok, a userek és a korábbi page view-k visszatérnek, és a recovery után egy új tesztlátogatás is megjelenik.

Szüksége van a Fathom Lite-nak HTTPS-re reverse proxy mögött?

A public Fathom Lite originhez használj HTTPS-t, a 8080-as portot pedig tartsd az internal route-on. Helyesen alkalmazd a Fathom Lite beállítását: állítsd be a server addresst és a tracking script által használt public HTTPS endpointot. A Fathom Lite esetében a HTTPS védi a credentialöket és a user contentet az átvitel során, valamint konzisztenssé teszi az originérzékeny client viselkedést.

Hogyan kell tesztelni egy Fathom Lite-upgrade-et?

Állítsd vissza a jelenlegi Fathom Lite-state-et egy izolált deploymentbe, alkalmazd a candidate verziót, majd ismételd meg az acceptance transactiont. Fordíts különös figyelmet erre, mert a Fathom adatbázis-sémáját és tracking scriptjét együtt kell tesztelni az események észrevétlen elvesztésének elkerüléséhez. Tartsd meg az előző Fathom Lite image-et addig, amíg nem érted pontosan az adat-migration és a rollback boundaryjét.