A Wallos önálló üzemeltetése 2026-ban: megújítások, értesítések és SQLite

A legtöbb Wallos-telepítési útmutató az első oldalbetöltésnél véget ér. Ez túl korai: a megújítási dátumok eltolódhatnak, ha hibás a TZ, vagy ha az SQLite könyvtára csak olvasható. A hasznos éles környezeti teszt ennél szigorúbb — hozz létre előfizetéseket különböző számlázási ciklusokkal, állítsd be a megújítási dátumokat, futtasd le az értesítési folyamatot, majd ellenőrizd az összegeket a kiválasztott pénznemben.

A Wallos szerepe egyszerű: előfizetéskövető megújítási dátumokkal és értesítésekkel. Az üzemeltetési hatóköre túlmutat a webes folyamaton, ezért a függőségeket, a tárolt állapotot és a nyilvános elérési útvonalat még a valódi adatok megérkezése előtt egyértelműen meg kell nevezni.

Térképezd fel a Wallost a Docker használata előtt

A Wallos esetében különíts el négy területet: a bejövő forgalmat, a 80-as porton figyelő listenert, a tartós állapotot, valamint a támogató szolgáltatásokat vagy a helyi kapacitást. A helyi runtime-követelmény a tartós adatbázis- és logófeltöltési könyvtárak, valamint az értesítések kézbesítése. Ezt az erőforrást a konténerrel együtt méretezd és monitorozd, ahelyett hogy egy nem kapcsolódó hálózati szolgáltatást tennél ki.

Futtasd le az ismert, működő tranzakciót — hozz létre előfizetéseket különböző számlázási ciklusokkal, állítsd be a megújítási dátumokat, futtasd le az értesítési folyamatot, majd ellenőrizd az összegeket a kiválasztott pénznemben — mielőtt lezártnak tekintenéd ezt a szétválasztást. Mérd az ütemezett értesítési feladatokat, a logótárolást, az SQLite-írásokat és az időzóna helyességét, majd az eredményt őrizd meg a deployment rekordjával együtt. Ez egyszerre biztosít elfogadási feltételt és az első kapacitásalapot.

Egészségesnek tűnő Wallos diagnosztizálása

A Wallos esetében ne egy folyamatot, hanem egy tranzakciót monitorozz: hozz létre előfizetéseket különböző számlázási ciklusokkal, állítsd be a megújítási dátumokat, futtasd le az értesítési folyamatot, majd ellenőrizd az összegeket a kiválasztott pénznemben. A késleltetést és a hibaarányt az ütemezett értesítési feladatokkal, a logótárolással, az SQLite-írásokkal és az időzóna helyességével együtt vizsgáld, hogy egy riasztás azonosítani tudja a korlátozott komponenst.

A frissítési próba során azt is le kell fedni, hogy a Wallos adatbázis-migrációit dátum- és pénznemadatokkal kell tesztelni a futó image cseréje előtt. Állítsd vissza az adatokat, futtasd le a migrációt, majd hajtsd végre a tranzakciót a production csere előtt. Ha a megújítási dátumok eltolódnak, mert hibás a TZ, vagy az SQLite könyvtára csak olvasható, ne töröld az adatokat azért, hogy a startup sikeresnek tűnjön; ebben a sorrendben hasonlítsd össze a verziót, a változókat, a mountokat és a függőségek elérhetőségét.

Alakítsd a Wallos smoke tesztjét release-ellenőrzéssé

A Wallos release-rekordjának tényeket kell tartalmaznia, nem azt, hogy „jónak tűnik”. Tárold a kiválasztott image digestjét, a konfiguráció ellenőrzőösszegét, a nyilvános hostname-et, valamint az időbélyeggel ellátott eredményt a következőkre: hozz létre előfizetéseket különböző számlázási ciklusokkal, állítsd be a megújítási dátumokat, futtasd le az értesítési folyamatot, majd ellenőrizd az összegeket a kiválasztott pénznemben. Nem production célú mintaadatokat használj, hogy az ellenőrzés minden deployment után lefuttatható legyen.

Bizonyíts külön két életciklus-eseményt. A konténer cseréjének meg kell őriznie a normál működést; a tiszta helyreállításnak pedig azt kell mutatnia, hogy az előfizetések, a kategóriák, a logók és az értesítési beállítások változatlan megújítási dátumokkal térnek vissza. A tesztek futása közben mérd az ütemezett értesítési feladatokat, a logótárolást, az SQLite-írásokat és az időzóna helyességét, majd őrizd meg az eredményt az adott verzióhoz elvárt keretként.

Tesztelj egy megtagadott vagy érvénytelen állapotot is: küldj ártalmatlan bemenetet az ehhez a határhoz kapcsolódó erőforrás- vagy formátumkorlát közelében: a megújítási dátumok eltolódnak, mert hibás a TZ, vagy az SQLite könyvtára csak olvasható. A Wallosnak diagnosztizálható módon kell hibáznia, és nem írhatja felül az egészséges állapotot. Állítsd vissza az érvényes állapotot, futtasd újra a mintát, és csatold a releváns, érzékeny adatoktól megtisztított logokat. Ezek az artefaktumok konkrét bizonyítékot adnak egy későbbi rollback-döntéshez.

Tedd reprodukálhatóvá a Wallos indítását

Egy production jellegű indítás szándékosan unalmas: névvel ellátott állapot, explicit port és az image-ben tárolt titkok nélkül.

docker run -d \
  --name wallos \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallos-data:/var/www/html/db \
  -e TZ=UTC \
  bellamy/wallos:latest

A példa alapkonfiguráció, nem teljes támogató stack. A kitettség előtt erősítsd meg a helyi követelményt: tartós adatbázis- és logófeltöltési könyvtárak, valamint az értesítések kézbesítése. Ellenőrizd a tényleges mountokat és a listenert, majd próbálj meg előfizetéseket létrehozni különböző számlázási ciklusokkal, állítsd be a megújítási dátumokat, futtasd le az értesítési folyamatot, és ellenőrizd az összegeket a kiválasztott pénznemben. A következő újraindítás előtt rögzítsd a működő image-et.

Találd meg a Wallos minden tartós adatát

Készíts leltárt minden tartós artefaktumról: az előfizetési adatbázisról, a feltöltött logókról és az értesítési beállításokról. A bootstrap előtt mountold a /var/www/html/db útvonalat, írj bele ártalmatlan mintaadatokat, majd cseréld le a konténert annak bizonyítására, hogy az útvonal valóban tartós. A tárolt adatok értelmezését módosító konfigurációt is vedd fel, ne csak a legnagyobb könyvtárat.

Állíts be megőrzési szabályokat, másold a biztonsági mentéseket a hoston kívülre, és futtass tiszta környezetben végzett visszaállítást. A Wallos-helyreállítás akkor tekinthető sikeresnek, ha az előfizetések, a kategóriák, a logók és az értesítési beállítások változatlan megújítási dátumokkal térnek vissza. Ha a terv részei a snapshotok, használd a PITR és snapshotok összehasonlításáról szóló útmutatót annak dokumentálására, hogy az egyes mechanizmusok mit képesek helyreállítani.

Adj a Wallosnak egyetlen kanonikus címet

A TLS kibocsátása csak a Wallos elérési útvonalának egyik fele. Szolgáld ki az alkalmazást HTTPS-en, és állítsd be az időzónáját. A forgalmat belsőleg a 80-as portra küldd, a külső sémát pedig továbbítsd, hogy a generált URL-ek és a secure cookie-k következetesek maradjanak.

A teljes Wallos-szcenáriót tiszta hálózatról teszteld, ne csupán a gyökéroldalt. Az 502-es vagy tanúsítványhiba elkülönítésében segíthet az automatikus domain- és TLS-beállítás. Ha a forgalom eléri a folyamatot, a megújítási dátumok pedig azért tolódnak el, mert hibás a TZ, vagy az SQLite könyvtára csak olvasható, ott diagnosztizáld a problémát, ahol jelentkezik, ahelyett hogy újabb redirecteket építenél egymásra.

Védd a Wallos értékes részét

Az első bejelentkezés után ellenőrizd, hogy egy anonim látogató, egy normál felhasználó és egy adminisztrátor pontosan mire képes. A Wallos esetében azt kell elkerülni, hogy az első fiók gyenge maradjon egy internet felől elérhető példányon. A kívánt szabályzat szerint a fiókot védeni kell, az értesítési tokeneket titokban kell tartani, a TZ-t pedig explicit módon kell beállítani, hogy a megújítások ne tolódjanak el.

A TZ a működést, nem pedig a bizalmasságot szabályozza; ellenőrizd a típusát és az értékét, a valódi Wallos-hitelesítő adatokat pedig külön tárold. A függőségekhez tartozó fiókokat válaszd külön az emberi felhasználói fiókoktól, ahol lehetséges, tiltsd le a nem használt kimenő forgalmat, és korlátozd az ütemezett értesítési feladatok, a logótárolás, az SQLite-írások és az időzóna helyessége által befolyásolt munkát.

Ahol a Dockup csökkenti a Wallosszal kapcsolatos munkát

Egy Dockup-sablonnak kódolnia kell az image-et, a 80-as portot, a mountokat, a health timing beállításait, a domaint, a TLS-t és a titkok átadását. A Dockupnak meg kell őriznie a Wallos runtime-beállításait, miközben az üzemeltető megerősíti ezt a helyi követelményt: tartós adatbázis- és logófeltöltési könyvtárak, valamint az értesítések kézbesítése. Ugyanaz a deployment célozhat Dockup-szervereket vagy ügyfél által csatlakoztatott kapacitást.

Miután az útvonal működik, alkalmazd a nyilvános beállítást, majd próbálj meg előfizetéseket létrehozni különböző számlázási ciklusokkal, állítsd be a megújítási dátumokat, futtasd le az értesítési folyamatot, és ellenőrizd az összegeket a kiválasztott pénznemben. Készíts biztonsági mentést az előfizetési adatbázisról, a feltöltött logókról és az értesítési beállításokról, és tartsd meg a visszaállítási gyakorlatot az üzemeltetési tervben; ezek olyan Wallos-feladatok, amelyek az infrastruktúra provisioningje után is láthatók maradnak.

Gyakran ismételt kérdések

Mire van szüksége a Wallosnak production deployment esetén?

A Wallos konténerét a 80-as porton keresztül, egyetlen HTTPS-origin mögött tedd elérhetővé. A helyi runtime-követelmény a tartós adatbázis- és logófeltöltési könyvtárak, valamint az értesítések kézbesítése. Ne tekintsd késznek a Wallost addig, amíg nem tudsz előfizetéseket létrehozni különböző számlázási ciklusokkal, megújítási dátumokat beállítani, lefuttatni az értesítési folyamatot és ellenőrizni az összegeket a kiválasztott pénznemben.

Mely Wallos-adatoknak kell szerepelniük a biztonsági mentésben?

Tartsd meg a /var/www/html/db tartalmát, és ugyanabban a recovery manifestben szerepeljen az előfizetési adatbázis, a feltöltött logók és az értesítési beállítások is. A tiszta Wallos-visszaállítás csak akkor sikeres, ha az előfizetések, a kategóriák, a logók és az értesítési beállítások változatlan megújítási dátumokkal térnek vissza.

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

A nyilvános Wallos-originhez használj HTTPS-t, a 80-as portot pedig hagyd meg a belső útvonalon. Helyesen alkalmazd a Wallos beállítását: HTTPS-en szolgáld ki az alkalmazást, és állítsd be az időzónáját. A Wallos esetében a HTTPS továbbítás közben védi a hitelesítő adatokat és a felhasználói tartalmakat, valamint következetesen tartja az originfüggő kliensoldali működést.

Hogyan kell tesztelni egy Wallos-frissítést?

Állítsd vissza az aktuális Wallos-állapotot egy izolált deploymentbe, alkalmazd a jelölt verziót, majd ismételd meg az elfogadási tranzakciót. Különösen figyelj arra, hogy a Wallos adatbázis-migrációit dátum- és pénznemadatokkal kell tesztelni a futó image cseréje előtt. Tartsd meg a korábbi Wallos-image-et addig, amíg nem érted pontosan az adat-migráció és a rollback határát.