A Wallabag saját üzemeltetése 2026-ban: importálás, adatbázis és háttérfeladatok
Gyakorlati útmutató a Wallabag saját üzemeltetéséhez Dockerrel, portokkal, perzisztens adatokkal, TLS-sel, biztonsággal, biztonsági mentésekkel és a production használatot akadályozó hibákkal. Ellenőrzési lépésekkel.
A legrövidebb Wallabag-demó azt bizonyítja, hogy egy process figyel a 80-as porton. A production környezethez ennél erősebb bizonyíték kell. Ezt a forgatókönyvet akkor is teljesítenie kell, ha a containert lecseréltük: mentsünk el egy szokásos cikket és egy problémás oldalt, futtassuk le a háttérben történő lekérést, szinkronizáljunk egy mobilklienst, majd keressünk az archivált tartalomban.
A Wallabagot egyértelmű célból telepítik: olyan read-it-later archívumként, amely eltávolítja az oldal zavaró elemeit. A leggyakoribb deployment-csapda az, hogy az assetek vagy a login redirectek HTTP-t használnak, mert hibás a domainváltozó. Ezért a publikus URL kezelésére és a tartós állapotra ugyanakkora figyelmet kell fordítani, mint az image indulására.
A lokális parancs alakítsuk ellenőrizhető szolgáltatássá
Az alábbi parancs láthatóvá teszi a container határát anélkül, hogy úgy tenne, mintha minden külső szolgáltatás provisionálását is elvégezné.
docker run -d \
--name wallabag \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v wallabag-data:/var/www/wallabag/data \
-e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
wallabag/wallabag:latest
Az ingress megnyitása előtt ellenőrizd a feloldott környezetet, a mountokat és a listenert. Add hozzá az átnézett kapcsolati beállításokat a Postgres vagy MariaDB, a Redis és az ütemezett import workerek számára; privát szolgáltatásokhoz használj privát neveket. A sikeres indulás akkor ér véget, amikor el tudsz menteni egy szokásos cikket és egy problémás oldalt, le tudod futtatni a háttérben történő lekérést, szinkronizálni tudsz egy mobilklienst és keresni tudsz az archivált tartalomban — nem akkor, amikor a docker ps az Up állapotot írja ki.
Mitől függ a Wallabag?
Rajzolj három határt a Wallabag köré: az ingresst a 80-as porthoz, a tartós állapotot és a támogató követelményeket. A container cserélhető, a másik két területhez viszont egyértelmű felelős kell. A Wallabag hálózati szerződésébe a Postgres vagy MariaDB, a Redis és az ütemezett import workerek tartoznak. A privát endpointokat tartsd belső DNS-en, csak a szükséges kimenő hívásokat engedélyezd, és adj a Wallabagnak korlátozott hatókörű service credentialt.
A diagram akkor teljes, amikor egy tiszta klienssel el lehet menteni egy szokásos cikket és egy problémás oldalt, le lehet futtatni a háttérben történő lekérést, szinkronizálni lehet egy mobilklienst és keresni lehet az archivált tartalomban. Rögzíts időzítési és erőforrásadatokat az oldallekéréshez, a parser munkájához, a képletöltésekhez, a queue-khoz és az adatbázis növekedéséhez. Ha a tranzakció sikertelen, az első dokumentáltan nem megfelelően működő határ megmutatja, hogy a routingot, a lokális kapacitást vagy egy támogató szolgáltatást kell-e vizsgálni.
A bootstrap után zárold a Wallabagot
Ne örököld meg egy lokális tutorial biztonsági feltételezéseit. A Wallabag sajátos kockázata az alapértelmezett credentialök meghagyása vagy a trusted proxy konfigurációjának kihagyása. Production környezetben ezért távolítsd el az alapértelmezett credentialöket, védd az import tokeneket, és a reader publikussá tétele előtt konfiguráld a trusted proxykat.
A SYMFONY__ENV__DOMAIN_NAME konfiguráció, nem secret; az értékét tartsd explicit módon megadva, miközben a Wallabag által használt külön credentialöket védd. Korlátozd a fájlrendszer- és hálózati hozzáférést, védd a setup endpointokat, és határozz meg upload-, request- vagy execution-limitet az oldallekéréshez, a parser munkájához, a képletöltésekhez, a queue-khoz és az adatbázis növekedéséhez.
Tedd egyértelművé a publikus origint
A Wallabagot egyetlen HTTPS-hostnéven tedd elérhetővé; a nyers 80-as port maradjon privát. A domainnevet állítsd be a végleges HTTPS-URL-re. Ezzel megakadályozod, hogy a böngészők és az API-kliensek két egymással versengő címet ismerjenek meg.
Egy tiszta klienssel futtasd le az ismert módon működő tranzakciót, és vizsgáld meg az első sikertelen requestet. Ha a DNS vagy a TLS hibás, használd a custom-domain útmutatót. Kezeld külön alkalmazásszintű diagnózisként azt az esetet, amikor „az assetek vagy a login redirectek HTTP-t használnak, mert hibás a domainváltozó”, miután az útvonal működését már igazoltad.
Válaszd külön a cserélhető containereket a tartós adatoktól
A tartós helyreállítási készlet az adatbázisból, az image-ekből, az importált tartalomból és a konfigurációból áll. A bootstrap előtt mountold a /var/www/wallabag/data útvonalat, írj bele ártalmatlan mintadatokat, majd cseréld le a containert annak bizonyítására, hogy az útvonal valóban perzisztens. A volume megvédi az adatokat a container lecserélésétől, de nem védi meg őket a host elvesztésétől, a véletlen törléstől vagy az alkalmazásszintű korrupciótól.
Olyan biztonsági mentéseket készíts, amelyek figyelembe veszik az adatforrást: szükség esetén használj logical dumpot futó adatbázisokhoz, és csak konzisztens állapotból másolj fájlokat. Tarts egy titkosított másolatot a Wallabag hostjától elkülönítve. A restore elfogadási feltétele konkrét: a cikkek, tagek, annotációk, felhasználók és API tokenek visszatérnek, a mobilkliens pedig szinkronizál. A restore-rel tesztelt biztonsági mentésekről szóló útmutató bemutatja, miért nem elegendő önmagában a job sikeres lefutása.
Milyen bizonyítékokat gyűjts a Wallabag élesítése előtt?
A Wallabaghoz már az indulás előtt határozz meg egy ismert módon működő tranzakciót: ments el egy szokásos cikket és egy problémás oldalt, futtasd le a háttérben történő lekérést, szinkronizálj egy mobilklienst, majd keress az archivált tartalomban. Az előfeltételeit, az elvárt választ és a cleanup-lépéseket secret értékek nélkül tedd verziókezelésbe. Rögzítsd az image-et, amellyel ezt a referenciát létrehozod.
A tranzakcióval ellenőrizd a cserét és egy független restore-t is. A visszaállított szolgáltatás csak akkor fogadható el, ha a cikkek, tagek, annotációk, felhasználók és API tokenek visszatérnek, a mobilkliens pedig szinkronizál. Ezzel egy időben figyeld az oldallekérést, a parser munkáját, a képletöltéseket, a queue-kat és az adatbázis növekedését, majd a leglassabb vagy leginkább korlátozott részből készíts service-level alertet.
A gate-nek negatív esetet is tartalmaznia kell: ideiglenesen vond meg a tesztidentitás hozzáférését a Postgreshez vagy MariaDB-hez, a Redishez és az ütemezett import workerekhez. Ellenőrizd, hogy a Wallabag értelmezhető hibát jelez, miközben megőrzi az adatokat, majd állítsd vissza a helyes állapotot, és ismételd meg az ismert módon működő tranzakciót. A két eredmény együttes megőrzésével nem válik egy felszínes health endpoint az egyetlen production-bizonyítékká.
A Wallabagot a valódi szűk keresztmetszetei köré építve üzemeltesd
A dashboardokat az oldallekérés, a parser munkája, a képletöltések, a queue-k és az adatbázis növekedése köré építsd. Egy workload-kontextus nélküli CPU-grafikon nem magyarázza meg, miért lassú a Wallabag. Adj hozzá egy synthetic vagy ütemezett ellenőrzést, amely ártalmatlan tesztadatokkal megpróbál elmenteni egy szokásos cikket és egy problémás oldalt, lefuttatni a háttérben történő lekérést, szinkronizálni egy mobilklienst és keresni az archivált tartalomban.
Upgrade előtt számolj ezzel az alkalmazásspecifikus kockázattal: a Wallabag migrationjeit, parser-viselkedését és worker-konfigurációját reprezentatív mentett oldalakkal kell tesztelni. Állíts vissza egy friss biztonsági mentést izolált deploymentbe, futtasd le ott a migrationöket, majd hasonlítsd össze a működést. Ha az assetek vagy a login redirectek HTTP-t használnak, mert hibás a domainváltozó, vizsgáld meg az érintett határt — a publikus origint, a storage-ot vagy a dependencyt — mielőtt nem kapcsolódó beállításokat módosítanál.
Használd a Dockupot a platformréteghez
A Wallabag esetében a Dockup létrehozhatja a route-ot és a TLS-tanúsítványt, megőrizheti a mountokat, kezelheti a secret értékeket, valamint privát hálózaton helyezheti el a Postgres vagy MariaDB, a Redis és az ütemezett import workerek szolgáltatásait, miközben a deployment történhet Dockupra vagy csatolt szerverekre.
A release gate továbbra is a konkrét Wallabag-tranzakció: ments el egy szokásos cikket és egy problémás oldalt, futtasd le a háttérben történő lekérést, szinkronizálj egy mobilklienst, majd keress az archivált tartalomban. Ellenőrizd a restore feltételét is: a cikkek, tagek, annotációk, felhasználók és API tokenek visszatérnek, a mobilkliens pedig szinkronizál. Ez a két ellenőrzés mutatja meg, hogy a deployment működik-e, és helyreállítható-e.
Gyakran ismételt kérdések
Mire van szüksége a Wallabagnak production deploymenthez?
A Wallabag containert a 80-as porton egyetlen HTTPS-origin mögött route-old. A támogató hálózati követelmény a Postgres vagy MariaDB, a Redis és az ütemezett import workerek elérhetősége. Ne tekintsd késznek a Wallabagot addig, amíg el nem tudsz menteni egy szokásos cikket és egy problémás oldalt, le nem tudod futtatni a háttérben történő lekérést, nem tudsz szinkronizálni egy mobilklienst, és nem tudsz keresni az archivált tartalomban.
Mely Wallabag-adatoknak kell szerepelniük a biztonsági mentésben?
Tedd perzisztenssé a /var/www/wallabag/data útvonalat, és ugyanabba a helyreállítási manifestbe foglald bele az adatbázist, az image-eket, az importált tartalmat és a konfigurációt is. A tiszta Wallabag-restore csak akkor sikeres, ha a cikkek, tagek, annotációk, felhasználók és API tokenek visszatérnek, a mobilkliens pedig szinkronizál.
Szüksége van a Wallabagnak HTTPS-re reverse proxy mögött?
A publikus Wallabag-originhez használj HTTPS-t, a 80-as port pedig maradjon a belső útvonalon. A Wallabag-beállítást megfelelően alkalmazd: a domainnevet állítsd be a végleges HTTPS-URL-re. A Wallabag esetében a HTTPS védi a credentialöket és a felhasználói tartalmat átvitel közben, valamint konzisztenssé teszi az originérzékeny kliensviselkedést.
Hogyan kell tesztelni egy Wallabag-upgrade-et?
Állítsd vissza az aktuális Wallabag-állapotot egy izolált deploymentbe, alkalmazd a jelölt verziót, majd ismételd meg az elfogadási tranzakciót. Fordíts különös figyelmet erre, mert a Wallabag migrationjeit, parser-viselkedését és worker-konfigurációját reprezentatív mentett oldalakkal kell tesztelni. Tartsd meg az előző Wallabag-image-et addig, amíg nem érted annak adatmigration- és rollback-határát.